Random Musings of Jeremy Jameson : Windows Vista

Update on Patching and Disk Space Usage

Jeremy Jameson — Wed, 03 Jun 2009 17:09:00 GMT

About a year ago, I wrote a post about saving huge amounts of disk space by slipstreaming service packs. Having just been through an ordeal installing Windows Server 2008 SP2, I thought it would be worthwhile to provide an update (since that original post refers to disk space usage with Windows Server 2003).

Note that since my original post, I have switched from using Virtual Server in favor of Hyper-V. Among other things, this allows me to run x64 virtual machines (VMs). Many months ago, I consolidated numerous physical machines onto a couple of "Server Core" machines running Hyper-V. In that time, I've also switched to running Windows Vista x64 on my primary desktop and Windows Server 2008 x64 on my laptop.

One of the things that I've noticed is that x64 versions of the operating system tend to use more disk space than their corresponding x86 equivalents. In particular, the "side-by-side" folder (WinSxS) is typically significantly larger on x64 installations. The storage differences are negligible on my physical machines, but on VMs I make a deliberate effort to "clamp down" the size of the VHDs. This can save me considerable time when copying VHDs from one server to another or from an internal hard drive to an external hard drive whenever I need to take one or more of them "on the road" with me.

Minimizing VHD sizes also allows me to cram more VMs onto my 100 GB external drive [I know, these days this isn't very big from a capacity perspective, but at least it's 7200 RPM (a must for running VMs) and it isn't nearly as bulky as my larger drive enclosure. It also doesn't require a separate power supply either.]

Here is a baseline of the disk space usage on a Windows Server 2008 Standard x64 VM:

Figure 1: Disk usage on Windows Server 2008 Standard x64 VM (baseline)

See full-sized image.

Notice that the total disk usage is about 7.5 GB and the Windows folder consumes a little over 7 GB. Also note that Windows Server 2008 included SP1 (i.e. Microsoft slipstreamed it into the initial installation in order to simplify the servicing model for both Windows Server 2008 and Windows Vista).

I then immediately installed Windows Server 2008 SP2 and captured the following:

Figure 2: Disk usage on Windows Server 2008 x64 VM (after installing SP2)

See full-sized image.

Observe that the Windows folder now consumes a little over 10 GB of storage. Ouch...3 GB for a service pack. That seems a little, um, irritating -- for VMs, anyway. Obviously for physical machines with 100+ GB hard drives, the additional space is trivial.

I then ran the Windows Component Clean tool (COMPCLN.exe) as described in my previous post, which reclaimed approximately 900 MB of space.

Figure 3: Disk usage on Windows Server 2008 x64 VM (after installing SP2 and running COMPCLN.exe)

See full-sized image.

Notice that the Windows folder now consumes about 8.5 GB of space (but the overall free space on the 20 GB VHD increased from roughly 9.7 GB to 10.6 GB). In other words, SP2 adds roughly 3 GB, but COMPCLN.exe trims this to a little over 2 GB.

Lastly, I want to point out the current disk space usage on COLOSSUS -- an x64 VM that I run WSUS (Windows Server Update Services) for managing patches and updates on the various machines in the "Jameson Datacenter." Note that this server only has WSUS (which requires IIS and SQL Server) but nothing else. Consequently, after installing Windows Server 2008 SP2 and running COMPCLN.exe, I was hoping it would have comparable disk space usage to that shown in Figure 3 (after deducting the space used by the WSUS database, of course).

Unfortunately, it isn't even close, as shown in the following figure.

Figure 4: Disk usage on a patched WSUS server (after installing SP2)

See full-sized image.

Notice that the Windows folder on COLOSSUS consumes almost 16.5 GB of space, of which roughly 10.5 GB is used by the WinSxS folder.

The lesson here is that you should expect some "bloat" in the Windows folder over time (largely due to the WinSxS folder), and while the Windows Component Clean tool (COMPCLN.exe) undeniably reclaims some hard drive space after installing SP2, it's definitely not the same as starting with a "fresh" SP2 install.

Reclaiming Disk Space After Installing Service Pack 2

Jeremy Jameson — Tue, 02 Jun 2009 16:39:00 GMT

In yesterday's post, I noted the errors I encountered when trying to install Windows Server 2008 Service Pack 2 (SP2) due to "insufficient" disk space. I ended up having to expand numerous VHDs (one for each of my VMs running Windows Server 2008 x64) in order to have roughly 5 GB of free space to allow SP2 to install.

Note that SP2 certainly didn't use the 5 GB of free space, but apparently it insists on having that much for some "factor of safety" during the install.

Note that SP2 for Windows Server 2008 and Windows Vista include a new tool which helps recover hard disk space: the Windows Component Clean Tool (COMPCLN.exe). According to the Windows Server 2008 SP2 Deployment Guide this tool permanently removes the files that are archived after Windows Vista SP2 or Windows Server 2008 SP2 is applied. It also removes the files that were archived after Windows Vista SP1 was applied, if they are found on the system.

The deployment guide also states that "running this tool is optional" -- however I, personally, highly recommend it. Of course, you have to weigh this decision with the probability that you will need to uninstall SP2 -- which, in my case, is essentially "zilch."

On my x64 VMs, running COMPCLN.exe freed up roughly 800 MB of disk space. This might not seem like a lot -- given that many hard drives these days exceed 1 TB -- but it is very significant on VHDs that you are trying to keep as "lean" as possible.

Note that I'm still a little disappointed in the disk space requirements for SP2. Up until yesterday I had been running each of my domain controller VMs on 16 GB VHDs, and many of my other VMs on 20-22 GB VHDs. Note that on some of those VMs, disk space was certainly getting tight -- due to all of the patches that have been installed since I originally built them -- but they were functioning just fine until Windows Server 2008 SP2 came along. Although I have to say that on a 20 GB VHD, a WinSxS folder consuming 8-10 GB seems a little ridiculous.

I ended up having to expand the system VHD for my MOSS 2007 development VM to 25 GB -- which I really didn't want to do -- since it essentially gives the SharePoint Unified Logging System another 5 GB of free space to fill with useless log messages. [That is, of course, until I get the April 2009 Cumulative Update installed -- which supposedly fixes this issue.]

Errors Installing Windows Server 2008 SP2

Jeremy Jameson — Mon, 01 Jun 2009 17:14:00 GMT

Last week I approved Windows Server 2008 Service Pack 2 (SP2) and Windows Vista SP2 on my local WSUS (Windows Server Update Services) server. My expectation was that the various physical and virtual machines in the "Jameson Datacenter" would subsequently install the update around 3:00 AM the following morning.

Unfortunately when I examined the WSUS console this morning, I found a number of computers reporting errors. After selecting one of the failed computers, I discovered the following:

Windows Server 2008 Service Pack 2 Standalone x64-based Systems (KB948465) - English, French, German, Japanese, Spanish

Event reported at 6/1/2009 3:02 AM:

Installation Failure: Windows failed to install the following update with error 0x80070643: Windows Server 2008 Service Pack 2 Standalone x64-based Systems (KB948465) - English, French, German, Japanese, Spanish.

A quick search for 0x80070643 led to the following KB article:

You receive error code 0x80070643 or error code 0x643 when you use the Windows Update or Microsoft Update Web sites to install updates

http://support.microsoft.com/kb/958052

Unfortunately, this error code indicates "generic errors that basically state that an error was encountered by Windows Installer." Rather than immediately following the steps in the KB article to enable logging and try to reproduce the problem, I decided to take a quick look at the event logs and discovered the following:

Log Name: System
Source: Microsoft-Windows-Service Pack Installer
Date: 6/1/2009 3:02:00 AM
Event ID: 8
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: dazzler.corp.technologytoolbox.com
Description:
Service Pack installation failed with error code 0x800f0826.

Another quick search for 0x800f0826 suggested that the problem might be due to insufficient disk space. However, I checked the free space on DAZZLER and observed that it had 4.09 GB free. Surely, 4 GB of disk space is sufficient to install Windows Server 2008 SP2!

Then I came across the following:

Windows Server 2008 SP2 Deployment Guide

http://technet.microsoft.com/en-us/library/dd351467(WS.10).aspx

Here are the disk space requirements according to the deployment guide:

Disk Space Requirements for Windows Server 2008 SP2
Installation method	Approximate disk space requirements
Stand-alone installation	x86-based: 1.8 GB to 2.9 GB x64-based: 3.2 GB to 4.9 GB ia64-based: 2.9 GB to 3.2 GB
Windows Update	x86-based: 350 MB x64-based: 600 MB ia64-based: 2.25 GB
Integrated installation	x86-based: 9 GB x64-based: 12 GB ia64-based: 13 GB

Crikey! According to this table, DAZZLER needs up to 4.9 GB of free space in order to install the Service Pack (since it is an x64 VM). Wow!

This, quite honestly, seems absolutely absurd!

However, given that it is relatively easy to expand a VHD, I decided to just go ahead and add another 2 GB to the system drive on the VM and see if that eliminated the issue. After all, as long as SP2 doesn't actually use 4.9 GB of space, then the actual physical space consumed by the VHD should be significantly less than 5 GB.

Using Hyper-V Manager, I expanded the VHD from 20 GB to 22 GB and then started the VM up again. I then logged into the VM and used the Disk Management console to extend the volume to include the additional 2 GB of available storage.

Next, I kicked off the installation of Windows Server 2008 SP2 again. This time the installation completed without error. Woohoo!

Note that DAZZLER is a dedicated Team Foundation Server "build server" -- so I didn't expect that it would need lots of disk space. In fact, it didn't -- at least not until Windows Server 2008 SP2 came along.

Now all I have to do is add some more disk space to the other servers that are failing to install SP2.

Redirecting stderr to stdout

Jeremy Jameson — Fri, 27 Mar 2009 14:29:00 GMT

Yesterday I replied to an email from a teammate in which I incorrectly stated that you can't redirect stderr to stdout in DOS -- er, I mean a command window in Microsoft Windows.

I would have sworn the last time I tried something like the following in Windows Server 2003 (a couple of years ago), I got an error message:

"Redeploy Features.cmd" > tmp.log 2>&1

Fortunately another teammate on the thread, Prashant Nayak, experimented with this and confirmed that it actually does work. Thanks, Prashant, for setting the record straight!

Fiddler + WPAD - VPN = SlowPerformance

Jeremy Jameson — Fri, 27 Jun 2008 19:57:00 GMT

I needed to look at some low-level HTTP traffic this morning, so I fired up Fiddler -- my tool of choice for this kind of thing. Unfortunately, I found that as soon as I enabled Fiddler, my browsing experience slowed to a crawl. Page requests that previously completed in 1-2 seconds were subsequently taking 30-40 seconds. Ugh!

Since I typically work inside a virtual machine running Windows Server 2003, I thought that maybe I was hitting a problem specific to Fiddler on Vista. I then did a quick Windows Live Search using the terms Fidder Vista slow and quickly found a couple of people -- apparently including Eric Lawrence, himself -- referring to disabling IPv6 within Fiddler when using Vista. I assumed that this must be the problem that I was encountering, but no matter what I tried (e.g. restarting Fiddler after disabling the option, repeatedly enabling and disabling IPv6, etc.) I couldn't get the performance to improve.

I then fired up Network Monitor 3.1 and performed a quick trace while I requested the page through Fiddler again. [By the way, I absolutely love the new filtering capabilities in NetMon 3.1 versus the old version. The interface is much more intuitive than the old 2.x version and it couldn't be any easier than right-clicking a frame in the capture and selecting Add Cell to Display Filter. NetMon Team, you guys rock! I haven't quite got around to downloading the 3.2 beta, but hopefully someday soon.]

Also note that I had to right-click Microsoft Network Monitor 3.1 and click Run as administrator in order to avoid the dreaded "Unknown Error" that occurs when no networks are detected to capture.

So, a couple of minutes later, sure enough, there it was right in my capture:

DNS: QueryId = 0x18FC, QUERY (Standard query), Query for wpad.northamerica.corp.microsoft.com of type Host Addr on class Internet

As soon as I saw the old "Web Proxy Auto Detect" I immediately became suspicious that this was the culprit. I then closed Fiddler and modified my Internet Explorer options to clear the Automatically detect settings checkbox.

Shazam! Problem solved.

Of course, had I actually been connected to CorpNet (which would have enabled DNS requests for "wpad.northamerica.corp.microsoft.com" to resolve), I suppose I wouldn't have encountered the problem in the first place.

Perhaps it is the fact that I am frequently connecting to different networks (e.g. wireless, VPN, etc.) -- whereas many others don't -- but I'd really like to think most people don't encounter little gotchas like this. The mere thought of having to guide my mother through capturing a NetMon trace is, quite frankly, horrifying ;-)

Disabling Hibernation in Windows Vista (and Deleting Hiberfil.sys)

Jeremy Jameson — Mon, 18 Feb 2008 05:33:00 GMT

As I described in my previous post, I found myself with a paltry 320 MB of free space on a 20 GB partition after installing Windows Vista and a handful of programs (which although I specified to install on a different partition, ended up "bloating" my system partition to an unmanageable point).

In order to free up some much needed space, I decided to disable hibernation, which would seem like a straightforward process. In fact, if memory serves, this was actually quite easy in Windows XP. However, in Vista, disabling hibernation and deleting the corresponding system file is a little tricky. Note that on my laptop with 4 GB of RAM, C:\hiberfil.sys consumes about 3.37 GB -- which I really need back, thank you very much.

My initial assumption was that the option to disable hibernation lies somewhere in the Power Options area of the Control Panel. However, after poking around in there for a few minutes and not finding it, I proceeded to perform a search in Control Panel for "hibernate" which displayed the following result:

Turn hibernation on or off

Perfect...this looks like precisely the option I was looking for. Unfortunately, when I clicked this link, it just took me back to the Power Options area that I had already thoroughly explored. Figuring I had simply missed the obvious, I proceeded to set the following options under advanced power settings:

Sleep

Hibernate after

On battery: Never

Plugged in: Never

Note that setting the value to 0 minutes is the same as saying "never hibernate." Okay, so now I should be able to delete the massive hiberfil.sys file, right?

Wrong.

Okay, so I guess Vista still has a lock on the file since I haven't rebooted since I "disabled" hibernation. Fine, I'll reboot my laptop. Now, I should finally be able to delete hiberfil.sys, right?

Still wrong.

Come on now...be reasonable...what's it going to take to delete that file?

It turns out that the way you delete hiberfil.sys is by using the Disk Cleanup utility.

To delete hiberfil.sys in Windows Vista:

Start Disk Cleanup.
On the Disk Cleanup Options window, click Files from all users on this computer.
On the Disk Cleanup: Drive Selection window, click select the system drive where Windows Vista is installed, and then click OK.
Wait for the utility to scan the drive and then in the Disk Cleanup window, click the checkbox next to Hibernation File Cleaner, clear all of the other checkboxes, and then click OK. When prompted to confirm the operation, click Delete Files.

After performing these steps, the free space on my Windows Vista partition (C:) increased from 320 MB to 3.66 GB. Woohoo!

That should get me going for a while -- or at least until I decide to install a few more programs on E: ;-)

An Update on Disk Space Usage by Windows Vista

Jeremy Jameson — Mon, 18 Feb 2008 04:35:00 GMT

Today I rebuilt my laptop to allow me to dual boot between Windows Server 2008 and Windows Vista. To enable this configuration, I created the following partions on my hard drive:

20 GB - Windows Server 2008 x64
20 GB - Windows Vista Ultimate x64
53.2 GB - Program Files and Data

Here is what my Vista partition looked like immediately after the baseline installation (no patches):

Figure 1: Disk usage on Windows Vista Ultimate x64 (baseline)

See full-sized image.

From this, you can see that about 10 GB of the 20 GB partition is needed to install Windows Vista Ultimate x64.

In order to free up some substantial disk space, I dialed the paging file down from the default (around 5 GB) to an initial size of 200 MB with a maximum size of 512 MB. I have 4 GB of RAM on this laptop -- so in my mind, if I start needing more than 500 MB of swap space, something is horribly wrong and it's probably time for a reboot anyway.

I then proceeded to install the following:

Windows Vista Service Pack 1 (SP1)
Microsoft Office Ultimate 2007 -- mostly using the default options but excluding Groove
Microsoft Office Communicator 2007
Microsoft Visio Professional 2007
Microsoft Project Professional 2007
Microsoft Visual Studio Team System 2008 Team Suite -- mostly using the default options but excluding Crystal Reports and including x64 compilers and tools
Microsoft Expression Blend
Microsoft Expression Web

Note: During each setup, I changed the drive letter from C: to E: in order to place the bulk of the program files on the large 53 GB partition -- not the "small" 20 GB partition.

I then configured Vista to use my WSUS (Windows Server Update Services) server in the "Jameson Datacenter" (a.k.a. my basement), so that patches only need to be copied over my LAN -- not downloaded from the Internet each time.

Windows Update then proceeded to install the following:

Definition Update for Windows Defender - KB915597 (Definition 1.27.6677.0)
Hold Em Poker Game -- I guess I am the only one to blame for this one, since I am the WSUS administrator and therefore the one who approves or declines all patches
BitLocker and EFS enhancements
Windows DreamScene
2007 Microsoft Office Suite Service Pack 1 (SP1)
Update for Outlook Junk Email Filter 2007 (KB943597)
2007 Microsoft Office Suite Service Pack 1 (SP1) -- this was applied again after rebooting, perhaps to pick up additional patches for Visio and Project

After rebooting a couple of times, my Vista partition looks like this:

Figure 2: Disk usage on Windows Vista after installing SP1, Office 2007, VS 2008, and Expression

See full-sized image.

If you look closely, you'll notice that I only have 320 MB of the 20 GB free. Ouch.

When I started the rebuild today, I thought 20 GB would be sufficient, but now I am wishing I had used two 25 GB partitions instead of two 20 GB partitions.

While I actually contemplated "nuking" the machine again and starting out with larger system partitions, I am going to try getting by with this configuration for a little while. However, I don't have any expectations of running with a mere 300 MB of free space. Instead, I am going to completely disable hibernation, thereby freeing up an additional 3.5 GB of disk space (by deleting the hiberfil.sys).

Unfortunately, disabling hibernation (and deleting the associated hiberfil.sys file) wasn't very straightforward in Vista. Actually, this was really the driving factor behind this post and the one that follows (I don't expect many people to find graphical depcitions of disk space usage to be all that interesting).