HowTo: Compare SIDs after Imaging

Have you ever imaged a ton of systems and then wondered, "Did sysprep really work? Or am I going to have goofy SID issues down the road?"

Well, I did that today, so I went looking for a way to tell. Here's what I found. According to Microsoft you can look in the HKLM\Security\SAM\Domains\Account registry key.

This subkey contains two values, F and V. Figure 2 shows a sample Registry editor session that displays these values .The V value is a REG_BINARY value in which the computer SID is embedded (at the end of its data). However, because the data is in binary format, it's difficult to read. For this information to be useful, you also need to now the format of a machine SID in NT 4.0: three 32-bit subauthorities, preceded by three 32-bit authority fields. By comparing the V value on different machines, you can identify whether the machines have duplicate SIDs.

Now you can put your mind at ease that SysPrep or SidGen or whatever else you might be using to ensure the uniqueness of your SIDs is actually doing its job.

Ugh... Symantec buys Altiris?

Just when I was starting to get over the licensing pain of Veritas being bought by Symantec, they go and buy Altiris.

I so look forward to yet another licensing scheme change. Yay.

PXE-E55: ProxyDHCP service did not reply to request on port 4011

I was working on a client’s server today and trying to get HP’s Rapid Deployment Pack (RDP) to connect to a blade for imaging.

The PXE boot environment kept recycling and I couldn’t figure out why until I managed to snag a screen capture of the error.



I did a little bit of digging and found this article on Microsoft’s site.

• PXE clients computers do not start when you configure the DHCP server to use options 60, 66, 67

While it didn’t help me exactly, since the PXE server was on the same server as the DHCP service, it did lead me to the right answer.

The Altiris PXE Server was set to manual and wasn’t started. I should have checked that first, but live and learn.