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?
Who is Participating?
sbsheriffConnect With a Mentor Author Commented:
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
copy SMSCFG-bad.ini %systemroot%\SMSCFG.ini /Y
tranguid.exe /R
net stop "SMS Agent Host"
ping -n 60 >nul
net start "SMS Agent Host"
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!
Adam LeinssConnect With a Mentor Senior Desktop EngineerCommented:
Have the PCs in question been syspreped?   I believe I've seen this issue raised here before and I believe that was one of the issues.   All PCs need to have unique SIDs to be correctly registered with SCCM.
sbsheriffAuthor Commented:
Good call. I just did some research and found out that they have in fact, NOT been syspreped. I started going through the SMSCFG.ini file on some of these computers and noticed that the SMS Unique Identifier on all these machines are all the same.

Simply re-installing the SMS client won't fix the issue. I found out that I can fix the ConfigMgr client if I uninstall the ConfigMgr client manually (using ccmsetup.exe /uninstall), delete the SMSCFG.ini file, then re-run the client install. However, when the SMSCFG.ini file is recreated, it uses the same SMS GUID as all the other machines that are having the same issue. So fixing one computer breaks another. I'm not sure where that GUID is coming from, but somehow it is being generated by all machines affected.

Wow, so I didn't think it was possible to deploy a Ghost image that hasn't been syspreped. I'm a little confused as to how these machines were joined to the domain at all. I assume that running sysprep on these machines now would forcefully disjoin it from the domain. But would that fix our ConfigMgr issue?Is there a way to force it to generate a new SMS GUID without running a full sysprep?
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Adam LeinssSenior Desktop EngineerCommented:
I don't know of a mass deploy way of fixing this.
You can use NEWSID ( if you don't want to go through the mini-setup.  You would, however, need to disjoin it from the domain, run NEWSID and then rejoin it.  I don't think it will work while the PC is joined to the domain.
However, this seems to contradict what I just said:
In any case, I would test, test and re-test the results of a few PCs if you want to leave them joined to the domain and run NEWSID. This is something you want to fix though, because you'll also run into WSUS not working correctly if the PCs can't be uniquely identified.
Adam LeinssConnect With a Mentor Senior Desktop EngineerCommented:
I'm impressed!  You should register to be an expert here...I did just to get free access to the EE knowledge base.

I think you can use "psexec -c" to copy the file to the workstation and execute it at the same time.

The only problem I see if a PC is turned off, how do you log that...

Might want to check this link for possible WSUS issues down the road (SCCM uses WSUS for its update engine):
sbsheriffAuthor Commented:
Thank you. I'm not quite sure what it means to be registered as an expert here, but I'll look into it.

psexec, that would have simplified the second script quite a bit. Thanks! I just found the PsTools while researching this problem so I've never used them before. I'll keep that in mind next time.

As for logging which machines fail...I really don't need to. I only exported a list of machines that do not show up in the Config Mgr console properly. When the script works, they pop up as correctly installed in the console. If it didn't work, then nothing changes and they are still listed as workstations that do not have the client installed.

We do use WSUS, and as far as I know we haven't had any problems with it. But who knows, not sysprepping those machines will probably explain a lot of the weird problems we've been seeing on our network for some time....and maybe even some issues we haven't seen!

I'm sure there are plenty of other issues I am sidestepping by not sysprepping or newsiding the machines. But since the only reason I really need the ConfigMgr clients installed at all is to deploy a new operating system, then this is all I really need. This solution definitely isn't for everyone, but if there is anyone else out there who only needs to get the Config Mgr client installed so they can deploy a new operating system, then this should help.

Thanks for pointing me down the right track aleinss!
Adam LeinssSenior Desktop EngineerCommented:
Anytime.  Registration is free and anyone can be expert...but I think you need to maintain at least 2,000 points per month to get the free membership.

I am having the same issue here.

So based on your testing the tranguid.exe has to be copied and executed locally computer that is having the issue? It wasn't clear reading your post but does the user executing tranguid.exe needs to have admin rights?

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.