The Deployment Guys : Deployment

Deploying Windows 7 VL with MAK (Multiple Access Keys) using MDT 2010

DeploymentGuys — Mon, 30 Mar 2009 11:00:26 GMT

My esteemed colleague - Doug Klokow who is a Senior Consultant in the worldwide deployment practice, working with Windows 7 TAP (Technical Adoption Program) customers in the US has put together a most useful set of instructions regarding Windows 7 deployment using MDT 2010 and MAK keys. This is of benefit when deploying to environments where access to KMS may be tricky during the activation timescales – I recently came across this in a university where professors and research staff go off on research assignments for up to a year at a time…When deploying Windows 7 Enterprise Volume License (VL) edition using MDT 2010, it is possible to include a MAK activation key, however, the standard methods of including the key in the unattend.xml file requires modification. Additionally, it is possible to deploy MAK keys using a custom script as part of a Task Sequence.

Situation

While deploying Windows 7 Enterprise VL with MDT 2010, the typical behaviour would be to include the activation key in the customisation wizard used to create a Task Sequence for the deployment of the Windows 7 operating system. By design, the Task Sequence wizard is designed to support retail activation keys, not volume license keys. The difference is subtle, but important to the context of this scenario.

As you complete the New Task Sequence Wizard, you are prompted the Product key.

When you enter a product key into the field shown above, the MDT 2010 wizard adds the code into two specific locations of the unattend.xml file for this task sequence.

The first location for the ProductKey is the WindowsPE phase, specifically, the x86_Microsoft-Windows-Setup_neutral\UserData\ProductKey setting.

The second location is in the Specialize phase, specifically the x86_Microsoft-Windows-Shell-Setup_neutral\ProductKey setting.

Issue

The Unattended Windows Setup reference explains why there are two entries for the ProductKey setting, but if the Product Key for Windows 7 Enterprise is placed in both locations (as is the default) when entering the Product Key using the task sequence creation wizard, you will receive the following error when attempting to build or deploy a client machine with that task sequence.

Resolution

There are a number of options available to address this particular situation. Each provides a resolution, but using different methods.

OPTION 1

Simply delete the ProductKey entry in the WindowsPE phase, specifically, the x86_Microsoft-Windows-Setup_neutral\UserData\ProductKey setting. The unattended install should work as expected deploying your Windows 7 machine using the configurations your define. Once the Windows 7 installation is complete, it will be necessary to either manually kick off the activation process from the Computer Properties screen of the machine, or using the Volume Activation Management Tool (VAMT) to complete the activation remotely.

NOTE: At the time this blog was authored, an updated VAMT tool is not presently available with support for Windows 7.

OPTION 2

Use the slmgr.vbs script to perform the activation as a task in the task sequence in lieu of the ProductKey entries in the unattend.xml file. Check the two locations in the unattend.xml file to validate that both entries for ProductKey are blank.

STEP 1: Add the first entry into the Custom Tasks section of the State Restore phase as shown below:

Task Name:	Activate Client using VL MAK
Command Line:	cscript.exe c:\windows\system32\slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Start in:	c:\windows\system32

NOTE: Replace the X's with your VL MAK key for Windows 7

STEP 2: Add the slmgr.vbs /ato script to automatically activate the client during deployment as shown below:

Task Name:	Activate the machine using the VL MAK
Command Line:	cscript.exe c:\windows\system32\slmgr.vbs /ato
Start in:	c:\windows\system32

NOTE: This task will only work if the machine is connected to the internet during the State Restore phase. If this task fails because the network connectivity is not fully initialized, it is possible to manually activate the client through the Computer Properties window.

Now when the client machine is deployed, the task sequence will provide the MAK key during the State Restore phase, and attempt to automatically activate the client machine.

OPTION 3

Use the OverRideProductKey entry in the CustomSettings.ini to specify the MAK key to be injected. This will add the MAK product key only into the x86_Microsoft-Windows-Shell-Setup_neutral\ProductKey location in the Unattend.xml.

From the MDT Toolkit Reference document:

OverrideProductKey

The Multiple Activation Key (MAK) string to be applied after the target operating is deployed to the target computer. The value specified in this property is used by the ZTILicensing.wsf script during the State Restore Phase to apply the MAK to the target operating system. The script also configures the volume licensing image to use MAK activation instead of Key Management Service (KMS). The operating system needs to be activated with Microsoft after the MAK is applied. This is used when the target computer is unable to access a server that is running KMS.

Value	Description
MAK	The MAK string to be provided to the target operating system.

Example

[Settings]

Priority=Default

[Default]

ProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF

OverrideProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF

Option 4

During deployment, it is possible to specify the Product Key while running the deployment of the workstation. The Deployment Wizard includes an option to prompt for the Product Key using the "SkipProductKey" entry in the CustomSettings.ini file for the Deployment Point. By specifying an entry of "SkipProductKey=No" the user will be prompted to enter a key while running the deployment of the machine, and if they enter their MAK key there, they deployment will complete successfully.

From the MDT Toolkit Reference document:

SkipProductKey

Indicates whether the Specify the product key needed to install this operating system wizard page is skipped.

For other properties that must be configured when this property is set to YES, see the section “Providing Properties for Skipped Windows Deployment Wizard Pages” later in this reference.

Value	Description
YES	Wizard page is not displayed, and the information on that page is not collected.
NO	Wizard page is displayed, and the information on that page is collected. This is the default value.

Example

[Settings]

Priority=Default

[Default]

SkipWizard=NO

SkipCapture=NO

SkipAdminPassword=YES

SkipApplications=NO

SkipAppsOnUpgrade=NO

SkipComputerBackup=NO

SkipDomainMembership=NO

SkipDeploymentType=NO

SkipUserData=NO

SkipPackageDisplay=NO

SkipLocaleSelection=NO

SkipProductKey=YES

Caution This property value must be specified in upper case so that it can be properly read by the deployment scripts.

UPDATE:

If you are working with MDT 2010 Beta 1 then the issue and resolutions referred to above are valid – however our other most esteemed colleague and MDT creator Michael Niehaus has pointed out that the issue has been fixed for MDT 2010 Beta 2. Now the screen will have another option to match the options that are available in the client-side Deployment Wizard:

Resources

For more information on the using the SLMGR.VBS script for activation tasks, see the Volume Activation 2.0 Deployment Guide.

For more information on the ProductKey setting, see the Unattended Windows Setup Reference.

This post was contributed by Richard Smith a senior consultant with Microsoft Services UK on behalf of Doug Klokow a senior consultant with Microsoft Services US

Boot from VHD and WDS

DeploymentGuys — Fri, 06 Mar 2009 18:44:00 GMT

Following on from Aly’s excellent article about configuring MDT to support Boot from VHD I thought I would add some words about WDS and boot from VHD.

Windows Server 2008 R2 contains an enhanced version of the WDS server. I will talk about some of the other enhancements in a later post – today I will touch on the VHD enhancements. WDS now supports the ability to deploy a VHD file to target computers and configure them to boot from it.

Which VHD to use? You cannot just use any VHD – there are some restrictions. The VHD has to contain either Windows Server 2008 R2 or Windows 7 Enterprise or Ultimate. Also you must use either use Hyper-Visor or the wim2vhd script running on Windows 7 or Windows Server 2008 R2, available from MSDN, to create the VHD. Once you have created the VHD place it somewhere you can access it from the WDS server.

Importing the VHD to WDS. Unfortunately it is not possible to use the WDS GUI to import a VHD file to the WDS server – we have to get our hands dirty using the command line – yippee! First though use the WDS management console to create a group that will hold the VHD images – for example create a group called VHD. Now use the command line below to import your image; this assumes the group is called VHD. (This should all be on one line. It may be wrapped here for readability. )

WDSUtil.exe /Verbose /Progress /Add-Image /ImageFile:<path to image file><image file name> /ImageType:Install /ImageGroup:vhd

You have to supply the full path and the name of the VHD file. Don’t forget if there are spaces in your directory structure or file name to enclose this string in quotes. The image will appear in the GUI with the same name as the VHD file.

Deploying the VHD. Ok so now it starts to get a bit tricky. If you boot a client and connect to the WDS server you will see the VHD image listed in the available images. However deploying via this method is not supported. The only supported method is to use an unattend.xml file. A sample file is given at the end of this article; the key code section is posted below.

<WillShowUI>OnError</WillShowUI>

</InstallImage>

Here you can see that we specify the name of the image to be deployed, the group the image is in and the actual file name of the VHD itself.

The rest of the unattend.xml defines things like credentials to connect to the WDS server, the disk to place the VHD on and if we are going to deploy to an existing disk/partition or wipe and create a new one. So lets just dwell on that for a moment. This means that we can PXE boot our working machines, have a new Windows 7 VHD file applied to it and still preserve the existing OS. Sweet! The example unattend below will do just this – it leaves the current partition alone.

Using the Unattend.xml. So how do we specify that a client is going to use the unattend.xml? There are a couple of ways of doing this. However before I outline this process I need to touch on a gotcha. In the full unattend.xml you will see that there is an entry for the architecture of the WinPE environment that this unattend will run in. So if we have both 32 bit and 64 bit boot environments we need an unattend.xml for each. Don’t forget though that a 32 bit boot Win PE can deploy a VHD with a 64 bit OS in it. Just make sure that the target client can support that architecture. If all boot environments are 32 bit then we only need one unattend file – unless we have different architecture VHDs of course.

So lets get back to the unattend file. There are two ways;

1) Associate the unattend with the boot WinPE image. This is the simplest configuration – the down side is that every client that boots with that architecture and using that boot image will get the VHD file.

2) Associate the unattend with individual clients via AD. This is more complex and if there are lots of clients or the clients frequently change deployment methods it takes a lot of management. However this solution gives you the most flexibility.

Use the Windows System Image Manger in the WAIK to create your unattend.xml file, or use the sample one below. The sample one will drop the VHD into partition 1 of your disk. If partition one is a 200Mb Bitlocker partition its not going to fit! Change the partition number to one with enough size.

Create a directory under the reminst dir on your WDS server and copy the unattend file to this directory. Give the unattend a suitable name. In the screen shot above you can see I have created an unattend file and placed it in the reminst\unattends directory on the WDS server.

Now I am ready to boot a client and deploy my VHD to it.

When the client boots it should automatically connect to the WDS server, select the VHD you chose and deploy it to the target system. The file gets dropped into a standard directory structure c:\Windows Images\XXX. XXX is an index number that starts a 000. Each new image you deploy increases the index by 1. When the image has been deployed you will find the BCD has been updated to include a new entry. For Windows 7 machines this is “Windows 7”. It is not possible to change this via WDS or the unattend.xml. If you do need to change it you will have to write a post deployment task to do so. The last image deployed is the default boot OS and is placed at the top of the list – which might make changing the description easier.

NOTE: The disk must already be running Windows 7 or Server 2008 R2 and the destination partition must NOT be Bitlockered.

I hope you found the post useful. I look forward to your comments.

This post was contributed by Richard Trusson, a Senior Consultant with Microsoft Services, UK.

The wim2vhd script can be found here: http://code.msdn.microsoft.com/wim2vhd

The example unattend.xml is below.

<?xml version="1.0" ?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="windowsPE">
<component name="Microsoft-Windows-Setup" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">
<WindowsDeploymentServices>
<Login>
<WillShowUI>OnError</WillShowUI>
<Credentials>
<Username>Administrator</Username>
<Domain>woodgrove</Domain>
<Password>*********</Password>
</Credentials>
</Login>
<ImageSelection>
<WillShowUI>OnError</WillShowUI>
<InstallImage>
<ImageName>Win7-Beta</ImageName>
<ImageGroup>VHD</ImageGroup>
<Filename>w7x32ulti.vhd</Filename>
</InstallImage>
<InstallTo>
<DiskID>0</DiskID>
<PartitionID>1</PartitionID>
</InstallTo>
</ImageSelection>
</WindowsDeploymentServices>
<DiskConfiguration>
<WillShowUI>OnError</WillShowUI>
<Disk>
<DiskID>0</DiskID>
<WillWipeDisk>False</WillWipeDisk>
<ModifyPartitions>
<ModifyPartition>
<Order>1</Order>
<PartitionID>1</PartitionID>
<Extend>True</Extend>
</ModifyPartition>
</ModifyPartitions>
</Disk>
</DiskConfiguration>
</component>
<component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">
<SetupUILanguage>
<WillShowUI>OnError</WillShowUI>
<UILanguage>en-US</UILanguage>
</SetupUILanguage>
<UILanguage>en-US</UILanguage>
</component>
</settings>
</unattend>

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

Deploying Win 7 to Boot From VHD with MDT 2010

DeploymentGuys — Tue, 03 Mar 2009 23:29:00 GMT

One of the more difficult scenarios that customers have found in the past is multi-booting a new OS. The effort needed to re-partition the drive to allow for the new OS is sometimes too great. One new solution that is gaining ground in deployment is Boot From VHD. This allows you to take a VHD file with Windows 7 or Windows Server 2008 R2 and boot your machine to it. This means that you can take advantage of the physical hardware of your machine while not having to repartition your drive for Win 7 and keep your original OS intact. More information on how to Boot From VHD can be found here http://edge.technet.com/Media/Windows-7-Boot-from-VHD/ .

MDT 2010 Beta 1 can deploy Win 7 Beta out-of-the-box however, it deploys it to the Disk 0 Partition 1 by default. In order to change this behaviour so that MDT 2010 deploys Win 7 to a VHD and leaves your existing OS you can follow the steps below:

1. Create a Task Sequence to install Win 7 in MDT 2010

2. Insert the following 3 steps in the Pre-Install \ New Computer only Phase:

a) Disable the format and partition disk step

b) Insert a Set Task Sequence Variable Step to set the path for the VHD with the variable BootVHDLocation. Ensure that path DOES NOT EXIST already on the machine.

c) Insert a Set Task Sequence Variable Step to set the size of the VHD (in MB) with the variable BootVHDSize. Ensure that there is enough space on the drive as the VHD may grow to this size.

d) Insert a Run Command Line step to run the command line cscript.exe "%SCRIPTROOT%\ZTIDiskPartVHD.wsf"

3. Copy the attached script below to your Distribution$\Scripts folder.

4. Run your task sequence on a machine and watch Win 7 install into a VHD. Once the process is done, your machine will have a boot menu similar to this:

Please note, this script does not deal with BitLocker encrypted drives and Boot From VHD will only work with Windows 7 Beta or Windows Server 2008 R2. As always test this out and feel free to post comments.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region.

GImageX Beta for Windows 7 Beta

DeploymentGuys — Wed, 04 Feb 2009 12:47:12 GMT

The Windows Automated Installation Kit (Windows AIK) is a set of tools and documentation that support the configuration and deployment of Microsoft® Windows® operating systems.. By using Windows AIK, you can automate Windows installations, capture Windows images with ImageX, configure and modify images using Deployment Imaging Servicing and Management (DISM), create Windows PE images, and migrate user profiles and data with the User State Migration Tool (USMT).

GImageX is a third-party graphical version of the ImageX command-line tool from the Windows AIK.

With the release of the Windows 7 beta and also the beta of the Windows Automated Installation Kit I’ve updated GImageX to work with these new beta versions. I’ve also tidied up parts of the documentation around installation and tweaked the “mount” functionality to provide better feedback during the operation.

Please note that GImageX is a third-party tool so please remember that you won’t be able to ring up Microsoft PSS to get support with it! However, it uses the official Microsoft published WIMGAPI SDK which is a supported way of working with WIM files.

GImageX Capture Tab

The GImageX beta can be downloaded here and the new beta version of the Windows AIK which it requires can be downloaded here. Please provide feedback, problems, questions, suggestions to the email address listed in the help file contained in the download. As both GImageX and the v2.0 Windows AIK are beta versions please only use these in test environments.

This post was contributed by Jonathan Bennett a Senior Consultant with Microsoft Services, UK.

Back to basics #2 – 7 Things you shouldn’t do in a LiteTouch Deployment

DeploymentGuys — Fri, 17 Oct 2008 11:48:00 GMT

The below list is a list of the most common mistakes made when creating a LiteTouch task sequence. While not an exhaustive list, it might help to improve your deployment experience when using MDT to create LiteTouch deployments.

1.) Hard-code paths to files/scripts in the task sequence, or inside a script, or referring to the distribution point as Z:\

I would say that this is the number one cause of errors that I see. Because MDT always maps the distribution point to Z:, most assume that it is safe to use this to refer to a file during the deployment process. 99% of the time they are right and it will work fine. However, there are some scenarios when this will generate a failure but it might not be immediately obvious as to why it has failed. So, the solution is to not use Z:\ when specifying paths to files. In the example in the below image, the variable %SCRIPTROOT% instead of Z:. MDT will make sure that the value of this variable will always be to the distribution share, regardless of where it is.

The most common scenario that I have seen this fail in, is when using a Media Deployment Point where the drive Z: does not exist, causing any custom script/processes to fail.

2.) Use non-descriptive names for each task or script, and not fill in the comments field for each task in the task sequencer.

When adding tasks to the task sequencer a lot of people skip the Description box, and also often give the task a rather ambiguous name (plenty of times I have actually seen the task left with the default name i.e. “Run Command Line”). This is not such a problem if it is you that will always administer the server, but when the day comes that someone else needs to look at the task sequence, it will be nigh on impossible for them to work out quickly what each task is doing. So, what could be a simple quick fix will turn into something much longer because they will need to go through the sequencer to work out which is the task that they are looking for.

You can save a lot of work for everyone, including yourself, by filling in Description field for each task you add to the sequencer. You can also later on use the content of this field to help with your documentation.

3.) Use an account for connecting to the deployment share that has full administrative access over the server.

Often, during the development stage of any deployment, most people use the administrator account of the domain in the laboratory, or the local administrator account of the MDT server, as the user that connects to the deployment share during any deployment. Although this works fine, from a security perspective it is pretty terrible, especially as you will often have to share the account credentials with anyone that wants to deploy a machine. If you are using an administrative account in the laboratory, make sure that this practice does not get passed into the production environment at a later stage.

The ideal option is to create an account group (either local to the server or in the domain) that has access to the share, and then add the necessary users to this group. That way they can use their own account credential for deploying a computer without compromising any security on the server. You can also use the auditing options on the server if you want to find out the who, what and when for any computer that was deployed.

4.) Create a LiteTouch task sequence that deploys a computer without any user intervention.

Although this might sound like a great idea as it provides an almost ZeroTouch deployment method, it is actually quite a bad thing to implement. Imagine that you launch a deployment on a computer, no user input is required so the task sequence launches. Just as the drives start to format themselves, you realise that you launched the deployment on the wrong computer. Doh!

I have to confess that this has caught me out before, because of the use of several computers all connected to a keyboard/mouse/monitor switch box. Consequently, I like to leave at least one user-required action at the start of any task sequence and before any ‘damage’ is done. Even if it is just a simple “Welcome to the Windows Vista Deployment project – Press OK to continue” message.

5.) Don’t specify the scripting engine when launching a script file.

As you can see in the image below, MDT will launch a custom VBS script during a deployment cycle, the problem with this example is that the scripting engine has not been specified for launching this script. So, by default, Windows will launch the script with WScript.exe rather than CScript.exe. Most of the time this will be fine and give no problems, however, if you have a script that has the command WScript.echo “My message” in it somewhere then the script will pause, showing a window to the user, and it won’t continue until the user presses the OK button.

You may want this behaviour, i.e. introducing a user intervention at some point in the deployment, but if you don’t then just specify CScript.exe on the command line before the script file (as shown in the images at the top of this post).

6.) Don’t bother creating detailed documentation of the whole process.

Although this won’t break anything, and although it is an extremely dull task, documenting everything that you have done during the creation of your deployment is invaluable. It will save you, and anyone else, a lot of time in the future when you need to make changes to anything on the server.

7.) Create a media deployment point, and then test the super massive 8Gb ISO image with Virtual PC.

Although Virtual PC now has support for large ISO files, it still sometimes has a few ‘issues’ when the files are super big. The issue never manifests itself with the same error message twice though. Instead, you might start seeing problems booting from the ISO file, and then the next time you might get an inexplicable failure in a script. The solution I have always found to work is to simply use the same ISO file with Virtual Server 2005 SP1, or better still, Hyper-V.

Without a doubt, there are plenty more do’s and don’t with MDT. This is simply a consequence of the fact that MDT is so customisable, a sure sign that it is a powerful tool. Feel free to comment on this post with any of your own suggestions that you want to share with everyone else!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Back to basics #1 – Locking the computer during deployment

DeploymentGuys — Wed, 01 Oct 2008 10:26:01 GMT

This is the first post in a series that will cover some of the more simple/basic tricks that you can do with MDT, but that are often overlooked. I’ll be the first to admit that a couple of them I only learnt recently, even though I have been using BDD/MDT for years.

During the deployment of a computer, MDT will auto-logon Windows using the local Administrator account in order to run its task sequence; during this time, the computer is left logged on as administrator with the desktop unlocked for all to see. Consequently, anyone who happens to walk past the computer during its deployment can use it with full administrative access.

The best way to protect your computer systems from any unwanted access is to simply lock the computer during the Windows phase of the deployment. To do this, just add a “Run Command Line” action to your task sequence, and place the following command in the command line of this action:

rundll32 user32.dll,LockWorkStation

You can place the action at any point in the task sequence, as long as it is executed from within Windows rather than during any Windows PE stage. It doesn’t matter if you have any reboot actions in the task sequence because, even though the workstation is locked, it will still reboot; just remember that you’ll need to execute the command again after reboot in order to lock the computer again. Bear in mind though that you won’t be able to see the summary screen at the end of deployment so you won’t know when it has finished.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Task Sequence logic tricks using MDT variables

DeploymentGuys — Mon, 28 Jul 2008 22:59:00 GMT

In my particular part of the Microsoft organization (the CTS testing lab), we install just about every OS, at every service pack level, on both major platforms. Because of this, I created a master template that is used to create dozens of task sequences where the only thing that changes is the OS. To pull this off, I made heavy use of the variables built into MDT2008 to branch my logic accordingly and create a framework in which future additions can simply get dropped into. See the screen shot to get an idea of what this framework looks like in the Workbench:

For this example, I have removed all of the actual Tasks themselves to only show the folder structure for clarity’s sake. But you get the idea. With this in place you can simply add tasks as appropriate into the appropriate level. Keep in mind, any folder level is valid and useful. For example, I have some things that I want only all clients to get, and other things for only all servers to get, so I drop them into the Client and Server folder root levels respectively. Also, something like anti-virus software can be dropped straight into a platform folder, such as x86 or x64 so all OS's regardless of flavour or SP level will get the applications. These are just simple examples, but what’s possible's are limitless.

The philosophy here is the only add logic to your task sequences to the folder level, and not individual task items. This makes keeping track of why things happen (or don’t happen) in your task sequence easier to control, manage, and troubleshoot when you don’t have to examine every individual task item, and can rely on the group level logic of the containing folders. This also means that every time I want to add a new task item to my sequence, I don’t also have to add in the logic to control it, since dropping it in the right folder makes sure it happens in the right OS environments.

So, for example, the top level of this folder has the following logic applied in the Options tab:

Obviously the x64 folder has similar logic with the x86 value changed to x64. For brevity here are the logic values applied to each folder in the first screen shot:

X86 – Architecture equals x86

Client - IsServerOS equals FALSE

Windows XP – OSVersion equals XP

Vista - OSVersion equals Vista

Server – IsServerOS equals TRUE

2003 - OSVersion equals 2003

RTM - SELECT * FROM Win32_OperatingSystem WHERE CSDVersion = ""

SP1 - SELECT * FROM Win32_OperatingSystem WHERE CSDVersion = 'Service Pack 1'

2008 - OSVersion equals 2008

X64 - Architecture equals x64

Client - Etc etc.

Using this framework, we have been able to maintain a single template task sequence that all others are based on regardless of what OS gets thrown at it. There are some other tricks using some other variables as well, but we can cover this in a separate post.

This post was contributed by Roland Sanchez a Lab Engineer with Microsoft Commercial Technical Support Labs, United States.

Useful Script Number 6 - Pausing the Task Sequence

DeploymentGuys — Mon, 07 Jul 2008 19:59:18 GMT

Have you ever wanted to pause the task sequence in MDT 2008 or ConfigMgr 2007 for a few seconds while something catches up...? I had a requirement to do this recently where I ran a task to close and cancel the Windows Sidebar at the start of the State Restore phase of the task sequencer and then turn the Windows Sidebar back on again at the end of the State Restore phase - I was doing this as the Windows Sidebar can sometimes get in the way of some customisation scripts and you can also see peculiar VB messages when 2007 Office System updates are applied. When the Windows Sidebar is turned back on, there is a couple of seconds before the Sidebar actually appears - yet my task for turning on the Sidebar had returned and the task sequence had moved on...it made be think that there may be other situations where a slight delay in returning to the task sequence may be useful - sure you could add sleep commands to the scripts that your running as commands - but that doesn't help with the tasks that are not scripted - so here is an MDT based script that will pause the task sequence for a specified number of seconds (specified on the command line)

I first have a couple of variables to store the time to pause (strTime) and the script name (strSName - for logging purposes) and the integer argument for the sleep method

Dim strTime, strSName, IntTime

ZTIProcess=1

...I then use a call to ZTIUtility.wsf to set the script name to the strSName variable - this is then used to insert the script name at the start of each line in the log.

strSName=oUtility.ScriptName

...then it's another call to ZTIUtility.wsf to use the arguments class - this makes passing input to the script via the command line easy - in this case I am setting a command line input called "Time"

strTime = oUtility.Arguments("Time")

oLogging.CreateEntry strSName & ": Starting Actions ********************************************* ",LogTypeInfo

...then I check that Time has been specified as a command line input (exit if not) or set the IntTime to number of seconds from the command line x 1000 to get milliseconds

If strTime="" Then
    oLogging.CreateEntry strSName & ": No pause time was specified on the command line.",LogTypeError
    ZTIProcess=90
    Exit Function
Else
    oLogging.CreateEntry strSName & ": Pause time has been set to " & strTime & " seconds",LogTypeInfo

IntTime = strTime * 1000
End if

...I then take the intTime (in milliseconds) and add it to the sleep method to pause the script

oLogging.CreateEntry strSName & ": Task Sequence will pause for " & int(IntTime/1000) & " seconds",LogTypeInfo

wscript.sleep intTime

oLogging.CreateEntry strSName & ": Task Sequence has been paused for " & int(IntTime/1000) & " seconds - returning control to the Task Sequence now",LogTypeInfo

oLogging.CreateEntry strSName & ": Completed Actions ********************************************* ",LogTypeInfo
ZTIProcess = 0
End Function

The script is called CFG-TSPause.wsf so the command line to run it would be CFG-TSPause.wsf /Time:xx (where xx = the number of seconds that you want to pause the task sequence for) Drop the script into your <Deployment Share>\Scripts directory. You can then add the script anywhere in your task sequence by adding a Run Command Line task and specifying the script and the command line input for the number of seconds you want to pause.

As usual, the full script is up on the Deployment Guys SkyDrive:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Useful Script Number 5 - Adjusting the Default User Registry Hive

DeploymentGuys — Fri, 06 Jun 2008 17:03:00 GMT

Michael Murgolo did a great post on the different ways to adjust default settings when building an image (Configuring default settings for Windows image deployment) and one of the options presented was to targeted changes to the Default User Registry hive and profile folders. I had to do this recently and put together a script that can be launched from the MDT task sequence because I was finding my customised Administrator profile wasn't being copied over correctly to the Default User profile as part of SysPrep.

As Michael mentioned in his post - there are three main processes...you first need to load the default user hive (NTUser.dat) - make the changes you require - then unload the user hive. I have reproduced the core part of my script that does this process for discussion.

The first section sets the two variables that will be used - one to store the temp key (sTempHive) that we will load to, and the second to hold the profile file and location that we want to load (sDefaultUserHive)

For Windows Vista the entry """%USERPROFILE%\..\Default\NTUSER.DAT""" refers to C:\Users\Default\ntuser.dat

sTempHive = """HKEY_USERS\Test"""
sDefaultUserHive = """%USERPROFILE%\..\Default\NTUSER.DAT"""
sSName = oUtility.ScriptName
set oshell = WScript.CreateObject ("Wscript.Shell")

iZTIRetValue="1"

We then need to start logging - it's the law :-)

oLogging.CreateEntry sSName & ": Actions Start - Updating Default Profile",LogTypeInfo
oLogging.CreateEntry sSName & ": Loading the Default User hive",LogTypeInfo

The next section runs reg load to load the NTUser.dat file from the default user directory to the temp key (HKEY_USERS\Test) set in the first section - if there is an error the script fails and quits with a specific failure number or we log success.

oShell.run "reg load " & sTempHive & " " & sDefaultUserHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to load the registry hive " & sDefaultUserHive,LogTypeError
ZTIProcess=70
Exit Function
End If
oLogging.CreateEntry sSName & ": Default User Hive Loaded to " & sTempHive,LogTypeInfo
oLogging.CreateEntry sSName & ": Starting Registry Changes... ",LogTypeInfo

Now that the hive is loaded we can start changing stuff...as an example - I have set the code to change the wallpaper and the screen saver for the default user - again with error checking and specific failure codes

This codes sets the wallpaper (the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Wallpaper",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "WallPaper", "C:\Windows\Web\Wallpaper\CorporateWallpaper.bmp", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update wallpaper file setting",LogTypeError
ZTIProcess=60
Exit Function
End If

...and this codes sets the screen saver (again - the file needs to be where you set the key to :-)

oLogging.CreateEntry sSName & ": Setting Default User Screensaver",LogTypeInfo
RegPath = "HKEY_USERS\Test\Control Panel\Desktop\"
oshell.RegWrite Regpath & "SCRNSAVE.EXE", "C:\Windows\CorporateScreensaver.scr", "REG_SZ"
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to update Screensaver settings",LogTypeError
ZTIProcess=50
Exit Function
End If

Once all of the changes have been made - its time to unload the hive from its temp key - again with logging and error checking

oLogging.CreateEntry sSName & ": Unloading the Default User hive",LogTypeInfo

oShell.run "reg unload " & sTempHive
If Err<>0 Then
oLogging.CreateEntry sSName & ": Failed to unload the default user registry hive",LogTypeError
ZTIProcess=40
Exit Function
End If
oLogging.CreateEntry sSName & ": Actions completed",LogTypeInfo

The completed script can be added to your MDT task sequence towards the end - so that it runs before the machine SysPreps and reboots for capture.

The complete script - in MDT format (to include logging and access to classes from ZTIUtility.wsf) with a number of other changes included is available on the Deployment Guys SkyDrive:

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Getting caught out by your logon script

DeploymentGuys — Mon, 26 May 2008 11:36:05 GMT

Whenever I go onsite with a customer to start a Windows Vista deployment project I always like to discuss with them the issues that we will be having during the project. I do this so that, together, we can try and avoid having the issues in the first place. Most of the issues the customer is already aware of as they have been testing Windows Vista in a laboratory environment for a while; however, there is one issue that nearly always catches them unaware and gives them major headaches, their logon script.

This is often one of the biggest problems that a company will have when trying to deploy Windows Vista. The reason that most people do not notice that the logon script does not work on Windows Vista is because they have done their testing only in a laboratory environment where the logon script does not exist.

Let's look at a hypothetical example. Contoso developed a MS-DOS based logon script when they first rolled out their systems on Windows NT 4.0. When Windows 2000 was realised, they made some amendments and added more code to the script in order for it to work on the new platform. When Windows XP was released, they had to tweak it again and add substantially more code in order to be able to migrate it to the Windows XP platform. Because the script has been extended each time they rolled out a new OS, it is now a monster of a script with almost 2000 lines of code.

Now, based on their past experience, they have assumed that they will just need to tweak it and probably add some more code so that it works with Windows Vista, consequently, they have not actually gotten around to testing the script yet, nor assign the resources to this task. Big mistake, because they haven't realised that the chance of the script working 100% on Windows Vista is almost 0.

Why? The new security model that Windows Vista uses, that's why. Let me give an example. Contoso has an application that is vital to their business. It is an application that requires certain keys to exist in the HKEY_CURRENT_USER section of the registry, and without those keys the application will not start. Because Contoso users do not have roaming profiles, the IT team added the following line to their logon script to ensure that this application always works, regardless of which computer the user logs on to:

regedit.exe /s %logonserver%\vitalapp.reg

Consequently, when the user logs on the registry file imports the required keys into the registry and the application works correctly, and because this is in the logon script the process is invisible to the end user. However, if the same script is run on Windows Vista, the following window will appear during the execution of the logon script:

The famous (or infamous...?) User Account Control (UAC) window

This window will appear because the resource regedit.exe is a protected file that requires administrative rights to be able to run it. Unfortunately for Contoso, their logon script imports 12 different registry files which means that their logon script causes the UAC prompt to appear 12 times.

There are several ways to stop this message appearing, but they all reduce the overall level of security of the operating system (for example, you could disable UAC or give all users admin rights).

But don't panic! There are plenty of solutions that you can use to solve these issues whilst maintaining the UAC feature and the extra security benefits that it gives. The method I also recommend to customers is to use custom ADM files to create the registry keys, see here for a good guide on how to do it. That way, every time the user logs on and receives their group policy configuration, the registry key will be created. And, because it runs in a different context to the user, it will have enough permissions in the registry to create the keys without invoking the UAC window.

If you are considering, or even if you have already started, deploying Windows Vista in your business environment, I strongly recommend that you test your logon script thoroughly and as soon as possible on Windows Vista. The last thing you want is to have to put the deployment on hold when the problems start appearing.

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain

Expanding the Scratch Space in Windows PE 2.1

DeploymentGuys — Mon, 12 May 2008 09:40:36 GMT

Recently, I have had to create a bigger scratch space (the MDT X: drive) in Windows PE to deal with the injection of a largish driver during a Windows Vista deployment. The driver in question is the NVidia driver for the Lenovo P60 and P61 and because of the limited scratch space under PE 2.0, this was causing an issue at injection time. There is a scratch file change (registry hack) that can be made to Windows PE 2.0 and below to change the scratch file space from the default 32 Mb - however this is unsupported.

With the introduction of Windows PE 2.1 (supplied with the Windows Automated Installation Kit (Windows AIK) 1.1), the scratch area can be changed from the command line. Below is the process for creating a larger scratch area.

Create a temporary mount folder on your hard disk - MD c:\temp\mount
Go to the Windows AIK tools folder for the platform of PE that you will be changing (ie x86/x64) - CD "Program Files\Windows AIK\Tools\x86"
Mount the default Windows PE image supplied with Windows AIK to your temporary mount folder - imagex.exe /MOUNTRW "C:\Program Files\Windows AIK\Tools\PETools\x86\winpe.wim" 1 c:\temp\mount
Go to the Windows AIK PETools folder - CD "C:\Program Files\Windows AIK\Tools\PETools"
Run the PEIMG command to adjust the scratch size in the mounted image using /SCRATCHSPACE flag to set the size of the drive you want (in this case 128Mb) - peimg.exe /SCRATCHSPACE=128 c:\temp\mount\windows
Change back to the PETools directory - CD "Program Files\Windows AIK\Tools\x86"
Unmount the image and commit the changes - imagex.exe /UNMOUNT /COMMIT c:\temp\mount

That's it - the scratch area will now be set at 128 Mb for all boot images based on this source - which means all boot images created by MDT will now have the set scratch space set (there's a script here somewhere to automate this - so feel free to create and send in your suggestions via the comments area :-)).

Remember that the scratch space is a RAM drive, so the machine being built by this boot environment will need enough memory to deal with Windows PE plus your additional scratch space (so that's approximately 240 Mb plus scratch space).

This post was contributed by Richard Smith a Senior Consultant with Microsoft Services, UK.

Dealing With Duplicate User Profile Links in Windows Vista

DeploymentGuys — Thu, 01 May 2008 16:24:00 GMT

Overview of Windows Vista User Profiles

In previous versions of Windows the user's profile was largely hidden away and only the more technically-minded of us would ever knowingly delve into its contents. With Windows Vista there seems to have been a significant change in that the profile has been dragged sulkily into the spotlight.

The Windows Vista user profile

The Windows Vista user profile is visible everywhere. It's the very first link in the Start Menu and it appears prominently in Explorer and most Open/Save dialogs. Some dialogs even open directly to this profile location and ignore any Favorite Links. Many people - including myself - initially tried to rebel against this new behaviour and attempted to hide the profile away again. This usually causes its own set of problems when a user who only understands Documents and Pictures suddenly gets a Save dialog with an eyeful of profile. They panic. They blindly click on the root of the C: drive and with brows furrowed in incomprehension they drag the entire contents to the Recycle Bin. Then they pull the power cord out.

Those are the good users. The rest call the helpdesk!

It's much better to embrace the new way of working and provide training around using the user profile to the end users.

Folder Redirection

Another change in Windows Vista is the ability to independently redirect each of the user profile sub-folders to a network location using Group Policy and Folder Redirection. This can significantly improve logon times in an organisation that uses roaming profiles where users move around lot. A common approach is to redirect the "big hitters" where large files are often stored, such as:

Documents (usually with the addition of Pictures, Music and Videos)
Desktop
Downloads

Let's have a look at our Windows Vista profile after we redirect these:

Duplicate infested profile - The Horror!

What's going on here?! What are all these duplicates? Which is the real one? If you thought users panicked when they hadn't seen a profile before then you haven't seen a user when presented with duplicate links! And no, a slightly different icon is never a good enough way to tell the difference. "No, don't save it in the one that looks like a folder, save it in the one that looks like a folder with a document on top of the folder". I think not.

So why does this happen? Well, when redirecting a folder using Group Policy one of the options is to "Move the contents". Unless this option is selected a duplicate link will be left behind - even when that folder is completely empty. The problem is that depending on the way the infrastructure is set up we can't always safely select this option.

Here are some common reasons you might not want to use the "move" option:

The user is often not the owner of the redirected folder. Many organisations pre-create redirected folders with administrator ownership to simplify administration. The Group Policy option to move the contents of the redirected folder fails when the user is not the owner.
Server moves and maintenance. Often administrators need to move the location of user data between folders or even servers. If the administrator changes the location of a redirected folder they generally want to move the corresponding files themselves at the same time. Using the Group Policy "move" option, if an administrator changed the redirected location for 10000 users they would need to wait for all 10000 users to logon for all of the data to be moved. Warning: Administrators tend to froth at the mouth a little when told this. You could attempt to change the Folder Redirection location and then move the files yourself anyway but this usually causes the Windows client to get confused, especially where Offline Files are involved.

If none of the above scenarios applies to you then you are very lucky indeed and can stop reading now. The rest can continue on for a possible workaround...

A Possible Workaround

So, to fix this we need to find a way to automatically remove these duplicate links, let's say on logon. The solution will need to:

Run on any Windows Vista build and not rely on any specific frameworks or runtime libraries which may not be present
Be able to check if folders have been redirected
Where a folder has been redirected, be able to work out what the duplicate/default location was
Check that the duplicate folder is indeed empty
Delete duplicates (or recycle them to be safer)

Usually I'd use VBScript for something like this, but in order to get the redirected and default profile folder locations we need to use the API call SHGetKnownFolderPath which means writing a custom application in Visual C++ 2008 Express (or the full version if you have it). What? Why don't I just use VBScript and read the registry keys in "Explorer\Shell Folders" and "Explorer\User Shell Folders"? Because Raymond says so, and because Technet says so.

Don't worry about using Visual C++ , it's going to be a tiny program that's pretty easy to follow for a scripter and you'll be able to act smug around the office and throw lines into conversations like: "VBScript, yeah, that's pretty good. I guess. <pause dramatically here> Check out my proper code and cast off your childish ways, mortals!".

The sample code will create a program that can be run as follows (from a login script, logoff script, StartUp group, RunOnce registry key - your choice):

RemoveDuplicateProfileLinks.exe [/norecycle]

By default, it will move deleted duplicates to the Recycle Bin (safe) but you can force a full deletion using the optional "/norecycle" switch (less safe).

Download the sample code here:

To compile:

Open Visual C++ 2008 Express.
Open the solution file "RemoveDuplicateProfileLinks.sln".
Ensure that the "Release" build is active.
Select the menu "Build \ Rebuild Solution".
The code will compile.
The resulting .exe file will be created in the top-level "Release" folder.

<disclaimer>Remember, this is sample code and you use it at your own risk :)</disclaimer>

A Quick Look at the Code

For the geeks among you let's have a quick look at the code. The main functions are in the "RemoveDuplicateProfileLinks.cpp" file and consist of:

wWinMain() and CheckFolder() - These do most of the work in reading command-line parameters, checking for redirection and deleting duplicates.
IsVistaOrLater() - Checks if we are running Windows Vista or later.
IsValidDir() - Checks if a given folder exists.
MyGetFullPathName() - Expands a given folder into it's non-relative and long path name version.
IsFolderEmpty() - Checks if a folder is empty and suitable for deletion. We have to be a little careful as duplicate profile links tend to still contain files like "desktop.ini" and junction points to "My Pictures" and the like. You can modify this function to suit your environment, but as it stands it should work well for a clean Windows Vista build that has just logged on and had a number of folders redirected.
FileRecycle() - Handles deletion or recycling of a folder.

The main two functions wWinMain() and CheckFolder() are shown below so you can see what you are getting yourself into:

The WinMain() function

The CheckFolder() function

That wasn't so hard was it? It's not rocket science after all - it's just brain surgery... Let me know how you get on with this and if you have any other ideas or suggestions.

This post was contributed by Jonathan Bennett a Senior Consultant with Microsoft Services, UK.

Useful Script Number 4 - Silent Installation of Windows AIK 1.1

DeploymentGuys — Wed, 30 Apr 2008 22:25:49 GMT

One of the things that you may need to do - particularly if you are tying to automate the creation of a deployment server in a lab environment - is install the Windows Automated Installation Kit. You may think that because Windows AIK is supplied as .msi files that this would be a simple process, however there is a requirement to manually accept the licensing agreement with no switch to bypass and the msi is coded to only run in full UI mode. Also there is the issue of installing the correct version (x86/x64 versions) on the correct platform.

With this in mind, back when Windows AIK was released (v1.0), I created a small Autoit script to screen scrape the installation - I have now updated this script for Windows AIK 1.1

#Region ;**** Directives created by AutoIt3Wrapper_GUI ****
#AutoIt3Wrapper_UseUpx=n
#AutoIt3Wrapper_UseAnsi=y
#EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****

;Copyright (C) 2008
;You have a royalty-free right to use, modify, reproduce and distribute the Sample Application Files (and/or any modified version) in any way
;you find useful, provided that you agree that Microsoft and the author have no warranty, obligations or liability for any Sample Application Files.
;
; AutoIt Version: 3.2.10.0
; Language:       English
; Platform:       Windows
; Author:         Richard Smith - Microsoft UK
; Script Function:
;   Gets CPU architecture then install the Windows Automated Installation Kit (Windows AIK 1.1) silently

#include <Constants.au3>

;Set variables and constants
Dim $Item
Dim $sCmd

;Check the CPU architecture
$Item = @ProcessorArch

; Set the msi to be run based on architecture found
If $Item = "X86" Then
    $sCmd = " waikx86.msi"
ElseIf $Item = "X64" Then
    $sCmd = " waikamd64.msi"
ElseIf $Item = "IA64" Then
    $sCmd = " waikia64.msi"
Else
    MsgBox(0,'Error','The processor type is not supported - Setup will now exit')
    Exit
EndIf

;Run the installation command
Run ("msiexec.exe /i" & $sCmd)

;Program Installation Automation
; Wait for the Welcome window
WinWait("Windows Automated Installation Kit", "Welcome to the Windows Automated Installation Kit Setup Wizard")
Send("!n")

; Wait for the EULA window to become active
WinWaitActive("Windows Automated Installation Kit", "License Terms")
Send("!a")
Send("!n")

; Wait for the Select Install Location window to become active
WinWaitActive("Windows Automated Installation Kit", "Select Installation Folder")
Send("!n")

; Wait for the Confirm Install windows to become active
WinWaitActive("Windows Automated Installation Kit", "Confirm Installation")
Send("!n")

; Wait for the Install Complete window to become active
WinWait("Windows Automated Installation Kit", "Installation Complete")
Send("!c")

; Wait for the Reboot Required window to become active (NO LONGER REQUIRED FOR WAIK VERSION 1.1)
;WinWait("Windows Automated Installation Kit", "")
;Send("!y")

Exit

The first part of the script uses an Autoit function - @ProcessorArch to get the processor type of the machine that the script is being run on. Based on the processor found, the script sets the correct .msi file to run.

The script then uses the Autoit WinWait and WinWaitActive functions to wait for specific screens to appear and then uses the Send function to deliver the correct key stroke to that window.

As usual the Autoit source script (.au3 file) and the compiled executable (x86 .exe file) are available from the Deployment Guys SkyDrive - the executable must be placed into the Windows AIK 1.1 source directory (where the .msi files are) and run from there.

This post was contributed by Richard Smith - a Senior Consultant with Microsoft Services, UK.

Windows Vista Product Guide (Updated for SP1) now Available

DeploymentGuys — Wed, 30 Apr 2008 17:25:06 GMT

For those that need (or want) to know the intricacies of what is included with Windows Vista, the newly updated (for SP1) Windows Vista Product Guide is available for download.

The 334 page Windows Vista Product Guide provides a comprehensive overview of the features and functions that make Windows Vista tick. This guide also provides information about the benefits Windows Vista offers diverse users, as well as information about the different editions available.

Download from here

This post was contributed by Jon Bennett - a Senior Consultant with Microsoft Services, UK.

Getting help when you are really stuck

DeploymentGuys — Fri, 25 Apr 2008 10:42:00 GMT

A lot of people think that because BDD and MDT are free products they are not eligible for support from Microsoft. This question seems to crop up quite often and people are often surprised when I point out the truth!

So, in true A-Team spirit (i.e. "If you have a problem, if no one else can help, and if you can find them, maybe you can hire the A-Team."):

If you have a problem with BDD or MDT, if no one else has been able to help you, maybe you can try Premier Support!

It is simple, just call the support number which you can find here: http://www.microsoft.com/services/microsoftservices/srv_premier.mspx.

Make sure that you state that you have a BDD/MDT issue because if you talk about deployment you might be routed to a different queue. Also it is worth mentioning that Premier Support have a different style to the A-Team in that they don't use guns and explosions to fix things. Thanks to the MSDeployment guys who first highlighted this problem on their blog. Of course, please carrying commenting on our blog as well!

This post was contributed by Daniel Oxley a consultant with Microsoft Services Spain