Scheduled maintenance on Saturday, August 8th from 7am to 10am (UTC). Licensing registrations and key activations will be unavailable during this period. More info here.
We'd love to hear about it! Click here to go to the product suggestion community
I'm testing rollout of Sophos Endpoint and am having problems trying to get it to work via AD + GPO, following the instructions here https://community.sophos.com/kb/en-us/120611
I set up the GPO etc as described, ran gpupdate /force, rebooted the computer and nothing appeared to happen. No Sophos folders appear in ProgramData etc or anything like that.
To test the GPO i edited the batch file to write some text into a text file, and positioned this lines at the start of the batch file, in the middle and at the end. This text file appears and contains the text from all parts of the script so the install script is definitely running.
The folder path in the batch file is definitely correct. If i double click the setup exe manually from the shared folder it runs, although it pops up a UAC prompt. I've disabled UAC though and it still doesn't do anything.
If i copy the batch file to the local system desktop and run it manually then it does a bit more - a Sophos folder appears in ProgramData and the computer gets registered in Sophos Central. However, nothing installs and the log in the CloudInstaller folder has error lines like this:
SUL error [E26245] Error fetching data from http://dci.sophosupd.com/update.......... WinHttpSendRequest (error 12175)
Does anybody have any ideas for any of these problems?
UPDATE: I've resolved the error when installing manually - I had to exempt sophosupd.com from DPI\SSL within our firewall.
However, I still have the issue of the install not running as part of a GPO script.
In reply to trevora:
UPDATE: I don't know if this helps but I've run Process Monitor with boot logging and can see:
Sorry for the delay in responding.
First note: while we do outline the steps and guidelines for installation via GPO, the Support team can not troubleshoot specific GPO issues, especially if our installer works when run manually. This is because our customers' environments vary. As an option you can engage our Professional Services team to assist with this issue.
However, reading through what you have tried, I see that you have white listed one of our updating domains, and successfully installed manually. We actually have several updating sites, which might be used for an install. This article goes over all the domains and ports we suggest to be white listed when installing Central Endpoint.
As for the domain users rights, As noted in KBA 120611:
"SophosSetup.exe requires an administrator privilege to run on the computer. If you wish to deploy using login scripts, the logged in user account should be an administrator of the computer for the installation to succeed.
For the deployment via the Active Directory startup script, the logged in users no longer have to be the local administrators of the computers."
Are you trying to do install through a startup script?
CreateFile doesn't always mean what it sounds like.https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
When the script runs, it is running as the system account on the computer, therefore using the machine account to access the share.What is the format you have in the batch file that references the share?\\netbios\share\
What OS is the server client?I assume you have a domain.Regards,
In reply to RodS:
I'll have a look at the domain\port list, but as the install works when run manually then i don't think it's the cause of this specific issue.
I'm trying to use an AD GPO Startup script, so the fact that the users aren't local admins shouldn't be a problem.
In reply to jak:
The share is \\netbios\share, which is visible and accessible to my test computer with a non-local admin logged in to the client. Server OS is 2012 and client is Windows 10, and we have a domain.
The Domain Users and Domain Computer groups have Read access to the share.
I've resolved this - I create a brand new share, with all the share and security permissions as in the original share, and it started working. No idea what the actual problem is with the original share that we've used for this in the past, but it looks OK now.