The new app is awesome!
Click an Ad
If you find this blog helpful, please support me by clicking an ad!
Tuesday, August 28, 2012
Saturday, August 25, 2012
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
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
Thursday, August 23, 2012
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.
Monday, August 20, 2012
Things get complex, but don't forget to check the easy stuff first
So my Veeam backup solution wasn't performing as I thought it should. Veeam had direct access to my SAN via a 4Gb FiberChannel HBA, and was only pulling around 40MB/s. I was pulling my hair out and finally posted on a forum for assistance. The advice? Check the driver on the HBA card. Lo and behold, the QLogic HBA card was using a MICROSOFT driver. That's just no good. After updating the driver, my speeds went from 40MB/s to anywhere between 130-250 MB/s. Now that's a speed boost!
I think it's important that we as technical people strive to maintain good troubleshooting skills. Sure, the infrastructure gets complicated, but don't ever forget that the best fix might be the easiest. Your internet isn't working? Start from the bottom and work your way up. Sure, it might be a routing issue, but put traceroute away for a minute and check that the network cable is plugged in. Keep it simple, stupid.
I think it's important that we as technical people strive to maintain good troubleshooting skills. Sure, the infrastructure gets complicated, but don't ever forget that the best fix might be the easiest. Your internet isn't working? Start from the bottom and work your way up. Sure, it might be a routing issue, but put traceroute away for a minute and check that the network cable is plugged in. Keep it simple, stupid.
Subscribe to:
Posts (Atom)