Blog: Windows 2008 Server

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

When I logged onto a customer’s terminal server/dc, the c: was completely out of space.  I loaded Space Monger and saw that most of the files taking up room were in c:\program files\sav in .xdb files.  I ran disk cleanup and compressed old files which freed up about 5 GB.

I then started researching what was downloading the xdb files.  I saw that they were dating back to almost 60 days ago and every day since.  Each file was approximately 100 MB. 

I looked at all of the Symantec products on their system and talked with the person who had updated Symantec Antivirus (SAV) to Symantec Endpoint Protection (SEP).  He asked me to check the scheduled tasks, and I discovered that there was a scheduled task that ran to download definitions to the old SAV program before they were upgraded to SEP.  I disabled the scheduled task and deleted the xdb files to finish cleaning up an additional 4 GB space.

Windows 2008 and IIS 7.0 installs with Secure Sockets Layer (SSL) version 2 and “weak” cryptography ciphers turned on by default.  Having that turned on will likely turn up some problems in a penetration test.  Here are some common vulnerabilities names that might be identified in your penetration test results:

• SSL Server Supports Weak Encryption
• SSL Server Allows Cleartext Encryption
• SSL Server May Be Forced to Use Weak Encryption
• SSL Server Allows Anonymous Authentication [more]

Disabling 

Unfortunately, there is not currently an intuitive way to enable/disable the protocols and ciphers built into the Windows GUI.  You must edit your systems registry to get the job done.  Some of the registry keys and DWORDs will likely not be in the registry, so you will need to add them. It’s always a good idea to back up your registry before making changes just in case something goes wrong.  Click Start, click Run, Type regedit32 or type regedit, click OK, and then add/modify the keys listed below.

Here are the registry keys to turn off PCT 1.0 and SSL 2.0 and leave SSL 3.0 and TLS 1.0 turned on:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server
  • DWORD = 1
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
  • DWORD = 1

Here are the keys to turn off “weak” SSL ciphers:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128
  • DWORD = 0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128
  • DWORD = 0

Testing

The easiest way I’ve found to verify the protocols and ciphers are turned off is to use the free OpenSSL toolkit.  Here are some instructions for installing Cygwin with OpenSSL on Windows 7: https://www.conetrix.com/Blog/post/How-to-Install-OpenSSL-on-Windows-7.aspx.  Here are some instructions for installing OpenSSL on Ubuntu: https://help.ubuntu.com/community/OpenSSL#Practical OpenSSL Usage.  If you are using a Mac OpenSSL should already be installed.  Once you get it installed you can verify your registry changes worked.

Once you get it installed here is the commands you can use to verify that SSLv2 is turned off:

# openssl s_client –ssl2 –connect YOURSERVERNAME:443

If server does not support SSLv2 then you should see an error like the following two examples:

CONNECTED<00000003>
Write:errno=113

Or

CONNECTED<00000003>
1324:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

Here is the command to test for weak ciphers:

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

If the server does not support weak ciphers then an error will be displayed similar to the error examples given above.

The traditional program switch to “fix” a hard disk drive may not fix everything. I have used chkdsk /f to fix disks for years, but it turns out that there is also a chkdsk /r . The /r switch does everything a /f  does and additionally checks for bad sectors on the disk.

I ran into a very interesting 32/64-bit problem the other day that looks to me like Microsoft has goofed. The issue involved installing the x64 version of WSUS on Windows 2008. In Windows 2008, WSUS is now a feature and can be installed without a download.  During setup of one of our new customers, WSUS was installed on an x64 Windows 2008 server that was currently hosting some .NET web services in IIS. After the install of WSUS, the web services would return a 500 error for every request. The error page noted a problem with DynamicCompressionLibrary. After much digging, the problem was caused by installing the x64 version of WSUS alongside x86 web applications in IIS. [more]

When WSUS is installed, it installs a dynamic compression library called suscomp.dll globally in IIS. This compression library is used to compress updates before they are streamed down to clients via BITS. However, due the inherited nature of .NET configuration (web apps inherit global settings in IIS), these .NET web services were looking for the x86 version of the suscomp.dll (search path is by default at c:\windows\SYSWOW64\) which WSUS DOES NOT install. It installs the x64 version (default path at c:\windows\system32\). Without a matching suscomp.dll compression library, the inheritance chain is broken, and you will get 500 internal server errors. This could all be avoided if Microsoft would just include the x86 version of suscomp.dll in the install of x64 WSUS. The fix is to find an x86 version of suscomp.dll (from another install of WSUS) and copy it to c:\windows \SYSWOW64\ and do and iisreset. Thanks Microsoft!

When new user profiles are created on a server, it is worthy to note that the profile gets created from the “All Users” profile.  Since the “All Users” group is used as a template in creating the new user’s initial profile, it is important that any settings in the “Application Data” directory that users need also be copied to the “All Users\Application Data” directory also.  This should prevent any problems with new users having different settings than other users that may have had their settings adjusted.

A couple weeks ago, one of our customers had their Exchange SCR copy fail due to a corrupt log file. At first we assumed that the log file was corrupted during transit to the DR site, but after recopying the log file over multiple times and attempting to restart replication, we realized the log file was actually corrupted on the source server which is a virtual machine. I had never seen this happen before and was a little surprised that the corrupt log file had not taken the mailbox database offline. With nothing to attribute the corruption to, I decided it must have been a fluke and started a database reseed the following weekend. After 3 days, the database seeding finished, but 4 hours after the reseed completed, the SCR copied failed again…another corrupt log file. [more]

I decided there must be a bigger issue. I reviewed the logs and found numerous eventid 7 errors (bad block on disk) and a few pvscsi warnings. It seemed logical that maybe the paravirtualized SCSI adapter that was being used on this virtual machine may be causing an issue…maybe it was a weird PVSCSI / Windows 2008 server problem. I had to take a break from this issue to troubleshoot another server issue for the same customer. In doing so, I had an idea…what if the physical disk is going bad, but hadn’t completely failed. Could that cause the underlying VMware VMFS partition to look fine but cause problems with virtual disk files attached to VMs. I used iLO to check out the hardware status and sure enough one of the disks had encountered numerous SMART errors and was marked “impending failure”. The array was not degraded yet because the disk had not completely failed. I have replaced the disk and will reseed the database soon, but since replacement there have been no bad block on disk errors on this VM so it looks promising.

On Windows Server 2008, I was trying to get Java installed, but Internet Explorer kept saying that I was unable to download the file because of my security settings.  My options for changing the security zone settings were grayed out, and adding the Java website to my trusted sites did not work.  I investigated whether group policies were blocking my ability to edit the zone settings, but it turned out that there were no IE-related group policies.  It turned out that I had to run IE as an administrator (right-click and select “run as administrator”) to get access to the zone settings.

Using Windows Powershell, you can get timestamps for creation, last access, and last write times. 

Examples:

• PS>$(Get-Item ).creationtime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
• PS>$(Get-Item ).lastaccesstime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
• PS>$(Get-Item ).lastwritetime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")

Another thing that the Powershell can be used for is setting the timestamps to whatever value you want.  It can be future or past.

Here is an example of setting the last write time of file “test.txt” to 1-1-2020:

• PS>$(get-item test.txt).lastwritetime=$(set-date "01/01/2020")