Showing posts with label r3. Show all posts
Showing posts with label r3. Show all posts

Tuesday, October 2, 2012

How to use USMT 4 hardlinking in a Configuration Manager 2007 Task Sequence

How to use USMT 4 hardlinking in a Configuration Manager 2007 Task Sequence

 
Suppose you want to use the USMT 4 feature of hardlinking in a System Center Configuration Manager 2007 Task Sequence, but you notice that the "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks do not have any options to perform a local capture with hardlinking.  What's up with that?
Well what's going on is that USMT 4, which introduced hardlinking, shipped after ConfigMgr 2007 so the hardlinking option was not available in ConfigMgr 2007. However, USMT 4 support was added in ConfigMgr 2007 SP2, and via the OSDMigrateAdditionalCaptureOptions and OSDMigrateAdditionalRestoreOptions variables, a hardlink user migration can be accomplished in a ConfigMgr 2007 SP2 Task Sequence.
Out of the box, ConfigMgr 2007 SP2 only supports USMT 4 online captures, or captures that take place while in the full Windows OS. ConfigMgr 2007 SP2 does not support USMT 4 offline captures, or captures that take place while in WinPE. Offline captures are possible using the UDI feature of MDT 2010 Update 1 when it is integrated with ConfigMgr 2007 SP2.
With that said, there are several ways that a USMT 4 hardlink migration can be accomplished in a ConfigMgr 2007 Task Sequence, including:
  1. Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking.
  2. Modify an existing ConfigMgr 2007 Task Sequence that have the "Capture User State" and "Restore User State" tasks to support USMT 4 hardlinking.
Since USMT 4 support was not added until SP2 of ConfigMgr 2007, SP2 of ConfigMgr 2007 is required for hardlinking.
USMT 4 is supported in the following refresh scenarios:
  • Windows XP --> Windows Vista
  • Windows XP --> Windows 7
  • Windows Vista --> Windows Vista
  • Windows Vista --> Windows 7
  • Windows 7 --> Windows 7
USMT 4 is not supported for Windows XP --> Windows XP scenarios.
The first step is to ensure that the USMT 4 package is created:

Create the USMT 4 Package

When ConfigMgr 2007 SP2 is installed on the site server, the Windows Automated Installation Kit 2.0 (WAIK 2.0) is automatically installed. USMT 4 is part of WAIK 2.0 and its binaries can be found within the WAIK 2.0 installation folder.
  1. In the ConfigMgr 2007 Admin console on the site server, navigate to the "Computer Management" --> "Software Distribution" --> "Packages" node.
  2. Right click on the "Packages" node and select "New" --> "Package".
  3. In the "General" window, fill out the appropriate fields. The name of the package should describe it as the USMT 4 package. Click on the "Next >" button.
  4. In the "Date Source" window:
    • Check the option "This package contains source files"
    • Click on the "Set..." button under "Source directory".
      • Click on the option "Local drive on site server"
      • Click on the "Browse..." button under "Source directory: "
      • Navigate to and select C:\Program Files\Windows AIK\Tools\USMT folder and click on the "OK" button. Make sure to select the root of the USMT folder. DO NOT directly select either the amd64 or x86 folders. When running, the Task Sequence will automatically choose the appropriate binaries.
    • Click on the "OK" button.
    • Click on the "Next >" button.
  5. In the "Data Access" window, click on the "Next >" button.
  6. In the "Distribution Settings" window, click on the "Next >" button.
  7. In the "Reporting" window, click on the "Next >" button.
  8. In the "Security" window, click on the "Next >" button.
  9. In the "Summary" window, click on the "Next >" button.
  10. In the "Wizard Complete" window, click on the "Close" button.
  11. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Software Distribution" --> "Packages" node and find the newly created USMT 4 package.
  12. Expand the USMT 4 package and then right click on "Distribution Points" and select "New Distribution Points".
  13. Go through the "New Distribution Points Wizard" and make sure that the USMT 4 package is placed on some Distribution Points.
Notes:
  • It is not required to create a Program as part of the USMT 4 package.
  • In Step 5, if the WAIK 2.0 is installed on a different drive or directory, make sure to adjust the path C:\Program Files\Windows AIK\Tools\USMT accordingly.
  • It is recommended that the above steps be taken in a ConfigMgr 2007 console running on the site server where the WAIK 2.0 is installed. However, the above steps can be taken in a ConfigMgr 2007 admin console that is not running on the site server. In Step 5 , instead of selecting the option "Local drive on site server", select the option "Network path (UNC name)" and browse to a network share that has the WAIK 2.0 installed or the USMT 4 binary source files.
  • Please remember that the USMT 4 source files should contain BOTH the amd64 and x86 directories. The package should point to the root of the USMT 4 directory. It should NOT point directly to either the amd64 and x86 directories.
After creating the USMT 4 package, select the method below to enable USMT 4 hardlinking in a Task Sequence.

Method 1: Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking
  1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
  2. Right click on the "Task Sequences" node and choose "New" --> "Task Sequence".
  3. In the "Create a New Task Sequence" window, select the option "Install an existing image package" and click on the "Next >" button.
  4. In the "Task Sequence Information" window:
    • Next to "Task Sequence name:" text box, give the Task Sequence the desired name.
    • Click on the "Browse..." button next to "Boot Image:" and choose an appropriate Boot Image.
    • Click on the "Next >" button.
  5. In the "Install the Windows Operating System" window:
    • Click on the "Browse..." button next to "Image package:" and select the Operating System Image that is desired to be deployed.
    • Next to the "Image:" drop down box, make sure the desired image is selected.
    • UNCHECK the option "Partition and format the target computer before installing the operating system".
    • If desired, enter the product key next to the "Product Key:" text box.  If using a KMS activation server, this field should be left blank when deploying Windows Vista or Windows 7.
    • If desired, select the option "Always use the same administrator password" and specify the password in the "Password:" and "Confirm password:" text boxes.
    • Click on the "Next >" button.
  6. In the "Configure the Network" window, select "Join a domain" and fill out the appropriate fields. Click on the "Next >" button.
  7. In the "Install the ConfigMgr client" window, click on the "Browse" button and choose a package that contains the ConfigMgr 2007 SP2 install files. Make sure that the package is an SP2 installer of the ConfigMgr 2007 client. Selecting a package that contains either the RTM or SP1 client install files will cause the "Restore User State" task to fail since clients that are not SP2 do not support USMT 4. Click on the "Next >" button.
  8. In the "Configure State Migration" window:
    • Click on the "Browse..." button next to the "USMT Package:" field. Select the USMT 4 package and then click on the "OK" button.
    • Select the option "Save user settings locally". If this option is grayed out, the option "Partition and format the target computer before installing the operating system" was not unchecked in Step 5.
    • If desired, leave the options "Capture network settings" and "Capture Microsoft Windows settings" checked.
    • Click on the "Next >" button.
  9. In the "Include Updates in Image" window, select whether or not to install updates during the Task Sequence, and then click on the "Next >" button.
  10. In the "Install Software Packages" window, add any packages that are desired to be installed during the Task Sequence, and then click on the "Next >" button.
  11. In the "Summary" window, click on the "Next >" button.
  12. In the "Wizard Complete" window, click on the "Close" button.
  13. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
  14. Right click on the newly created Task Sequence and choose "Edit".
  15. Click on the "Set Local State Location" task. Next to the "Value:" text field, change it from %_SMSTSUserStatePath% to %SystemDrive%\UserState.
  16. Make sure that the "Set Local State Location" task is still selected and go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task in after the "Set Local State Location" and before "Capture User Files and Settings" tasks.
  17. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name:" text box, enter in:
      Set USMT Additional Capture Options
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalCaptureOptions
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink
  18. Click on the "Capture User Files and Settings" task to select it:
    • Check the option "Enable verbose logging"
    • Click on the "Options" tab and then uncheck the option "Continue on error".
  19. Click on the "Restore User Files and Settings" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after the "Restore User Files and Settings" group and before the "Restore User Files and Settings" task.
  20. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name: " text box, enter in:
      Set USMT Additional Restore Options
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalRestoreOptions
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink
  21. Click on the "Restore User Files and Settings" task to select it and then click on the option "Enable verbose logging".
  22. Click on the "OK" or "Apply" button to save the task sequence.
Please make sure to look at the notes section at the end of this post for detailed explanations on some of the above actions.
Method 2: Modify an existing ConfigMgr 2007 Task Sequence that has the "Capture User State" and "Restore User State" tasks in it


If a ConfigMgr 2007 Task Sequence that was used with USMT 3 or USMT 4 exists and was setup for either network capture with a State Migration Point (SMP) or for local capture on the hard drive without hardlinking, it can be modified to support USMT 4 local capture with hard linking.

The below instructions assume that there is already a "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks in the appropriate spots in the Task Sequence. If these tasks do no already exist in the Task Sequence, it is recommended to create a new Task Sequence using the method detailed above.
The below instructions are also not valid for a ConfigMgr 2007 Task Sequence that was created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard. Please see the section "More Information" for additional information regarding Task Sequences created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard:
  1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
  2. Right click on the affected Task Sequence and choose "Edit".
  3. Find any "Request State Store"/"Request User State Store" and "Release State Store"/"Release User State Storage" tasks and disable them. They can be disabled by clicking on the individual tasks, clicking on the "Options" tab, and then clicking on the option "Disable this step". If none of these tasks exist in the Task Sequence, continue to Step 4.
  4. Find any "Format and Partition Disk"/"Partition Disk"/"Partition Disk 0" tasks and disable them. They can be disabled by clicking on the individual tasks, clicking on the "Options" tab, and then clicking on the option "Disable this step". If none of these tasks exist in the Task Sequence, continue to Step 5.
  5. If a task "Set Local State Location" already exists before the "Capture User State"/"Capture User Files and Settings" task, skip to Step 6. Otherwise, click on the "Capture User State"/"Capture User Files and Settings" task to select it and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Capture User State"/"Capture User Files and Settings" task.
  6. 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%\UserState If there was already a "Set Task Sequence Variable Task" task in the Task Sequence that sets the OSDStateStorePath variable, make sure that it is configured to the above value.
  7. Click on the "Capture User State"/"Capture User Files and Settings" task to select it and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Capture User State"/"Capture User Files and Settings" task and after the "Set Local State Location".
  8. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name:" text box, enter in:
      Set USMT Additional Capture Options
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalCaptureOptions
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink If there was already a "Set Task Sequence Variable Task" in the Task Sequence that defined the variable OSDMigrateAdditionalCaptureOptions with some options, such as /ue, then add the additional options /nocompress /hardlink in the "Value:" text box after the options that already exist. Make sure that there is a space between each option.
  9. Click on the "Capture User Files and Settings"/"Capture User State" task to select it:
    • Ensure that the package under "User state migration tool package:"  is a USMT 4 package.
    • Check the option "Enable verbose logging".
    • Click on the "Options" tab and then uncheck the option "Continue on error".
  10. Click on the "Setup Windows and ConfigMgr" task. Ensure that the package selected next to the "Package" field is a package that installs the SP2 version of the ConfigMgr 2007 client. RTM and SP1 versions of the client will not work with USMT 4.
  11. Click on the "Restore User State"/"Restore User Files and Settings" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Restore User State"/"Restore User Files and Settings" task.
  12. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name: " text box, enter in:
      Set USMT Additional Restore Options
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalRestoreOptions
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink If there was already a "Set Task Sequence Variable Task" in the Task Sequence that defined the variable OSDMigrateAdditionalRestoreOptions with some options, such as /lac, then add the additional options /nocompress /hardlink in the "Value:" text box after the options that already exist. Make sure that there is a space between each option.
  13. Click on the "Restore User Files and Settings"/"Restore User State" task:
    • Ensure that the package under "User state migration tool package:"  is a USMT 4 package.
    • Check the option "Enable verbose logging".
  14. Click on the "OK" or "Apply" button to save the task sequence.
Notes on the two above methods:
  • A "Format and Partition Disk" task is not desired in the above Task Sequences. If a format and partition of the disk occurred, it would wipe all data on the drive, including the State Store, and the captured data would be lost. Instead, to erase content off of the drive in preparation to install the new Windows OS, during the "Apply Operating System Image"/"Apply Operating System" task, a recursive delete of all files and directories occurs on the drive 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. 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 you will see the recursive delete and wipe process 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
  • In Step 15 (Method 1) and Step 6 (Method 2), the State Store path location is changed from %_SMSTSUserStatePath% to %SystemDrive%\UserState. The _SMSTSUserStatePath variable normally resolves to the path C:\_SMSTaskSequence\UserState. The C:\_SMSTaskSequence folder is the Task Sequence cache folder. This is done to fix several issues that can be caused by saving the State Store in the Task Sequence cache folder. These problems include:
    1. Whether or not a Task Sequence succeeded, the Task Sequence usually exits cleanly. When the Task Sequence exists cleanly, it deletes the Task Sequence cache folder of C:\_SMSTaskSequence. This can be a problem if the Task Sequence fails for whatever reason before the captured user data is restored.
      If the Task Sequence fails but exists cleanly before the user data is restored, then the cache folder of C:\_SMSTaskSequence is deleted, which will cause the C:\_SMSTaskSequence\UserState user State Store folder located within the C:\_SMSTaskSequence folder to also be deleted. The captured data will then be deleted and lost before it can be restored.
      If instead the State Store is specified to be a folder outside of the Task Sequence cache folder, such as C:\UserState, when the Task Sequence exists cleanly, it will not automatically delete the State Store since it is no longer within the Task Sequence cache folder. The Task Sequence cache folder will still be deleted, but the State Store will not. In case of Task Sequence failures before user data is restored, user data can still be restored from the State Store using manual methods.
      See KB958808 for additional information:
      User data from the USMT may be deleted unexpectedly by the task sequence engine during the operating system deployment process in System Center Configuration Manager 2007 SP1
      http://support.microsoft.com/kb/958808

      Note: KB958808 does not have to be installed in ConfigMgr 2007 SP2 as this hotfix is already included as part of SP2.
    2. Given the following scenario on a PC:
      1) PC has two (or multiple) drives or partitions
      2) User profiles and Windows are located on the first drive or partition (assume drive letter C:)
      3) Second drive or partition has more available free space than the first (assume drive letter D:)
      then the Task Sequence cache folder will probably be created on the second drive/partition (D:).
      In these scenarios the variable _SMSTSUserStatePath would resolve to the path D:\_SMSTaskSequence\UserState. This is a problem when using USMT 4 hardlinking because the hardlink store has to be on the same drive/partition as Windows and the user profiles. In the above scenario, Windows and the user profiles would be on C:, but the State Store would be created on D:. USMT 4 will actually capture the data in this scenario and not cause any errors, but the captured data will be invalid and it will not be able to be properly restored.
      By making sure that we save the State Store to the drive that contains Windows and user profiles via the variable SystemDrive, we make sure that this problem does not occur.
    3. There are known scenarios when going from a Windows OS with UAC off to a Windows OS with UAC on that will cause permissions not to be set properly on the State Store if the State Store is located within the Task Sequence cache folder. In these scenarios, user data is restored successfully, but the user will receive an "Access Denied" error message when trying to access their files. Saving the State Store outside of the Task Sequence cache folder will resolve the problem.
  • Even though in Step 15 (Method 1) and Step 6 (Method 2) it is recommended that the State Store be saved to a location outside of the Task Sequence cache folder so that it is not automatically deleted, it is still advisable to delete the State Store at some point after the Task Sequence has completed and the user state has been verified that it has been restored successfully. This can be done properly via the usmtutils.exe utility included with USMT 4. To properly remove the State Store, run the command:
usmtutils.exe /rd <Path_to_State_Store>
where <Path_to_State_Store> is the path as specified in the OSDStateStorePath variable via the "Set Local State Location" task (without the brackets <>).
Not deleting the State Store can cause the following problems:
  • If an administrator tries to access the State Store, it may change the permissions of all of the user files in the State Store to the administrator's permissions. This may cause users not to be able to access their files and they may receive "Access Denied" error messages. For this reason it is recommended that an administrator not try to access the State Store directly.
  • A user deleting files in their profile will not cause the actual file to be deleted since a second link exists to the file in the State Store. Although the user will no longer see the file in their profile, the link to the file will still exist in the State Store, and disk space will not be freed up.
  • In Step 18 (Method 1) and Step 9 (Method 2), the option "Continue on Error" is disabled. This option is originally enabled because with USMT 3, USMT 3 could report a lot of false positive errors, causing the task to un-necessarily fail. However this has been improved in USMT 4 and this situation should rarely happen with USMT 4.
    If the option is left checked and the USMT 4 state capture fails for some reason, the Task Sequence will continue and eventually wipe the drive at the "Apply Operating System Image"/"Apply Operating System" task, causing all user files and settings to be deleted and lost. For this reason it is safer to leave this option unchecked when using USMT 4. Leaving the option unchecked will cause the Task Sequence to fail in the event that users' files are not captured successfully, which is a desired outcome.
  • In Steps 18 and 21 (Method 1) and Steps 9 and 13 (Method 2), the option "Enable verbose logging" is enabled. This is optional, but it is advisable to leave this option enabled to help troubleshoot USMT 4 capture and restore failures. Enabling verbose logging will cause the capture and restore tasks to take a bit longer, but will the add the benefit of having more detailed logs to help resolve problems.
  • The tasks "Request State Store" and "Release State Store" are not needed in the Task Sequences that performs local capture with hardlinking because these tasks are only used when a State Migration Point (SMP) is being used. An SMP is only used when the State Store is saved to a network location. When using hardlinking, the State Store is always saved to the local hard drive and an SMP is not used.
  • In Steps 17 and 20 (Method 1) and Steps 8 and 12 (Method 2), please make sure to make the distinction between the variables specified in the tasks "Set USMT Additional Capture Options" and "Set USMT Additional Restore Options". The variables have similar names but they are different. One is OSDMigrateAdditionalCaptureOptionsand the other is OSDMigrateAdditionalRestoreOptions.

More Information

What is a hardlink and why use the USMT 4 feature of hardlinking?

Hardlinking is a feature of NTFS where multiple links can exist to one file on the hard drive. As long as one link exists, the file is not deleted. When a file has multiple links to it, the file will appear to exist in different locations in the file system, but the file only exists once on the hard drive. When the file is deleted from one location, as long as other links to the file still exist, the file is not actually deleted, and the file will still appear in the other locations that it has links to. The file is not deleted until it has been deleted from all of the locations that it has links to.
When USMT local capture is used without hardlinking, files are copied from their original location into the local State Store. For this reason, there has to be sufficient space on the hard drive to store all of the captured files. Even when compression is used, this can mean needing enough space on the hard drive somewhere in the area of almost double the amount of space taken up by the original files. If the original files take 30GB of space, then the hard drive will need about 30GB of free space on it.
When USMT 4 with hardlinking is used, instead of a file being copied to the local State Store, a second link to the file is created in the local State Store. The time taken to create the link to the file in the State Store is almost instantaneous, does not vary with the size of the file, and is much faster than trying to copy the file to the local State Store. The time it takes to capture 30GB of data will only take a bit longer than the time it takes to capture 1GB of data. When not using hardlinking, the amount of time taken to capture 30GB of data would be significantly longer than capturing 1GB of data.
Additionally hardlinking requires almost no additional hard drive space. The only additional hard drive space taken by USMT 4 with hardlinking are administrative files that keep track of where the files need to be restored to. This usually only takes a few MB of disk space vs. the potential GB of disk space taken when hardlinking is not used.
When USMT 4 with hardlinking is used in a ConfigMgr 2007 SP2 Task Sequence via the "Capture User State" task and the OSDStateStorePath and OSDMigrateAdditionalCaptureOptions variables, during the "Capture User State" task, new links are created for the captured files in the State Store location . All of the original links to the files are then deleted during the "Apply Operating System Image" task via recursive delete and wipe of the hard drive. However, because a second link exists in the State Store, and because the State Store is not deleted or wiped during the "Apply Operating System Image" task, the original files remains intact and are not deleted. Later in the Task Sequence via the "Restore User State" task and the OSDStateStorePath and OSDMigrateAdditionalRestoreOptions variables, the original links to the files are recreated back to their original location.
USMT 4 hardlinking also has the advantage over saving the State Store on a network location, such as a State Migration Point (SMP), in that it does not have to take the time to copy the files up to the network share, bandwidth is not used, and a server with plenty of disk space for saving the State Stores is not needed.
To summarize, USMT 4 with hardlinking has the following advantages:
  1. It is significant faster than either copying the captured files to the local State Store or a State Store located on a network share (SMP).
  2. It requires only a few additional MB of disk space vs potential GB of disk space, whether on the local hard drive or on a network share on a server (SMP).
  3. It saves network bandwidth when opting to use hardlinking over a network share (SMP).
The only disadvantage that hardlinking has is that it could potentially run into problems if there is file corruption on the hard drive, the hard drive has bad sectors, or the hard drive is having some other type of problems. However these problems would also be exposed when using local capture without hardlinking. In these scenarios, running a CHKDSK /R on the hard drive is advisable, and a full format of the drive may also be advisable. A network share (SMP) may be needed in these cases.

Why are the two above methods not valid when using a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard?

The above methods are not valid when using a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard because the Task Sequences created using the Wizard already have hardlinking enabled by default.
If a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard is inspected, it will be missing the "Set Task Sequence Variable" tasks that set the variables OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions. So if the Task Sequence is missing the steps that sets these variables, and these variables are required to do hardlinking, how does the Task Sequence accomplish hardlinking?
It does this via the task "Determine Local or Remote UserState" task and the MDT script ztiuserstate.wsf. If the USMT 3 package is selected at the "Determine Local or Remote UserState" task, the ztiuserstate.wsf script determines if there is enough space on the hard drive to do a local capture (without hardlinking since it is USMT 3), and if not, it will perform a network capture via a State Migration Point (SMP). Based on which capture method determined by the ztiuserstate.wsf script is used, it defines the appropriate variables, OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions, and along with conditions set on the relevant tasks, the Task Sequence will perform the appropriate capture.
However if the USMT 4 package is selected at the "Determine Local or Remote UserState" task, since disk space is not an issue, the ztiuserstate.wsf script will always default to local capture with hardlinking. It will then set the appropriate variables for the Task Sequence to perform a hardlink migration.
There is one problem though with using the ztiuserstate.wsf script. The ztiuserstate.wsf script defaults the State Store to the subdirectory StateStore within the Task Sequence cache folder. For the reasons stated in the notes above about saving the State Store within the Task Sequence cache folder, it is not always desirable to save the State Store within the Task Sequence cache folder.
The Task Sequence created by the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard actually works around the first issue (State Store is deleted even if the data was not restored) by moving the State Store out of the Task Sequence cache folder via the ztimovestatestore.wsf script and the "Move State Store" task. The State Store is moved whether or not the Task Sequence succeeds or fails. However the other two problems can still happen.
To resolve the other two problems and save the State Store outside of the Task Sequence cache folder when using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard, follow the below steps:
  1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
  2. Right click on the affected Task Sequence created using the MDT Wizard and choose "Edit".
  3. 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.
  4. 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
  5. Click on the "OK" or "Apply" button to save the task sequence.
The above steps resets the variable OSDStateStorePath to a path outside of the Task Sequence cache folder after the "Determine Local or Remote UserState" task and the ztiuserstate.wsf script sets it to the StateStore subdirectory within the Task Sequence cache folder.

Can an existing ConfigMgr 2007 Task Sequence that does not have any USMT tasks including the "Capture User State" and "Restore User State" tasks be modified to do USMT 4 hardlinking?

Yes, but the order of the steps and where they are placed in the Task Sequence are critical. The five tasks that need to be added, and the order that they need to run in are as follows:
  • Set Local State Location
  • Set USMT Additional Capture Options
  • Capture User State
  • Set USMT Additional Restore Options
  • Restore User State
In addition, any "Format and Partition Disk" tasks need to be disabled.
The first three tasks, Set Local State Location, Set USMT Additional Capture Options, and Capture User State, have to run in the original full Windows OS before the Task Sequence boots into WinPE. This is usually before a "Restart Computer" task, such as the "Restart in Windows PE" task. The tasks also have to be placed into a group that has a condition where it only runs in the full Windows OS and not in WinPE. This can be accomplished by setting a condition on the group where the Task Sequence variable _SMSTSInWinPE equals false. The prevents the tasks from running in Bare Metal scenarios where the PCs are booted directly into WinPE and state capture is not needed.
The last two tasks, Set USMT Additional Restore Options and Restore User State, have to run in the newly deployed full Windows OS at some point after the "Setup Windows and ConfigMgr" task, preferably towards the end of the Task Sequence after all applications have been installed.
The Capture User State and Restore User State tasks are built in tasks of ConfigMgr 2007. They can be found under the "Add" --> "User State" menu in a Task Sequence.
The Set Local State Location, Set USMT Additional Capture Options, and Set USMT Additional Restore Options are all actually Set Task Sequence Variable tasks. For instructions on how to properly set up these tasks, see the two above methods.
As a general guide and template to modifying the existing Task Sequence, Method 1 above can be used to create a Task Sequence that serves as the template and guide to modifying the existing Task Sequence.

Tuesday, May 8, 2012

SCCM Capture Media not able to Capture Reffrence Computer image.

When trying to capture a new image of DELL Optiplex 790 windows 7 Proff SP1.  After I fill in the relevant information to save to a network share on a SCCM Server itself and then select finish, the windows disappears and does nothing.
i looked for Sysprep Folder in %System Drive %\windows32\Sysprep but it was present and able to run properly.
Checked Computer Network Access Account on SCCM Server and for Local Computer also then after
  i have looked at the logs and this is what it states:

AllocateCDRoms is set; will not start TSManager

This seems to halt the capture process and nothing else happens.
i have also plugged in an external drive to capture the image to this, and the same error comes up.

Cause :

AllocateCD Rome is Restricted by Group Policy when it was in Domain or by default set by some OEM vendors.

SCCM Capture media uses SYSTEM and Domain Account for Capturing the Windows Image but GPO is only allow CD ROM access to Logged on Users in result Capture wizard Finished without any capture process.

Resolution :

"allocatecdroms" is the REG Key value which is responsible for the CD ROM access.

By default the Value is "0" if this value is "1" that means CD ROM access has been restricted for Local logged on users only.

To resolve this issue set REG Key value to Default "0" and save it.

close Regedit and Restart Computer.

Start Capture wizard again and check...

For More information Please browse Microsoft Technet Article for the same...

http://technet.microsoft.com/en-us/library/cc957388.aspx

Cheers!!!!!

exchange spam filter exchange spam filter exchange spam filter exchange spam filter exchange spam filter

Wednesday, May 2, 2012

Windows Deployment Service Fail to start in 2003 and 2008 with SCCM

Windows Deployment Service Fail to start in 2003 and 2008 with SCCM.

I have a Windows 2008 Server that has WDS + SCCM 2007 R3 installed.  The Windows
Deployment Services Server Service isn't started and when I try to
Start  it I got a message that says:

Windows could not Start the Widows Deployment Services Server on Local
Computer.  For more information, review the System Event Log.  If this
is a non-Microsoft service, contact the service vendor, and refer to

server-specific error code 2310.
Event viewer lists Event ID 257 and this:
An error occurred while trying to Start the Windows Deployment Services
server.
 Error Information: 0x906
  
Hear is the Problem Analysis and Resolution of below errors.

CAUSE :

This problem occurs because the location of the computer object that is running WDS has changed in the Active Directory directory service.

A Windows Deployment Services (WDS) server is running Microsoft Windows Server 2003 with Service Pack 1 (SP1) or Microsoft Windows Server 2003 with Service Pack 2 (SP2). If you move the WDS server to a different organizational unit, the WDS server may not start. Additionally, one of the following error messages may be logged in the System log on the WDS server:

Error Messages :

Error message 1
Type: Error
Event ID: 7024 Source: Service Control Manager
Description: The Windows Deployment Services Server service terminated with service-specific error 9 (0x 3).
exchange spam filter exchange spam filter exchange spam filter exchange spam filter exchange spam filter Error message 2
Type: Error
Event ID: 7024 Source: Service Control Manager
Description: The Windows Deployment Services Server service terminated with service-specific error 19 (0x13)
One of the following groups of error messages may also be logged in the Application log:

Error message group 1

Type: Error
Event ID: 261
Source: WDSPXE
Description: An error occurred while trying to initialize provider BINLSVC loaded from C:\WINDOWS\system32\binlsvc.dll. If the provider is marked as critical the Windows Deployment Services server will be shutdown. Error Information: 0x 3

Type: Error
Event ID: 1800 Source: BINLSVC
Description: An error occurred while creating the Service Control Point object for this Windows Deployment Services server in Active Directory Domain Services. Error Information: 0x 3

Type: Error
Event ID: 1803
Source: BINLSVC
Description: An error occurred while attempting to locate the Service Control Point object for this Windows Deployment Services server in Active Directory Domain Services. There was an error reading the 'netbootSCPBL' attribute from the Computer object. Error Information: 0x2
Error message group 2

Event Type: Error
Event Source: BINLSVC
Event ID: 1803 Description: An error occurred while attempting to locate the Service Control Point object for this Windows Deployment Services server in Active Directory Domain Services. There was an error reading the 'netbootSCPBL' attribute from the Computer object. Error Information: 0x2

Event Type: Error
Event Source: BINLSVC
Event ID: 1800 Description: An error occurred while creating the Service Control Point object for this Windows Deployment Services server in Active Directory Domain Services. Error Information: 0x13

Event Type: Error
Event Source: WDSPXE
Event ID: 261 Description: An error occurred while trying to initialize provider BINLSVC loaded from C:\WINDOWS\system32\binlsvc.dll. If the provider is marked as critical the Windows Deployment Services server will be shutdown. Error Information: 0x13

Event Type: Error
Event Source: WDSPXE
Event ID: 265 Description: An error occurred while trying to initialize provider BINLSVC. Since the provider is marked as critical, the Windows Deployment Services server will be shutdown. Error Information: 0x13

Event Type: Error
Event Source: WDSServer
Event ID: 513 Description: An error occurred while trying to initialize provider WDSPXE from C:\WINDOWS\system32\wdspxe.dll. Windows Deployment Services server will be shutdown. Error Information: 0x13

Event Type: Error
Event Source: WDSServer
Event ID: 522
Description: An error occurred while trying to shutdown provider WDSPXE. Error Information: 0x6

RESOLUTION :

To resolve this problem, reinitialize the WDS server after you move the WDS server to a different organizational unit. To do this, follow these steps:
  1. Click Start, click Run, type cmd, and then click OK.
  2. At the command prompt, type wdsutil /uninitialize-server, and then press ENTER.
  3. Move the WDS account to Active Directory in the new organizational unit.
  4. To reinitialize the WDS service, type wdsutil /initialize-server /reminst:{RemoteInstallFolder} at a command prompt, and then press ENTER.

Enjoy!!!!

Tuesday, May 1, 2012

Enabling workgroup clients to locate SMS and ConfigMgr site systems using LMHOSTS files

System Center Configuration Manager can Manage Workgroup Computer clients but Workgroup computers must be able to locate a server locator point for site assignment and their default management point in order to be managed. Because workgroup clients cannot query Active Directory Domain Services to find these site systems, in this situation, you have three options:

  1. The server locator point can be specified in the CCMSetup.exe installation command-line parameters. For more information about doing this see About Configuration Manager Client Installation Properties at: http://technet.microsoft.com/en-us/library/bb680980.aspx.
  2. You can manually publish the server locator point and management point in WINS. For more information about doing this see, How to Manually Add Configuration Manager Site Information to WINS at: http://technet.microsoft.com/en-us/library/bb632567.aspx.
  3. The server locator point can be specified in the LMHOSTS file on workgroup computers when a WINS server is not available
For Workgroup clients to locate these site systems, you need to enable some sort of NetBIOS name resolution. If you do not have a WINS server in place to support these clients, you can use an LMHOSTS file to enable site system name resolution for Workgroup clients.
To use the LMHOSTS file for site system name resolution, just add the following information (where <site code> is the site code for the primary site the client should be assigned to) to the LMHOSTS file. The LMHOSTS file is generally located in the client's %WINDIR%\system32\drivers\etc directory:
<IP address of MP> "MP_<site code> \0x1A" #PRE
<IP address of SLP> "SMS_SLP \0x1a" #PRE

NOTE: For the lmhosts file to work, it should not have a file extension. If you only find the lmhosts.sam (sample file) in that location just modify the file for your purposes and save it without the .sam file extension.
Because these names contain special characters, they must be enclosed in quotation marks. There must be a total of 20 characters within the quotation marks. There must be a total of 20 characters within the quotation marks. Yes, I wrote that twice on purpose for emphasis! If there aren't 20 characters in the name then using the LMHOSTS file for this will not work. Make sure that the backslashes are at the 16th character the end quotes should be after the 20th character.
Here's a handy trick for doing this that I picked up from How to write an Lmhosts file for domain validation and other name resolution issues (http://support.microsoft.com/kb/180094):
There must be a total of 20 characters within the quotations (the domain name plus the appropriate number of spaces to pad up to 15 characters, plus the backslash, plus the NetBIOS hex representation of the service type).

To help determine where the sixteenth character is, copy the following line to your Lmhosts file:
# IP Address "123456789012345*7890" Line up the double quotation marks (") by adding or removing spaces from the comment line, and put the \ on the sixteenth column (the column marked with the asterisk). You must use spaces after the name and before the \, not a tab.
After that has been done, to verify it worked just open up a command prompt and enter the following command to refresh the name cache:
nbtstat -R

Tuesday, April 10, 2012

0x80070091 error while upgrading Windows XP to Windows 7 by SCCM 2007

Hello Friends,

Today i am trying to updgrade operating system windows xp to windows 7 by using System Center Configuration Magager (SCCM) 2007 R3.
i have made Task Sequence by using Microsoft Deployment tool kit 2010 Update 1 and advertise on collection, but while "wimping C:\ Drive " step task sequence gets failed..... I tried many times with new task sequece and face same error like mentioned in image.

Cause :

This error occured due to task sequece engine may not able to wipe c:\ Drive propperly or some files which is having wrong file extention or ended with # or ended with ( dot .) or some corrupt files.

Resolution :

1) Run chkdsk command if task sequence fail. ( this command may take lot of time to complete operation )
2) Press f8 while facing error and manually delete currept profile.
3) or write Script to delete currupt files.

For more information please refer http://blogs.msdn.com/b/alex_semi/archive/2012/02/22/os-refresh-fails-with-ntldr-can-t-be-found-error.aspx


exchange spam filter exchange spam filter exchange spam filter exchange spam filter exchange spam filter

Determine when the operating system was installed on a computer

Determine when the operating system was installed on a computer

Introduction

The Win32_OperatingSystem WMI class can be used to gather useful information about the Operating System. It supports many properties, out of which the InstallDate property is used to determine the Operating System installation date in a computer.

Script to determine the Operating System installation date

To run the script, copy the following lines to a Notepad document, and save as a file with .VBS extension (use double-quotes) and double-click the file. The installation date and time would be displayed.
' © 2006 Ramesh Srinivasan.
'Returns the Operating System installation date.

strComputer = "."
Set dtmInstallDate = CreateObject( _
  "WbemScripting.SWbemDateTime")
Set objWMIService = GetObject("winmgmts:" _
  & "{impersonationLevel=impersonate}!\\" _
  & strComputer & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
  ("Select * from Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
  MsgBox "Install Date: " & getmydat (objOperatingSystem.InstallDate)
Next
Function getmydat(wmitime)
  dtmInstallDate.Value = wmitime
  getmydat = dtmInstallDate.GetVarDate
End function

Two more methods - For Windows XP Professional systems

Systeminfo.exe console-utility

Systeminfo command-line tool displays detailed configuration information about a computer and its operating system, including operating system configuration, security information, product ID, and hardware properties, such as RAM, disk space, and network cards. More information available at Microsoft Windows XP - Systeminfo

WMIC - command-line tool

Click Start, Run and type:
CMD /K WMIC OS GET InstallDate
You'll see the Operating System installation date (in WMI format). The first eight characters in that output gives you the installation date.

Tuesday, March 13, 2012

Run Charts in ConfigMgr Reports when the Reporting Point is located on a Windows Server 2008 x64 server / HTTP Error 500.19 – Internal Server Error


At a customer site last week, I used Windows Server 2008 x64 to host all the ConfigMgr roles, including the Reporting point. I also installed the Microsoft Office Web Components to add chart support to some of the reports. But I kept getting this error “This report has a chart, but the Microsoft Office Web Components required to view charts are not installed on the Reporting Point. Please contact your administrator." I remember reading Some blogs about changing the whole web server in Windows Server 2003 x64 to run as a 32 bit web server. So narrowing down the problem is that the Microsoft Office Web Components is 32 bit application and the Reporting Point is running in the Default Application Pool (DefaultAppPool) on the web server, which is running 64 bit.

You might have read that in Windows Server 2008 x64 web server is it possible to run different applications in different worker processes. This means that by changing the application pool for the Reporting Point to run as a 32 bit application, is it possible run the Charts in the ConfigMgr web reports. So I did and problem solved.
After installing System Center Configuration Manager 2007 SP2 (SCCM) on a Windows Server 2008 SP x64 system, I decided to install also the Reporting Point on this Site Server.

SQL Reporting Services and ConfigMgr Report Services Point configured properly and I didn't had any issues copying and running reports on IIS 7.0. But when I came to a report that had a graph I got the following message:

"This report has a chart, but the Microsoft Office Web Components required to view charts are not installed on the Reporting Point. Please contact your administrator."

I downloaded and installed in the Office 2003 Add-in: Office Web Components from


After that, I tried to run again the report and still I was getting the same informational message.

After doing some research on the issue I found that I need to create a custom Application Pool with enable32BitAppOnWin64 set to True. This because the worker responsible to execute the graphs needs to operate in 32bit mode. Then I've assigned the reporting point web site to the custom 32bit application pool and when I tried to open the reporting point web site on a browser I got a new error message.

HTTP Error 500.19 – Internal Server Error


So I started wondering what causes the problem. After some research again I identified that it was WSUS 3.0 SP2 x64 and more specifically the 64bit version compression module (suscomp.dll).

Therefore the solutions on this were the following. Either disable totally the compression scheme on the web site, but this will cause wsus responses to be uncompressed and this will cause some performance degradation. Or to replace the 64bit version of suscomp.dll with the 32bit version.

To view the compression scheme, run the following command

%windir%\system32\inetsrv\appcmd.exe list config -section:system.webServer/httpCompression

the command will display the compression scheme for the webserver. Schemes are registered globally therefore by removing them, the compression is disabled on the webserver.

To remove the compression scheme type:

%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']

To add the compression scheme type:


%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+[name='xpress',doStaticCompression='false',dll='%windir%\system32\inetsrv\suscomp.dll']

References

Run Charts in ConfigMgr Reports when the Reporting Point is located on a Windows Server 2008 x64 serverhttp://uje.spaces.live.com/blog/cns!DAE27042D25E8A2A!310.entry

500.19 Error When Enabling 32-bit Application Poolhttp://forums.iis.net/t/1149768.aspx

Error message when you visit a Web site that is hosted on IIS 7.0: "HTTP Error 500.19 – Internal Server Error"http://support.microsoft.com/kb/942055