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

Installation could not be started - Error code 80072afc

Hi all, we have a somewhat urgent issue at this point.

We are trialing using Windows Deployment Services with Microsoft Deployment Toolkit for imaging now.

In the past we have not used sysprep on our machines etc, and Sophos has always installed from the Enterprise console by right clicking the PC and clicking protect computers after it has been added to the domain.

Now that we are using Microsoft Deployment Toolkit, we have a similar setup, it gets added to the domain etc and once all completed I tried to go into the enterprise console and right click > protect computers.

After a few seconds it fails with the following error:

Code 80072afc - The installation could not be started: the requested name is valid, but no data of the requested type was found. The computer may need additional configuration before installation.

I have disabled the windows firewall, turned of UAC. We are on Win7 64bit.

I cannot think of anything else that would cause this with the way we are imaging PCs now...

Any ideas? Thanks very much. 



This thread was automatically locked due to age.
  • 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