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):
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, “”)