Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 38 replies
  • Subscribers 3 subscribers
  • Views 67636 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

A Windows API call returned error 1909 [0x00000070]

KAR AAR

 Hi Experts :) ,

 

I am facing an issue with the following ESC. We have Windows 7 and 10 OS installed in our environment. Below is the error I am getting.

Actually the Update is failing with the below error, and sometimes it updates successfully but next moment if I check it says Failed and the reason shows account locked. Whereas I've also checked the account in local machines its not locked. 

Would highly appreciative if I get quick response and support in solving this issue.

 

Please find error attached.

 

Thanks

Best Regards

Faisal



This thread was automatically locked due to age.
Parents
  • 0

    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

  • 0 in reply to QC

    Hello QC,

     

    Regarding the endpoints update, please find attached screen shoot.

    Regards

    Faisal

  • 0 in reply to KAR AAR

    When you say the account is locked out, can you confirm that this is the case for the locally created account, i.e. the sophossau... one?

     

Reply Children
  • 0 in reply to jak

    Hello Jak,

    How to confirm, if this is the case for default / system created acct ? Also see the log of one of the PC for example.

     

    Regards

    Faisal

  • 0 in reply to KAR AAR

    Hello Faisal,

    How to confirm
    Start → Computer, right-click → Manage, Local Users and Groups → Users → click the SophosSAU... user.

    Christian

  • 0 in reply to QC

    Hello QC,

    This is what I know but how to check whether its the same account is locking or some other is getting locked. 

    The issue is why its getting locked and then itself getting active.

    Regards

    Faisal

  • 0 in reply to KAR AAR

    Hello Faisal,

    why it's getting locked
    that's the puzzling part. AutoUpdate either has the correct password or not. In the latter case it should report the 1909 (or a 1326 - incorrect password) for every update attempt.

    It looks like an account lockout policy is in effect with a finite lockout duration that causes the accounts to get unlocked. This does not explain what gets them locked though. By default workstations don't audit failures, if failure auditing is turned on the Security Event Log should show which process is responsible.

    Christian 

  • 0 in reply to QC

    What is the default time set for account locked out ? Is there any policy in Sophos for this settings?

    What's the best practice for signature update time in workstations? Should this be every an hour or twice a day ?

    What's the fastest solution to resolve this issue ?

     

    Regards

    Faisal

  • +1 in reply to KAR AAR

     will probably provide you with a fuller answer.  I'm currently on holiday and only have a Mac.

    One thing that *might* help, and could be a quick fix would be to setup a web cid - https://community.sophos.com/kb/en-us/38238. There is a chance that the local sophossau account is only used for UNC updating.  If the clients were using HTTP the issue could just go away.  Might be worth a quick try. Should only take 10 minutes to try.

    If this did "fix" it, it would at least buy you some time for troubleshooting on maybe a single client using UNC.

    For what it's worth, the Sophos Central client, which uses Sophos AutoUpdate XG, doesn't even create a local account.  So if you were to switch to Sophos Central this issue would also be removed.

    Regards,

    Jak

  • 0 in reply to KAR AAR

    Hello Faisal,

    any policy in Sophos
    no, account lockout is a Windows setting and as said, I don't see how AutoUpdate could cause this behaviour. Could you show the errors in the updating log from an endpoint (local Sophos GUI → View updating log) starting at the end of a successful update like this:

    Christian

  • 0 in reply to jak

    ++Jak

    In this case I suspect all the update traffic will route to internet, I can't use the internet for big number of machines.

    Please correct me if I am wrong.

    Regards

    Faisal

  • 0 in reply to KAR AAR

    No, you can get the clients to update from your server but rather than using UNC, they can use HTTP.

    So if you have say a single management server, this is maintaining a CID/Distribution point.  If you add the IIS role (you could use any web server), you can share the CID/Distribution point out using that.  The KBA details IIS.

    The clients can then use http://server rather than \\server\ for example.

    Regards,

    Jak

  • 0 in reply to QC

    QC,

    How to know from the console about the machine account? used for update ? i.e.

    Regards

    Faisal

Unfiltered HTML