Michael Murgolo has a nice post over on The Deployment Guys blog.
Read the full and download the example script here.
Some tools require setting an environment variable when they are used. For example, the User State Migration Tool has several that can be used for troubleshooting. Unfortunately, the built-in MDT or ConfigMgr Task Sequence steps for capturing and restoring the user state don’t allow you to set environment variables.
Trying to set the environment variable using a script in a preceding step will not work. If you set an environment variable in the script (e.g. using the SET command in a command shell script) it will only be set for that script. The task sequencer parent process will not inherit the environment variable, so neither will subsequent steps. Setting a System (or master) environment variable will have the same issue. The task sequencer will not inherit the new master environment. However, if you restart the computer after setting the System environment variable then task sequencer will inherit the updated System environment variables.
So the process for using an environment variable with something like USMT is to have steps before the steps that run the tool (the user state capture and restore steps in this case) that set the variable in the System environment and then restart the computer. This is shown in the steps prefixed with Custom: in the sample MDT Lite Touch Task Sequence below.
After a recent Exchange 2010 crash at a client, We ran into an issue with a “Crawling” Content Index State. Everything was up and running as expected, all the databases were mounted and the copies were healthy, but the ContentIndexState on several of the databases was in a failed or crawling state.
The first thing we tried was updating the copy: Update-MailboxDatabaseCopy -Identity DB1MBX1 –CatalogOnly
This worked for the failed databases, but those that were stuck in the Crawling state would not update. So I went down the troubleshooting steps in Diagnose Exchange Search Issues and even Reseeded the copy (Reseed the Search Catalog) to no avail. I then tried suspending the DAG copy, removing the catalog directories of both the Primary and Copy, and allowing the entire catalog to be rebuilt. Finally, I removed the DAG copy entirely and tried rebuilding the copy. The end result was always the same: Crawling. ????
So I started digging a little deeper into the health of the Exchange Server and the DAG itself. I finally discovered that the DAG Cluster Name was offline, which prevented the activation of the copy database and the seeding of the Content Index. In our case, starting the DAG Cluster Name in the Cluster services MMC allowed the seeding to occur and the ContentIndexState to reach a healthy state.