The new application model in Configuration Manager 2012 will require administrators to study up on how best to deploy software – this isn’t anything like traditional software distribution like you would find in ConfigMgr 2007.

I recently set up Office 2010 as an application in ConfigMgr 2012 Beta 2.  Here are the steps I used – not necessarily the only way to do it, but it worked for me.

Create the application

First you need to create a new application.  If this were a simple MSI, you could just choose the MSI file and the whole process would be simpler.  But Office 2010 is a little different than your typical application, so we need to manually define the information.

Specify general information

Now you need to specify some general identification and ownership information.  This information is primarily for the ConfigMgr administrator’s use, as the end user can see different information in the software catalog.

Notice the “Allow this application to be installed from the Install Application Task Sequence Action without being manually deployment” checkbox.  If you are planning to have MDT install this application dynamically in a task sequence (by specifying the application name in CustomSettings.ini, e.g. Applications001=Office 2010), you will need to check this box.

Specify how it should appear in the software catalog

ConfigMgr provides a software catalog, the Software Center, where end users can choose from optional applications (deployed as “available”, i.e. non-mandatory).  You need to specify how the application should show up in the catalog – you can even specify different languages.

Add a new deployment type

The high-level “application” doesn’t say how to actually install the application.  That’s done by one or more deployment types (similar in concept to the old package/program concept, where one package can have multiple programs, but in this case each deployment type can have different content – maybe one deployment type is an MSI install and another uses App-V).

Again, because Office 2010 isn’t a typical application, you need to manually specify the deployment type details.

Specify the deployment type details

You need to give the deployment type a name.

Specify install and uninstall details

Now you need to specify the source files, the installation command line, and the uninstall command line.

Since we are deploying Office, the install command line is pretty simple, just specify SETUP.EXE.  This assumes that the package source contains an “Updates” folder with an MSP patch file that is configured to install Office without any user intervention.

The uninstall command line is a little harder to come up with – I just copied the command that Office placed in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS on a 64-bit computer).  It isn’t very complicated, just specifying “SETUP.EXE /uninstall PROPLUS”.  (I haven’t actually confirmed that this command line works, so test appropriately.)

Add a new detection rule

ConfigMgr 2012 will automatically reinstall an application targeted to a computer if it detects that it is no longer present.  In order for this to work, you need to specify a detection rule so that ConfigMgr can figure out if it is still installed.

First add a new detection MSI detection rule.  In the case of Office 2010, you can check for the present of any of the MSIs that are installed by the Office Setup program. I usually pick the one for the main product, Office Professional Plus, as that uniquely identifies the specific Office SKU that is installed. You browse to the “proplusww.msi” file in the “ProPlus.WW” folder so that you don’t need to type in the MSI product GUID.

Specify user experience settings

Typically you want to install Office in the system content and whether or not a user is logged on (both are mandatory settings for the task sequence to install the application).  Neither of these settings are defaults, so be sure to change them:

There are a few more screens, but you can take the defaults for each of them.

Now you have successfully created the application, but you aren’t done yet.

Distribute content

The source files specified on the deployment type still need to be distributed to your distribution points.  (You don’t need to do each deployment type separately, just once for the application.)  There are different options you can choose for distributing the content.  In my case, I’ll just keep it simple and distribute it to every one of my distribution points (one of them):

Deploy

At this point, you are ready to deploy.  You don’t choose to deploy a specific deployment type.  Instead, you deploy the application itself.  It’s pretty simple in this case, with only one deployment type, as it’s fairly obvious which one will be installed.  But if you had multiple deployment types, you would need to specify rules to determine which one is used.

There’s no doubt that this will take ConfigMgr administrators some time to get used to – just one of the big changes coming in ConfigMgr 2012.g

I gave a presentation today at the TechEd New Zealand conference on “Customizing the User State Migration Tool 4.0” – something I’ve talked with customers about back from my consulting days (way back when, probably with USMT 2.6 at that point – remember that one and its INF-style configuration files?), but haven’t presented in public for a very long time.  Needless to say, it was somewhat nerve-wracking.  For those in attendance, I hope it was worth your time.  (I thought it was only OK.  I’ll do better the next time.)

The next few blog postings will likely be related to USMT 4.0 – it’s always good to write about things that are freshly in your mind.

First off, I wanted to take the opportunity to pass along some of the troubleshooting items that I mentioned in the slide deck, consolidating various issues that you might run into while using USMT 4.0.  Here they are:

• USMT 4.0 isn’t migrating Office 2010 settings
• Make sure you install the USMT 4.0 update that adds Office 2010 support.  See http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx for more information.
• http://support.microsoft.com/kb/2023591
• USMT fails with some half-hour time zones
• Install the USMT update for Office 2010 (see above), as it fixes this too.
• Bad user profiles (usually a ProfileList registry entry that points to a non-existent folder) can cause state capture issues (delays, failures)
• Clean them up or tell USMT to ignore them with MIG_IGNORE_PROFILE_MISSING=1
• See http://blogs.technet.com/b/deploymentguys/archive/2010/03/28/usmt-failures-due-to-bad-profile-list-entries.aspx for a script that can help identify these and clean them up so that they don’t cause any issues.
• See http://blogs.technet.com/b/askds/archive/2011/04/14/usmt-pauses-at-quot-starting-the-migration-process-quot-for-many-minutes-then-works.aspx for more details about the problem.
• Setting MIG_IGNORE_PROFILE_MISSING is rather challenging in ConfigMgr (you can’t set it as a process environment variable because it goes away before the “Capture User State” step runs, so you need to set it as a system variable, reboot, and then capture state).  See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2011/08/03/setting-environment-variables-in-a-task-sequence.aspx for details on how to do this.  (You could do a shorter way with MDT Lite Touch by modifying ZTIUserState.wsf to set the variable.)
• OS settings don’t migrate with ConfigMgr
• This happens because USMT can only find the “DLManifests” folder necessary to do OS setting migration in the working directory, and ConfigMgr doesn’t set the working directory to the location that contains this.  See http://support.microsoft.com/kb/2018593 for more information.
• MDT 2010 Update 1 includes a workaround for this problem, although the USMT 4.0 fix for Office 2010 (see above) breaks the workaround, requiring a script change (also described in the blog above).
• USMT migrates user data from removable drives even with /localonly
• It migrates USB disks even with /localonly, use an unconditional exclude to exclude undesired USB disks.
• See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2009/04/29/excluding-usb-firewire-and-other-drives-from-usmt-capture.aspx for a scripted approach of doing this (taking into account that the drive letters can be different on each system, so you might need a different exclude list for each PC).
• Shortcuts to files on network drives don’t migrate
• Known issue, you can modify MigUser.xml to remove section with IgnoreIrrelevantLinks (but then all links are retained, even invalid ones).
• USMT doesn’t exclude the users that I want when I specify /UE and /UEL
• These two parameters don’t work together the way you would expect them to, acting like an “or” instead of an “and”.  See http://blogs.technet.com/b/askds/archive/2009/11/30/understanding-usmt-4-0-behavior-with-uel-and-ue.aspx for more information.

Any other good troubleshooting tips for USMT 4.0?

So maybe migrating Angry Birds high scores and settings isn’t terribly useful to you.  Let’s try something a little more practical and self-serving.  Many of you are using Configuration Manager 2007 or testing Configuration Manager 2012.  As part of that, you have installed the ConfigMgr console and connected to one or more ConfigMgr sites.  When you refresh your own machine, you want those connections to be retained, because it’s too much trouble to have to type in a server name again.

So it’s the same basic exercise as before:  Figure out where the ConfigMgr console stores that information (using ProcMon or even Bing searches), then build an XML manifest that says to migrate the data.  Fortunately, I already know where ConfigMgr stores that (we use that information in MDT):  it’s in the user’s registry.  The exact path is different for ConfigMgr 2007 vs. 2012:

ConfigMgr 2012:   HKCU\Software\Microsoft\ConfigMgr10\Admin UI\MRU

ConfigMgr 2007:  HKCU\Software\Microsoft\ConfigMgr\AdminUI\MRU

So the manifest needs to specify that these registry keys (and all values and subkeys) get backed up and restored if they exist.  Simple enough:

A few things to point out with this one:

• There are two components defined in the same XML manifest.  You can put as many components in the file as you want, so whether you want 20 small XML files or one larger one (as you define more application settings to capture) is entirely up to you.
• Since these are user registry entries, the rules will be processed for each user that exists on the machine.

So what happens if the ConfigMgr 2007 console is installed in the old OS but not in the new OS?  Will the settings be restored?  Yes they will, as the detection rules are only used to determine on the source computer whether the component is present. (When it is detected, it will be put into a generated config.xml file too.)

Out of the box, USMT 4.0 migrates settings for Windows, Office, and various other applications (typically current versions as of 2009), mostly consumer-focused.  (See http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx for the full list.)  So what if you want to migrate settings from additional applications?  Well, then you need to author your own migration XML file.

First though, you need to figure out what application settings need to be migrated.  Does the application store its settings in a file?  In a registry key?  Per user or per system?  There’s no single right way to do this, so you have to do some investigative work to figure this out for each application.  Tools like ProcMon from SysInternals can help with that, by capturing details of all registry and file accesses made by the process.  But there can be lots of data captured, so finding the data can be somewhat time-consuming.

So let’s look at a real example using Angry Birds, which is available for download from http://download.angrybirds.com/.  Install this on a computer, then start ProcMon and tell it to capture details from process name AngryBirds.exe:

Then launch Angry Birds and click on “Play” to see where you left off – at that point, you know it’s read the saved settings, wherever those came from.  At that point, you can stop the capture and begin scanning the captured data.  Usually I start at the bottom (most recent) and work my way up, looking for something “interesting”.  (What is “interesting” can vary by app, but you will begin to notice patterns that applications follow so the more applications you do this with, the better you’ll get at it.)

From scanning the ProcMon output, I can see a few references to my user profile folder:

Those files (“highscores.lua” and “settings.lua”) sound promising, especially since I noticed that the settings are per user (log in as someone else and you have different progress displayed) and I don’t see any relevant HKCU registry access in the trace.

OK, so we know what we want to capture and restore.  Now we have to figure out how.  Using your favorite XML editor (I use Visual Studio), create a new XML file that looks like this:

A few things to point out:

• The “urlid” value on the first line can be any URL – it just needs to be unique among all XML files being used (no duplicates).  Make up whatever value you want, as it’s effectively just a text string, not used for anything beyond identification.
• The component type can be either “Application” or “Documents”, depending on what you are capturing.  It doesn’t really matter what you specify, as it just controls where the component shows up in the config.xml file (if you generate one).  For Angry Birds, I specified “Application”.  (If you specify an invalid value, USMT typically doesn’t complain – it does end up ignoring the component though.)
• The context is very important.  It should be “System” if you are capturing machine-level configuration, or “User” if you are capturing user-specific configuration.  You can also specify “UserAndSystem” if you need to capture both.  In the case of Angry Birds, we’ve already determined that it is using user settings, so that’s what we need to specify.
• The remaining entries generally occur in this type of pattern:
• A role node.  The type can be “Data”, “Binaries”, “Settings” or “Data” – really just labels for you to use, as all values are treated the same.
• One or more detection rules. In this case, we look for the existence of a folder to indicate that this rule should be processed.
• A rules node that specifies whether these are “User” or “System” settings.  (Typically this is the same as the component value, although it can be a subset, e.g. the component specified “UserAndSystem” while the rule specifies “User”.)
• One or more include rules that specify what to migrate.
• Potentially more optional elements, e.g. exclusions.  See http://technet.microsoft.com/en-us/library/dd560769(WS.10).aspx for a description of all the possible XML elements.

So then lets look at the condition:

MigXmlHelper.DoesObjectExist("File","%CSIDL_APPDATA%\Rovio\Angry Birds")

This uses a helper function to determine if the specified directory exists.  The “%CSIDL_APPDATA%” text is a reference to one of the many “environment variables” (listed at http://technet.microsoft.com/en-us/library/dd560744(WS.10).aspx) that can be used; the value will be substituted when evaluating the condition.  Because this is a per-user rule, the condition will be checked for each user, with “%CSIDL_APPDATA%” pointing to the user profile’s roaming data folder (e.g. C:\Users\<userID>\AppData\Roaming on Windows 7).

The "include" rule specifies to capture all files and subfolders under the detected path.  By default, these will be put back into the same location they were captured from, doing any necessarily translation for changes in %CSIDL_APPDATA% (e.g. drive letter changes).

That’s all there is to it – just tell Scanstate and Loadstate to use this new XML file and all of your Angry Birds progress will be preserved even through an OS refresh or replacement process.

One of the questions that came up after my TechEd New Zealand session on USMT 4.0 was whether USMT migrated the contents of the client-side cache (CSC) used for offline files.  Well, it sounds like it “sort of” does – but by default, it only moves the “dirty” files (those not yet sync’d to the network location).  That’s a decent default I suppose, as the remaining files can be pulled back from the network after the state is restored, and the modified files won’t be overwritten.  So there’s no data loss (always a good thing), but there will be extra network traffic to pull the content down to the cache again.

The actual cache migration is performed by a plug-in to USMT, so the question is whether that plug-in can be influenced to capture everything, instead of just the “dirty” files.  From http://support.microsoft.com/kb/942960, you can adjust the behavior by telling CSC you want to migrate everything.  (While this article talks about MigWiz.exe, the Windows Easy Transfer Wizard, the underlying engine being used is basically the same as that used by USMT.  So the end result of setting “MigrationParameters” should be the same.)

But before you say “great, let’s do it” you need to understand what’s going on behind the scenes.  First, this CSC migration plug-in is called automatically by USMT as part of the Windows manifest processing.  If you search through the Scanstate log you’ll see lots of references to it, with “CscMig” in the log entries.  For example, here is an entry I saw on my computer for a “dirty” file (one that was created while the folder was offline, so USMT needs to capture it):

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480

But the rest of the files in that folder were skipped, as I didn’t have the MigrationParameters registry key set:

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(653):Skipping item File1.txt because it is in sync with remote location. ItemStatus = 00050020

OK, great, we see what’s happening.  But it’s also worth digging a little deeper and seeing what it did with that original file (something you can see from specify verbose logging, /v:5):

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigGetWorkingDirectory(837):exit: workingDir = <\??\C:\Users\mniehaus\AppData\Local\Temp\tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC>, status = 0x00000000 ( EE = 0 )
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item \\ continueCtx = 00000000003DAF00
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item bdddev continueCtx = 00000000003DB9A0
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item data$ continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigWrite(446):exit: bytesWritten (743) at offset (0)
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(974):Backup API file content till offset 743

So it used the Windows Backup API to make a backup of the “dirty” file in the CSC cache and placed that backup into a folder in my %TEMP% directory named “tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC”.  So even though I’ve specified to use hardlinks, there is data copying going on.  In the end, this temporary folder created by CscMig is included in the hardlinked state store, but because these are different files (the backups) you will see twice the disk space consumed, so if you have lots of cached data you better have lots of free disk space to store the data.  This isn’t so bad in the default configuration where it is only grabbing “dirty” files, but if you tell it to backup all files, then what happens?

No better way to find out what will happen than to try it.  I made the MigrationParameters registry entry as described in the KB article mentioned above and repeated the Scanstate execution.  (No service restart was required.)  Upon checking the log, I can see now that each file in the CSC was backed up into the temporary folder.  Where before it said “skipping item File1.txt”, now it says it’s backing it up:

2011-08-24 23:07:54, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item File1.txt continueCtx = 000000000045C480

And like before all of these items get backed up into a temporary folder, then that temporary folder is hardlinked into the state store folder.  So hardlinks or not, if you had 2GB worth of cached files, you’ll end up with those being doubled (temporarily, until the process is complete and the temporary folder and state store are cleaned up).  It’s actually going to be tripled if you aren’t using hardlinks:  first copy is the original file, second copy is the backup, third copy is contained in the compressed state store.

So that definitively answers the question of whether you can get USMT to migrate the complete contents of the client-side cache.  It may not answer the question of whether you should do that, but hopefully the information is useful to help you make that determination yourself.