Question : Problem: Configuration Manager 2007 console does not recognize installed clients

I am trying to install the Config Manager client on 500+ workstations. So I did a client push to all PCs in the domain from the Config Manager console. According to the console, about half of the PCs now have the client installed on them, the other half does not. However, on every PC I have ever logged into (whether the console tells me it has a client installed or not), it appears that the Config Manager client is installed just fine.

I am installing Configuration Manager 2007 R2 on top of Server 2008 Standard with a SQL 2008 database in a Windows 2000 domain (2000, I know, we're upgrading the domain this month). This is a side-by-side installation within a domain that previously had SMS 2003 installed in it. I have not kept any of the old SMS infrastructure, I have even deleted the old SMS site information out of Active Directory. So when I check workstations one-by-one, I know that my client push seemed to work, since on every machine I now have a "Configuration Manager" icon in the control panel instead of the old Systems Management icon. In addition, the Configuration Manager control panel applet all point to the correct ConfigMgr site and Management Point.

So, if I sit behind one of the workstations, I would have no idea anything was wrong. Everything looks fine. I can even open a remote desktop session from the console to workstations that are listed as not having a client installed. The only reason I know something is wrong is because the Config Manager console says they don't have a client installed. I found another EE article that said to delete the SMSCFG.ini file on the workstation and try pushing the client install again, but that didn't work for me. Can anyone help me troubleshoot this issue?

Answer : Problem: Configuration Manager 2007 console does not recognize installed clients

Well, I finally found a solution, and I didn't have to run sysprep, or newsid or do anything that would interfere with the clients' membership to the domain. Nor did I have to physically visit any of the workstations to fix them. Here's what I did...

I found this article on Microsoft's support site: How to locate and clean Advanced Client Duplicate GUIDs in SMS 2003. It is an article that talks about upgrading from SMS 2.0 to SMS 3.0. We're upgrading from SMS 3.0 to ConfigMgr 2007 R2 so this shouldn't apply. However, I decided to give it a try anyway, and it worked! The article tells you to download the SMS 2003 Toolkit and copy a file called Tranguid.exe to the broken workstation. You open a command prompt, run tranguid.exe /R, then restart the SMS Agent Host service, and voila! New SMSID. It took a couple minutes for the ConfigMgr client to regenerate a new ID, but after about 5 minutes, I updated collection membership on the All Systems collection, and the workstation showed up installed and healthy.

So there's the fix. Now the next problem, how do I automate this on 250 PCs? Well first-of-all, I wrote a little batch file that would run the tranguid.exe command (I'm no scripting expert, I'm sure there's better ways to do this) and saved that to NewConfigMgrGUID.cmd. That looked like this:

net use B: \\ Domain\netlogon\scripts
B:
copy SMSCFG-bad.ini %systemroot%\SMSCFG.ini /Y
tranguid.exe /R
net stop "SMS Agent Host"
ping 127.0.0.1 -n 60 >nul
net start "SMS Agent Host"
c:
net use B: /delete

Couple of notes about this script: I put tranguid.exe in a folder called "scripts" in the domain netlogon share along side a known bad SMSCFG.ini file. I noticed that depending on how bad the client install was, the transguid.exe may or may not have been able to fix the SMSID. So I got around that potential error by overwriting the existing SMSCFG.ini file with a file that I knew would be able to be fixed properly (line 3). Also, I noticed that the SMS Agent Host service took a long time to stop and the script would fail because it would not wait long enough for the service to finish stopping. So I added the ping command in there to put in a delay of about 60 seconds before attempting to start the service again (line 6). This script will do the job...if you happened to be logged in locallly to the workstation with admin rights. Close...but not quite. I want it to be fully automated.

So next I downloaded PsTools and tried executing the script above remotely using PsExec. It worked, but the catch there is...the script above needs to be located on the workstation itself. So I wrote another script that would first copy the script above to the workstation, then execute it remotely. That script looked like this:

net use B: \\ Workstation1\c$\winnt
copy NewConfigMgrGUID.cmd B:\NewConfigMgrGUID.cmd
psexec.exe \\ Workstation1 -w C:\WINNT -u domain\user -p password NewConfigMgrGUID.cmd
net use B: /delete

(The psexec command is all on one line. This script is 4 lines total.)

I saved this script to FixClients.bat at the root of my C: drive. So then I put psexec.exe and the script above (NewConfigMgrGUID.cmd) at the root of my C: drive and executed FixClients.bat. What you end up with is a local script (FixClients.bat) running a remote script (NewConfigMgrGUID.cmd) all in the same command prompt (weird). This was a lifesaver due to the necessary pause needed between stopping and starting the SMS Agent Host service.

So all that was left to do was to run a query on ConfigMgr of all the PCs who did not have a client installed and export them to a csv file. A little Excel magic helped me generate a 908 line "FixClients.bat" file. (The same 4 lines above repeated for each workstation with the workstation name listed in lines 1 and 3). The gi-normous FixClients.bat file ran for a little over 5 hours. Beats the hell out of syspreping 250+ workstations spread out all across the county!