I had a problem with a small group of computers which I deployed in my organisation.
The computers were deployed through images which I created with DriveImage XML.
All went well but I forgot one small step which I will explain later. The computers didn't show up in WSUS but did get their updates from the wsus server I was puzzled.
Then it hit me I did nog give the computers a new sid!
This explained why they did get their updates but did not show up in wsus except for 1. On the systinternal site I grabbed the utility NewSID v4.10 and gave the computers a newsid.

However they still didn't showed up in WSUS. But I found the solution here Athif Khaleel's WSUS blog:

@echo off
Echo Save the batch file "AU_Clean_SID.cmd". This batch file will do the following:
Echo 1. Stops the wuauserv service
Echo 2. Deletes the AccountDomainSid registry key (if it exists)
Echo 3. Deletes the PingID registry key (if it exists)
Echo 4. Deletes the SusClientId registry key (if it exists)
Echo 5. Restarts the wuauserv service
Echo 6. Resets the Authorization Cookie
Echo 7. More information on http://msmvps.com/Athif
Pause
@echo on
net stop wuauserv
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v AccountDomainSid /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v PingID /f
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate" /v SusClientId /f
net start wuauserv
wuauclt /resetauthorization /detectnow
Pause

And now your clients will show up in WSUS if they do not show up immediately don't worry allow for a 10 minute cycle.

I create millions and billions of Virtual Machines - ok, maybe not that many but it feels like it. Everytime I have copied the physical files (VHD/VMC) a number of things must be done if I want to join those virtual machines to my domain(s) - most importantly: the machines SID (Security ID) must be re-generated to be unique and the computer must be renamed of course.

So, heres the thing. Back in the good old days you had to find the Windows CD, find and extract the Deploy.CAB file to you hard drive and then execute the SYSPREP.EXE tool. But, with Windows Vista and Windows Server 2008 the SYSPREP file(s) can be found below:

%WINDIR%\System32\Sysprep - ready “out of the box”, just waiting for you to go for it!

And this is the important thing (and the reason why I started this blog): If you want to create a new SID, remember to CHECK the “Generalize” checkbox - or else you have to go all over again…

During the following reboot a new SID is automatically generated - and you will have to type in your Product/License Key, provide a new Computer Name, select an Administrator Password etc.

You may have known this already - personally I didn’t because I tend to use the wonderful Sysinternal NewSID tool for this purpose in most cases (it’s much faster)… However, that tool is not officially supported for Windows Server 2008 (or even Vista) at this time - but hopefully it will be soon?

_

I received an interesting question by mail the other day regarding my article about MLGO on Windowsecurity.com. The question was, if it is possible to export a local policy assigned to a specific user to a user on another computer…?

After scratching my head and researching a bit it seemed like nobody had a good answer for this and no GUI tool is apparently available - so I had to come up with something myself… This is the result:

The following undocumented - and probably unsupported - method worked for me:

On “Source Computer”:
1. Create/modify a local policy for the “Source User”
2. Go to “C:\Windows\System32\GroupPolicyUsers\” and locate the last modified policy folder
- the folder should be named with the SID (Security ID) of the “Source User”, e.g. “S-1-5-21-452792215-1268730067-2626448776-1108″
3. Copy the folder and content to the “Target Computer” into the same directory structure

On “Target Computer”:
1. Rename the newly copied folder to the SID of the “Target User” (the user who should receive the “exported” policy)
- how to find the SID of a local user?
2. Set NTFS permissions on the newly renamed folder to:
- SYSTEM = “Full Control”
- Administrators group = “Full Control”
- “Target User” = “Read & Execute”
3. Test a logon as the “Target User”, the policies should be correctly applied.

Done! Well, the procedure is a bid “odd”, but it could be scripted if required.