This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Windows Desktops not updating with user accounts

We have a Server/Client environment with Sophos Endpoint Security and Control installed.  Most PC's are running a limited "user" account in a domain and almost everything seems to be working fine...but randomly, some clients won't update at all.

Trying to force an update from the Sophos Enterprise Console on the server doesn't do anything.  Also, manually right clicking and hitting "Update Now" won't fix the issue when logged in via a user account, but if I log in as an administrator, it WILL update the PC.

Is there a fix for this?  Do I have to remotely launch "C:\Program Files (x86)\Sophos\AutoUpdate\SophosUpdate.exe" as an administrator, or is there an easier way?



This thread was automatically locked due to age.
Parents
  • Hello Robert Neal,

    are you updating via UNC or HTTP?
    What is the error reported to the console when updating fails? In addition please check the ALUpdate log in %ProgramData%\SophosAutoUpdate\Logs\ - it should have a more detailed description and a records of all errors during an update cycle.
    Furthermore, once you "update as admin" - do the next automatic updates succeed then?

    Christian

  • Hi Christian,

    Thanks very much for your response.  To answer your questions:

    1) We're updating via HTTP.

    3) After I've logged in as an admin to run the update and reboot, the consoles appear to update themselves.

    2) The specific error I'm looking at is computers who's update status show "Not since..." in the Sophos Enterprise Console.  What's even more interesting is that some of these actually show "updated successfully" if you open the "computer details" window specific to that device.

     

     

    Is there a way to just force the client to update? 

  • Hello Robert Neal,

    seems like there are different issues.
    A required dependency is missing is an installation error - if there are any details they should be in the Sophos Anti-Virus [Major Install|Install] Log in %windir%\Temp\. Don't think it depends on the user logged in but maybe. Anyway please check the install log.
    The Not since in the status on console together with Updated successfully in the details suggests an endpoint-internal communication problem. While the endpoint does update (or at least claims to do so) it fails to send its correct status. The status is sent with the text SAV state observer received a status - while only 4k data a logged (the lines is broken into two) the SAV version info is at around 1k, tag <product-version> and it should be not too hard to find out whether it's the one actually on the endpoint. If the local GUI also shows the old version please check the version of SAVService.exe, in addition vvf.xml (like the service executable in the Sophos program directory) contains the VirusData Version in use. I've seen various infrastructure (i.e. endpoint-internal) communication issues but unfortunately all of the on machines not administered by us and I have not yet been successful in obtaining a complete set of logs. A re-install might or might not resolve the issue.

    You say that everything seems to be fine after you've logged in as an admin? You also said reboot so I'm not sure it's actually the login (that shouldn't make a difference anyway). Asked about UNC vs. HTTP as I at first thought it could be related actually to updating - but this doesn't seem to be the case (at least not for all endpoints).

    Christian

  • Yeah, it actually seems like there's a few different things going on.  I'm in charge of the project to get it all cleared up and it's really overwhelming.  It also seems that many updates require a reboot, which is sometimes extremely hard to schedule in 24/7 production environments.  I'll have to find a way to address that as well.  Overall, it's going to be a nightmare if I have to reinstall the client and reboot over a hundred PC's.

     

    To answer your response:

    "Sophos Anti-Virus [Major Install|Install] Log in %windir%\Temp\. Don't think it depends on the user logged in but maybe. Anyway please check the install log."

    I'll start digging into the logs tomorrow, but we have hundreds of computers and there's currently about 40 with "critical' Sophos issues.  While I'm really curious about the cause, I need to come up with a fix that can be pushed remotely ASAP.

     

    "The Not since in the status on console together with Updated successfully in the details suggests an endpoint-internal communication problem."

    In these cases, we'll have 10 - 150 PC's with Sophos installed and only a handful will have the issues.  They'll all be from the same OS image on the same PC hardware, under the same switch / networking environment.  

     

    "You say that everything seems to be fine after you've logged in as an admin?"

    No, I have to manually right click on the taskbar icon and hit "update" while logged in as administrator.  In the cases where there's an issue, if I do that as the user, it won't actually update.  Either way, the update isn't final until a reboot is performed.  I think in these cases, manually pushing an update scrip that's run as an administrator, then setting the PC to reboot after it's done would be the fix.

     

    Should I just open a ticket with Sophos support?

     

  • Hello Robert Neal,

    many updates require a reboot
    it's not an "immediate" requirement, especially on upgrades. Mainly it's because updated components can't come into action for already running processes. Basic AV functionality doesn't require a reboot - whether on an upgrade or an install.

    under the same switch
    it's not networking as the endpoints do send messages to the management server. By endpoint-internal I mean COM or .NET. In this case for example AutoUpdate informs the Agent of a successful update, the Agent in turn sends this information via the Router to the management server. The Anti-Virus component though fails to send its version information to the Agent for whatever reason - therefore the seemingly contradictory information in the console.
    Unfortunately (or rather fortunately) I have none of these issues on the approximately 1000 endpoints we (IT) fully manage, of the other several thousands managed by the respective departments (academic freedom) a few have issues of this kind. Furthermore the problem-endpoints pop up in only a few departments thus I assume it depends on how they are managed or perhaps certain software installed.

    manually pushing an update script
    shouldn't be necessary. Endpoints should automatically update as specified in the policy - unless the AutoUpdate service is stopped. It doesn't stop by itself though. If the service is stopped during a user session this breaks AFAIK the connection between it and ALMon.exe (that display the icon) and Update now fails (without a message) even if the service has been restarted. Logging off and on (whether as user or admin) establishes a connection provided the service is started (haven't tested lately but it seems that under certain circumstances it is started by some other component).
    Did you try to send an Update Computers Now request from the console?

    open a ticket
    Hm, let me put it this way - basic support will help you with the immediate issues (and reinstall or uninstall/reinstall might be among the suggested solutions) but likely not assess and address your processes and procedures. But this is just my personal view.

    Christian

  • Well, I think the most pragmatic way I can approach this is the following:

    1)  Use the uninstall / reinstall script I wrote to fix machines with anything that seems like it would be more than a few minutes to troubleshoot;  In about ten minutes, I can script a handful of computers to update overnight and should be fine in the morning.  While it might be a bit overkill, it will definitely fix the issue and any issues I run into will most likely be less effort to correct than manually logging into any of these PC's.

    2)  Find a way to fix the "No update since" error, preferably a silent solution I can push that won't require a reboot.

     

    That second one is pesky;  The PC's are actually updated and running fine, but shows up in both the Sophos console and our automatic ticketing system as "antivirus out of date".  I found one this morning with the issue and downloaded the entire C:\ProgramData\Sophos directory, which is the location all the logs seem to be stored in.  What exactly should I be looking for to try and find the answer?  I skimmed through the logs and couldn't find anything.

     

    Thanks again for your help!

  • Hello Robert Neal,

    the pragmatic solution should also help in case 2). I'm not sure that it can be fixed by easy to find method, and also a reinstall without a preceding complete uninstall won't help - otherwise the updates/upgrades should already have taken care of it.

    There's probably no error in the logs, but maybe they show the lack of communication. In the Agent logs (%ProgramData%\Sophos\Remote Management System\3\Agent\Logs\) you should find lines like 15.02.2018 03:08:23 0B20 I SAV state observer received a status: followed by the status XML. If they aren't there - well, then SAV doesn't talk to the Agent. Or, some 70 or 80 lines after the start of the agent service SAV state observer notified that SAV is running. Absence, presence, and contents of these lines might show what is happening - but not why.

    Christian

Reply
  • Hello Robert Neal,

    the pragmatic solution should also help in case 2). I'm not sure that it can be fixed by easy to find method, and also a reinstall without a preceding complete uninstall won't help - otherwise the updates/upgrades should already have taken care of it.

    There's probably no error in the logs, but maybe they show the lack of communication. In the Agent logs (%ProgramData%\Sophos\Remote Management System\3\Agent\Logs\) you should find lines like 15.02.2018 03:08:23 0B20 I SAV state observer received a status: followed by the status XML. If they aren't there - well, then SAV doesn't talk to the Agent. Or, some 70 or 80 lines after the start of the agent service SAV state observer notified that SAV is running. Absence, presence, and contents of these lines might show what is happening - but not why.

    Christian

Children
No Data