Untitled At my current customer we are performing a clean, side-by-side upgrade from their current SMS 2003 infrastructure. We are using client push to install the ConfigMgr 2007 SP2 agent on all client systems. Pretty smooth for the most part with two exceptions.

The first issue has to do with automatic uninstallation of the SMS client during the installation of the ConfigMgr agent. On a handful of clients (about 5% of our initial 200 in the pilot group), we were getting the following message in ccmsetup.log and then the log would stop, services.exe would jump to 50%+ CPU time, and the client install would just hang there:

RemoveW2KDrivers. Removing Remote Control drivers ccmsetup

After some web searching and only a couple of hits and some manual inspection we determined that the permissions on the registry key holding the information for SMS Remote Tools mouse driver were somehow corrupt. The exact key is HKLM\System\CurrentControlSet\Enum\Root\*SMS_MOUSE and all of its subkeys (not values). We wrote a quick for loop in a batch script to use regini to connect to every client in SMS and reset the permissions. Given the very low number of hits I got while searching for this issue, I can only conclude that it was something very unique to this environment and perhaps one of the legacy images used to deploy systems.

The second pain point has been that another handful of clients (some of the same ones) would get fully installed, find the MP properly, get assigned to the site, registered, and even start downloading policies but would never actually flip from No to Yes in the console for having the client installed. Multiple collection updates and client Data Discovery cycles changed nothing. This was a real head-scratcher for a while until I ran across an entry in the ClientIDManagerStartup.log on the client:

Smsid is missing but (re)generation is disabled.

A quick web search revealed a couple of posts relating this message to the local SMS certificates on the client system. Given that these were being upgraded from SMS, it made (some) sense that the self-signed certificates created by the SMS Agent were expired, corrupt, or in some other way unusable. Using the Certificates snap-in I deleted the two SMS certificates (located in the SMS store of the local computer account) on one of the systems and then restarted the ConfigMgr agent. During agent startup I monitored the ClientIDManagerStartup.log to verify successful registration. Once that happened, I waited a minute (or two) for prosperity and updated a collection containing the resource and low and behold, the client was now properly showing in the console. I truly have no idea what the exact cause of this issue is/was either. Unfortunately, the actual client registration process is somewhat of a blackbox and very little documentation exists for it. I thought that the ConfigMgr team had recently posted an article with some more detail, but I can’t find it right now.

The next step is automating the certificate removal for systems experiencing the same which I haven’t quite figured out yet because certutil is not native to Windows XP (yes this customer is still stuck on XP, 3,000 systems worth) and as far as I can see certutil has no remote capabilities.