You would expect that having Microsoft in the Seattle area would result in having a plethora of Microsoft-related users groups around.  But over the years, I’ve found that these are somewhat hard to find.  So here’s my compilation:

• Seattle IT Pro User's Group.  This group talks about all sorts of IT pro-related topics, including Windows 8, Windows Server 2012, Windows Azure, System Center, Office, SharePoint, etc. – pretty much anything that an IT pro would care about.  They meet the first Wednesday of every month in Bellevue at the Lincoln Square Microsoft office.  As long as I’m in town, I try to make it to this meeting.  There is a meeting coming up on Wednesday of this week (November 7th) at 6pm – there will be copies of Windows 8 Pro to be given away and free food provided, so RSVP now using the hyperlink above.
• Northwest System Center User’s Group.  This group meets every other month at the Microsoft Civica office in Bellevue to talk about System Center products, and there is ample participation from the System Center product groups (including Wally Mead).  I usually try to make it to this one too.  The next meeting is coming up on November 9th, so sign up now via the LinkedIn hyperlink above.
• Pacific Northwest SQL Server User’s Group.  This group meets every second Wednesday of the month, usually on the main Microsoft campus, to talk about topics related to SQL Server.  By my calculation that means there is a meeting coming up next week, for those interested in SQL Server, so keep checking their web site for details.
• Puget Sound SharePoint User’s Group.  This group meets monthly at the Microsoft Civica office in Bellevue to talk about SharePoint.  The next meeting is coming up on November 15th, from 6-8:30pm.

I’m sure there are more groups out there that I haven’t heard about, so let me know if there are more that I should add to this list.

MDT 2012 includes a task sequence for deploying an operating system into a VHD, setting up the computer for booting from that VHD.  See my previous blog posting about Deploy to VHD for more details on that.  As I mentioned in that blog, setting up a differencing disk to be created during the “Deploy to VHD” task sequence doesn’t make sense, as the parent VHD would be empty.  But it would be useful to be able to do it later, so that you have the already installed and configured OS in the main VHD, and then one or more differencing disks set up with that VHD as the parent.

So how do you actually do that?  The basic steps would be:

• Boot into Windows PE.  (You can’t create a differencing disk off of a parent VHD if that VHD is currently open, as it would be when boot from the VHD.)
• Use DISKPART to create a new differencing disk with the existing VHD as the parent.
• Create a new BCD entry for the differencing disk.

To help with that process, I created a new script called Diff.wsf, attached below, that will perform all of those steps.  Set up a new custom task sequence in your MDT deployment share that has a single step in it that runs the script like so:

Then reboot into your MDT Lite Touch boot image (either from media or from PXE) and run this task sequence.  The command line parameters above tell it what to do:

• /CREATE specifies to create a new differencing disk.
• /CLEAN specifies to remove any existing differencing disks that might be present.
• /STAGE says to copy the Diff.wsf and all related scripts locally onto the disk, in the same folder as the parent VHD file.

The task sequence completes while in Windows PE, and as soon as you click finish on the summary wizard page, the computer will reboot into the new differencing disk, causing all changes to be written into the diff file while the parent VHD remains unchanged (and effectively read-only).

After that initial differencing disk has been created, the locally-staged script can be run directly without even using a task sequence.  Assuming that the drive letter assigned to the physical disk containing the parent VHD (and the differencing disks) is D:, then the script will be located at D:\VHD\Scripts\Diff.wsf.  When you run it from there (initiated from within the currently-running OS), you can specify any of the parameters described above, or you can leave off the parameters and the script will prompt.

Note that the script can’t actually delete the differencing disk that is presently in use because, well, it’s currently in use.  But it can remove the BCD entry for it, and after a reboot it can then be deleted.  So the script will also take care of cleaning up any “orphaned” differencing disks it finds laying around.

A few final comments on scenarios for running Diff.wsf from within the currently-running OS:

• If you specify /CLEAN without /CREATE, it will remove all the differencing disks and boot back into the main VHD file.  This is useful if you want to update (e.g. patch) the installed OS.
• If you specify /CREATE without /CLEAN, you’ll get another differencing disk and another BCD entry – so if you really want to, you can boot between different differencing disks.

In my previous post, I talked about using a small RAMdisk to speed up the process of generating MDT boot images.  But the trial version only supports RAMdisks up to 4GB in size and only on client OSes.  One comment posted to that blog pointed out that StarWind also has a free RAMdisk available, and it supports larger RAMdisks and server OSes.  See http://www.starwindsoftware.com/high-performance-ram-disk-emulator for more information.  (Again, I’m not recommending it, just pointing out its existence.  Registration is required to download.)

This let me test out another scenario: Creating a RAMdisk large enough to hold an entire virtual machine, then seeing how much faster Windows can be deployed into such a virtual machine.  Fortunately, I have a workstation-class machine with enough RAM to do something like that.  I created a 20GB RAMdisk, formatted it as NTFS, then created a new VM where the VHDX file (using Windows Server 2012) was on the RAMdisk.

Using a physical disk array (attached to an Intel RAID controller) on the same system, I can deploy Windows 8 in about 10 minutes (new computer, clean install, no apps, no updates, etc.).  So how much faster is the RAMdisk?  On my machine, it took about eight minutes – noticeable, shaving 20% off of the time, but not as fast as I would have hoped.  That’s another case of shifting the bottleneck: the image is pulled across the (virtual) network, read from a physical disk (VHD), consumes CPU, etc.  Now if I only had enough RAM to load my entire server VHD into a RAMdisk to see what that does.  Last time I checked, the server required about a terabyte of disk space, so going that far is not possible.

But I can do the next best thing:  Create an MDT media ISO, copy that into the RAMdisk, and do a deployment using that instead of over the network.  How long did take?  About 7 minutes and 30 seconds.  Sigh, 30 seconds saved.

One more test:  Give the VM more CPUs.  Instead of the default single core, I increased it to four cores and tried again.  This time, the deployment completed in 6 minutes and 30 seconds.  Another minute shaved off.  (Don’t have lots of RAM?  Well, you probably have more than one CPU in your Hyper-V server, use it when building images.)

So that’s up to a 35% improvement in performance – good overall, but not quite the fantastic results I was hoping for.  Ah well, it was worth a try…

One of the slow operations in the MDT Deployment Workbench is the initial “Update deployment share” process that has to completely generate new Lite Touch boot images.  I always assumed that this was slow due to the amount of I/O being generated by the update process.

Recently, ATI and Dataram released a trial version of their RAMdisk software at http://www.radeonramdisk.com (not that I am endorsing the product – it just happened to come through my Twitter feed and it works on Windows 8), so I had a chance to test the assumption:  What would happen if the temporary storage used by MDT to generate the boot images would be on a RAMdisk?

So I installed the software on my laptop, created a 2GB RAMdisk, and formatted it as an NTFS disk.  First, I “completely regenerated” the MDT boot images without using the RAMdisk.  That process finished in six minutes and 15 seconds (6:15).  Then, to get it to use the RAMdisk, I did the following:

• Start an elevated command prompt.
• Set TMP and TEMP to point to the RAMdisk (E:\ in my case).
• Run “mmc.exe DeploymentWorkbench.msc” from the elevated command prompt, so it inherits the TMP and TEMP environment variable settings.
• “Completely regenerate” the MDT boot images again.

That looks sort of like this:

So what difference did it make?  Well, instead of 6:15, the whole process finished in 4:55.  Not too shabby, about 20% faster, but I expected more.  So why wasn’t it any faster?  Well, it turns out it’s just a case of shifting the bottleneck.  Watching the process using ProcMon and the Windows 8 task manager, I could see that the process was CPU-bound; the RAMdisk utilization was negligible.  Hmm, I guess it’s time for a faster CPU…

The trial software doesn’t support server OSes or more than 4GB of RAM; you have to purchase the full version for that.  Maybe I’ll try that sometime: Imagine a VM where the entire VHD is in a RAMdisk.  I wonder how long that would take…

I was working on a separate blog posting (to be posted soon) that referenced the “Deploy to VHD” support that was present in MDT 2012 and improved in MDT 2012 Update 1 and wanted to include a link to that previous blog.  Except there was no previous blog – I guess I never did one…

So let’s start with what was added in MDT 2012.  Present in this version are two task sequence templates:

• Deploy to VHD Client Task Sequence.  This is the equivalent of the “Standard Client Task Sequence” template, modified to deploy a client OS (Windows 7 or above) into a VHD file.
• Deploy to VHD Server Task Sequence.  This is the equivalent of the “Standard Server Task Sequence” template, modified to deploy a server OS (Windows Server 2008 R2 or above) into a VHD file.

Just to be clear, these task sequences have nothing to do with the creation of virtual machines (although you could use them in virtual machines – there’s nothing preventing a VM from using boot from VHD).  Instead, these are designed to do the following, in the case of a new computer deployment:

• Format and partition the physical disk.
• Create a new, empty VHD file.
• Format and partition the VHD file.
• Apply the specified operating system WIM image to a volume created in the VHD file.
• Set up a BCD entry to boot from the OS volume contained in the VHD file.

Of course all the other standard task sequence components are present too (injecting drivers, installing apps, applying patches, etc.).  Also, in MDT 2012 Update 1, the first step to format and partition the physical disk can be skipped, causing the new OS to be created on the existing disk, not disturbing the existing OS that might be on that disk.  As a result, you could then have a dual-boot computer, choosing the appropriate OS from the boot menu as there would be multiple BCD entries.

MDT 2012 Update 1 also will work with other scenarios, e.g. refreshes, but I’m not exactly sure why would want to do that.  Imagine what happens:  The user state is captured from current OS on the disk, a new VHD is created with the new OS, and then the user state is restored into that new OS in the VHD.  But now the user state is in both places, in the old OS and in the new OS.  (MDT 2012 RTW wouldn’t preserve the existing BCD, so you would always end up with only one BCD entry.  That behavior was fixed in MDT 2012 Update 1.)

If you want to try refreshing from a system already booting from a VHD file into a new OS running from a VHD file (same or different one), don’t.  It won’t work.  The challenge is that MDT really isn’t aware that the existing OS volume is in a VHD, so it might run into a variety of issues (e.g. staging the boot WIM in the VHD, or any operation that requires accessing the old OS files from within Windows PE).

So why is this referred to as “Deploy to VHD”?  It’s called that because MDT is not moving around VHD files (which would be highly inefficient, as these files aren’t compressed in any way).  Instead, it creates a new empty VHD file and deploys the operating system WIM file into it.  This is actually fairly fast and efficient, and surprisingly doesn’t complicate the deployment process very much at all.

Why might you want to do this?  This is primarily useful as a mechanism for setting up an additional OS on an existing computer.  Personally, I prefer using virtual machines for most things, but there could be some valid cases where using an OS running on the physical hardware (which after all is what you are doing, even when booting from a VHD file) is advantageous.

There are a few gotchas in the process though.  Because of some technical issues that could occur when using dynamically expanding VHDs, any time you perform a “boot from VHD” the VHD file will automatically expand to its full size (to make sure that Windows never needs to do this while the OS in the VHD is actively running).  So even if you have a 10GB operating system WIM (expanded from a 3GB WIM), you’ll end up with a much larger VHD file.  By default, MDT will create a VHD file whose maximum size is 80% of the available disk space on the OS volume.  So if you do a bare metal deployment to a computer with a 128GB physical drive, you’ll end up with a 102GB VHD file and about 26GB of free disk space.  You can customize this by editing the task sequence if you don’t want it to be that large:

Another gotcha has to do with the use of differencing disks, which you can see in the above screen shot.  What happens if you configure that?  Well, it will happily create a new empty VHD and then create a differencing disk on that empty VHD.  So then when the operating system image gets deployed, it ends up writing the whole thing into the differencing disk, while the parent VHD stays empty.  That’s not terribly useful.  But there are some additional properties in the underlying MDT ZTIVHDCreate.wsf script that could be leveraged instead to have MDT start by making a copy of an existing VHD file, instead of starting with an empty VHD.  But that’s a more advanced scenario, left for the creative types.