Installation could not be started - Error code 80072afc

https://docs.sophos.com/esg/enterprise-console/tools/deployment_guide/en-us/index.html is one source of information that may help you.

The account you specify in the SEC Deployment Wizard needs to be an admin on the client.  I.e if you're using a user which is a member of domain admins, then domain admins group should be a member of the local administrators group on the client.  Does this all resolve as a basic test.

Other tests include:

1. Is the Remote Registry Service running on the client?

Running Regedit.exe as the deployment user say on the SEC server should be able to connect to the client and you should be able to access keys under say, HKLM\software\

2. Is the Task scheduler service running on the client?

3. Logged on to a client (preferably the SEC server as the deployment user) can you browse to:
\\remoteclient\C$\
Can you access the administrative shares?

4. Firewall considerations at the client side should also be considered but the above tests check most of the requirements.  Aside from allowing TCP 8194 incoming on the client for RMS, but that is all post setup.exe running.

Out of interest, is a pull, i.e. running setup.exe with the switches an option as opposed to a push?

Regards,

Jak

jak said:

https://docs.sophos.com/esg/enterprise-console/tools/deployment_guide/en-us/index.html is one source of information that may help you.

The account you specify in the SEC Deployment Wizard needs to be an admin on the client.  I.e if you're using a user which is a member of domain admins, then domain admins group should be a member of the local administrators group on the client.  Does this all resolve as a basic test.

Other tests include:

1. Is the Remote Registry Service running on the client?

Running Regedit.exe as the deployment user say on the SEC server should be able to connect to the client and you should be able to access keys under say, HKLM\software\

2. Is the Task scheduler service running on the client?

3. Logged on to a client (preferably the SEC server as the deployment user) can you browse to:
\\remoteclient\C$\
Can you access the administrative shares?

4. Firewall considerations at the client side should also be considered but the above tests check most of the requirements.  Aside from allowing TCP 8194 incoming on the client for RMS, but that is all post setup.exe running.

Out of interest, is a pull, i.e. running setup.exe with the switches an option as opposed to a push?

Regards,

Jak

 

 

Hi,

Thanks for the reply, here is what I have found.

To push Sophos, we specify an AD account called Sophos, the account is active and the password has not expired, I am able to login to the server using this account. It is a member of the domain admins group. I have checked on the local computer and the Domain Admins group is under the local admins group on the machine.

1. I have gone onto the server which is working as the Sophos Server and ran regedit under the sophos admin user. I connected remotley to the PC I am attempting to push Sophos to and I am able to browse to HKLM\Software\XXX

2. Task Scheduler is started and running on the client and is set to Automatic.

3. I can browse to the C drive as remote client without issues from the server logged in as the sophos deploy user.

4. The windows firewall has been switched off on the client and disabled for testing, so I don't think this would get in the way?

Thanks for the update, does the scheduled task get created on the client following the protect from SEC?

I'm not at a Window client at the moment but I assume with the MMC snap-in for the task scheduler you can connect to a remote computer, do you see the Sophos Install task get created? If it exists, does the history or exit code help?

You should also see it appear under:

\\client\C$\Windows\tasks\

It's the mgntsvc.exe process on the management server that connects to the remote client to create the task.  It might be worth restarting the Sophos Management Service just to ensure it's not in an odd state.  Note: This will disconnect the console but you can reconnect.  

It may also be worth following: https://community.sophos.com/kb/en-us/112246 to see if the management service throws any more useful messages.

So I went to try and push the install again to the client and I was checking in the task scheduler, it did appear to show a Sophos install task.

Much to my amazement it has actually installed too. It is showing in the console as fully up to date, I have tried clicking update from the client and that works too, no errors....

I have not changed anything at all, but it seems to be working now, I am very confused.... 

Tomorrow I will reimage again and try the same again and see what happens, I will let you know the outcome on this.

Your help on this has been much appreciated so far :) 

Well that's something.  

As a tip, when you see the scheduled task get created on the endpoint, it's worth copying out the command line from the scheduled task as created by the management server.  

It will have all the switches you need to deploy.  You can supplement with the -G switch as well if needed.  Details here:

https://community.sophos.com/kb/en-us/12570

At least with this you can create a simple batch file for the future which can install the endpoint silently with all the required parameters.

Regards,

Jak

OK, so I tried to image again this morning. After completion, the PC is in a domained state, it can login, updated GPO's and everything works without issues with the PC itself.

I can see the PC name has appeared in the Enterprise console. But it is greyed out, if I right click the "protect computers" is greyed out.

If I double click on it, it shows that it knows it is Windows 7, and it knows the computer name, all other fields (IP address etc) are empty. On other machines that work most fields are populated.

I went to Discover Computers and tried that way, but that did not make a difference, technically the computer is in the list, but I cannot do anything with it :(

Again, UAC disabled and firewall off etc for testing.

Thanks again in advance

OK, so I tried to image again this morning. After completion, the PC is in a domained state, it can login, updated GPO's and everything works without issues with the PC itself.

I can see the PC name has appeared in the Enterprise console. But it is greyed out, if I right click the "protect computers" is greyed out.

If I double click on it, it shows that it knows it is Windows 7, and it knows the computer name, all other fields (IP address etc) are empty. On other machines that work most fields are populated.

I went to Discover Computers and tried that way, but that did not make a difference, technically the computer is in the list, but I cannot do anything with it :(

Again, UAC disabled and firewall off etc for testing.

Thanks again in advance

I figured out that issue, I needed to wait for the sync to take place with AD, it is set to every 60 mins...

So back to the original issue :)

I tried to hit protect computers and tried to look at the task scheduler to see what was going on, I kept hitting refresh to see if the Sophos task came up, but I didn't see it appear. It took about 20 seconds to fail with the same error on the console. 

I went into C:\Windows\Tasks and there is a task there called Sophos_InstTask.JOB just sitting there now.

But again, I am unable to add Sophos to the machine.

Again, if I look against other machines in the console and double click, it shows all the details as below

Where as, the new machine I am trying to deploy is only showing the following:

You can see there is a bunch of stuff missing...Not sure if that helps with what could be causing this?

The missing details would be expected at this stage.  That is filled in when the computer becomes managed by the RMS component and sends in the first status message.  Typically 20 seconds after install of RMS.

The code 80072afc, in this case,  translates to:

2afc = 11004

https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx

WSANO_DATA
Valid name, no data record of requested type.
The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record—indicating the host itself exists, but is not directly reachable.

Could it be that the address in the defined updating policy cannot be resolved?  I.e. it creates the task, the task has a command line back to run setup.exe from the server share.  This path comes from the updating policy linked to the group the computer resides in.

By default this would be send back from the Update Manager to the management server as just the NetBIOS form, e.g. \\server\sophosupdate.

Is it that initially out of the blocks, it can't resolve this form?  Things to try might include:

1. Create a new test updating policy and change the initial install path to be \\ip\sophosupdate.

2. Ensure that the DNS suffix for your domain is configured in the clients interface, so that "domain.local" or whatever is appended to "server", making the FQDN form.

3. As per point 1, change the initial instal path to be the FQDN.

I hope this helps.

Regards,

Jak

I will give this a go and let you know the result.

On another note, is there an MSI for installing Sophos ? So that I can push it as part of the OS deployment? 

We tick the boxes usually as follows (so the MSI would need to do the same)

There is no MSI to install.  

The easiest way to generate the single command line to install is to deploy to one computer as you would and copy the details from the created scheduled task.  You can then optionally add the -G switch I mentioned before if you want new computer to arrive in a specific SEC group for a initial set of policies.

Thanks for that, just a bit of an update then....

So on our network, for PCs, laptops, end user devices we untick the "register this connection in DNS" on the adapter. Show in the image below. We ensure that our DNS servers do not have the information of the end user machines.

The reason we do this is because we use remote software to access end user devices and sometimes if the IP changes and DNS does not update quick enough then we are unable to access the machine for some time.

We have been doing this for years and everything seems to work without issues, even without the machines showing in DNS, if we do a ping to the PC name, it takes less than a second and then it resolves.

For some reason though, the server hosting Sophos cannot see the IP addresses of the machine names when it tries to resolve them. I guess this is why it is failing. If I try using other servers it resolves fine, and it resolves fine from my machine, but not from the server with Sophos Enterprise Console.

I am wondering now... With the PC/Laptop names not showing in DNS, what protocol is used to try and resolve the names of the devices back to their IP addresses? If I try to ping a machine, is some sort of broadcast sent out looking for it? What protocol/system does this, then I can have a look on the server to see what config may be different on the NICs etc.

It is running on Windows Server 2008 Standard SP2.

The management server wouldn't need to resolve the client's IP from the name for the deployment to succeed. 

I would have though this is more of a client side issue not being able to resolve the server name as configured in the "initial install source" tab of the linked updating policy.

As a test, if you change the address in the "initial install source" page of the updating policy to the IP of the management server does it always work?  This would rule out the possible resolution issue I would think.

Sorry Jak, I think I am being stupid, where do I go about doing/changing this?

It is strange because anything we image in the old method seems to come through OK, also anything we image with the new method and call a name that exists in Sophos already (when we reimage a machine) it seems to also work and it pushes the client without issues. It just seems to be devices with new names, strange...

The computer in question you are deploying to must be in a SEC group.  This SEC group has a linked Updating policy.  If you edit that linked Updating policy you should see a tab called "Initial install source".  This is essentially the path that the management server uses when setting up the scheduled task.  I was just curious as a test if you were to say:

1. Create a new SEC group (a sub group of the current is fine).
2. Create a new test Updating policy changing the above  initial install path and link it to the test group.  
3. Copy a test client, you expect to fail or is currently failing to the test group and try a protect.

Does it work given these changes?  You can check the created scheduled task that it is referencing the management server by IP rather than the previous NetBIOS name.

Regards,

Jak

Thanks very much for that. I have created a new updating policy called Testing. Screenshots of this are below. I changed the address from the hostname to the IP address in both locations shown below:

I then created a group from the left called Testing, edited the policies and set the Updating policy dropdown to be set to the Testing policy as shown in the image below:

I will be back on site this afternoon to test this hopefully. Is this all correct though now ?

I think I should mention though, if I ping the server name from the client PC having the issue, it can ping using both the name and the IP. If I go to the server and ping the client, it can resolve the IP of the client, but not the name.

Thanks again. 

That looks correct and I understand the reservation as I'm not 100% confident it will help but it will rule something out which is related to name resolution.

If the Sophos Management Service on the management server (given the NetBIOS name of the client as the target) is able to setup the remote task on the client with the correct command line, then the management service has really done its job.  It's then really over to the task scheduler to run the command.

When you see the task get created and it fails, presumably the Task Scheduler shows an error for this task?  Does that also return 80072afc?

It might even be worth running Process Monitor [https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx] on the client during the protect to confirm that setup.exe does/doesn't get started.  If it doesn't which I assume is the case, is there anything of interest?

Regards,

Jak