I’ve had this issue more often than I’d like to actually care to remember.

First thing I check is website security settings:

Open IE
Select Tools
Select Internet Options
Click on the Security Tab
Click on the Trusted Sites button (check mark)
Click on the Sites button
Add https://update.microsoft.com, http://update.microsoft.com, and any other microsoft update related sites

Next thing I generally check is if the Trusted Sites are actually being trusted

Open IE
Select Tools
Select Internet Options
Click on the Security Tab
Click on the Trusted Sites button (check mark)
Click on the Custom Level button
Make sure that the security is at Medium or below (Medium, Medium Low, or Low) – I generally put this at Low

After that make sure that the following services are enabled:

Start
Run

services.msc

Automatic Updates/Background Intelligent Transfer Service (BITS)

Finally, if nothing else works, turn off Automatic Updates and remove the SoftwareDistribution folder

Start
Run

services.msc

Right-Click on Automatic Updates and select Stop
Start
Run

%windir%\SoftwareDistribution

Open the DataStore folder
Delete everything inside
Right-Click on Automatic Updates and select Start
Retry the Windows Update

I was having issues with my 2008 servers clocks: they were running fast. After 30 days they were 2 minutes fast. 90 days they were 6 minutes. You can guess how fast they were after 120 days. Yay math!

In XP and 2000 one could simply open up the date and time control panel (or double click on the clock) and, through some tabbed Internet Time, select a predetermined NTP server. Maybe I’m just blind, but I couldn’t find the option in 2008 or vista. It could be one of my GPO’s blocking said option. In any case, my clients were all receiving this “fast” time. Not good.

To fix:
Open up an administrative command window (windows key + r works wonders for me)
Set the NTP server to time-nw.nist.gov
net time /setsntp:time-nw.nist.gov
Make sure that the NTP server has been saved
net time /querysntp
See where you’re grabbing your NTP information from (usually a domain controller)
net time
Actually corrects the time to your NTP server
w32tm /resync

One of the good things about Windows Server versus XP is the number of connections that you can have. XP is limited to 10 connections, Server is not limited. XP is limited to a single console connection and no RDP, Server is limited to a single console connection and two other RDP connections (total of 3).

One of the bad things is that in order to get your server to allow more than 3 simultaneous connections you need to install, and license, terminal server. Then you need to convert the server to run in Application Mode. Lots o’ fun. Our company made the mistake of installing a proof-of-concept of terminal server on a non-domain controller and non-production server. The server then died. And in order to retrieve the licenses, we’d have to contact the fine folk over at Microshaft and explain the situation, then get the new license keys, and then create the new server, and then configure the other servers to run in application mode. And hope it all works.

So I did it the easy way – hack the termsrv.dll file.

FYI hacking Microsoft files is a breach of the terms of service agreement and license agreements with Microsoft. Do so at your own risk.

First I will post how I went about “hacking” said file and how to implement in your own environment.
Unfortunately I can’t post the hacked file due to legal issues. So there is no “hey, here’s the file if you’re lazy”.

Now I’ve only tested this on Windows Server 2003 standard and enterprise, R2 and regular. ALL 32bit. I’m sure it’ll work on 64bit, but we have no needs to allow more than even the single console session on our 64bit servers.

Download the following files:
http://it.thelibrarie.com/utilities/vpatch32.exe
http://it.thelibrarie.com/utilities/2003tspatch.zip

Install the vpatch32 program (works on XP and Vista32/64)
Unzip the 2003tspatch.zip to find a PatchData.pat file
Copy the termsrv.dll file from your server’s WINDOWS\system32 folder to your desktop (easier to find, and you can’t patch an ‘in-use’ file)

Open vpatchprompt.exe located in %programfiles%\VPatch\
This will prompt you to find the PatchData.pat file you unzipped
Then it will prompt you to find the file you want to patch, in our case it’s the termsrv.dll residing on your desktop
Then choose a file name and the program will save the patched dll as this new name. I chose termsrvNEW.dll to keep it easy to locate.

Now the tricky part – because Windows has built-in protection for system files, we have to go about this in a trick-defeating manner.

On your server, locate the file in WINDOWS\system32\dllcache\termsrv.dll
Rename this file termsrvOLD.dll
Now locate the termsrv.dll file in WINDOWS\system32\
Rename this file termsrvOLD.dll as well
Copy the termsrvNEW.dll to WINDOWS\system32\
Rename this file to termsrv.dll

Windows will generally complain that a file has changed. Let the OS know who’s boss and that you want to keep the file. Now, reboot.

Test – if anything breaks you can always undo the files by using your old one again. If it all goes as planned, you can now have unlimited RDP connections to your server.

Yay!

***EDIT***
If you change the files and Windows changes them back, that’s the built-in security DEP of Windows. You may have to start in Safe-Mode (F8 before the black Windows Screen but after the BIOS) in order to edit these files.

***EDIT PT 2***
Before I could respond to a comment left by an anonymous internet troll, I did some extra research into the matter.
http://www.remkoweijnen.nl/blog/2008/12/09/windows-2003-x64-terminal-server-patch/ <--- apparently that will work on 64bit SP2 or R2 of Win2k3. I haven't tested it, so I won't comment further unless I need to apply this patch as well.

I had an issue of a printer showing up as offline even though it was most certainly online. I could ping it from the print server, and I could view the html pages for the configuration of said printer, but the print server was still listing it as offline. WTF, eh?

Then I came across a hotfix from Microsoft that says if the printer uses SNMP for certain communication that if it goes offline at any time there is a possibility that the printer will show offline even if all other communication works. The fix is as follows:

ON THE PRINT SERVER/HOST:
Open Regedit
start > run > regedit
Locate the Print key container
HKLM\SYSTEM\CurrentControlSet\Control\Print
Add a DWORD value to the print key container
Right-click and add DWORD Value
Give the DWORD key the name of SNMPLegacy
Set the SNMPLegacy key to 1
Close out of the registry editor

Now reset the print spooler service:
Start > run > services.msc
Find print spooler, right click, restart service
Test