Once you have installed Service Pack 1 for Server 2008 R2 or Windows 7, you can remove the installation files if you won't be uninstalling the service pack.

Online image: DISM /online /cleanup-Image /SPSuperseded

Offline image: DISM /image:<Root Path of Offline Image> /cleanup-Image /SPSuperseded

This is handy to do post-Sysprep and pre-ImageX.

We encountered a strange one today that may not affect many folks out there, but after three hours of mind numbing troubleshooting (and some Wireshark Ninja Skillz), I figured it would be worth passing along what's happening here...

Server 2008 R2 DNS Service by default supports DNSSEC.  This is a long-awaited feature for many of us, and is generally a good thing.  However after migrating our DNS services to R2, we noticed quickly that we were no longer able to resolve *.internet2.edu addresses.  When we looked at packet captures of this traffic, we could see the request leave our server, but the response from the destination DNS server showed up in Wireshark as "Fragmented IP Protocol", and we were only seeing one of the fragmented packets (the first packet transmitted by the responding DNS server) getting to our R2 server.

When we did the same packet capture against our old Server 2008 SP2 DNS server, that same behavior did not occur.  We examined the difference between the request packet sent by the 2008 SP2 box versus the 2008 R2 box, and noticed that R2 is requesting DNSSEC information on each request.  For most domains there is no DNSSEC information to return, and thus the vast majority of the Internet worked correctly.

We brought our firewall guy in on the problem and he began poking around in that space.  We eventually determined that the information being returned to R2 based on it's request for additional DNSSEC information exceeded the 1514 byte size limit on the Ethernet frame, causing the response packet to become fragmented.  This alone should be handled gracefully by the OS, but in our case we had an upstream firewall that was configured to block these kinds of packets (not the first fragmented packet, only the trailling packet fragments), which caused our DNS server to think that it never received a response from the queried DNS server.

Reconfiguring the upstream firewall to allow those fragments through to just our DNS servers solved the issue, and we're now running our DNS services on Server 2008 R2 without error.

Great success!

Somewhere in the neighborhood of about 2006, Microsoft's HTML help viewer application stopped gracefully opening CHM (compressed HTML help) files consistently.  I've noticed this problem on XP, Vista and Win7, across rebuilds, across browser versions, nearly universally.  There's a lot of advice out there about how to make Windows open CHM files correctly when faced with a content pane in the viewer application that reads "Navigation to the webpage was cancelled", however on my Windows 7 x64 workstation nothing worked.  A quick Google search this morning yielded a handy little utility called CHM Decoder that will extract the HTML content from a CHM file, allowing you to view the contents within a web browser.  Great stuff!

http://www.gridinsoft.com/chm.php

1. Download the Windows Automated Installation Kit for Windows 7 (WAIK) - http://www.microsoft.com/downloads/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en 

2. Start | All Programs | Microsoft Windows AIK | Windows PE Tools Command Prompt -> This command prompt preloads the necessary folders into the path variable for easy image editing. Make sure to Run as Administrator!

3. copype.cmd <x86 | amd64 | ia64> <destination folder to create, ex: z:\PEBuild> This script creates a workspace for manipulating WinPE images prior to burning a CD or copying to a flash drive.  The ISO folder contains the files used for both.  The file ..\PEBuild\ISO\Sources\boot.wim is the actual WinPE image that the bootloader extracts to a RAMDisk when WinPE boots.  The copype.cmd also creates a second copy of the WIM called winpe.wim in the root of the PEBuild folder - this provides you with an easy way to make a "start fresh" with a new WinPE boot image if necessary.

4. To place tools or files within the ISO (on CD) or on the flash drive you will boot from, copy the files to the z:\PEBuild\ISO folder.

5. To place tools or files within the RAMDisk that WinPE boots from (which is useful to retain access to tools, such as Imagex, when you pull the flash drive or CD from the computer upon which you will boot into WinPE), use this command: imagex /mountrw ISO\Sources\boot.wim 1 .\mount  ->  This mounts the WIM file to the mount folder within your PEBuild workspace. (Note that DISM.exe can be used in place of Imagex if you prefer.)  This step is also necessary to perform driver servicing on the WinPE boot image, as discussed in step 6 below.

6. To load additional drivers into a your WinPE image, use the following command after proceeding with step 5 above): Dism /image:<path_to_image> /Add-Driver /Driver:<path_to_driver.inf>  Note that this command must be run against a mounted WIM file (performed in step 5 above).  For more on driver servicing and WinPE, see the following article on TechNet: http://technet.microsoft.com/en-us/library/dd799258(WS.10).aspx.

7. When you are finished editing the WIM file, do this: imagex /unmount /commit .\mount

8. Make sure to copy ImageX to your ISO folder so you can apply an image to a hard drive.  Use this command: copy "c:\Program Files\Windows AIK\Tools\x86\imagex.exe" z:\PEBuild\ISO

8. WinPE is now ready to go.  Either burn the entire contents of the ISO folder to a CD marked as bootable (step 9), or copy the entire contents to a flash drive (follow the steps listed here to prepare your flash drive).

9. If you intend to create a bootable CD, you'll need to use the following command to create an ISO from the files in the ISO folder (using the PE Tools Command Prompt): oscdimg -n –bz:\PEBuild\etfsboot.com z:\PEBuild\ISO Z:\PEBuild\winpe_x86.iso  You can then burn the resulting ISO to disk.

Here, are instructions for integrating the Hyper-V RTM (!) Integration Components device drivers into a WinPE image.  This is based on Mike Sterling's post on the same topic, however the scripts below have been updated to use RTM Hyper-V bits.

1. Create your WinPE build folder, if you haven't already done so.  See Building a WinPE Image from Scratch for help (follow only steps 1 through 5).
2. In the root of your build folder, download the appropriate integration batch file from the bottom of this post.
3. Locate Windows6.0-KB951634-x86.msu.  This file is on the c:\windows\system32\vmguest.iso, located on any Hyper-V enabled host.  The update file should be located in the Support folder of the ISO.  Copy this file to the root of your WinPE build folder - the same location as your integration batch script.
4. From the Windows PE Tools Command Prompt, execute the integration script.  If everything went correctly, you'll see "PEIMG completed the operation successfully." listed seven times in the output of the script.
5. At this point your WinPE build is updated.  Resume steps 7 through 9 in Building a WinPE Image from Scratch to complete the process.

If you have questions about the above, please e-mail me at jason.huitt@colostate.edu - I've run both of these scripts successfully as of today, and now have working x86 and x64 WinPE ISOs.  My trust WinPE flash drive has been updated as well.  You'll love the integrated mouse and NIC support when building Hyper-V VMs.  No more Legacy Network Adapter!

Integrate_x86.bat (1.10 kb)

Integrate_x64.bat (1.12 kb)

A breath of fresh air: Windows Mobile 6.1 for the Samsung Ace.  Finally.

http://www.samsungmobileusa.com/i325/upgrade/

I'm blogging this from my laptop, tethered to my Ace.  It's no long necessary to "unlock" the device, as they've set the security profile correctly to allow installation of apps.  To tether a newly updated Ace:

http://cameronfuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1318.entry

Guest OS processor utilization will not affect processor utilization on the host OS, per se.

Today I encountered a volume-licensed Vista box that had not been activated for more than 180 days.  I was under the impression that Reduced Functionality Mode (RFM) had gone away with Service Pack 1, however when I attempted to log into the box, I was greated with an activation dialog box, and clicking cancel returned me to a log on prompt.  Here's how I got back around the problem...

• From the Activation dialog, click on one of the Help links.  This will pull up the Help and Support window.
• In Help and Support, do a search for "command prompt".  One of the returned links will show you how to open a command prompt, and will provide a link to do this for you.  Go ahead and open the command prompt in this manner - while I was in this activation mode, I was unable to use Ctrl+Alt+Del to pull up Task Manager, and had to get to a place where I could actually do some work.
• If you need to connect to a VPN in order to access your company's KMS server, do so now.
• In order to manually activate Vista from the command line, you have to run slmgr.vbs from an elevated command prompt.  How do you launch an elevated command prompt without right clicking on an icon to launch a UAC prompt?  Here's a nifty trick:
  • Run "control schedtasks" to bring up the Task Scheduler interface.
  • Create a new task to run cmd.exe without any triggers.  Also make sure to check the option for "Run with highest privileges" on the General tab.  This will set the task up to run with elevation.
  • Right click your newly created task and click Run.  Lo and behold, you've got a command prompt running with elevation!  Note "Administrator: taskeng.exe" in the title of the command prompt window.
• Now that you are elevated, run "cscript slgr.vbs -ato".  Assuming this volume-licensed copy of Vista had been previously activated, you should now be re-activated.
• Log off using the "logoff" command, and then log back in.  At this point you should be staring at your desktop once again.

Check out this great post from the Windows Server Setup / Core Team, which details the WinSxS folder - the single-instance file storage location for all system files (components) in Vista and 2008.  Fascinating stuff.

http://blogs.technet.com/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx

SlySoft, makers of Virtual CloneDrive - the easiest and best ISO mounting software for Windows, has released version 5.4.0.6 of CloneDrive as of 2008-07-31.  This new version offers support for Windows Vista x64!  This tool is a must have for any self-respecting server jockey.

Download the new version here: http://www.slysoft.com/en/download.html