A Windows API call returned error 1909 [0x00000070]

Hello Faisal,

this is strange as the accounts mentioned are apparently the local SophosSAU accounts created by the installer (with User cannot change password and Password never expires set). Does this affect all endpoints and when did this start?

the account in local machines its not locked
As only AutoUpdate uses this account and should "know" the correct password I can't see why the lockout should occur in the first place. The lockout time is set with the Account Security Policy (minimum one minute) so they might get unlocked automatically.
AFAIK AutoUpdate nevertheless tries to make the connection and updates should succeed if there is no other issue. Are the endpoints shown as up to date in the Console? 

Christian

Hello QC,

Regarding the endpoints update, please find attached screen shoot.

Regards

Faisal

The local machine account (SophosSAU...) is created by the AutoUpdate installer.  

Note: You can follows this procedure:

https://community.sophos.com/kb/en-us/48910

...if you want to use your own account.  I'm not suggesting this as a fix but knowledge of this maybe useful for troubleshooting as at least you'd have control over the account/password etc..

The local account is used by the update process (alupdate.exe) to be able to "see" the network as the process is running as SYSTEM.  It then goes on to perform the download from the server using the updating account specified in the updating policy.

Maybe QC can confirm; as I'm sure he has at least one client using HTTP updating and I only have a Mac available to me at the moment, that if you enable auditing of account logon events at the client, with HTTP updating, the SophosSAU account is not used.  For a client which is performing UNC updating, I assume you see the auditing event for the sophossau account.  This could prove if it's not used with HTTP vs UNC.

Regards,

Jak

Thanks Jak,

Using the link you provided with "http" has solved my issue. My one last question is about the security. Is it secure to use this way or unsafe ? 

Thanks

Regards

Faisal

Any advise for this issue ?

Regards

Faisal

Hello Jak and Faisal,

Correct, contrary to the SophosSAU article (It checks if the machine can connect to resources via UNC or HTTP) the impersonation account is only used for UNC connections.
As said, the 1909 should be preceded by some other error but as only the last one during an update is reported to the console the local AutoUpdate log must be checked. Also I still can't see why the update should sometimes work and sometimes not.

Hmm, in your first screenshot I see that the SophosSAU account and computer names don't always match. Have the machines been renamed or do you have machines which have been cloned from an image?

Christian

Hello Faisal,

the Download failed errors are usually transient (i.e. a subsequent download/update succeeds)
Could not find a source might be transient as well (happens for example when an endpoint tries to update when the network connection is not yet established)
I have a few endpoints that report the correct update location but updating fails with no update source. Have not yet determined the actual cause, a reinstall might fix this
Finally the Failed to install - you'd have to check the Sophos Anti-Virus logs (Install, Uninstall, MajorActions) in \Windows\Temp\ on the endpoint

Christian

Hello QC,

All the machines were working fine earlier but recently this issue has started. I am also surprised and confused why the machines are getting successful updates and then failing. 

I will provide you the local log shortly so that can help us to dig down the root cause :)

Regards

Faisal

Hi QC and Jak,

Why there's an error "Differs from policy" with some of the machines ? Any idea.

Regards.

Faisal

Hello Jak,

Is there any procedure to set IIS as https rather than http for security ?

Thanks for your best support.

Regards

Faisal

I don't believe that version of SAU supports HTTPS at least from a non Sophos update location.  I know that the Sophos Central AutoUpdate client can pull files using HTTPS.

That said, the files being downloaded over that channel are just Sophos files.  Unless you put your own custom files in the CID (configcid.exe [https://community.sophos.com/kb/en-us/13112] would need to be used), then you're only downloading.  SUM on the server is pulling the same set of files using HTTP also.

There is no chance of tampering with the files as they all have content derived names and signatures are used.

As for differs from policy, which component differs?  This article is a good starting point: https://community.sophos.com/kb/en-us/113069

Regards,

Jak

Hi Jak / QC,

Having an issue with some machines as below screen shoot. Also the way http has started generating the traffic on network as we are using QRadar for log monitoring there we can see that Sophos is using "user" account and Authentication failures messages being generated :( . Any tip to resolve this issue ?

Regards

Faisal

Hi Jak / QC,

Having an issue with some machines as below screen shoot. Also the way http has started generating the traffic on network as we are using QRadar for log monitoring there we can see that Sophos is using "user" account and Authentication failures messages being generated :( . Any tip to resolve this issue ?

Regards

Faisal

Given the screenshot, there are potentially a number of issues.

The "Not since x" updating messages, these could be fine, without seeing the connected state of the endpoint or last message time it's hard to say if these are OK.

There are a number of errors of course but I can't see the details.  You might have to focus on one error/computer initially.

As for the QRadar log monitoring, which user account are you seeing issue with?  The local sophossau account or the account defined in the updating policy?

Hello Jak,

The screenshot I've sent you is of connected state machines.

In QRadar its showing as following.

Regards

Faisal

The referenced account SophosSAUPxyz presumably has been altered by you to obscure the machine name or part of it?

Based on the machine name or part of it, can you check that that computer has received the updating policy and is now using a HTTP path?

Could it be that the one (or more?) clients which are causing the alerts in QRadar just haven't received the updating policy?

The connected state for a computer in SEC, should be maintained (RMS issues) aside by the Sophos Management Service as per this article:
https://community.sophos.com/kb/en-us/113293

There is also a last message time column in SEC just to confirm that it is indeed messaging in.  The last message time will be updated when either an event takes place or when there is a status message.  A status happens at Sophos Agent startup and when a managed component changes in some way.  An ide update for example would cause a new status message. 

I just want to be sure that these computer are messaging.

For a computer that is showing as Not since, can you check that under: \program files (x86)\sophos\sophos anti-virus\ there is a recent .ide file.  This would prove that the client is updating and is in sync with the distribution point it is updating from.  There are install logs under \windows\temp\ also for Sophos.

Beyond that, I'd probably check the RMS logs (Agent and Router) to see that Status messages are being sent to the management server.

Regards,

Jak

Dear Jak,

Here's the screenshot of the IDE file. Why this is not generating the updated IDE file ? The path is also Program Files.

Regards

Faisal

I guess it's a 32-bit computer.  OK, so it's not updating.  The next thing would be to check the alupdate log file.

https://community.sophos.com/kb/en-us/36262#ALUpdate.log

To trim thing down, you could rename the current one to "get it out of the way", then force an update now and wait for it to finish.  This way the new alupdate log file will just contain the last update.

Dear Jak,

You mean to rename "ALUpdate.log" from the Location: 32-bit - C:\Program Files\Sophos\AutoUpdate\Logs\ALUpdate.log and 64-bit - C:\Program Files (x86)\Sophos\AutoUpdate\Logs\Alupdate.log

Regards.

I didn't realise that the kba was out of date.  I believe all versions of AutoUpdate now write their logs to:

\programdata\sophos\autoupdate\logs\

Regards,

Jak

the kba was out of date
I've at least twice submitted a Helpful no with a detailed comment in the hope it'll be amended ...

Christian

Hello QC,

Really appreciated your quick response to my posts. I am just new to Sophos and assigned to fine tune the issues in running environment. I've submitted the max as of my understanding :) What exactly is required please assist me so I will provide the needful to drill down the issue at grass root level.

Regards. 

For a computer that isn't showing as up to date then either:

1. The messaging system (RMS) isn't working, i.e. the client is not reporting in the status of SAV.

I believe we have ruled this out to some extent as you say the computer is "Connected" in SEC, so we know it must have sent a message in withing at least 24 hours + the offset of the management service running its job once every 24 hours depending on when it started.  So sometime between 24 and 48 hours.  SEC shows the last message time of each computer so you can check that.
Now there is a chance that the RMS system doesn't have the SAVAdapter referenced/loaded so although it is sending in status messages there is nothing from the SAV component.

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sophos\Remote Management System\ManagementAgent\Adapters\SAV\
DLLPath should point at savadapter.dll so the Sophos Agent service can load the DLL in question.  This is pretty edge case and not the first check but for completeness I have mentioned it.

The latest Sophos Agent log (\ProgramData\Sophos\Remote Management System\3\Agent\Logs\) file can prove all of this.

2. RMS is working, but then AutoUpdate is either:
1. Failing to download files from the distribution point/CID.  Note: We didn't check the cache (\ProgramData\Sophos\AutoUpdate\Cache\) AutoUpdate uses, only the install directory.
2. Failing to install the updates.  We know that the client is not getting the latest updated IDEs so it could be failing to install the update.  Logs are under \windows\temp\
3. AutoUpdate isn't installed at all.  Again unlikely.

The alupdate log file from an out of date computer will help prove the above.