Collecting USMT Estimates using ConfigMgr

A common ask is how much space is needed to store user state data captured by USMT. This is an important question to answer so that you know how space you may potentially need when capturing user data to the network in traditional Replace scenario task sequences.

It’s not an easy question to necessarily answer because of a lot of variables. Gathering the data from all of your systems could also prove tricky. Fortunately, there is a fairly straight-forward way to get this done using USMT’s built-in space estimate ability and by extending ConfigMgr’s Hardware Inventory. Of course, I did this all for the customer as detailed below.

[ms_panel title=”Script Update – January 9, 2019″ title_color=”#f5f5f5″ border_color=”#00274c” title_background_color=”#00274c” border_radius=”2″ class=”” id=””]Based on some feedback (and gentle nudging by Gilbert T.), I’ve updated the script to account for spaces in path names which was causing file not found issues when folks were manually running the script or included the files within another sub-folder containing spaces in the name.[/ms_panel]

The Steps

Step 1: Use USMT to estimate the space needed

USMT’s scanstate has a /p switch that will generate an XML file with estimated space required to capture the user data (much emphasis on estimated).

Step 2: Store USMT’s space estimate in WMI

Consume the XML file grabbing the space estimate and store it in a custom WMI namespace and class.

Step 3: Configure hardware inventory to gather the data

Very easy to do via the GUI in ConfigMgr 2012. Not too difficult to do in 2007 either but you must edit the sms_def.mof file. Note that for data already in WMI, there is no need to touch configuration.mof.

Step 4: Report on the data

Use your favorite mechanism report on the data including (WQL) queries, SQL queries, or reports.

The Script

Steps 1 and 2 above are in a fairly straight-forward script called USMT-Estimate.vbs. This script runs scanstate.exe with the /p (space estimate) option using the default MigApp.xml and MigDocs.xml configuration files. By default, the script also uses the scanstate uel option and sets it to 90 days – this option causes scanstate to only consider user profiles for users that have logged in within the last number of specified days (90 in this case by default).

scanstate outputs an XML file with estimates in it to the %temp% directory called scanstate.xml. The script grabs the results from this file, creates a new namespace in WMI (if it doesn’t already exist) called ITLocal under root, creates a new class called USMT-Estimate in this namespace (if it doesn’t already exist), and then creates an instance/object of this class with the space estimate (in MB) and a date/time stamp.

[ms_button style=”normal” link=”https://github.com/jason4tw/ConfigMgrScripts/blob/master/Inventory/USMT-Estimate.vbs” size=”medium” shape=”rounded” shadow=”yes” block=”no” target=”_blank” gradient=”no” color=”#4f4f4f” text_color=”#ffffff” icon=”fa-github” icon_animation_type=”” border_width=”0″ class=”” id=””] USMT Estimate script: Get it on GitHub[/ms_button]

Script Use

To use the script, place it in the root of your USMT 4 package (at the same level as the x86 and amd64 folders) and update your DP(s). Create a program that runs with admin privileges that runs the following command line:

Deploy. That’s it really.

Check

scanstate will produce a log file in %temp% called scanstate.log so you can check it if you suspect something wonky has happened.

There are a lot of ways to check if the data is being populated into WMI, but my favorite is PowerShell (and it should be yours also). On a system where the script has run, this is easily done using two simply PowerShell commands:

Get-WMIObject has a –computer parameter to connect to remote systems also and of course you can use all of the power of PowerShell. Other possible ways to review the data in WMI include WBemTest, CIMStudio, and wmic, to name a few.

Script Customization

If you have custom configuration files, you can run those instead (or in addition to the default ones) by using the /xml option making sure to also specify any default configuration files that you would like to use also (comma separated):

The script looks for all scanstate XML configuration files in either the x86 or amd64 subfolder of the USMT package source files folder so place any custom configuration files you have into one or both of these directories based on your expected usage.

To change or remove this or add other options, update the ScanStateOptions variable on line 9 of the script. The complete set of options is listed at http://technet.microsoft.com/en-us/library/cc749015(v=WS.10).aspx.

Data Gathering

This is step 3 from above and is the easy part in ConfigMgr 2012. First, run the script (either manually or through a deployment) on at least one system first though so that ConfigMgr can find information about the new class.

Navigate to Overview –> Site Configuration –> Client Settings in the Administration workspace. Create a new set of client settings or edit an existing set (just like with Group Policies, it is highly recommended that you don’t edit the Default Client Settings and instead create and deploy your own as needed).

In the Hardware Inventory section, click on the Set Classes … button.

In the resulting Hardware Inventory Classes dialog, click Add…

In the Add Hardware Inventory Class dialog, click Connect…

In the Connect to Windows Management Instrumentation (WMI) dialog, enter the Computer name for the system where you’ve already successfully run the script and rootITlocal for the WMI namespace. Supply alternate credentials if necessary to connect to the system specified and click Connect.

This will (eventually) return showing the one and only class in this namespace: USMT_Estimate. Check the checkbox next to this class and then click Edit… at the bottom.

In the Class qualifiers dialog, Change the Display name to USMT Estimate (without the underscore). Leave all of the Units as None and click OK four times.

That’s it. The next time the clients update their machine policy, they will be informed of this change and the next hardware inventory cycle after this they will collect the data from this class (if it’s been populated by the script). You can check on this by looking in InventoryAgent.log on the client:

If you’re stuck on ConfigMgr 2007, you should be able to just add this snippet to your sms_def.mof file:

I have not explicitly tested this on 2007 but there’s no reason this shouldn’t work.

Once ConfigMgr has gathered the data, you’ll be able to see it in a variety of places:

Resource Explorer

Query Wizard

SQL Server

Reporting

I didn’t explicitly create any reports so I’ll leave that as an exercise for you and your gangnam style reporting skillz.