There was a problem while establishing a connection to the server. Details: LogonUser ("SophosSAUTHSERVERANMEaaa",".",...) failed A Windows API call returned error 1450. Code 00000070

You mention endpoints but then also mention restarting servers.

From the message I assume that the API call LogonServer (
https://msdn.microsoft.com/en-gb/library/windows/desktop/aa378184(v=vs.85).aspx) is being called to logon this local user account: SophosSAUTHSERVERANMEaaa.

This local account is only used for UNC updating.  One workaround would therefore be to setup HTTP updating.  Not great but it would work.

Back to the issue... The API LogonServer is presumably failing and calling GetLastError as documented to find out why (https://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx)  is returning error 1450.  I assume it is always this code?

This translates to:
"Insufficient system resources exist to complete the requested service."

So there is some sort of resource depletion causing this.

Can you confirm the OS of the computers that are reporting the error?

Regards,
Jak

It is really hit and miss with this error.

Sometimes from the SEC "Update Computer" it works.

Sometime if I logon to the server with my domain admin account and then  from the SEC "Update Computer" it works.

Sometime if I logon to the server with my domain admin account and then select "Update Now" from the S Shield it works.

More strange.  When I do logon to the server and first thing I do is hover over S shield I get "Failed to Update", but then from the SEC "Update Computer" I get update successful but the error remains.

More weird is I can reboot the server get clean updates in the logs and then the error shows up again 1,2 or 3 weeks later.  The error is more noticeable on servers as they don't get reboot very much.

I doubt it is a resource issue as some as some of these servers are using less than 10% of the total resources.  CPU, RAM and Disk.  Almost all of the servers are in the same subnet as the SEC also.

Server 2008 R2

Server 2012 R2

Server 2016

Windows 7

Windows 10.

Hello ,

one reason for a 1450 is the Registry Size Limit - though this should no longer be an issue with recent Windows versions. Is there perhaps more information or detail (which resource)  in the Windows Event logs?

Christian

Hello ,

one reason for a 1450 is the Registry Size Limit - though this should no longer be an issue with recent Windows versions. Is there perhaps more information or detail (which resource)  in the Windows Event logs?

Christian

I suppose the best way to troubleshoot this is to isolate the API call LogonUser.

If you have Visual Studio installed*, you could create a new empty C++ project called LogonUser, add the following source code and build it.

Note: Under the properties of the project, Under the configuration Properties - C/C++ - Code Generation you may want to set the Runtime Library option to be /MTd if building in debug to make it more portable.  The code file, e.g. Source.cpp:

#include <iostream>
#include <windows.h>

int wmain(int argc, TCHAR* argv[])
{
if (argc != 4) {
std::wcout << "Usage: <Username> <domain/computer> <password>" << std::endl;
return 1;
}

HANDLE hToken = NULL;

if (!LogonUser(argv[1], argv[2], argv[3], LOGON32_LOGON_SERVICE, LOGON32_PROVIDER_DEFAULT, &hToken))
{
wchar_t buf[1024];
DWORD gle = GetLastError();
FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL,gle, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), buf, sizeof(buf), NULL);
std::wcout << "LogonUser Failed: " << gle << ": " << buf << std::endl;
return gle;
}
else
{
std::wcout << "LogonUser succeeded." << std::endl;
return 0;
}
}

This will create you a exe called LogonUser.exe.

As a test I would use the local SophosSAUTHSERVERANMEaaa account as the local SophosSAUTHSERVERANMEaaa username already has the logon as a service right which is required given LOGON32_LOGON_SERVICE is set on the LogonUser call.

LogonUser.exe SophosSAUTHSERVERANMEaaa . password

I'm using . to denote the local computer but the local computer name could also be used.  The username ad password should be in the registry: 
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Sophos\AutoUpdate\Service

To best emulate what is happening.  As Alupdate.exe is running as system in a non-interactive session.  I would download PsExec and run:

psexec -accepteula -s "C:\test\LogonUser.exe" SophosSAUTHSERVERANMEaaa . password

The context the process is running in and its session could be important.

Hope it helps.

Regards,
Jak

* https://www.visualstudio.com/downloads/ Visual Studio Community 2017 would do.

UPDATE.  To save you the hassle, I've built and attached the tool LogonUser.exe as created from the above code.  As I would be suspicious of such things on forums, I have added a screen cap of me building it and generating a SHA-256 to help offer some re-assurance:

Name: LogonUser.exe
Size: 215040 bytes (0 MB)

SHA256: 323986A26505F5B06625E887E1EA7F1B36B8DAEBC01583CE7BDAD0E90575296B

LogonUser.zip