Blog: SBS

I had an issue where wsus on a Windows SBS 2008 system was saying it was synchronizing successfully, but it wasn't downloading updates. All you would get was a message in the event logs from Windows Server Update Services (event id 10032) saying that "The server is failing to download some updates". Clients would show that they needed updates through the WSUS console and via the SBS Console, but the updates would never show up on the server for installation. In the local client WindowsUpdate.log file you would see something similar to the following [more]

2010-10-12  10:39:45:574  784  1a20 PT       +++++++++++  PT: Synchronizing server updates  +++++++++++
2010-10-12  10:39:45:574  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:49:011  784  1a20 PT       +++++++++++  PT: Synchronizing extended update info  +++++++++++
2010-10-12  10:39:49:011  784  1a20 PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://...
2010-10-12  10:39:52:433  784  1a20 Agent  * Found 0 updates and 57 categories in search; evaluated appl. rules of 643 out of 1075 deployed entities

So why would the WSUS server recognize the server needed updates and the client not recognize and download them? Further investigation uncovered the fact that the WSUS Content Repository was nearly empty. Total size of the repository was less than 100 MB. Obviously, none of the patch data had been downloaded.

So why was the sync successful? Moving on, after more investigation, I discovered that the ISA server was blocking what appeared to be anonymous web traffic from the SBS server even though there was a access rule set to allow all http, https, and ftp traffic from the SBS server. So, skipping to the solution. First, ISA 2004 has a problem with BITS 7.0 that is used in Windows 2008 and Windows 7. Because the initial synchronization from WSUS ONLY downloads metadata, ISA was letting that out and it would show success in the consoles. Then WSUS turns over processing and downloading of the actual patch files (.cabs, etc.) to BITS. ISA was blocking BITS background download processing so what we had was metadata for the updates, but no updates. WSUS knew the servers needed the updates, but the servers had nothing to download because the actual content for the updates wasn’t there. The fix is to change the processing of update downloads using BITS from a background to a foreground process. ISA seems to allow that just fine.

Do it by running the following query against the WSUS database. The connection can be made via SQL Management Studio Express in most cases…you are just looking to run the query against the SUSDB database.

update tbConfigurationC set BitsDownloadPriorityForeground=1

If you are using Windows 2008 with the Microsoft Internal Database (as SBS 2008 does), this proves to be a little more challenging because you have to connect with SQ Management Studio Express using named pipes instead of TCP/IP. Connect using named pipes by using this as the server

\\.\pipe\mssql$microsoft##ssee\sql\query

Changing Product Key on Windows 2003 (and SBS2003):  I needed to change the product key on a SBS machine that was virtualized from an IT consulting customer’s machine. I did not want to re-activate the SBS machine using the customer’s key since the machine was still active and did not want to interfere with the proper operation of the production machine. I needed to install our MSDN key since this is the proper usage for that type situation.

In order to do this, when the product ask you to activate, chose the option to telephone a customer service representative to activate Windows.  Then when the Activate Windows by phone comes up, chose the “Change Product Key” at the bottom to enter the new product key. Then cancel out of this operation and activate the windows over the internet as usual. [more]

Small Business Server 2008 has several "Connect to the Internet" wizards under Getting Started Tasks in the SBS Console.  Depending on your order of setup, running the "Set up your Internet Address" task may activate DHCP without telling you it is doing so.  A key problem here is that, when activating it, a scope is auto-created which includes the entire subnet on which the SBS server sits.  The only exclusions auto-created might be the SBS address and that of the SBS’ gateway.  This could occur on a production subnet and cause IP-address conflicts with other live devices if not noticed quickly.

I am doing an SBS 2008 install at a customer and have run into the whole x86 / x64 print driver problem. The SBS box is x64 and that is where I wanted to install the network printers. The terminal server is x86. I did some research on the driver compatibility and universal printer drivers and decided for simplicity sake to use the HP universal print driver. I got everything installed, but during testing a couple of the printers (specifically the HP 4050 series LaserJet), I had a very weird problem come up. Every time I printed something, the printer would display “waiting on manual feed tray” as if the job was specifically targeting that tray. Even when I statically set the default tray in the driver config, it would try to pull from the manual feed tray….ahh the joy of printers. Well, after about an hour of troubleshooting, I tried changing what seemed like a very unrelated setting. [more]

Notice the Paper type is unspecified. By default that is set to "HP Tough Paper" on this model of printer. If that setting is not changed, it defaults back to the manual feed tray NO MATTER WHAT. Does the gremlin in the printer know what type of paper is loaded…well, apparently so. Do yourself an favor and set it to “Unspecified”.