Coming soon: Microsoft Deployment Toolkit 2012 Beta 1!

New features include support for Microsoft System Center Configuration Manager 2012, an improved Lite Touch user experience, and more!

  • Visit the MDT home page and subscribe to the news feed to be notified when he beta is available for download (releasing in early June).

Source: Microsoft Solution Accelerators May Newsletter!

USMT 4.0 Hotfix: Support for Office 2010

Earlier this year Microsoft released an update to USMT 4.0, adding support for Office 2010 and a few other minor updates:

  • The XML rules included in the default Migapp.xml file are updated to include new rules that support migrating Office 2010 application settings.
  • Changes that resolve an issue that creates many temporary files, that does not correctly remove the temporary files in a hard-link migration, and that causes poor LoadState performance.
  • An issue that prevents migration in certain time zones is corrected.

You can download the update from Here.

Run Command Line in Task Sequence for a 64-bit OS

When running certain applications and commands through the “Run Command Line” task sequence in System Center Configuration Manager 2007 for a 64-bit Operating System you might find that the task will fail. This is true for applications that don’t fully support 64-bit mode. Some commands are not available by default when running in 32-bit mode, for example “manage-bde.exe” or “winsat.exe.

To work around this issue, simply disable the “64-bit file system redirection” in the task sequence when running such applications or commands.

Run Command Line in Task Sequence for a 64 bit OS

Undocumented Properties in MDT 2010 Update 1

Mikael Nyström (aka The Deployment Bunny), has a new blog post on some of the undocumented Properties in MDT 2010 Update 1. Read the full blog post here.

Once again, at 33000 feet over the Atlantic Ocean on my way back from TechEd NA in Atlanta I started to think about all the different properties in MDT 2010 Update 1 that I use which are not really documented, trust me there are “some”. Some of them is, well, not really so useful, but some of them I really use and so should you. So this post is solely made for the purpose of giving you the same “relaxed” life that I have. Hmm, that did not really came out right I think, anyway, You know what I mean, right…

Now, since I not work on that team, I just happen to know the a bit. This is NOT any kind of official description, hopefully someone@microsoft.com will update he documentation sometime around this, especially when virtualization is getting to be more of the standard.

Continue to read the full blog post here.

Creating a fully-patched image using MDT 2010 Lite Touch

Michael Niehaus has a new post on how to create a fully patched image using MDT 2010 Lite Touch. Read the full post here.

I’ve always been a fan of the thinnest image possible. Taking that to an extreme, that means using the original image straight off the Microsoft media. But over time if you did this you’d find that the time required to apply patches to that image becomes unmanageable. (Case in point: I started up a new laptop for the first time with an OEM-installed image that had hooks to require all patches be applied before first logon. It took three hours for that to happen.)

I’ve also been a fan of doing “just in time” patching, which is something that MDT can do too: Instead of patching the image in advance, you can inject updates offline after the image has been applied to the disk but before it boots for the first time. That does often improve the time required, but it doesn’t eliminate it – it adds time when initially injecting the updates offline, and then more time on first boot as the “online actions” for those “offline patches” are completed (you’ll see the messages on the screen during the first boot showing a percentage complete while this is happening).

So reading between the lines, that means I would suggest always creating your own master image containing at least all the current service packs and patches. (Don’t try to install the OS service pack yourself – just download “slipstreamed” media from the Microsoft licensing website, as that’s the ultimate time-saving technique.) So how should you do this? Well, there are a few ways:

  • Mount the existing WIM image and just inject the updates offline with DISM. This is certainly doable, but there are three challenges:
    • The online actions for these updates will still take some time
    • It introduces a “human touch” into the process, unless you go through the effort of automating this to make it a repeatable process.
    • It only works for operating system updates.
  • Build a new image and install all the updates into that image before sysprepping and capturing the image using a completely automated process. This is my preferred approach, because it’s a consistent process for any other type of update being made to the image.

Not surprisingly, MDT 2010 Lite Touch provides a way to implement my preferred method above – and actually multiple methods that can be used. Let’s go through those methods.

Read the full post here.

OSD: Change Volume Name

Lets say you need to change/rename the volume name of the C: drive to the computername, as part of your OS deployment Task Sequence. This script will help you do that:

Enjoy

+Ronni Pedersen

Enable AERO on Windows 7 64-bit systems during OS Deployment using Configuration Manager

If you wish to deploy Windows 7 32-bit using Configuration Manager, and you need to enable AERO during deployment, you needs to add a “Run Command Line” step to the Task Sequence with the following command:

WinSAT.exe formal

If you do the same while deploying Windows 7 64-bit, the step will fail. The is due to the File System  Redirector, and the fact that the Tack Sequence is running in 32-bit context.

To workaround this minor issue, make sure that you select Disable 64-bit file system redirection, on this step.

Enable AERO on Windows 7 64 bit systems during OS Deployment using Configuration Manager

How to change the default BitLocker encryption method and cipher strength when using the Enable BitLocker task in ConfigMgr 2007

By default, the "Enable BitLocker" task of a System Center Configuration Manager 2007 Task Sequence defaults to an encryption method and cipher strength of "AES 128-bit with Diffuser". However, the "Enable BitLocker" task does not have any way of changing from the default encryption method and cipher strength to any of the other options:

AES 256-bit with Diffuser
AES 128-bit
AES 256-bit

Normally the BitLocker encryption method and cipher strength is controlled by Group Policy. This policy can be found in the Group Policy Editor (gpedit.msc) under the following node:

Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption

and under the following policy:

Choose drive encryption method and cipher strength (Windows 7 and Windows Server 2008 R2)
Configure encryption method (Windows Vista and Windows Server 2008)

The default setting in Windows for the BitLocker encryption method and cipher strength is "AES 128-bit with Diffuser". This setting can be changed using the above policy, however when running a ConfigMgr 2007 Task Sequence a policy that changes the default encryption method and cipher strength may have not been applied by the time that the "Enable BitLocker" task runs.

To ensure that the "Enable BitLocker" task encrypts the drive at the proper encryption method and cipher strength, add a "Run Command Line" task to the Task Sequence that sets the BitLocker encryption method and cipher strength correctly via a registry entry:

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. Click on the task immediately BEFORE the "Enable BitLocker" task.

4. Click on "Add" –> "General" –> "Run Command Line". This should add a "Run Command Line" task immediately before the "Enable BitLocker" task.

5. In the newly created "Run Command Line" task:

In the "Name:" text box, enter: Set BitLocker Encryption Method and Cipher Strength

In the "Command line:" text box, enter in one of the following registry commands depending on the encryption method and cipher strength desired:

    AES 256-bit with Diffuser
    reg add HKLMSOFTWAREPoliciesMicrosoftFVE /v EncryptionMethod  /t REG_DWORD /d 2 /f

    AES 128-bit
    reg add HKLMSOFTWAREPoliciesMicrosoftFVE /v EncryptionMethod  /t REG_DWORD /d 3 /f

    AES 256-bit
    reg add HKLMSOFTWAREPoliciesMicrosoftFVE /v EncryptionMethod  /t REG_DWORD /d 4 /f

6. Click on the "OK" or "Apply" button to save the Task Sequence.

After the "Enable BitLocker" step has run and BitLocker has been enabled, the encryption method and cipher strength applied can be checked by running the following command at an elevated command prompt after the Task Sequence has completed:

Manage-bde –status <Drive_Letter>

where <Drive_Letter> is the drive letter of the disk where BitLocker was enabled (without the brackets <>). For example, to check the encryption method and cipher strength on the C: drive, run the command:

Manage-bde –status c:

The above command can also be used to check the current progress of the drive encryption and/or if the encryption has been completed on the drive.

 

Author of this post: Frank Rojas | System Center Support Escalation Engineer

Original Port: http://blogs.technet.com/b/configurationmgr/archive/2010/08/10/how-to-change-the-default-bitlocker-encryption-method-and-cipher-strength-when-using-the-enable-bitlocker-task-in-configmgr-2007.aspx

Exploring the User State Migration Toolkit (USMT) 4.0

Richard Smith has created a great video on how to get started with USMT 4.0.

View the video online here:

Exploring the User State Migration Toolkit (USMT) 4.0

About this Video

User State Migration Tool (USMT) 4.0 is a scriptable command-line tool that provides a highly-customizable user-profile migration experience for IT professionals. USMT includes two components, ScanState and LoadState, and a set of modifiable .xml files: MigApp.xml, MigUser.xml, and MigDocs.xml. In addition, you can create custom .xml files to support your migration needs. You can also create a Config.xml file to specify files or settings to exclude from the migration. In this video we show the fundamentals of installing, configuring and using USMT 4.0

Posted By: Richard Smith
Length: 45 minutes 30 seconds

Downloads

Video: WMV | 3GP | Zune | iPod

Audio: AAC | WMA | MP3 | MP4

P2V Migration adds documentation and support of System Center Configuration Manager 2007 Zero Touch Installation!

What is better than spending a moment to kick off a completely automated process to redeliver an existing operating system as a virtual machine within a new build of Windows 7?

Answer: Making the entire process "zero touch" without necessitating a visit to the target computer or manually initiating the migration!

P2V Migration for Software Assurance can now be implemented using System Center Configuration Manager 2007 Operating System Deployment as well as native Lite Touch Installation with the Microsoft Deployment Toolkit 2010. Computer refresh, replace and restore task sequence templates for Configuration Manager are included and documented in this Beta release.

Additional optimizations beyond Configuration Manager functionality included in this release are:

  1. Better flexibility for backing-up and restoring VHD files using default file locations
  2. Support for PCs using system and boot volumes
  3. Globalization of scripts to handle varying regional and locale formats
  4. General bug fixes and improved documentation

These fixes reflect the feedback of our Connect community and MVPs – thanks to everyone for submitting feedback!

Download P2V Migration for Software Assurance Beta 2 now:

http://connect.microsoft.com/site14/InvitationUse.aspx?ProgramID=1646&InvitationID=P2VM-C49K-PQHR