Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 20448 views
  • Users 0 members are here
Options
Suggested
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

Sophos AutoUpdate issue

Techplay27

Hi all,

Recently changed password in our environment for the Sophos Protection.

Since doing that and sending out the new password to all machines, only a few have managed to update without issue.

Now we are getting a lot of locked out account errors, once the service account is unlocked my machine updates and downloads the packages, but when another machine that I use as well, that just errors after 3 download package attempts, I've looked at the log file and have pinpointed these errors below.

Any ideas what the issue is and how I can go about resolving this other than doing a fresh install on the server?

Folder is being shared with new service account and password. (not advanced sharing-should I configure to this?)

I've looked at some previous discussions on this forum, but a lot have been due to errors not affecting my environment

Error -2147217660 in ReadCustomerIDFile
SAUControlConfigParser:: Caught runtime_error exception: SAUControl config is not available
InstallSequencer:: Caught runtime_error exception: Invalid cache path.
<ErrorMessage><ID>CIDDownloadFailed</ID><StringID>107</StringID><Sender>CIDUpdate</Sender><Insert>Sophos AutoUpdate</Insert><Insert>\\servername\SophosUpdate\CIDs\S000\SAVSCFXP\</Insert></ErrorMessage><ReadableMessage>
Trace(2021-Sep-02 18:22:32): CIDUpdate(Info): Could not add a connection to server \\servername\SophosUpdate; user domain\SophosUD612; Windows error 1909
Trace(2021-Sep-02 18:22:33): CIDUpdateLocation::SyncProduct: Failed to update product (RMSNT) from "\\servername\SophosUpdate\CIDs\S000\SAVSCFXP\", Error is :CIDSYNC_E_SRCNOTFOUND (Source not found.)



This thread was automatically locked due to age.
  • 0

    Well 1909 = ERROR_ACCOUNT_LOCKED_OUT

    I would suggest creating a new updating account (only needs read access to the share \\servername\SophosUpdate) and then update the updating policies in SEC to use that.  The clients that have the old username will get the new one over RMS as that channel should be unaffected but it could take quite some time to catch them all if machines are offline for a couple of weeks for example.

    Over time, when all the clients have the new policy, they will show as same as policy in SEC for the updating policy you can remove the old account.

  • 0 in reply to Sophos User930

    Do you think when making such changes such as this, we need to ensure all machines are in the office and all on the network and then we can force the updating policy? I fear we will catch the suspecting machines because they are online and flagging of locking the account, but any we can't see can cause this issue again. I suppose if we limit it to just one machine flagging as locking the account out then we can just update to that and then we are good. We haven't got too many laptops so suppose that is a saving grace, if we had quite a few this would be quite an issue no?

    Or am I overthinking it?

  • +1 in reply to Techplay27

    When you make the change to the updating policies, the management server will queue up the config messages for the clients.  They should pick it up next time they come on-line.  That said, I might suggest following this article: Service and Support (sophos.com) to create MessagingSetConfigurationTimeout.  Maybe configure it for 2 weeks.  This will ensure the config messages you generate when you update the policy persist on the server for longer.  This will save having to either make changes every 4 days or manually force a policy compliance.  I would monitor the updating column on the computer list view to check the policy compliance state over time.

  • 0 in reply to Sophos User930

    I see ok, thanks.

    One other thing, ummm when that service account was being locked out and then I had unlocked it, I then went onto targeted machine and clicked on update policy, this brought up a prompt showing a progress bar of not connecting to server, but also the packages downloaded upto 3 and then it failed. To add on my machine when I did the same thing it worked fine.

    Since creating this account, it progressed even further, so confused why that is the case?

    I am re-building/pxe booting a laptop to see that the new information we have added to SCCM is present in the log file, prior to creating a new account, even though the account details were specified, they were not reflecting in the targeted machine's log file. 

    I would think it should have.

    Update on the reimaged laptop the Sophos password is not updating as to what was specified.

    Same thing happens again, where I try to update Sophos manually on the target machine, a progress prompt appears, shows no connection to server, but then 3 download packages appear to do so, and then it just vanishes and fails. New account now gets locked out.

  • 0 in reply to Techplay27

    The credentials defined in policy should end up in the file:
    \ProgramData\Sophos\AutoUpdate\Config\iconn.cfg
    This is the file AutoUpdate gets the username/password from.

    If you want to share the alupdate.log of an particular scenario that fails I can take a look.  You can always delete the current one and call update now to reduce the size.  The UI progress bar can be a bit confusing at times.

    The new Sophos Central managed client removes all of this should you be thinking of moving to the cloud managed version.

Unfiltered HTML