December 2010 - Posts
I was discussing Task Sequence customizations with a colleague today and he sent me a link to and older post by the ever knowledgeable Michael Niehaus. Reading through it was a great reminder of the do’s and don’ts when working with Task Sequence’s.
Read Michael’s full post here.
Some key points from his post:
Command lines that contain spaces need to be surrounded by quotes. The parameters to those commands should not be included in the quotes (although some of them may also require quotes, depending on the command being executed). Working directories should not have quotes. The task sequencer will set the working directory via a Windows API (which doesn't need quotes) before launching the command. Avoid characters that look like XML, e.g. >, <, &, as these could cause XML parsing errors. Batch files can’t have UNC path working directories. CMD.EXE does not support this, so if you specify a working directory that is a UNC path, then execute CMD.EXE or a batch file that implicitly invokes CMD.EXE, the working directory will likely end up being set to C:\WINDOWS\SYSTEM32 - possibly harmless, depending on what your batch file does, but if the working directory is necessary to find the batch file, then there is a problem. Know the difference between a command processed by CMD.EXE and an executable in its own right. Don’t specify CMD.EXE commands directly without using a batch file or a “CMD.EXE /C” prefix. A few examples: - NET.EXE can be used directly (with or without the .exe)
- XCOPY.EXE can be used directly (with or without the .exe)
- COPY must be used with “CMD.EXE /C”, e.g. “CMD.EXE /C COPY C:\BLAH C:\BLAH2”, or used in a batch file.
- MD or MKDIR must be used with “CMD.EXE /C”, or used in a batch file.
- Other examples of commands built into CMD.EXE: CLS, DIR, COLOR, DATE, ECHO, ERASE, EXIT, FIND, LABEL, MOVE, PATH, RD, RMDIR, START, TYPE
- Other examples of commands that are stand-alone executables: ROBOCOPY, XCACLS, FORMAT, DISKPART, TASKKILL, SC, GPUPDATE
Don’t specify a working directory of “.\anything” (e.g. “.\Applications”) in the task sequence because the current working directory is not guaranteed. (Notice that when you add an application from Workbench, which does use this “.\” notation, it translates “.\” into “%DEPLOYROOT%\”. This is done at deploy time by the ZTIApplications.wsf script.) The task sequencer expects all actions to indicate whether they were successful via the exit code (return code). By default, exit code 0 and 3010 (reboot required) are considered to be successful, and all other values are considered failures. If you task returns something other than 0 or 3010, be sure to add those valid values to the list of successful return codes on the "Options" pane. (You can also modify your batch file to include an "exit 0" statement to force a success return code, when appropriate.)
Great post by Daniel Oxely over on The Deployment Guys blog.
It's been a while, but I'll now continue this series of basic tips in the hope to help avoid some deployment unpleasantness that you might rub shoulders with at some point! In this post I'll explain 5 common errors that people make when configuring their newly deployed Windows 7, and what you should really be doing instead... if there is an "instead".
- Windows 7 x64 and Office 2010 x64 - This is a great combination, all that 64 bit goodness on your computer will make all your friends and family drool with envy... (not). Trouble is, if you roll out the 64 bit version of Office 2010 and then at a later date try to use add-ins that are only available in 32 bit, then you might come a bit unstuck and have egg on your face. Why? Because all of your Office add-ins will also need to be 64 bit. As such, it is vital that you plan carefully any Office 2010 x64 roll out to ensure compatibility and all round happiness.
Recommendation: If there is nothing stopping you using Office 2010 x64, then go for it but test it carefully. Otherwise, the best combination at the moment is Windows 7 x64 and Office 2010 x86.
-
C:\Windows\WinSxS - A lot of people are rather dumbstruck by the size of their customised WIM image that they freshly created with MDT. For "no apparent reason", what was a fairly low-calorie Windows + Apps installation has out-of-the-blue created a 6Gb captured WIM file. Upon investigation, it is deemed that the C:\Windows\WinSxS has somehow become bloated and then begins a manual process of cleaning out the "junk". Well, if you do this then you will most definitely break something...! The WinSxS folder is the component store for Windows and where an attempt to avert "DLL Hell" is made through the use of Side-by-side assemblies. Unfortunately, this folder will very likely grow larger over time, so you should also take into account its growth when planning your partition sizes.
Recommendation: The only recommendation really is to do nothing at all. A good explanation of the "what" and the "why" is available here: http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx
- Cleaning Up the Default Scheduled Tasks - Since Windows Vista, Windows has come with a lot of default scheduled tasks that might, at first glance, appear to be surplus to your requirements. Do you really need those "Windows SideShow" tasks even though you don't use the feature? The answer is YES. Although you might have decided that you really don't need them, if you remove them you'll be entering into unknown territory that could possible cause a conflict with something that appears to be unrelated. Given the sheer number of different combinations of scheduled tasks possible, Microsoft can't test every single permutation. As such, the only configuration that is completely and thoroughly tested by Microsoft is the one you get once Windows has finished installing. Feel free to remove the ones you want, but you may find that you are on your own when your computer disappears into a whirling pit of death, pain and destruction (not too over-dramatic is it ?!!?)
Recommendation: Don't remove any of the default tasks. This page details what they all do: http://support.microsoft.com/kb/939039
- Configuring Windows Events via the Registry - It is easy, and plenty of people do it, to change the configuration of event logging in Windows via the registry, but it is not the best way at all. There exists a little known tool that will do this for you, WEVTUTIL.exe, which you should use instead.
Recommendation: If you want to change a setting, such as the log retention policy for example, then use this tool rather than going editing the registry directly. More information here: http://technet.microsoft.com/en-us/library/cc721981.aspx
- Disabling the Windows Firewall - Personal firewalls have become quite common now, even in the enterprise. Windows has had once since XP and also a lot of common 3rd-party security products also provide them. However, a very common configuration mistake that I see in a lot of projects is that if a 3rd-party firewall product is being used then the Windows Firewall service should be disabled via Group Policy. Don't do that though because it is an unsupported method and also, more importantly, if the firewall service is stopped or disabled then the IPsec configuration portion of Windows 7 will also stop. Disabling the Windows Firewall also disables certain features of Windows Service Hardening which is most certainly not a good thing.
Recommendation: Turn the Windows Firewall feature off via Group Policy rather disable the service. More information: http://technet.microsoft.com/en-us/library/cc766337(WS.10).aspx
This blog will be a walkthrough and setup guide for Configuration Manager (ConfigMgr) R3 prestaged media. This will cover the basic steps required in order to use the new R3 feature in your environment.
First some background on prestaged media from Microsoft:
Prestaged media is an alternative way to deploy an operating system to computers. Prestaged media is a Windows Image (.wim) file that can be installed on bare metal computers by the computer manufacturer or at an enterprise staging center. This media includes a boot image and an operating system image that an administrator can predeploy to a hard disk prior. Prestaged media reduces network traffic and the time required to provision a computer. Prestaged media works with existing task sequences to provide a complete operating system deployment.
Prestaged media is suitable for use in environments where you would want to deploy content to a computer, but do not want to or are unable to have the computer fully provisioned, for example during the computer manufacturing process or at an enterprise staging center. Computers are distributed within the enterprise with the prestaged media already loaded. When the computer starts for the first time, the computer will boot into WinPE and connect to the Configuration Manager site management point to check for available task sequences.
NOTE: When creating prestaged media, ensure that the boot image you are using has the appropriate network and mass storage drivers need for the system to complete the provisioning process.
Creating the prestaged media image
Right click on Task Sequences and select “Create Task Sequence Media”.
Select “Prestaged Media”.
Enter any information you want added to the .wim file, then specify the location and name of the file, then click Next.
Take note of what you put in the Created By field because whatever you put there, will end up the name of the drive as in these examples.
You can however change the field in the image properties. If you leave it blank, then “SCCM” will be added automatically for you.
Next, you can select whether or not to enable unknown computer support, password protect the media, as well as the certificate options.
Next, we need to select the boot image and operating system you want to stage to the computer.
Then we have our summary before the operation begins.
Click Close when the process is completed.
Importing the prestaged image into ConfigMgr
Next we need to import our newly created .wim into ConfigMgr.
Browse to the path where you put the prestaged wim we previously created. Then select Next.
Provide properties for the image, then select Next.
Review the summary and then select Next.
Click Close when the process has completed.
Next you will need to distribute the image out to the distribution points. Right-click on the image and select Manage Distribution Points. Then select “Copy the package to new distribution points”. Then select Next.
Select the Distribution Points you want to copy the image to, then select Next.
Select Next.
Click Close when the process completes. You can monitor distrmgr.log to review the distribution status.
Creating a Task Sequence to deploy the prestaged image to a computer
Right-click on Task Sequences and select New – Task Sequence.
Select “Create a new custom Task Sequence”.
Name the Task Sequence appropriately and then select Next.
Select Next.
After the process completes successfully, click Close.
Ensure the Task Sequence has the appropriate boot media. You can do this by selecting Properties on the Task Sequence.
Ensure the boot image selected is the same one as you used when creating the Prestaged Media image.
Next we need to edit the Task Sequence and add the appropriate steps.
First we need to add a “Format and Partition Disk” step.
If you are using Bitlocker, then you’ll need to create a 100mb partition, something similar to this example.
If you are not using bitlocker, then you can just create a single partition.
NOTE: You do not need a Bootsect.exe command as you may have seen with other documentation. This is unnecessary as the Format and Partition disk step takes care of this for you.
Next we need to add a “Apply Data Image” step. Select the Prestaged media image you had previously imported.
If you are not using bitlocker, then you can leave the Destination as “next available formatted partition”.
If you are using bitlocker, then you need to change the Destination to match your configuration.
Next we need to add another “Run Command Line” step to shutdown the computer and end the Task Sequence.
Using a command line of “wpeutil shutdown”.
The finalized Task Sequence should look something like this.
Next if you advertise this Task Sequence to the appropriate collection, then you can run this Task Sequence on a reference machine to apply the prestaged image to that machine. (Other Task Sequences have been removed from the screenshot)
Configuring a Task Sequence to “finish” a prestaged image
Prestaged media is designed to work with your existing Task Sequences. We only need to make one minor change to the “Partition Disk” step in order for Prestaged media to work successfully. We need to add a Task Sequence variable step that says _SMSTSMediaType not equals OEMmedia. This tells the Task Sequence to skip this step when using Prestaged media, so that we don’t delete the content we’ve prestaged.
No change is required to the Apply Operating System step as the logic already exists to detect OEMMedia.
You will however, need to configure your Destination to match whether or not you are deploying bitlocker or whatever other custom setup you may have.
If you are using bitlocker, ensure this step matches the configuration you used when applying the prestaged image to the disk.
If you are not using bitlocker, then just use the default configuration.
Executing the Task Sequence on a prestaged machine
If you power on a computer that has a prestage image applied to it, it will automatically boot the WinPE image that is staged on the machine.
Then we can contact the ConfigMgr server and get our policies.
You will see it run through the first Task Sequence steps fairly quickly.
After a couple minutes you’ll see the system reboot.
Sysprep will then run, along with whatever final configurations you have in your Task Sequence and you should find yourself with a computer joined to the domain and ready to log in within a few minutes. In my Hyper-V lab, without any additional software applications to install, the login prompt was presented in less than 10 minutes after starting the Task Sequence.
Here's another KB we published this morning. This one talks about an issue where creating an MDT based task sequence fails with An error occurred when loading the task sequence and logs a 0x80041002 error in TaskSequenceProvider.log:
=====
Symptoms
After clicking the Finish button when attempting to create an Microsoft Deployment Toolkit (MDT) task sequence, the task sequence may fail to create with the following error:
An error occurred when loading the task sequence
The TaskSequenceProvider.log may also show errors similar to the following:
Failed to load class properties and qualifiers for class BDD_UsePackage in task sequence. 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load node Use Toolkit Package from XML into WMI 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load children steps for node "Execute Task Sequence" from XML 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load children steps for node "" from XML 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Failed to load XML for the task sequence into WMI 0x80041002 (2147749890) TaskSequenceProvider 11/18/2010 8:28:12 AM 1204 (0x04B4)
Cause
This error can occur if the MDT WMI classes are not properly registered.
Resolution
To resolve this issue follow the steps below:
1. Close all of your remote and local SCCM admin console sessions.
2. Log on to your Configuration Manager server and select Start -> All Programs -> Microsoft Deployment Toolkit -> Configure ConfigMgr Integration.
3. In the Configure ConfigMgr Integration wizard, select “Remove the ConfigMgr custom action definitions” and then click next to remove all the definitions.
4. Re-run Configure ConfigMgr Integration again, and select “Install the ConfigMgr extensions”
Once you do this try creating the Task Sequence again. It should now complete successfully.
More Information
This error occurs because the BDD_* WMI classes have not been correctly registered under the \root\SMS\site_<sitecode> namespace in WMI.
=====
For the latest version of this article see the link below:
KB2468097 - A System Center Configuration Manager 2007 MDT Task Sequence fails with "An error occurred when loading the task sequence"
Orignal Post Linked Here.
We are announcing support changes for the following releases. Please look for these changes to be reflected in the Supported Configuration pages within a few months.
Windows Storage Server 2008 R2 is now supported on Configuration Manger 2007 SP1 and SP2
System Center Configuration Manager 2007 SP1 and SP2 now support the Windows Storage Server 2008 R2 operating systems for client installation. The site system role of a standard distribution point and branch distribution point is supported. Installations of the administrator console or other site system roles are not supported.
No software updates are required.
Microsoft SQL Server 2008 SP2 is now supported on Configuration Manager 2007 SP1, SP2 and R2
System Center Configuration Manager 2007 SP1, SP2 and R2 now support Microsoft SQL Server 2008 SP2 as a Configuration Manager 2007 site database. The site system role of Reporting Services Point and the client status reporting feature of System Center Configuration Manager 2007 R2 are supported.
No software updates are required.
Dell has released a new white paper on Enterprise deployment using Configuration Manager 2007 for Dell systems.
Be sure to check out the document here.
System Center Configuration Manager 2007 Hotfix Installation Guidance
A System Center Configuration Manager 2007 (ConfigMgr) hotfix will affect one or more separate roles within the distributed environment. Possible roles include:
· Primary Site Server
· Secondary Site Server
· Remote Administrator Console
· Remote Provider
· Client
This article is designed to provide general guidance as it relates to ConfigMgr hotfixes. For details on a specific hotfix refer to its accompanying Knowledge Base (KB) article athttp://support.microsoft.com.
Hotfix Basics
Regardless of the affected roles, only a single bundle is released. The bundle, when distributed via Microsoft Customer Service and Support (CSS) or directly via the Knowledge Base article (KB article), will be packaged using the Microsoft Hotfix Self-Extractor.
The name of this executable file will be:
<FixID>_<Language>_<Platform>_zip.exe
Note that the FixID value is an internal reference number separate from the KB article ID.
420401_ENU_i386_zip.exe is one example.
The platform identifier is not relevant for a ConfigMgr SP2 or higher hotfix; the same file will extract on both 32-bit and 64-bit platforms.
The self-extracting file can be run on any machine and will display a prompt to choose a location to extract the contents which will be the actual hotfix bundle.
With the release of Service Pack 2 (SP2) for ConfigMgr, this bundle is a Windows Installer .MSI file. Prior to SP2 the bundle was built using Update.exe.
The .MSI is named according to the following convention:
<Product>-<Affected Service Pack >-<KB Article ID>-<Language>.MSI
For example, SCCM2007-SP2-KB2263826-ENU.MSI is the ConfigMgr 2007 post SP2 English version of the fix from KB2263826. Some early post-SP2 hotfixes also contained an x86 identifier in the name, but this was not relevant as the x86 file worked on either platform.
If a hotfix is released as a general update and made available for download from the Microsoft Download Center it will be in the .MSI format; the hotfix self-extractor is not used.
The KB article for a given hotfix will list the applicable roles. If you attempt to install a hotfix on a machine that does not contain one of those roles you would see the message:
This hotfix doesn’t match the installed role of Configuration Manager 2007
International environments and localized hotfixes
Hotfixes will be available in the localized server languages, or in the case of clients in one of the two International Client Packs (ICPs). An ICP version of a hotfix only affects the client binaries but will still be applied to the site server. Once an ICP has been installed on a site it also changes the version number. The end result is that ICP versions of hotfixes will need to be applied for those clients in the future. To confirm the ICP version of a site server check the Full Version value in the following registry key:
Software\[Wow6432Node]\Microsoft\SMS\Setup\
The value should be in the format of 04.00.XXXX.YZZZ
Where XXXX is the build number (6487 for ConfigMgrSP2), Y is the service pack number, and ZZZthe QFE version.
QFE versions are 000 for ENU or other localize language, 400 for ICP1 and 700 for ICP2. So for ConfigMgrSP2 ICP1 the version would be 04.00.6487.2400 and ICP2 is 04.00.6487.2700.
For more information refer to Supported Localized Languages and Tasks for International and Multi-Language Configuration Manager Clients.
Non-client Hotfix Installation (SP2)
With the exception of a ConfigMgr client, the hotfix .MSI file should be installed directly to the machine housing the applicable role. This includes Administrator Console machines and remote Provider servers.
In the case of a hotfix that applies to both primary and secondary sites, it is possible the same files will not be updated on the secondary site. This is only done when a hotfix contains a file that isn’t applicable to a secondary site, such as dataldr.dll, and is usually referenced in the KB article.
Remote site systems, such as a remote Management Point or State Migration Point, are updated by installing the hotfix on their respective site server.
Some components on a site server or remote site system will be reinstalled depending on the roles to be updated. Progress can be tracked using the <ConfigMgr Install Folder>\Logs\sitecomp.log file. This is a process similar to performing a Site Reset. All components that are installed on a server housing the affected role will be reinstalled.
For example, take a case where SiteServer1 has the Management Point installed and RemoteServer1 has the State Migration Point (SMP). A hotfix affecting only the SMP will result in that component being reinstalled on RemoteServer1, with no direct impact to running components on SiteServer1.
Administrator customizable files, such as sms_def.mof or AdminConsole.xml may be replaced by some hotfixes. When this happens it should be noted in the KB article, and the files will be backed up to %Windir%\$NTUninstall<KB Article ID>\,e.g., C:\Windows\NtUninstallKB955262$\. Any changes made by the administrator will need to be merged from the backup to the file supplied with the hotfix and then tested.
Any required database updates are applied by running an update.sql file automatically as part of the installation process. This file will also be placed in the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ folder.
The reset of site components and running of the update.sql script can be bypassed using the switched noted below.
Other actions taken during the hotfix installation will be captured in the %temp%\MSI*.log file created during installation. Separate logging for the MSI file can be accomplished via global Windows Installer Logging policies, or directly via the command line as noted below:
msiexec.exe /I <Product.msi> /L*v <logfilename> [/Quiet] [NODBUPGRADE=1] [NOSITERESET=1] [NOADVCLIPACKAGE)=1]
Where:
/Quiet: Unattended installation mode; no UI
NODBUPGRADE=1: Will not run the update.sql script to update the database/
NOSITERESET=1: Will not perform site reset; this could result in remote site systems not updating until manually reset at a later time.
NOADVCLIPACKAGE=1: Won’t launch the wizard to automatically create a package & program to update clients.
Once a server hotfix has been deemed relevant to a given operating environment, we recommend applying the hotfix to all site servers to maintain consistency once you have completed testing and confirmed it resolved the issue. Targeting the servers can be done via inventory based collections using file details from the KB article, or other methods as needed in your environment.
Non-client Hotfix Installation (Pre-SP2)
Prior to the release of SP2, Configuration Manager 2007 hotfixes were built using Microsoft’s Update.exe technology instead of Windows Installer. The primary functional difference was that if a hotfix contained a SQL script (update.sql) it would have to be run manually against the site database server.
Client Hotfix Installation
A Configuration Manager Client hotfix is comprised of a Windows Install Patch (.MSP) file which will update the necessary binaries when applied to a client.
This file is contained within the original hotfix .MSI file, which in turn must be installed on a site server.
The .MSI will move the client patch to the \<Configuration Manager Install Folder>\client\<platform>\hotfix\KBxxxxxx\ folder on the site server.
In addition it will by default launch a wizard to guide you through the creation of a package and program to distribute the patch to client machines. This is recommended but can be skipped by using the NOADVCLIPACKAGE switch noted previously.
NOTE: If the wizard is bypassed, the following command line should be used:
msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous
e.g. msiexec.exe /p sccm2007ac-sp2-kb2261172-x86.msp /L*v %TEMP%\sccm2007ac-sp2-kb2261172-x86.msp.LOG /q
Note the REINSTALL=ALL REINSTALLMODE=mous parameters are required.
When defining the remaining program properties the following parameters should also be set:
Run with Administrative rights
Run Minimized
After Running: Program Restarts Computer; this is needed to ensure that any status MIF files are collected after a restart of the client service (ccmexec.exe). No actual restart of the computer should occur.
Note: In either case – using the wizard or manually creating the command line – any parameters previously sent to the client.msi file should be resupplied for the patch.
For example if the Fallback Status Point (FSP) and Server Locator Point (SLP) were originally supplied during client installation, the patch command line should be modified to include those.
Modifying the previous example this would be:msiexec.exe /p <patchname.msp> /L*v %TEMP%\<logname.log> /q REINSTALL=ALL REINSTALLMODE=mous FSP=SMSFP01 SMSSLP=SMSSLP01where SMSFP01 and SMSSLP01 are the names of the FSP and SLP respectively.
Do not attempt to install a patch file directly on a client. Applying the patch file directly to a client is not supported and may prevent future hotfixes from properly installing. It also prevents you from specifying any of the additional command line parameters required.
In addition it is not supported to apply the patch directly to the client.msi file (slipstream). This too may cause unexpected issues on the client and prevent future servicing.
If a hotfix needs to be applied during the initial installation of the ConfigMgr client, this can be accomplished using the PATCH= installation property. For more information refer tohttp://support.microsoft.com/kb/907423; while written for Systems Management Server 2003 the article also applies to ConfigMgr 2007.
Further details associated with the wizard will be noted in a text file copied to the <ConfigMgr Install Folder>\Logs\<KB Article ID>\ACReadme.txt file on the site server.
The wizard launched from the .MSI will create a package a program, but will not create a query or collection for use in distributing the hotfix. Possibilities for creating these include querying inventory data for specific file versions, or building queries based on client component versions. File version data is documented in the File information section of the KB article. Client component versions can be seen via hardware inventory data or manually checking the properties in the client control panel applet. Components may include the CcmFramework, CCMPolicyAgeny,SMSInventory or others. Refer to the ACReadme.txt file that is bundled with client side hotfixes for a more complete list of components.
Below is an example of a query that assumes the CCM Framework component was updated to version 4.00.7487.2012 by a hotfix. This query could then be used as the basis for a collection to target the hotfix.
select * from SMS_R_System
inner join SMS_G_System_SMS_ADVANCED_CLIENT_STATE
on SMS_G_System_SMS_ADVANCED_CLIENT_STATE.ResourceID = SMS_R_System.ResourceId
where SMS_R_System.ClientType = 1
and SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Name = "CcmFramework"
and (SMS_G_System_SMS_ADVANCED_CLIENT_STATE.Version < "4.00.6487.2012"
In summary, a hotfix .MSI file should be run on the affected computer except in the case of a client. In that scenario the .MSI file must be run on a site server, and the .MSP file then distributed to affected clients.Summary
This article will be updated with additional information as needed to reflect any version specific changes or other details related to applying Configuration Manager 2007 hotfixes.
Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.
Fellow myITforum blogger Brandon Linton has created a nice post on how to capture and restore USMT data when you are using a 3rd party encryption tool instead of bitlocker. There are typically challenges around this since you usually can’t do a straight up refresh with the 3rd party encryption activated like you would be able to if you were using bitlocker.
Be sure to check out his full post here.
Here is a snippet:
Ok a lot of us are forced to implement full disk encryption and unfortunately most of the time our input into the solution is never requested. So ConfigMgr & MDT have built-in actions to handle HDD Encryption by disabling the protectors etc.. Third party products generally don't provide these means as its considered a security risk. So the challenge is how do i perform a computer refresh to my computer systems that are encrypted? Well you could painfully decrypt the HDD but that would take hours. You could even just blow the system away and not worry about the data if your policies allowed for that. But for us suckers who care about our users or are forced to care about our users! 
We have to come up with a solution that will work, which brings us to the purpose of this blog posting.
We will use a Client Replace Task Sequence to gather the data, then we will use another task sequence that is MDT Integrated to Refresh the system as a bare metal New computer deployment and restore the data.
Nice post by Trevor Sullivan.
Read the full post and get the script here.
Someone recently posted on the MyITforum ConfigMgr mailing list, asking how to delete a bunch of old, empty collections in ConfigMgr. I took this opportunity to write a simple PowerShell script that will do just that. The code simply iterates over all collections, looks to see if each collection has members, and if not, then it prompts the user to delete it.
You’ll need to configure a couple things at the top of the script, before you run it:
-
ConfigMgr server name ($SccmServer)
-
ConfigMgr provider namespace (just replace the last 3 characters with your site code)
-
Add any collection IDs to the $ExcludedCollections array, that you want to explicitly exclude
If you’re really daring, and are absolutely confident that you want to remove all empty collections, you can remove the user confirmation. I’ll leave that up to you, if you’re savvy enough 
The Top 7 Deployment Resources for Windows 7
By Jeremy Chapman, Senior Product Manager - Windows Division, Microsoft Corporation
Just before flying to Tech•Ed Berlin a month ago, I guest-blogged for Keith Combs. In the Windows 7: Best of Deployment Compilation, I enumerated 34 key deployment resources ranging from blogs to videos to complete virtual-machine-based deployment environments. While 34 different resources sounds like a bunch of stuff to read, watch, and play with, it actually only scratches the surface of the information that's available. The Springboard Series pages showcase most of these 34 resources, as well as additional content I didn't call out in that blog. In this article, I will distill that list, counting down the seven most valuable resources to consult as you begin your quest toward Windows deployment.
This article is mainly geared toward people who haven't needed to worry about Windows deployment and were recently tasked with figuring it out. It's not just about cloning a bunch of reference computers with sector-based imaging tools. And, thanks to heavier-hitting automation and less custom scripting work, deployment is much more fun.
I'm going to put these seven items in order of consumption-instead of order of importance. As with most of my blogs, I aim to make this marketing-free, and I'm highlighting items to get the work done using primarily free tools. Let's get started!
7.
Deploying Windows 7 from A to Z
I wrote this as a blog series almost a year ago, and it quickly became the most informal whitepaper ever published by Microsoft (to my knowledge). This is an "unplugged" session that explains deployment tools and processes end-to-end.
6.
Deploying Windows 7: Essential Guidance from the Windows 7 Resource Kit and TechNet Magazine
This downloadable eBook explains all of the Windows 7 deployment tools succinctly and without glossing over anything. In my opinion, this is actually the most important item on the list.
5.
Planning Optimized Desktops and Windows 7 Projects with MAP
If you are going to target some of your existing hardware and don't have a great inventory now, or if you just want to build nice reports to show less technical people which hardware will and won't work, this video outlines how to use the free* Microsoft Assessment and Planning (MAP) Toolkit to do just that. (Approximately 5 minutes)
4.
Application Compatibility Toolkit (Five-Part Video Series)
Okay, I'm cheating here a little by using one entry to highlight five items, but if you watch all five videos, you will learn about everything from installing the toolkit and taking an application inventory to triaging and fixing any detected incompatible applications. (Approximately 50 minutes total)
3.
Thrive Live! Migrating from IE6 to IE8 (Two-Part Webcast Series)
Chris Jackson is a personal hero of mine, and in this two-part series he explains how to think about migrating Web applications from Internet Explorer (IE)6 to Windows IE8 without using virtualization crutches. These demo-heavy webcasts highlight real-world scenarios to configure, manage, deploy, and ensure the compatibility of Web applications with Internet Explorer 8. (53 minutes total)
2.
Building the Deployment Environment and Initiating the Install and Migrating the PC
These two videos explain how to use Microsoft Deployment Toolkit (MDT) 2010 to create fully automated Windows XP to Windows 7 migrations that include data, applications, drivers, and packages. (Approximately 20 minutes total)
1.
Windows 7 and Office 2010 Proof of Concept Jumpstart Kit
The only thing better than powerful, task sequence-based automation is having everything already built and working in virtual machines for you to play with. Test it, reverse engineer it, customize it, do whatever you want with it. The Proof of Concept (PoC) Jumpstart Kit provides resources in preconfigured VHD files, with MDT and the Windows Automated Installation Kit (AIK) already installed. It's prebuilt to deploy a desktop proof of concept with Windows 7, Office 2010, Internet Explorer 8, and Microsoft Application Virtualization using the technologies in the Microsoft Desktop Optimization Pack. Access the guidance online or download the entire kit.
There you have it—my top 7 deployment resources. If you are new to the deployment space, or revisiting it after a long hiatus, this content will give you a pretty good grasp on everything out there and roughly how it works. Plus, it will take you as little as one day to go through these resources. Visit the Springboard Series on TechNet for even more Windows 7 content recommendations.
One last thing... As I write this, my countdown clock gadget on my desktop tells me there are 3 years, 4 months and a few days left until Windows XP end of support, so if you plan to roll out Windows 7 over three years of hardware replacement, now is a good time to start. If it was me, however, and I was on a three-year hardware replacement cycle, I would deploy Windows 7 to the hardware I've purchased over the last two years and target this coming year's new hardware investments for Windows 7. That way, I'd only need to touch these machines once, and the recently purchased hardware can enjoy blazing fast user state migration via hard links. The tools I introduced in this Top 7 list make targeting existing hardware a reasonable operation—even for the more conservative IT shops out there.
Thanks for reading!
Great post by Kenny Buntinx.
Read the full post here.
Attached to this blog post are the Task Sequence templates for my previous post on ConfigMgr and USMT, using a UNC path. These templates can be used with USMT4 as well, just make sure to chose a USMT 4 package for the Capture User State/Restore User State task sequence steps.
In addition, I’ve attached 2 other templates I’ve created.
One is for doing a USMT capture to the State Migration Point (SMP). (Based upon the MDT replace template)
The last one is for doing a USMT capture to the SMP, backing up the computer to a .wim and then optionally wiping the disk. (Based upon the MDT replace template)
If you want to wipe the disk, just enable the disabled TS step “Set WipeDisk to TRUE”
http://powerevents.codeplex.com/
What is PowerEvents?
PowerEvents is a Windows PowerShell v2.0 module designed to facilitate the ease of creating, updating, and deleting WMI (
Windows Management Instrumentation) permanent event registrations. PowerEvents makes it easy to create WMI event filters (define the events you want to capture) and event consumers (responders to events), and then bind them together to initiate the flow of events. By leveraging permanent event registrations, you can perform advanced monitoring functions on a workstation or server, that would otherwise require implementation of an enterprise monitoring product. Because WMI is incredibly vast in the information it provides, very detailed monitoring can be performed using almost any of the WMI objects that exist on a computer.
What are WMI Permanent Event Registrations?
A little-known capability of the WMI service, is its capability to create a permanent registration (listener) for events, and then automatically respond to those events. At a very basic level, it's "if X happens, do Y" but in this case, it's all built into WMI,
without the need for any additional software.
What Can I Monitor with PowerEvents?
WMI contains a vast amount of information about the Windows operating system, the hardware underneath it, and applications that extend WMI.
Here are a very
few examples of events that you can monitor in WMI:
- Microsoft Active Directory
- Changes in group policy configuration on GP clients
- Users created or deleted
- Computer accounts moved
- Microsoft System Center Configuration Manager
- Package created, deleted, or modified
- Advertisement created, deleted, or modified
- Collection created, deleted, or modified
- Monitor Disk Events
- USB flash (UFD) or eSATA drive plugged in or removed
- Detect shrink or expansion of partitions
- Monitor Processes
- Start/stop events
- Change in process priority
- Working set (memory utilization) increase/decrease or exceeds "X" value
- I/O operations increase or exceed a certain value
- Windows Services
- Start / stop events
- New service installed or removed
- Service start type changed
- Device changes
- Detect addition or removal of devices
- Print jobs
- Detect new job or finished job
- Changes in job status
- Software & Patches
- Software installed or removed
- New patches installed
- Operating System
- New reliability records created
- New game registered with Windows 7 Games Explorer
- User Events
- User logon / logoff
- User attributes
- Network
- IP address changed
- Default gateway changed
- Network adapter added or removed
- Server Message Block (SMB) session created or ended
- ODBC Data Sources
- Created or removed
- Driver installed
- Configuration changed
- Threads
- Creation or termination
- Thread state changes
- Microsoft Distributed File System (DFS)
- Last replication time changes
- Errors during replication
- Volume serial # changes
Why Should I use PowerEvents?
Because it's
awesome! In all reality, the capabilities of this module are quite vast, only limited by the information available in WMI. Because many applications extend WMI through WMI providers, these can be not just managed, but also extensively monitored. Additionally, the Windows operating system itself makes extensive use of WMI to provide system information to applications. Through this, you can discover and monitor almost anything you'd want to know about your workstation or server!
- Microsoft Active Directory (AD)
- Distributed FileSystem (DFS)
- Microsoft DNS
- System Center Configuration Manager (SCCM or ConfigMgr)
- Internet Information Services (IIS) 6 / 7
- Windows XP / Vista / 7
- Windows Server 2003 / 2008 / 2008 R2
About the Author
Trevor Sullivan has 7 years of experience in the Information Technology field, and has worked primarily with Microsoft products such as Active Directory, Group Policy, System Center Configuration Manager 2007, Microsoft Deployment Toolkit (MDT) 2010, VBscript, Windows PowerShell, and C#/.NET. Trevor is passionate about sharing with community, and is an active community participant in a variety of mailing lists, forums, blogging, Twitter (@pcgeek86), and other social media outlets.
Follow Trevor on Twitter: http://twitter.com/pcgeek86
Trevor's Blog (Art of Shell): http://powershell.artofshell.com
Trevor's Blog (WordPress): http://trevorsullivan.net
Read the original post on TechNet here.
Please review all of the information in this post specific to your systems for any antivirus scan issues and workarounds.
Important: Some of the steps defined herein may increase your security risk. These steps may also make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We recommend the process below in order to enable programs to operate as they are designed or to implement specific program capabilities. Before you make these changes, it is your responsibility to evaluate the risks that are associated with implementing this process and to test in your specific environment. If you choose to implement this process, take any appropriate additional steps to protect your system. It is recommended that you follow this process only if it is absolutely required for your environment.
System Center Configuration Manager 2007:
If you have Microsoft System Center Configuration Manager 2007 (ConfigMgr 2007) installed and are running into the specific issues defined in the Knowledge Base articles below, you should consider excluding the folders/files defined in each:
KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied
KB327453 - Antivirus programs may contribute to file backlogs in SMS 2.0 and in SMS 2003
KB922358 - Microsoft Systems Management Server 2003 Inventory Tool for Microsoft Updates cannot run when a McAfee antivirus program is installed on the same computer
KB924148 - A Systems Management Server (SMS) 2003 client computer stops responding when you try to perform a software update scan of the Inventory Tool for Microsoft Updates (ITMU) on a computer that is running SMS 2003
KB824722 - "Cannot Open the File to Verify the Signature" Appears in Despool.log
Inventory Tool for Microsoft Updates (ITMU):
If you are running ITMU then review the Knowledge Base articles below for issues with virus scan and their workarounds:
KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied
KB922358 - Microsoft Systems Management Server 2003 Inventory Tool for Microsoft Updates cannot run when a McAfee antivirus program is installed on the same computer -
Windows Server Update Services (WSUS):
If you are running WSUS on your system then review the Knowledge Base articles below for issues with virus scan and workarounds:
KB900638 - Multiple symptoms occur if an antivirus scan occurs while the Wsusscan.cab file is copied
If you have SQL Server installed on your system then consider using the guidelines as defined in the following Knowledge Base articles:
KB309422 - Guidelines for choosing antivirus software to run on the computers that are running SQL Server
KB250355 – Antivirus Software that is not cluster-aware may cause problems with cluster Services
If you are running Windows Server 2003, Windows 2000 or Windows XP, review the following Knowledge Base article for virus scan exclusions:
KB822158 - Virus scanning recommendations for computers that are running Windows Server 2003, Windows 2000, or Windows XP
Internet Information Server (IIS):
If you have IIS installed on your system, use the following Knowledge Base articles for virus scan exclusion information:
KB817442 - IIS 6.0: Antivirus Scanning of IIS Compression Directory May Result in 0-Byte File
KB821749 - Antivirus software may cause IIS to stop unexpectedly
· Exclude the Wsusscan.cab file from the antivirus scan. –OR-
· Exclude all .cab files from the antivirus scan. –OR-
· Exclude all archived files from the antivirus scan. –OR-
· Exclude the following items from the antivirus scan:
· The folder in which the Wsusscan.cab file is located.
· The path of the Wsusscan.cab file on the local computer.
The SMS_Executive service may stop responding to some threads. These include the following threads:
• SMS_Discovery_Data_Manager
• SMS_Status_Manager
• SMS_Replication_Manager
• SMS_Despooler
• SMS_Data_Loader
• SMS_Collection_Evaluator
If you experience the behavior described above or in this article (KB327453), use one or more of the following methods to reduce the file backlog:
• Exclude the <DriveLetter>:\<ConfigMgr install folder>\Inboxes\SMS_Executive Thread Name directory or the SMS_CCM\ServiceData directory from the virus-scanning process
• Make sure that the antivirus software is not configure for Real-Time monitoring.
• Remove the antivirus software, and then restart the server so that any remaining traces re unloaded and removed from memory.
Note: If you exclude the <DriveLetter):\<ConfigMgr install folder>\Inboxes directory from virus scanning or remove the antivirus software, you may make the site server and all clients vulnerable to potential virus risks. The client base component files reside in the <DriveLetter):\<ConfigMgr install folder>\Inboxes directory, therefore use these options only as a short-term troubleshooting step and not as a solution for this behavior.
Review the issue described in KB922358 where the antivirus program is configured to scan the %Windir%\SoftwareDistribution folder on the computer on which the ITMU scan is run. In this case, when the antivirus program scans the .edb file the antivirus program locks the file. The result is that ITMU cannot access the .edb file. To workaround this issue please make sure that the antivirus program does not scan the files in the %windir%\SoftwareDistribution folder on any computer on which the Windows Update Agent is installed.
It is recommended from a performance point of view that antivirus scanning be disabled on certain key non-executable items. As these items are non-executable they provide minimal risk on a server, where the number of non-trusted application should be negligible and the opening of files by user applications is also minimal. The key items include:
- ConfigMgr 2007 database data and log files (server-side)
- ConfigMgr 2007 log files (server-side)
- ConfigMgr 2007 transactional files (server-side)
- Windows Update Scan Catalog (client-side)
The following is a listing of the details of the above types of key items:
For the latest version of the article see the link below:
KB2269650 - A System Center Configuration Manager 2007 SP2 Task Sequence may fail if the computer has multiple drives or partitions and USMT 4 with hardlinking is being used
Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published this morning. If you're using a ConfigMgr Task Sequence on a PC with multiple drives or partitions and it uses USMT 4 with hardlinking then you'll want to check this one out:
Symptoms
Consider the following scenario:
- A computer has two or more drives or partitions.
- The User Profiles and the Windows directory are located on the first drive or partition (assume drive letter C:).
- Second drive or partition has more available free disk space than the first (assume drive letter D:).
- A Configuration Manager 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the computer.
In this scenario the Capture User Files and Settings"/"Capture User State" task will succeed but the "Restore User State"/"Restore User Files and Settings" task will fail.
Viewing the SMSTS.log reveals the following errors:
Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\UserState/c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml" /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User Files and Settings.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager
Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:
Executing command line: osdmigrateuserstate.exe /apply /continueOnError:%OSDMigrateContinueOnRestore% TSManager
==============================[ OSDMigrateUserState.exe ]============================== OSDUSMT
Initializing from environment successful OSDUSMT
Trying to resolve package path for packageID - <Pacakage_ID> OSDUSMT
Successfully connected to "<Package_Location>\<Pacakage_ID>" OSDUSMT
USMT package path = '<Package_Location>\<Pacakage_ID>\' OSDUSMT
Initiailization succeeded OSDUSMT
EncryptionKey ENV var not found. This may be because Local state Store is used. OSDUSMT
Building Default USMT params successful OSDUSMT
Adding config files to user params successful OSDUSMT
Additional user defined options = "/hardlink /nocompress" OSDUSMT
Building user defined params successful OSDUSMT
Building USMT command successful OSDUSMT
Executing command line: "<Package_Location>\<Pacakage_ID>\<Arch>\loadstate.exe" "D:\_SMSTaskSequence\StateStore /c /all /v:5 /l:"C:\Windows\CCM\Logs\SMSTSLog\loadstate.log" /progress:
"C:\Windows\CCM\Logs\SMSTSLog\loadstateprogress.log" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\miguser.xml" /i:"<Package_Location>\<Pacakage_ID>\<Arch>\migapp.xml" /hardlink /nocompress OSDUSMT
Process completed with exit code 38 OSDUSMT
USMT completed with exit code 38 OSDUSMT
USMT returned exit code (0x00000026). Look USMT log file loadstate.log for detail error message. OSDUSMT
Invoking ReleaseSource on USMTPackagePath <Package_Location>\<Pacakage_ID>\ OSDUSMT
OSDMigrateUserState finished: 0x80070026 OSDUSMT
Process completed with exit code 2147942438 TSManager
!--------------------------------------------------------------------------------------------! TSManager
Failed to run the action: Restore User State.
Reached the end of the file. (Error: 80070026; Source: Windows) TSManager
The loadstate.log will also show the following errors:
<Date> <Time>, Status [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info [0x000000] Opening hardlink store D:\_SMSTaskSequence\UserState
<Date> <Time>, Info [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\UserState\USMT))
<Date> <Time>, Error [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.:There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error [0x000000] Unable to open store at D:\_SMSTaskSequence\UserState\USMT[gle=0x00000002]
<Date> <Time>, Info [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\UserState[gle=0x00000002]
<Date> <Time>, Warning [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info [0x000000] An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]
Alternatively, if you are using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard you will see the following:
<Date> <Time>, Status [0x000000] Activity: 'MIGACTIVITY_TRANSPORT_SELECTION'
<Date> <Time>, Info [0x000000] Processing the settings store[gle=0x00000006]
<Date> <Time>, Info [0x000000] Opening hardlink store D:\_SMSTaskSequence\StateStore
<Date> <Time>, Info [0x000000] Entering MigOpenHardLinkStore method
<Date> <Time>, Info [0x0802e2] User selecting transport(UNC Transport (class CUNCTransport) ) with initialization data(UNC: Path(D:\_SMSTaskSequence\StateStore\USMT))
<Date> <Time>, Error [0x080000] HARDLINK: cannot find distributed store for c - 0694a57d-1506-4755-af10-782d0a5b1723[gle=0x00000002]
<Date> <Time>, Error [0x0802e3] SelectTransport: OpenDevice failed with Exception: Win32Exception: HARDLINK: cannot find all distributed stores.: There are no more files. [0x00000012] void __cdecl Mig::CMediaManager::SelectTransportInternal(int,unsigned int,struct Mig::IDeviceInitializationData *,int,int,int,unsigned __int64,class Mig::CDeviceProgressAdapter *)
void __cdecl Mig::CHardLinkHelper::Open(class UnBCL::String *)[gle=0x00000002]
<Date> <Time>, Error [0x000000] Unable to open store at D:\_SMSTaskSequence\StateStore\USMT[gle=0x00000002]
<Date> <Time>, Info [0x000000] Leaving MigOpenHardLinkStore method
<Date> <Time>, Error [0x000000] Failed to select store. Path: D:\_SMSTaskSequence\StateStore[gle=0x00000002]
<Date> <Time>, Warning [0x000000] Internal error 23 was translated to a default error
<Date> <Time>, Info [0x000000] Failed.[gle=0x00000006]
<Date> <Time>, Info [0x000000] An error occurred during store access[gle=0x00000006]
<Date> <Time>, Info [0x000000] USMT Completed at 2010/06/30:15:46:50.995[gle=0x00000006]
Cause
This problem occurs because the default path where the USMT 4 state store is to be saved as specified by ConfigMgr 2007 is on a drive or partition other than the one where the Windows directory and User Profiles are located. When using hardlinking, this could possibly cause the state store to either span multiple drives/partitions and/or actually reside on a drive/partition other than the drive specified in the path by ConfigMgr 2007. The reason for this is that when using hardlinking, the state store has to reside on the same drive/partition where the original data existed.
The state store location is stored in the variable OSDStateStorePath. The default value of this variable is another variable, _SMSTSUserStatePath. _SMSTSUserStatePath usually resolves to a subdirectory called UserState within the Task Sequence cache folder. The Task Sequence cache folder is automatically created by the Configuration Manager Task Sequence and placed on the root level of the drive with the most available free space and given the name _SMSTaskSequence. Similarly, when using MDT 2010/MDT 2010 Update 1 integration, the state store location is determined by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task. The ztiuserstate.wsf script also sets the value of OSDStateStorePath to a subdirectory within the Task Sequence cache folder, but to a subdirectory called StateStore.
If a computer only has one drive or partition, or has multiple drives or partitions but the first drive/partition has the most available free space, the Task Sequence cache folder will be created at the path C:\_SMSTaskSequence. The state store would then be saved within this folder in either the path C:\_SMSTaskSequence\UserState or C:\_SMSTaskSequence\StateStore.
However, if a PC has multiple drives/partitions and the first drive/partition is not the one with the most available free space, then the Task Sequence cache folder will be created on the drive/partition with the most available free space. Assuming that the drive/partition with the most available free space has the drive letter of D:, then the path where the Task Sequence cache folder would be created is D:\_SMSTaskSequence. The state store would then be specified to be in either the directory D:\_SMSTaskSequence\UserState or D:\_SMSTaskSequence\StateStore. Assuming that the drive/partition where the user profiles are located and Windows is installed onto is the first partition/drive with the drive letter of C:, then the state store will actually span multiple volumes and/or reside on a drive/partition other than the one specified in the state store path since some or all of the original data exists on C:.
This is a problem when using USMT 4 hardlinking with ConfigMgr 2007 because at least part of the hardlink state store is on a different drive/partition (D:) than Windows and the user profiles (C:). When a ConfigMgr 2007 OSD Task Sequence runs, at the "Apply Oeprating System Image" step, before the OS is applied to the hard drive, a recursive delete runs that wipes all contents of the drive minus a few protected folders. Normally the folder containing the state store and specified in the OSDStateStorePath variable is marked as one of the protected folders. However, if the state store spans multiple volumes, only the part of the state store that resides on the same drive/partition that is specified in the OSDStateStorePath variable is not wiped. The state store that resides on the OS volume is wiped, causing the problem.
This scenario will not cause the capture performed by scanstate.exe via the "Capture User State" task to fail because a hardlink state store that spans multiple drives/partitions is a supported scenario when using USMT 4 outside of ConfigMgr 2007. However, when the restore of the state store is attempted by loadstate.exe via the "Restore User State" task, loadstate.exe will report that state store is invalid since part of it has been deleted and it will exit with a failure. If the drive/partition where the user profiles were originally located has been formatted, wiped, or erased (usually via the "Format and Partition Disk" or "Apply Oeprating System Image" tasks) then there is no way to recover the original files and settings.
Resolution
To resolve the prople the state store has to be all saved to the same drive/partition where the Windows OS and User Profiles reside. This will cause the state store not to span multiple drives/partitions. To do this, the variable OSDStateStorePath has to be changed from its default value. When using MDT 2010/MDT 2010 Update 1 integration, the variable has to be redefined after it has been set by the "Determine Local or Remote UserState" task via the ztiuserstate.wsf script .
To ensure that the state store is saved to the same drive/partition where Windows is installed and the User Profiles are located, the environment variable SystemDrive can be used as part of the path that defines the variable OSDStateStorePath.
If MDT 2010/MDT 2010 Update 1 integration is not being used, the "Set Task Sequence Variable" task that sets the variable OSDStateStorePath needs to be modified:
- In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
- Right click on the affected Task Sequence and choose "Edit".
- Click on the "Set Local State Location" task. Ensure that the task is a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath.
Next to the "Value:" text field, change it from
%_SMSTSUserStatePath%
to
%SystemDrive%\UserState
-
Click on the "OK" or "Apply" button to save the task sequence.
If the "Set Local State Location" task does not exist, look for a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath, and then make the changes above.
If using MDT 2010/MDT 2010 Update 1 integration, then a new "Set Task Sequence Variable" task needs to be added after the "Determine Local or Remote UserState" task that redefines the variable OSDStateStorePath:
- In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
- Right click on the affected Task Sequence and choose "Edit".
- Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task.
- In the newly created "Set Task Sequence Variable Task":
- Next to the "Name:" text box, enter in:
Set Local State Location
- Next to the "Task Sequence Variable:" text box, enter in
OSDStateStorePath
- Next to the "Value:" text box, enter in:
%SystemDrive%\StateStore
- Click on the "OK" or "Apply" button to save the task sequence.
If in Step 3 the task "Determine Local or Remote UserState" does not exist or has been renamed, look for the "Run Command Line" task that runs the script ztiuserstate.wsf, and then follow the above steps.
Note:
-
In the above two methods, the state store subdirectories are called UserState and StateStore. However the name of the state store can be whatever the user desires as long as it is within Windows naming conventions. The key point is to use the environment variable SystemDrive as part of the path to ensure that the state store is saved in the same drive/partition as Windows and the user profiles.
-
Ensure that there are no "Format and Partition Disk"/"Partition Disk"/"Partition Disk 0" tasks in the Task Sequence that format and partition the drive/partition where the user profiles are originally located and where the state store is saved. If there are any such tasks, either disable them or make sure that they have conditions on them where they do not run if state store is saved locally on the hard drive.
If a "Format and Partition Disk" task runs on the drive/partition where the user profiles are originally located and where the state store is saved, then all of the data and settings captured in the state store will be lost. Instead the "Apply Operating System Image"/"Apply Operating System" task will run a recursive delete of all files and directories on the drive/partition minus a few protected folders.
The protected folders that are not deleted include the Task Sequence cache folder and the state store folder. The Task Sequence cache folder path is stored in the variables _SMSTSMDataPath , _SMSTSClientCache, and _SMSTSNewClientCachePathToCleanup and usually resolves to the path C:\_SMSTaskSequence. As mentioned earlier, the state store path is stored in the variable OSDStateStorePath. The protected folders that will not be wiped are stored in the variable _SMSTSProtectedPaths
In the SMSTS.log, the recursive delete and wipe process that occurs during the "Apply Operating System Image"/"Apply Operating System" task is logged as something similar to the following:
Wiping C:\ ApplyOperatingSystem
Set "C:\_SMSTaskSequence" to not be wiped ApplyOperatingSystem
Set "%OSDStateStorePath%" to not be wiped ApplyOperatingSystem
Set "%_SMSTSClientCache%" to not be wiped ApplyOperatingSystem
Set "%_SMSTSNewClientCachePathToCleanup%" to not be wiped ApplyOperatingSystem
Skipping C:\_SMSTaskSequence for wipe ApplyOperatingSystem
Calculating expected free space. ApplyOperatingSystem
Reporting deletion progress. ApplyOperatingSystem
Successfully wiped C:\ ApplyOperatingSystem
More Posts
Next page »