SCCM 2007 to ConfigMgr 2012 client migration site assignment issue

Recently discovered an interesting issue when migrating clients from SCCM 2007 R3 to ConfigMgr 2012 R2. Issue occurred while using client push, or during manual installs of the CM 2012 client.

Some clients refused to assign to the new site code. BTW, this is one of the reasons that you always want to use a NEW site code for an upgrade like this!

This behavior can be observed by monitoring the Locationservices.log, the CM 2012 client push will show the new site code, then the client will indicate that it is still assigned to the old site. This prevent the CM 2012 client from completing the install.

I’ll spare you the long list of things that I eliminated before reaching the conclusion. The short list, boundary assignments were ruled out, the prior SCCM 2007 client push had been disabled, the GPOs Group Policy Objects (GPOs); client startup script and automatic site assignment policy GPO links had been disabled.

Turned out to be the automatic site assignment policy GPO that forced site assignment for the old site (SCCM 2007). Even after removing the GPO, the old site code was tattooed in WMI.

I could have scripted the removal of the prior site code, however, since this is a single site. I ended up implementing another ConfigMgr 2012 site assignment GPO to force the new site code. All is well.

There are a few scripts that can be used if you end up with a multi-site implementation to remove the entry from WMI.

Here is one VBS Script that will take care of the WMI tattoo issue (original source):

Option Explicit
Const HKLM = &H80000002
Const sRegKey = “SOFTWARE\Microsoft\SMS\Mobile Client”
Const sRegValueName = “GPRequestedSiteAssignmentCode”
Dim oReg, iReturnValue

Set oReg = GetObject(“winmgmts:\\.\root\default:StdRegProv”)
iReturnValue = oReg.SetStringValue (HKLM, sRegKey, sRegValueName, “”)
wscript.quit iReturnValue

Filed under: ConfigMgr, OSD

email

Written by , Posted .
  • Bob Panick

    What was the GPO that was setting it?