The Deployment Guys : Windows 7

Preventing OEM builds from Accidentally Performing Mini-Setup without the Task Sequence

DeploymentGuys — Tue, 01 Dec 2009 16:48:00 GMT

When you pre-load an OEM build on machines, they are usually set-up to perform Mini-setup as soon as they come up. Customers sometimes have difficulties ensuring that these machines boot to WinPE using boot media or PXE rather than simply performing Mini-setup...(read more)

Location Deployment Wizard for ConfigMgr 2007

DeploymentGuys — Mon, 17 Aug 2009 19:37:00 GMT

When working on deployment projects, there is often a requirement for a workstation to be customised on a location by location basis. Common workstation customisations which are applied in this manner include:

Localisation settings (locales, keyboard settings, time zones, Windows (Windows Vista/Windows 7) language injection
Domain membership/organisational unit join information
Location based applications to be installed
Site or location based administrator groups or accounts that need to added to the local administrators group

The Microsoft Deployment Toolkit (MDT) and its accompanying database offers features to tailor a workstation based on its location during a deployment. The MDT Database allows locations to be defined and a set of location specific settings can be stored against each entry. When a workstation is been deployed, an MDT database lookup determines its location and collects the relevant build settings for that location. The location is determined by carrying out a lookup of the default gateway on the target workstations assigned NIC against default gateways assigned to locations in the MDT Database. To learn more about the Microsoft Deployment Toolkit and the database supplied with MDT see http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

During a mass deployment it is quite common for workstations to be built in central locations and then to be shipped to other sites for use. In these circumstances, the MDT Database location functionality may not be as useful as any database location lookups will return settings for the site at which the workstations are being built and not the site to which the workstation will be eventually shipped.

A solution to this is to use a location deployment wizard when using the MDT Database along with System Center Configuration Management (ConfigMgr) 2007 Operating System deployments (OSD) in zero touch scenarios. A location deployment wizard is an HTA that is displayed to the user/build engineer at the start of the workstation deployment process to display the location in which they are currently situated. If the location is the site at which the workstation will be based they can click next and the deployment will continue applying all the deployment settings for that site. However, the wizard allows an “override” for the detected location and allow the user/build engineer to select another location from the MDT Database. Overriding the detected location will apply all of the selected location deployment settings from the MDT Database to the workstation despite it not being at that location. This solution allows workstations to be built in a central location whilst being fully customised for their destination locations.

The location deployment wizard is an HTA that is stored in a customised ConfigMgr OSD boot image and is executed before a ConfigMgr task sequence starts. The HTA uses Operating System Media Pre-Execution Hooks (http://technet.microsoft.com/en-us/library/bb694075.aspx) to place itself before the task sequence window. The location deployment wizard allows inputs that are stored as a ConfigMgr task sequence variable. The location variable can then be used by a ConfigMgr deployment task sequence to recover settings from the MDT Database throughout the deployment (During ZTIGather phase).

Pre-Requisites

The following pre-requirements should be configured in your deployment environment:

System Center Configuration Management 2007 (RTM, SP1, R2 or SP2 beta) environment configured for OSD deployments.
Microsoft Deployment Toolkit 2008 / MDT 2010 Workbench + Database hosted on Microsoft SQL 2005 or 2008 (Express / Standard / Enterprise)
ConfigMgr 2007 console with integrated MDT console functions
The MS SQL Database hosting the MDT Database should be configured to allow NamedPipes
A share should be setup on the MDT Database server for authentication when using NamedPipes from a WinPE environment by using the SQLShare$ method.
ConfigMgr “Network Access Account” should have db_datareader access to the MDT SQL Database
Another AD account should be created which is assigned db_datareader access to the MDT Database. Note This account will be stored in a plain text file in the ConfigMgr OSD Boot image. This account should be limited to just db_datareader access on the MDT SQL Server and denied all other rights on the domain

Location Deployment Wizard Setup Steps

Download the location deployment wizard attached to this post and extract the files to a temporary location on the computer/server which has a ConfigMgr 2007 Console with integrated MDT console functions. There are 4 components which need to be configured in your environment for this solution to operate:

Configure the Bootstap.ini file
Create a custom boot image
Configure Location settings in the MDT Database
Configure CustomSettings.ini file

1. Configure the Bootstrap.ini file

The Bootstrap.ini file contains the settings required by the Location Deployment Wizard to make the initial connection to the MDT Database. These settings need to be configured for your environment:

Edit the Bootstrap.ini file in the Location Deployment Wizard\LocationDeploymentWizard folder. This file is used by the location deployment wizard HTA to connect to the MDT Database for the first time:
- Replace <USERNAME> with the AD account created for reading the MDT Database in the pre-requirements e.g. CONTOSO\MDTDBReader
- Replace <PASSWORD> with the password of the account entered above
- Replace <SQL SHARE FOR AUTHENTICATION> with the name of a shared folder on the MDT Database server e.g. \\MDT01.contoso.com\SQLShare$
- Replace <MDT DATABASE SEVER> with the fully qualified domain name of the MDT Database server e.g. mdt01.contoso.com
- Replace <MDT DATABASE NAME> should be replaced with the instance name of the MDT Database in SQL e.g. MDTDB

2. Create a custom boot image

During OSD deployments a WinPE boot image provides the environment for deploying a workstation. ConfigMgr 2007 provides default boot images in the Operating System Deployment -> Boot Images node in the console. A new custom boot image needs to be generated containing the location deployment wizard HTA and its supporting files – this will execute when the boot image first loads on a workstation:

Create a new custom boot image in the ConfigMgr console using the “Create Boot Image Using Microsoft Deployment” wizard:

Follow the wizard, selecting the default options. On the Image Options page set the Extra Folder to Add as the Location Deployment Wizard folder which is found in the root of the files extracted earlier
Complete the wizard selecting the default options. ConfigMgr/MDT will now create a new customised boot image with the location deployment wizard included.
Assign the boot image to the OSD deployment task sequence that you wish to use the location deployment wizard with:

3. Configure location settings in the MDT Database

Locations and their associated settings need to be configured in the MDT SQL Database, these are typically configured through the interface in the MDT workbench. In the MDT workbench go to the Database >> Locations Node. Here you can add as many different locations as are required for your environment.

For a location to be available to the location deployment wizard it must be assigned at least one default gateway. This can be found in a locations properties on the Identity tab.
If no default gateways for a site are initially known then assign 0.0.0.0 as the default gateway for that location. Although this site will never be automatically detected by the location build wizard, it can be manually selected.
In the Details tab of a locations properties use the SERVERA property to populate sites or country e.g. UK. This is used by the location deployment wizard to break down the locations so there is not just one long list:
Populate any other deployment site settings as required for your deployment including locales, time zones, keyboard settings, UI Language, location specific apps and location specific admins.

4. Configure CustomSettings.ini file

The CustomSettings.ini (http://technet.microsoft.com/en-us/library/bb977690.aspx) is a rules file which is used to automate deployments and setup how to query settings from the MDT Database. The location deployment wizard has its own CustomSettings.ini which is used during Gather phases in a ConfigMgr task sequence to retrieve location settings from the MDT Database. The CustomSettings.ini file included in the supplied location deployment wizard must be customised to your environment:

Edit the CustomSettings.ini file located in the root of the extracted files. The customsettings.ini file is a rules file is used by the MDT script ZTIGather.wsf to gather all of the location based settings from an MDT database:
- All instances of <FQDN MDT DATABASE> should be replaced with the fully qualified domain name of your MDT Database server e.g. mdt01.contoso.com
- All instances of <MDT DATABASE NAME> should be replaced with your MDT Database name in SQL e.g. MDTDB
- All instances of <AUTHENTICATION SHARENAME> should be replaced by your shared folder name on the MDT Database server e.g. SQLShare$

Once the customsettings.ini file has been updated it should be wrapped up into a ConfigMgr package (typically this is the MDT Settings package) and sent to all distribution points on your network which will be used for OSD. This rules package must be used by all Gather phases in your MDT integrated deployment task sequence to gather location settings from the MDT Database.

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.

This post was contributed by Mark Hooks and Richard Smith, consultants with Microsoft Services – U.K.

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>

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.