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

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

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

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.

Hello Faisal,

been thrown in at the deep end, haven't we?
One thing: The subject of this thread doesn't resemble the issues you're working on right now. Please use individual threads for the various issues. And it's perhaps, as Jak has said,  better to work through one issue at a time until you have a better understanding of how it all works together, which issues are related (and have perhaps a common cause) and which not. For example the message in which you mentioned QRadar first has a screenshot of the Status view: It's not clear which row corresponds to the QRadar message in a subsequent post - it's better to start with the QRadar message, check if the error is reflected in this endpoint's details in the console and proceed from there.

Christian

Hello QC,

Yes I agree with you and Jak's point. Lets work on issue by issue :)

Regards.