Guest VM Agent Installation Failure

I have the same issue, however it's only impacting the install on our domain controllers. I'd be curious to understand the fix or "workaround" for this.

The issue is that most environments use some type of domain policy (we use Microsoft Active Directory) and that service accounts used by the agent installer do not have 'logonasaservice' permissions. 

There are 3 service accounts that are needed for this supposed 'off-board' system. (Not sure how it is off-board if the solution uses 4 Windows services on each VM OS but that is another topic all together.)  :) 

The 3 service accounts needing 'logon as a service' rights are:

NT AUTHORITY\SYSTEM

NT Service\SGVMManagementService

NT Service\SGVMScanningService

You have 2 choices so far. You can wait for the agent install to fail, set the services to local system and then retry the install and it should succeed. For most larger environments, this is not feasible but should be good for initial function testing. 

I eventually had to modify our domain GPOs to give the logon as a service permissions throughout my domain to the accounts above. I understand modifying GPOs is not quick and easy in most environments but I am not sure of any other way, at least in my domain. 

The fact that there is no mention of this in the startup guide, Sophos support has yet to respond to a single question I have submitted relating these accounts tells me that it wasn't tested/QA'd properly and they are probably having internal discussions on the next agent version. I think most companies will have problems with this service account as they try to install the new agent. 

hello PMIAdmin 

We have not seen this internally, however it could be related to another customer who had an issue installing when they seem to have removed some rights in their domain environment.

Is this VM in a domain?

Have you changed any security policy settings manually?

Have you logged a support call too?

Thanks

Mark

Same here, only an issue on our DCs.  Every other SVR2012 install is ok, regardless of things like SQL, etc. being installed, which I had expected to be problematic given the hassles with the DCs.

I have a support ticket open with Sophos so I'll report back what they come up with.

Neil

There are typically 2 problems with agent installs from my experience. There is either a networking issue related to the GVM <-> SVM or there is a permissions issue with the service accounts that the agent installer uses. I would confirm both are good. 

Networking is good - confirmed by the fact that I was able to roll out to all other servers across different hosts.

Just those problematic DCs but like you said earlier Tyler, when I set the SGVMManagementService to local system the installer runs through ok but the following services do not get created as they should:
Sophos Guest VM Agent
Sophos Guest Vm Agent Event Service
Sophos GVM Scanning Integration Service
Sophos GVM Scanning Service

Net effect is the installer looks like it's completed ok but the guest is not protected.

Tyler Caldwell said:

 

I eventually had to modify our domain GPOs to give the logon as a service permissions throughout my domain to the accounts above. I understand modifying GPOs is not quick and easy in most environments but I am not sure of any other way, at least in my domain.  

Based on Tyler's comment about GPOs I have figured out a crude way to get the install to go through and setup all the necessary service accounts.  Here are the steps I took:

1. Create an OU in AD and set GPO to block inheritance on that folder.
2. Create and apply a GPO to that folder: Computer Configuration>Windows Settings>Security Settings>User Rights Assignment>Log On as a Service
    Enable "Define These Policy Settings" and Add the "Everyone" Group (just type in Everyone).

3. Move DC to that OU. Force Update on DC (gpupdate /force).
4. Run installer and confirmed services are setup and running (with the correct Log On As service accounts created).
5. Test Eicar file.
6. Move DC back to original OU. Force Update on DC (gpupdate /force).
7. Restart DC (for good measure more than anything) - double-check services and Eicar file.

Obviously creating GPOs and moving DCs between sets of policies is NOT best practice but it's a workaround until Sophos figure it out.  Hope that helps someone!

IT Manager2 & Tyler Caldwell 

I will feedback the information and steps you took to the development team to see about making it easier for you.  

Thanks again!

Mark 

I'm having the same issue where the SGVMManagementService fails to start.  However, this is happening on a standard Windows 7 VM.  I just deployed the agent to about 20 machines using PsExec, and the majority of them worked fine, but there are a couple giving this error.

I don't think it is a GPO issue, because all of these machines are members of the same OUs, and have the exact same GPOs applied to them.

I had the same issue on our domain controllers but after it failed I changed the service to run as SYSTEM and it continued. I'll have to submit a change request if I have to do anything that requires a reboot but I like this option -- thanks!