What is this error?

If the client computer has the Windows firewall turned on and the required exceptions are not made, then it may report in the CCM.log on the site server that it couldn’t connect to that machine.

If the client machine is behind a firewall that does not allow access to the SCCM server or the local distribution point, then it will be unable to get the files it needs to install the client. For example, on one remote site, access was restricted by the firewall to certain servers only, and the SCCM servers were not included. The SCCM server was able to copy the ccmsetup.exe to the client machine and start it, but it was then unable to get the files it needed from the local DP to install the client. This resulted in the following error in the ccmsetup.log on the client:

Failed to send HTTP request.

Look at the ClientLocation.log to see if it was assigned to your site. If so, then look in the LocationServices.log to see if it found the default management point.  Then check ClientIDManagerStartup.log to see if it is registered.  Check Ccmexec.log for Http errors.

How it can be resolved?

The client will need to get policy from the MP to get configured before all of the client tabs will be available.  You can use Policy Spy from the toolkit to check on policy.  If the client is a new install it can take up to 30 mins depending on your environment to get policy.  Run the install and verify that the client installed correctly in c:\windows\system32\ccmsetup\ccmsetup.log and then allow some time for policy if it can communicate with your MP and is installed correctly.

The ‘Connection-oriented TCP/IP’ protocol is set to use ‘Intranet Range’ when you view the DCOM properties of the machine:

o Run DCOMCNFG on the machine
o Under Component Service, go to Computers > My Computer
o Right-click My Computer and choose Properties
o On the ‘Default Protocols’ tab, choose ‘Connection-oriented TCP/IP’ and click Properties

By default, it should look like the screenshot below. If it is using the ‘Intranet range’ and no port ranges are assigned, then you probably have this problem.

Cause:

Actually, there was nothing much wrong with the WMI on that machine, and the problem wasn’t with WMI, neither in the DCOM security, which was all set correctly. It turns out that the DCOM ‘Connection-oriented TCP/IP’ protocol was set in the registry to use InternetPorts, yet no ports were defined, therefore no connections were being allowed. In the following registry key, there is no subkey called ‘Internet’ by default:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc

This is usually done for security reasons. But if the keys are not created correctly, for example you create the ‘UseInternetPorts‘ key, but don’t create the corresponding keys to define which ports are to be used, then RPC communication to that machine will fail.

Resolution:

In the case that you are not intentionally using pre-defined RPC ports, then simply delete the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet and all its subkeys, then reboot the computer, and RPC access will be restored.

You can use this Powershell script to delete the registry key on a remote computer. It will also get the logged on user, so you can ask them to reboot their machine.  It must be run as administrator, and with an account that has local admin rights on the remote computer.

This entry was posted on Monday, June 2nd, 2014 at 10:00 am and is filed under Windows FTP. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.