Archive for February, 2010

Unable to connect to WMI on remote machine

February 15, 2010

So, the duplicate SID thing from my previous post seemed to be fixed.  Well, not completely…. there were a lot of XP workstations  to which the SCCM Tools could not connect, so the certificates or the SID could not be removed.

The tool said: The RPC Server is unavailable. (Exception from HRESULT 0x800706BA)

What was going wrong? Appearantly the tool couldn’t connect to the workstation. But how/what/why?
The following errors also  showed up in the ccm.log on the SCCM Server:
“Unable to connect to WMI on remote machine “, error = 0x800706ba.”

So it appeared that a connection to WMI could not be established.

But when i ran wbemtest or msinfo32 on the workstation locally, no problems.  So WMI was working… Off to some Googling then.

Following the things i found using Google, what did i check on the workstations?

– Firewall was OFF (completely, utterly OFF 🙂 )

– No firewall / filtering between the VLAN’s used.

– Correct services were running (RPC, WMI, etc. etc.)

– Checked WMI on the workstation using WMIDiag , no errors.  Just to be sure, i followed all steps listed here ( rebuilt the WMI repository,  re-registered all WMI files and even re-installed the whole WMI)

– Correct DCOM permissions were in place (using dcomcnfg )

– Removed all virusscanners and other security, or even VPN related tools.

So, i was stuck.

Then i thought: Well, let’s see if patching the boxes will make a difference. They were still XP SP2, so i started installing SP3 on them.

But it failed, with error 0x8007007E

Strange. So i downloaded the offline version of SP3 for Windows XP, and tried to install that. A beautiful error came up:

“Windows has detected that one or more protected core system files (kernel) on your computer have been modified”.

The KB article related to this error gave a clear signal: look in your boot.ini file for modifications there.

And yes, there i saw the following lines:

[boot loader]
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect /TUTag=NEWEW4 /Kernel=TUKernel.exe
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional (TuneUp Backup)” /noexecute=optin /fastdetect /TUTag=NEWEW4-BAK

Notice the /Kernel=TUKernel.exe part. It turned out that someone had been meddling with some software named TuneUp Utilities, to change the bootlogo screen of these boxes. And to change that, the software had just loaded it’s own modified kernel instance. Nice huh?

So i deleted the /TUTag and the /Kernel= switches and rebooted the box.

And sure enough, after that, no problems connecting to WMI! Incredible…

Now, how to change the boot.ini on a couple of hundred computers?

I found a nice post of someone containing a batch file to delete and re-create the boot.ini file. Nice!

Now to get this batch file kicked off on all those workstations… PSExec to the rescue!

The command:

PSexec @faultymachines.txt -e -c -f -n 05 editboot.bat >errors.txt

This uses a .txt file containing all targeted workstations, copies the editboot.bat file to them, runs the batch, and logs to errors.txt file.

To make these changes effective, the machines of course need to reboot. Again, PsTools to the rescue:

psshutdown -r -v 0 -n 5 -t 23:00:00 @faultymachines.txt

With this, the same machines will Silently reboot at 23:00 o ‘clock that night.  No displaying of “Your computer will reboot in xx minutes” also 🙂

To be continued….


SCCM 2007 troubles with duplicate SID’s

February 9, 2010

I was installing SCCM 2007 SP2 with R2  on a network, where they were using SMS 2003. This was a side-by-side upgrade.  Defined boundaries, enabled the automatic Client Pushing, no problem.

The clients were installing nicely, the Deployment Report showed a 97% successrate of installing, but only 10% of the clients were presented as “Client installed: Yes”.

What happened to the other 90% then? The ConfigMgr Clients were installed, but they weren’t reporting correctly.

After running the Report  “Computers that may share the same unique SMS ID” , the other 90% showed up… with same ID’s.

Apparently, the sysadmins used Ghost for cloning their workstations, and did not use sysprep in the process. Although there is some discussion about the impact of having duplicate machine SID’s in your domain, it is still very clear that for instance WSUS and SCCM are not too happy about this.  That’s because they create their own WSUS-ID and SCCM-ID, based on the Machine SID.


So how to go about then? Running NewSid.exe on all of the computers is not an option, because:

– It takes too long ( up to 45-60 minutes per workstation)

– It’s not supported by MS. They say: Use sysprep, no other option.

First i made a script to delete all the smsconfig.ini files on the workstations, and then restart the SMS Agent Host service on the computers. But alas, this was not enough…

I was looking for some way to change only the SCCM ID, when I stumbled across this website that contains the tool SCCM Client Center, by Roger Zander.

It turned out to be exactly what i needed, with this i could make a connection to all workstations, remove the ID, restart the SMS Host Agent service on the machine, and all was good.

Quite a bit of work, doing this for about 900 computers, but hey, what are interns for? 🙂