PSA: Test your Directory Service Restore Mode Password

Directory Service Restore Mode is what you have to use in order to authoritatively restore things in active directory, like a domain controller. Or something. I've never actually used it outside of a lab until this past week, when I wanted to move where the Active Directory logs were. You can find that process here.

The shocking part came when I needed to boot into Directory Service Restore Mode (DSRM from now on, crikey). On a domain controller (and only a domain controller) you access DSRM by hitting F8 before Windows boot (just like going into Safe Mode) and then choosing DSRM from the list. I made it to safe mode, but didn't know the DSRM password. It wasn't in our password database either. Hmmmm.... and no one else knew it. It's a damn good thing that we weren't in some DR situation where we needed it!

So, please take a minute to check your DSRM password before you REALLY need it. If you need instructions on how to reset it, then look no further.

New Skydrive App for Android

The new app is awesome!

Working With WSUS (Windows Update Server) from the Client Side

WSUS (Windows Software Update Server) is what us admins use (usually) to push out the Windows patches every month. I've had some occasions where my clients were behaving oddly in the past and there are some tricks I've learned over the years on how to deal with this. So, here goes:

If you are imaging machines, it will be easy for the WSUS ID to get stuck in the registry and then propagated out to your computers. You won't notice this unless you compare your real inventory to the computer listed in the WSUS Admin Console. When an ID is used by more than one computer, then your reporting is off. What happens is that ComputerA will check in with ID#4 (The ID's a lot longer than that, but bear with me). ComputerA will get its updates and be happy. Now ComputerB will check in with ID#4. To WSUS, this looks like the computer changed its name. ComputerB will get its updates, too. The problem isn't that the computers won't update. Run that scenario again, but this time let's say ComputerA had errors and patching failed for one or many of the patches. If ComputerB checked in before you ran a patching report, you'll never know that ComputerA had issues.
To combat this, I like to delete the ID from the registry. It's one of the very last things I do when I build/image a new computer. You can do this while the computer's running safely.
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f

After the key is deleted, you should restart the "Windows Update" service. It's important to note that the name of this service is different between Windows XP and Windows 7.
In Windows XP you'd run:
net stop "automatic updates" && net start "automatic updates"
In Windows 7 you'd run:
net stop "Windows Update" && net start "Windows Update"

Or, in Powershell:
restart-service "Windows Update"

That's much easier, but I've been messing with WSUS since before I became Powershell savvy, and old habits die hard....

There's a command to regenerate the SUS ID we deleted from the registry (that's not available in Powershell), and it uses a switch within THE command that Windows manages its updates with: wuauclt.exe.

This is kind of a weird little CLI program, because entering wuauclt.exe /? won't get you anything. The commands I use are as follows:
wuauclt.exe /detectnow - forces the computer to check with it's WSUS server for new updates.
wuauclt.exe /resetauthorization - this is the command that re-registers the computer with WSUS, and generates the new SUS ID.
Note that you can combine the switches on a single line, like this:
wuauclt.exe /resetauthorization /detectnow

Miscellaneous How To's So I Don't Forget!!

I'm using this blog as much for me as for my readers (which I only have a handful of, but whatever). It's another source of documentation, as far as I'm concerned. So today, I've got some neat tricks that I perform fairly often, and I'm sick of searching the web for them every time I need them.

Disk Cleanup in Windows 2008 R2

Did you know that Windows 2008 R2 doesn't come with the Disk Cleanup app installed? I have NO idea what Microsoft is thinking, but it's still on the system; you just have to copy some files and make a shortcut to use it.

• Move cleanmgr.exe from %systemroot%\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da to%systemroot%\System32
• Move cleanmgr.exe.mui from %systemroot%\winsxs\amd64_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_en-us_b9cb6194b257cc63 to %systemroot%\System32\en-US
• Now go back to %systemroot%\system32 and send-to --> desktop (create shortcut), or you can simply type cleanmgr.exe into the run dialog box since system32 is listed in your system path variable.

Bit and Byte Conversion

I found this handy website to convert bits to bytes and vice-versa

Creating Test Files of a Certain Length

Here's a handy command to create test files for testing copy speeds, for instance. Note that you have to run the command prompt as administrator if you have UAC turned on.
C:\> fsutil file createnew <filename> <filesize_inbytes>

For Example (This creates a 1GB file):
C:\> fsutil file createnew C:\Temp\Test_File_1GB.txt 1073741824

Removing Old Patch Installation Files in Windows 2008 R2

Back in Windows Server 2003, one way to reclaim disk space was to delete hidden folders with the $Uninstall prefix from the C:\Windows folder. This would make it impossible to uninstall updates, so you had to be relatively sure that you wouldn't need to do that. There are ways around that: Build a 2003 Test machine, install the update that you need the uninstall files for, and copy the $Uninstall folder for that patch back to the server.

This process was altered in Windows Server 2008 and again in R2. For Windows Server 2008 R2, the command you need to run (as an administrator) is:
C:\> dism /online /cleanup-image /spsuperseded.