Chris Nackers Blog

ConfigMgr and MDT Deployment Solutions

Useful Blogs

User Groups

February 2011 - Posts

I’m Now On the Solid State Disk Bandwagon–I’ve Gone To The Dark, err Fast Side!

So I finally decided to jump on the SSD bandwagon. Up to this point, I’ve simply said, they can’t be that good, no way I’m spending that kind of money on a hard drive.   I recently built a new Hyper-V lab at home, and it’s been working out great for me, the performance is outstanding.  I also however, always carry a full ConfigMgr lab around with me on my laptop.  This allows me to do demo’s for clients as well as test things when needed.  Or mainly just show people how life would be so much simpler if they would just use the Microsoft Deployment Toolkit.  First, I had this lab running on my single laptop drive, not so good, things got SLOW.  Then I was using a Lacie 1TB external esata drive.  This worked great, but was HEAVY, and one more thing I have to carry around in my already heavy backup (maybe I’m just a wimp).  Plus I got funny looks from clients as I pulled out my laptop, my hard drive, my power supply, my laptop power supply, my esata cable, my monster power strip, and then proceeded to plug everything in.  I’m pretty sure they were thinking, are you going to bill me for this time?

In an effort to increase my efficiency, and be “green”, I decided to replace my DVD drive with a HD caddy and a SSD disk.  Don’t you need a DVD drive? I don’t apparently, I have never used it in all the time I’ve had my laptop, it’s just taking up valuable HD space!  I thought about just buying another 7200RPM drive, but I figured, what the heck, I’ll try this SSD new-fangled thingy.  I’m here to report I have converted to a SSD enthusiast.  I have also been called names by friends that I can’t repeat, because after seeing what I’m about to post, they decided they will have to go buy one as well.  I still stand by saying that is NOT my fault.

So, is there a point to this conversation we’re having? Yes, there is, keep reading!

Well, I was chatting with another colleague and he was asking how well my TowerRaid assembly was performing in my home lab, he was trying to decided if he needed to go buy one.  Yes he does I told him repeatedly.  So we were trying to figure out how to test the performance of it, so I downloaded this product (HD Tune Pro) that I found with a Google search (sorry Bing).  I decided to test all my hard drives while I was at it for the sake of it, and I found the results to be quite interesting!

So some background first. I promise I’ll show you pretty pictures/graphs in a little bit.

My laptop is a Lenovo W510 i7 with a Toshiba 500GB internal drive, and now a Mushkin Enhanced 240GB SSD in the DVD bay.

My lab at home is a custom-built i7, 24GB DDR3 1600, 320GBx2 Raid 0 for the Operating System, and then a SansDigital TowerRaid.  The TowerRaid connects to the host computer via dual Sata 6GB connections via PCI-E controller card.  I have 8 1.5TB Seagate drives in a Raid 10 configuration (6TB).  Works fantastic for running my little Hyper-V lab at home. 

Ok enough chatting already, lets see the results! AKA Pretty pictures/graphs.

Laptop Drive Toshiba 500GB



Laptop Drive Mushkin SSD in DVD bay



TowerRaid 8x1.5TB Raid 10



Intel 320GBx2 Raid 0



Posted: Feb 24 2011, 08:48 PM by cnackers | with no comments
Filed under:
Should you delete files in the \WinSXS directory? And what’s the deal with VSS?

Nice post over on TechNet by “Joseph”, there are some great comments below the post as well.

Read the original post here.

I like to read about how Windows is affecting peoples lives, specifically, the servicing components.  One of the common threads I noticed in my recent web trolling was the question “Can I delete the \Windows\Winsxs directory to save space?”.  This is usually asked in conjunction with what the directory does and why its consumed the space it has, but I’ve already covered that in prior posts.

So, to answer the question, the answer is simply: No.

Why?  Because the component store (\Winsxs) is needed to repair the OS binaries in the event that a file becomes corrupted or, in worst case scenarios, compromised.  There are a few directories in the component store so let’s look at them and what their general role is in Windows.

1.\Winsxs\Catalogs:  Contains security catalogs for each manifest on the system
2.\Winsxs\InstallTemp: Temporary location for install events
3.\Winsxs\Manifests: Component manifest for a specific component, used during operations to make sure files end up where they should
4.\Winsxs\Temp: Temp directory used for various operations, you’ll find pending renames here
5.\Winsxs\Backup: Backups of the manifest files in case the copy in \Winsxs\Manifests becomes corrupted
6.\Winsxs\Filemaps: File system mapping to a file location
7.\Winsxs\<big_long_file_name>: The payload of the specific component, typically you will see the binaries here.
So, can you delete these?  Sure, you could I guess.  What would happen?  Well, it depends.  So long as the files in the \Windows\System32 directory are valid, most likely you wouldnt see any problems initially, the machine would “most likely” operate properly.  However, the first time you attempt to update a binary, apply a service pack or service a component, it’s going to fail because the backing components needed arent there.  The way the files end up in \System32 are via hardlinks.  This should help answer another common question I see regarding how VSS is used in servicing.  Short answer: It’s not.  We use NTFS hardlinks to project the file to the file system from the component store.  That’s why the \Winsxs directory is so important.  The files there can be seen as the “authoritative” versions on the file system.  When you encounter an issue and that binary needs to be replaced, running an SFC /SCANFILE against it will check the directories above and if the version doesnt match, it will re-project it so that its working.

Here’s an example of how you can see the hardlink via CLI:

C:\Windows\System32\drivers>fsutil hardlink list ntfs.sys

This isnt the best overall example but its one I use often as a quick and dirty way to see the links in the OS.  You can see that the NTFS file has a link to the \Winsxs directory and if that version of NTFS were to become corrupted, we could go back to the component store and find you a new copy.  The backup directory in \Winsxs is there in the event that the version in that directory has also become corrupted.  It’s a good way of having protection on the OS without consuming a huge amount of space. 

Also, as Andre mentions in the comment below, its worth noting that the new servicing structure does remove the $NTUninstall$ folders that many people have become accustomed to from Windows NT to Windows 2003.  Updates, if they are marked removable, no longer contain that structure.  Instead, updates are recommended to be removed via the Control Panel --> Programs  --> View Installed Updates path.  You can remove the updates via the appropriate switches in DISM.EXE or PKGMGR.EXE, but the control panel method tends to be cleaner.

Hope that helps.


Remote Desktop Services–Load Simulation and Capacity Planning Tools

I had previously blogged about some great step by step guides for Remote Desktop Services. I wanted to add a couple more useful links for a load simulation tool and a capacity planning document.

Remote Desktop Load Simulation Tools

The Remote Desktop Load Simulation toolset is used for 32-bit and 64-bit (x86 and x64) server capacity planning and performance/scalability analysis.

Download Here.

Remote Desktop Session Host Capacity Planning in Windows Server 2008 R2

Use the RD session Host role service to allow multiple concurrent users to run Windows-based applications on a remote computer running Windows Server 2008 R2. This capacity planning guide describes the most relevant factors that influence the capacity of a given deployment along with methodologies to evaluate capacity for specific deployments.

Download here.

Approving Windows Updates in an MDT 2010 Standalone Environment from a ConfigMgr Software Update Point

Here is a great post over The Deployment Guys Blog.  A client actually sent this to me today and I hadn’t read it before.  This was one of the main pain points when building your images with MDT Lite Touch. 

Read the full post here.

You’ve no doubt read some of the benefits around using the Software Update Point features of ConfigMgr. However, if you are already using MDT standalone as an Image Engineering environment – there is sometimes a duplication in having to manage software updates in both environments. The most common solution is to set up an external standalone WSUS server for your reference machine to pull down updates. However, it would be ideal to have a single place to manage the approval and download of updates for both the deployed machines in ConfigMgr environment and the reference machine during an image capture in the MDT standalone environment.

Configuration Manager-Reporting Services Access Denied When Running R3 Power Management Reports

Ran into an issue at a client this week that I haven’t run into before.  When trying to access the new R3 power management reports, we were receiving an access denied.  The errors we received were the following:

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DataSet2'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors

An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'DataSet2'. (rsErrorExecutingCommand)
The EXECUTE permission was denied on the object 'PowerManagementGetPowerCapabilities', database 'SMS_XXX', schema 'dbo'.  

All other reports in Reporting Services worked fine.  The reason turned out to be that the new R3 reports use some stored procedures in the ConfigMgr database.  Web reports are typically just queries that use tables and views.  The new R3 reports are the first ones for ConfigMgr that are Reporting Services only reports.  Typically when locking down permissions on reports or a reporting service account, you would just assign the account DB_Reader rights in the SQL database.  This works for all the web reports but didn’t work for the R3 reports.  DB_Reader doesn’t have access to run the stored procedures that are required for the power management reports. 
In order for the R3 reports to run successfully, we need to add the service account to the “smsschm_users” database role. Huge thanks to Kent Agerlund and Garth Jones for providing me with the appropriate fix.

First, lets open up the database and drill down to the database roles:


Next we need to go into the properties of the "smsschm_users” role:


Next we need to add our service account to be a Role Member:


Select “Browse” and then select the service account you want to use.


Here we have our service account selected, then click “ok”.


Once you verified the service account is listed in the Role Members pane, then select “ok”.


Another way to add the necessary rights is to go into the login properties of your service account. Then go to “user mapping” and select the SMS/ConfigMgr DB and check the database role membership. This is probably the easier method (less clicks), but it’s good to know there are 2 ways to do it Smile


Kent Agerlund also has a post on this.  I wasn’t able to find his post when I encountered the issue and used Google, however I was told that using Bing would have resolved my issue, but I haven’t tested that.

Configuration Manager–Configuring SQL Reporting Services (SRS)

Here is a great step by step for configuring and setting up SRS with ConfigMgr:

Here is a great article that details setting up the required permissions for SRS:

Here is the SRS tag on Steve Thompson’s blog, lots of great posts here:

Posted: Feb 22 2011, 10:09 AM by cnackers | with no comments
Filed under: , ,
ConfigMgr 2007 Post-SP2 Hotfixes

Fellow ConfigMgr MVP Jason Sandy’s has created a nice post on post SP2 hotfixes that are a good idea to install on your servers.

Read the full post here.

Windows AIK for Windows 7 SP1 Released

Michael Niehaus has a great post over his blog discussing the new SP1/WAIK release.

Read the full post here.

Some of you probably noticed a new download showed up today:

The Windows® Automated Installation Kit (AIK) for Windows® 7 SP1

Be sure to read the “readme” that goes along with this at:

Windows Automated Installation Kit for Windows 7 Readme

A quick Q&A that I assembled from information in this readme and our own MDT testing:

Q:  Do I have to use this to deploy Windows 7 SP1 and Windows Server 2008 SP1?

This supplement is optional. If you do not need to modify the SP1 boot.wim and winre.wim files, you can continue to use the Windows 7 RTM tools, including WinPE 3.0, without installing this supplement.  (So MDT and ConfigMgr can deploy WIndows 7 SP1 just fine using Windows PE 3.0.)

Q:  How do I install this on a machine currently running the Windows 7 RTM version of Window AIK?

There’s no installer provided with this.  You need to extract the contents of the download and then XCOPY the files over the top of your existing Windows AIK installation.  See the details in the readme.

Q:  What’s changed in this Windows AIK supplement?
  • The number in the Version registry value is 3.1 to reflect the new Windows PE version.
  • The Windows PE 3.1 base image contains Remote Network Driver Interface Specification (RNDIS) binaries. These binaries are also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID: 979265 (
  • Windows PE 3.1 includes 802.1x binaries as an optional component. The file name of this package is This optional component is also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID 972831(
  • The Windows PE 3.1 base image contains fixes that are related to 4k/512e drive support. These fixes are also available for Windows PE 3.0 as a hotfix. For more information, see Knowledge Base Article ID: 982018 (
  • Windows PE 3.1 includes bug fixes that are related to the Windows PE version that is included with Windows 7 SP1.
Q:  Does Windows 7 SP1 and Windows PE 3.1 work with MDT 2010 Update 1?

Yes, this is fully supported.  (There is one small issue involving Windows 7 SP1, Windows PE 3.1, and having Windows RE included in your MDT-generated Lite Touch boot images, but if you don’t mind Windows RE not being there, you don’t need to worry about this.)

Q:  Does Configuration Manager 2007 SP2 support Windows 7 SP1 and Windows PE 3.1?

The Configuration Manager team is still testing Windows 7 SP1 and Windows PE 3.1, so this is unsupported until that testing is completed.

Q:  Does this supplement include the recently-released USMT 4 update for Office 2010 support?

No, you need to download and apply that one ( separately.

PXE Cache Expire Behavior in Configuration Manager 2007 SP1 and SP2

Great article over The Configuration Manager Team Blog.

Read the original post here.

If a Configuration Manager client has received and started an advertised operating system deployment task sequence, attempting to start another operating system deployment advertisement within a certain period of time might result in the deployment being ignored and failed to start. In this case, the client ignores the PXE boot request and falls back to the local hard disk when booting up.

This is an expected behavior in both Configuration Manager 2007 SP1 and SP2 based on the value of the PXE cache expire setting, which controls how long before a PXE advertisement expires. The default value is set to 60 minutes. This setting is useful when unknown computer support in R2 is turned on. If the value is too short, an unknown computer running a mandatory operating system deployment will repeatedly begin the same advertisement when rebooting in WinPE. For deployments that do not use unknown computer support, setting the value to a shorter period of time can help them quickly recover from failures that occur during operating system deployment and restart the advertisement.

For Configuration Manager 2007 SP1 hotfix KB969113 will set the default value from 60 minutes to 2 minutes. Configuration Manager 2007 SP2 improved functionality to make this value configurable in a registry key. The default value is 60 minutes in Configuration Manager 2007 SP2.

To set the registry key for the cache expire value for the PXE service point role, open the following registry key on the computer with PXE service role installed:

On a x86 machine


On a x64 machine the registry key is under WOW6432Node


Create a new DWORD value CacheExpire, and set the desired value in seconds. For example, if you prefer the cache expired in 2 minutes, set the value to 120. If the value is set to 0, then the default 60 minutes value is used.

Note: Setting the value in CacheExpire is only supported in ConfigMgr 2007 SP2.

Computers upgraded to Windows 7 using OSD might generate a new SMS GUID

Great new post over on the Configuration Manager Team Blog.

Read the full post here.

[Today's post is provided by Chaohao Xu.]

If Windows hotfix KB974571 is installed on a Windows 7 reference image, then it is highly likely that you would see the following log entries in smsts.log when deploying this image to an existing client. Notice that because the client certificates were not found, the end result is that the client uses a new certificate to register itself, losing its own identity in the process.

Installing SMS client
Clearing existing client configuration.
Cleaning existing client certificates from SMS certificate store
Restoring SMS client identity.
The client certificates were not found. New certificates will be generated.
Successfully restored the client identity.

This behavior is not desired when you refresh Windows using an operating system deployment task sequence. When an OSD Task Sequence is used to refresh a PC, the ConfigMgr 2007 client certificate should be migrated from the old Windows OS to the new Windows OS.

The problem is caused by the self-signed certificates automatically generated by the ConfigMgr 2007 client in mixed mode. If the KB977203 ConfigMgr 2007 client patch was not installed on the existing client when the certificates were generated, then the certificates will have an embedded NULL character in the friendly name as described in KB974571.

If the ConfigMgr 2007 client certificate on the original Windows OS has an embedded NULL character in the friendly name as described in KB974571, and if KB974571 is installed as part of the reference image being deployed by the Task Sequence, then when the new Windows OS is installed, KB974571 will block the ConfigMgr 2007 client certificate with the embedded NULL character in the friendly name from being migrated over. This will cause the above issue.

This can be fixed by installing ConfigMgr hotfix KB977203 to fix the client certificate prior to deploying Windows 7 or simply run ccmcertfix utility on client prior to Windows 7 deployment.

The instruction to fix the client certificate for any existing client is as follows:

1.Install hotfix KB977203 on site server
2.A utility called CCMCertFix.exe is placed in the directory
3.Run CCMCertFix.exe on any existing client to fix the certificate, software distribution can be leveraged for distribution to a large number of clients. Another way is to add this as a step to the Windows 7 deployment task sequence.
The correct way to guarantee any new client has a fixed certificate is to make sure the client patch is installed before the newly installed client registers itself. The instruction detail is as follows:

1.Install hotfix KB977203 on site server
2.A ConfigMgr 2007 client patch is placed in the directory
3.Go to Client Push Installation Properties and specify the PATCH parameter
4.The above configuration would make sure that any new clients installed using the client push method would include the client patch from KB977203 before the client registers itself.
After the existing client has the certificate issue fixed by hotfix KB977203, the Windows 7 deployment would successfully restore the client identity as shown by the following log entries in smsts.log.

Installing SMS client
Clearing existing client configuration
Cleaning existing client certificates from SMS certificate store
Restoring SMS client identity
Successfully restored SMS certificate store
Successfully restored the client identity

Posted: Feb 15 2011, 06:23 PM by cnackers | with no comments
Filed under: , ,
Breaking IT Down: Deploying MED-V with Existing Management Systems

Read the original post here.

Today’s post is from David Trupkin, Sr Product Manager from our Windows Virtualization Team.

As I’ve talked to IT pros at events around the world, many of you have told me that the biggest barrier to your Windows 7 deployments has been incompatible legacy applications. These applications may run on Windows XP or they might be browser-based applications that run in Internet Explorer 6 or 7. While many older applications just work in Windows 7, some may require compatibility shims. Others may require upgrades or patches. You may decide to replace some applications or retire them altogether. For those applications that are left – the ones that simply must run on Windows XP – you should know about Microsoft Enterprise Desktop Virtualization (MED-V) 2.0. MED-V bridges the “last mile” of application compatibility between Windows XP and Windows 7, allowing older applications to run inside Windows XP compatibility workspaces but integrate seamlessly into your users’ Windows 7 environment.

Don’t confuse MED-V with Microsoft’s consumer and small business compatibility tool, Windows XP Mode. MED-V expands on the capabilities in Windows XP Mode by adding enterprise features such as the ability to use a custom Windows XP image, automated first time setup, control of Internet Explorer URL redirection, automatic network printer mapping and easy packaging for enterprise distribution. MED-V version 1, first released in 2009, was based on a client-server model and required dedicated management servers. MED-V version 2, in Release Candidate status now and due for release before the end of March, 2011, is based on an application model which eliminates the need for a dedicated server. You can deploy and manage MED-V 2.0 with your existing software distribution management tools, like System Center Configuration Manager (SCCM).


Let’s spend some time looking at MED-V 2.0 and its requirements. On the client, the MED-V Host Agent installs on Windows 7 Professional, Enterprise or Ultimate with a minimum of 2GB RAM and will support either x86 or x64 architectures. At least 10 GB of disk space is recommended, although you may use more or less disk space depending on your particular workspace image and combination of applications. You’ll also need to deploy WVPC and WVPC KB977206 (which allows WVPC to run on systems without hardware-assisted virtualization) to systems that do not have them installed already.

MED-V Workspace Packager lets you package your Windows XP virtual machine for use as a MED-V workspace. The documentation included with the Workspace Packager will guide you through the process of:

•Preparing your Windows XP image
•Creating a MED-V Workspace package for deployment
•Testing and deploying your MED-V workspace
•Managing applications and software updates within MED-V and
•Managing MED-V settings after deployment
Often, you’ll deploy a management agent such as the SCCM client inside of your MED-V workspace to allow for application distribution and update along with patch management. The SCCM team has provided a client hotfix, to be installed on your SCCM SP2 Site Server, which improves SCCM functionality when you’ve configured your MED-V workspace to use network address translation (NAT). The hotfix allows a MED-V workspace that is also an SCCM client to use the same SCCM site and distribution point assignment as its host.

Once you’ve created your MED-V workspace package you’ll have a MED-V Workspace Package – a standard application file set that’s ready to deploy. You’ll find:

•A setup.exe
•A .medv file that is a compressed copy of your workspace VHD file and
•An .msi installer
You can create installation tasks within your software deployment tool to install MED-V and its prerequisites together, or you can create separate tasks that deploy the individual components. If you are using SCCM, you can create packages and a Task Sequence to install the MED-V and WVPC components.

In this sample batch script for MED-V component installation, the MED-V components are installed in inverted order, allowing the installation to complete with a single reboot. There are two things to keep in mind about this batch script. First, while the MED-V Client installer and MED-V workspace package installer will detect if they are running on an x86 or x64 system and will install the appropriate “bitness”, the WVPC update and associated hotfix are specific to x86 or x64 systems. Second, the MED-V installation will not be complete until the system is restarted.

REM install the MEDV Host Agent
start /WAIT msiexec /i MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
REM install the MED-V workspace package
start /WAIT .\setup.exe /qn OVERWRITEVHD=1
REM Install Windows Virtual PC (this example is for Windows Virtual PC x64)
start /WAIT Windows6.1-KB958559-x64.msu /norestart /quiet
REM Install Windows Virtual PC update (this example is for the x64 version of the update)
Windows6.1-KB977206-x64.msu /norestart /quiet

Here are command line examples for creating packages within SCCM:

•MED-V Host Agent
•msiexec /i MED-V_HostAgent_Setup.exe /qn IGNORE_PREREQUISITES=1
•MED-V workspace package
•setup.exe /qn
•WVPC installation (Note: This example shows the x64 version of WVPC. If installing within a Task Sequence, use “Run Command Line” instead of “Install Software” to avoid a reboot at this step.)
•wusa.exe Windows6.1-KB958559-x64.msu /norestart /quiet
•WVPC update (Note: This example shows the x64 version of the update. If installing within a Task Sequence, use “Run Command Line” instead of “Install Software” to avoid a reboot at this step.)
•wusa.exe Windows6.1-KB977206-x64.msu /norestart /quiet
Once MED-V 2.0 and Windows Virtual PC have been deployed, and any necessary reboot completed, the MED-V First Time Setup runs and legacy applications published from MED-V are available in the Windows 7 Start menu. Legacy web based applications or sites defined by the MED-V administrator are seamlessly redirected to Internet Explorer 6 or 7.

For more information on MED-V 2.0 and to try it yourself, register on Connect and check out the MED-V 2.0 Release Candidate today and for a complete library of information on MED-V, App-V, VDI and other desktop virtualization solutions, visit the Desktop Virtualization Zone on the Springboard Series on TechNet.


New Step-by-step guides available for Remote Desktop Services

Great post over on the Remote Desktop Services Team Blog

Read the original post here.

We are busily writing and publishing Step-by-Step guides to help you explore the new features of Remote Desktop Services included with Windows Server 2008 R2. Below is a list of the guides that are currently available. Please check back often, as we plan on publishing more documentation in the coming months.

What's New in Remote Desktop Services

Installing Remote Desktop Session Host Step-by-Step Guide

Word document download:

Web version:

Deploying Remote Desktop Web Access with Remote Desktop Connection Broker Step-by-Step Guide

Word document download:

Web version:

Deploying RemoteApp Programs to the Start Menu by Using RemoteApp and Desktop Connection Step-by-Step Guide

Word document download:

Web version:

Deploying Personal Virtual Desktops by Using RemoteApp and Desktop Connection Step-by-Step Guide

Word document download:

Web version:

Deploying Virtual Desktop Pools by Using RemoteApp and Desktop Connection Step-by-Step Guide

Word document download:

Web version:

Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide

Word document download:

Web version:

Deploying Virtual Desktop Pools by Using Remote Desktop Web Access Step-by-Step Guide

Word document download:

Web version:

Deploying Remote Desktop Gateway Step-by-Step Guide

Word document download:

Web version:

Deploying Remote Desktop Licensing Step-by-Step Guide

Word document download:

Web version:

Driver Management Resources

Driver management is always an interesting topic, I typically have some links that I give to people to read on the subject.  I’ve found that that list has grown over the years.  So this post is meant to be a compilation of links on the subject.  If you have additional information, please ping me and I’ll get them added here to this post:

Configuration Manager:

Microsoft Deployment Toolkit:

Driver Management Tag on my blog:

USMT 4 Update Released to Support Office 2010 Migrations

Microsoft has created an update for USMT 4.0 that adds support for Office 2010. USMT 4.0 migrations of Office 2010 are now supported .

You can get the update here:

Here are some things you should be aware of:

  • Certain settings and customizations in MS Word won’t migrate from any version to Word 2010, because of with the way Word is designed and how data is stored in “HKEY_CURRENT_USER\software\Microsoft\Office\<OfficeVersion>\Word\Data".
  • Many Office settings (across all Office apps) won’t migrate when going from 32-bit Office to 64-bit Office. This is due to the way that the settings are stored in 64-bit Office installations.
  • If you’ve launched Office on the destination PC as a user before doing the migration of that user’s profile, most of your settings won’t migrate. This happens because Office relies on some code that only runs the first time that an Office app is launched to migrate settings.
  • This update isn’t a magic bullet. You may still need to do some customization to make USMT fit your particular configuration.

The update also fixes a couple of issues around hard-link migration performance when copying a folder with a huge number of files and an issue that affected certain time zones.

Also Michael Niehaus has a blog about the release of this KB that are of note.

Read his original post here.

A new hotfix for USMT 4.0 was released today to support migrating Office 2010 settings.  (It includes other fixes too.)  You may want to download this and integrate it into your deployment processes.  The full instructions for doing this (including what needs to be done with MDT and ConfigMgr) are included in the KB:

There is one complication that you should be aware of if you are using ConfigMgr and moving from Windows XP or deploying Windows XP.  USMT 4.0 uses a set of manifest files to determine what needs to be migrated from Windows XP.  These manifest files are stored in the “DLManifests” folder, which is part of your USMT package in ConfigMgr.  There is an issue though where Scanstate.exe can’t find this DLManifests folder when run from ConfigMgr.  In MDT 2010 Update 1, we included a workaround for this, copying the folder where Scanstate can find it:

' Workaround for USMT bug in Windows 7 AIK
If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" then
    oUtility.RunWithHeartbeat "cmd.exe /c xcopy /iesryhd """ & sUSMTPath &"\DlManifests"" """ & oEnv("SystemRoot") & "\system32\DlManifests" &""" 1>> " & oLogging.LogPath &"\zticopyUSMT.txt 2>>&1 "
End if

Notice that this checks specifically for build 6.1.7600.16385 of Scanstate.exe, the version released in the Windows 7 version of Windows AIK, as we expected this problem to be fixed in the next version of USMT.  Well, it wasn’t.  But once you install the KB 2023591 hotfix, the version changes to 6.1.7601.21645 and our fix stops working.

You can work around this by fixing the fix, to read like this:

If oEnvironment.Item("DeploymentMethod") = "SCCM" and oEnvironment.Item("OSVersion") = "XP" and (oFSO.GetFileVersion(sFoundScanState) = "6.1.7600.16385" or oFSO.GetFileVersion(sFoundScanState) = "6.1.7601.21645")  then

If you aren’t using ConfigMgr or don’t have Windows XP around any more, you won’t need to worry about this.

Getting The ConfigMgr V.Next VHD To Work For Native VHD Boot

This came from the myITforum SMS email distribution list.  Credit to Richard Benfield for figuring this out and posting the solution to the mail list.

Here is the long and short of getting the SCCM vNext VHD Test Drive to work for Native VHD Boot:

1) Download the SCCM vNext VHD Test Drive from the following link (Note it is over 9.5 GB so it will take a while):


2) Download the VHD Resizer from the following link and install it:


3) Download all of the appropriate (Server 2008 x64 compatible) drivers for your model system.

4) Extract the contents of the SCCM vNext VHD Test Drive (Note the vhd is 20 GB, so it will take a while)

a. You only really need the two .\*.mht files and the .\Virtual Hard Disks\*.vhd file

5) Decide what size you want the VHD to be. (The actual used space is about 25 GB and you won’t want to cut it too close)

a. I decided on 50 GB for my use.

6) Use either the “Disk Management” console or the “Diskpart” command-line utility to shrink the volume in the VHD

a. You will need to attach the VHD, select the larger volume of the two, shrink it to the desired size minus 100 MB, then detach the VHD

7) Run the VHD Resizer and change the VHD to Fixed and the size listed for “Min” (again, this will take a while)

a. FYI, it sat there for a long time appearing to do nothing. I was convinced it wasn’t working and may not be compatible with 2008x64, but eventually it started cranking away.

8) You may want to move and rename the VHD. (I renamed mine SCCMvNext.vhd and moved it to C:\VHDBoot\)

9) Use the process described at the following link to copy the Windows 7 or Server 08 default BCD entry and point it to your VHD file.


10) Either change your systems SATA mode to ATA in the BIOS or inject the appropriate Mass Storage Controller Driver in the VHD image.

11) Boot up and choose the new boot entry from the menu.

12) Login and install the drivers…

That’s pretty much it, at that point you have a Windows Server 2008 R2 x64 Native VHD Boot system with SCCM vNext preinstalled on it for testing/demos…

Posted: Feb 01 2011, 09:14 PM by cnackers | with no comments
Filed under: ,
More Posts Next page »