Troubleshooting ConfigMgr 2012 Client Migration using Powershell (Part 3)

In this post, we’ll start looking at some of the common reasons why client upgrades fail, and how to resolve them.

Firewall Restrictions or Missing Boundaries

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.  The windows firewall requirements are documented here: http://technet.microsoft.com/en-us/library/gg682180.aspx.

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. (Error at WinHttpSendRequest: 12002)

In addition, if the client is not a member of an SCCM boundary, and no fallback location is permitted in the ConfgMgr client package, the client will not be able to get the files it needs to install the SCCM client.  Nickolaj Andersen has a nice post to identify if an IP is within a boundary: http://www.scconfigmgr.com/2014/04/15/check-if-an-ip-address-is-within-an-ip-range-boundary-in-configmgr-2012/

Machine is not Online, or Doesn’t Exist

In many cases, the reason the ConfigMgr client did not upgrade is simply because the client machine is not currently online.  ConfigMgr will try every hour for 7 days to push the client again.  If it hasn’t succeeded in this time period, it will give up, therefore if the client has not been succesfully installed or the problem remediated during this time period, you will need to push the client installation again from the ConfigMgr console. You can push it to the entire collection that contains computers without the SCCM 2012 client, if desired.

If the computer is not online, or doesn’t in fact exist, you will see errors like this in the CCM.log:

—> Attempting to connect to administrative share ‘\DB-MyLaptop\admin$’ using account ‘mydomain\sccmadmin’

—> WNetAddConnection2 failed (LOGON32_LOGON_NEW_CREDENTIALS) using account mydomain\sccmadmin (00000035)

—> The device DB-MyLaptop does not exist on the network. Giving up

—> ERROR: Unable to access target machine for request: “2097156880”, machine name: “DB-MyLaptop”, access denied or invalid network path.

In some cases, there are stale computer accounts in Active Directory, for example the machine was rebuilt with a different name, and was not first removed from the domain.  There may also be stale computer records in ConfigMgr, depending on the defined period of the maintenance tasks that clear out old records.  In these cases, the client records should be removed from AD/ConfigMgr.

DNS Errors

If the client is not properly registered in DNS, ConfigMgr may report that it cannot connect to the machine in the CCM.log. For example, I had one such case where I could ping the machine and I could connect to the admin$ share by it’s IP address, but not by it’s hostname. After searching in DNS I found multiple A records for different hostnames associated with the IP address! So after deleting the additional A records and flushing the DNS on the SCCM site server, the client push install went through successfully.

Unsupported Operating System

The client machine must be at Windows XP SP3 or above for the 2012 client installation to work, otherwise it will report it as an unsupported OS in the CCM.log:

—> OS is X86 bit Windows XP, Service Pack less than 3, returning as this is an unsupported OS

ERROR: Target machine (DB-MyLaptop) must be Windows 2003 SP2 or Windows XP SP3 or newer
Install SP3 or upgrade the machine to a newer OS to install the 2012 client.

Incorrect RPC Port Range Assignment

Symptoms

This problem took a long time to track down the cause! The symptoms are you cannot access the WMI on the machine, and the following error is reported in the CCM.log:

• —> Unable to connect to WMI on remote machine “”DB-MyLaptop””, error = 0x80070057.

This error code means ‘The parameter is incorrect’.  When you run wbemtest utility and try to remotely connect to the WMI on that machine, you get the same error.

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

• Run DCOMCNFG on the machine
• Under Component Service, go to Computers > My Computer
• Right-click My Computer and choose Properties
• 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

It has to be created manually, and this can be done to allow RPC communication on pre-defined ports, as described in the Microsoft KB: http://support.microsoft.com/kb/154596. 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 it’s 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.

$Path = "HKLM:\SOFTWARE\Microsoft\Rpc\Internet"
$ComputerName = "DB-MyLaptop"

$s = New-PSSession -ComputerName $ComputerName
Invoke-Command -Session $s -Argu $Path,$ComputerName -ScriptBlock `
{
param ($Path,$ComputerName)

if (Test-Path $Path)
{
write-host "$Path exists in the registry on $ComputerName. Attempting deletion of key..."
Remove-Item $Path -Recurse -Force
if (Test-Path $Path)
{
write-host "$Path could not be deleted!"
}
else
{
write-host "$Path was deleted!"
}
}
else
{
write-host "$Path does not exist in registry on $ComputerName"
}
}
Remove-PSSession $s

# Get logged on user
Write-host "Logged on user:"
@(Get-WmiObject -ComputerName $ComputerName -Namespace root\cimv2 -Class Win32_ComputerSystem)[0].UserName

Next time we’ll look at another cause of ConfigMgr client upgrade failure.