MICHAEL,BERTUIT,PASSION,SYSTEM,CENTER,FR,SCCM2016,SCCM2012,SCCM2007,SCCM2012,SCOM,SCSM,SCVMM,SCDPM,ORCHESTRATOR,MICROSOFT,WINDOWS,SERVER,HOW,TO,CAPTURE,DEPLOY,WIM,SERVICE,MANAGER,2008R2,2010,2012,2013,2016,SYSTEM-CENTER.FR,SP1

Deployer la gestion des licenses Windows 7 VL MAK (Multiple Access Keys) avec MDT 2010

Add a comment avril 5th, 2009

Salut,

Document très intéressant >> à lire en urgence!!!

MDT 2010 Webcast


You have to register to download & they have both Live Meeting & WMV formats available.

Register and download here:

http://msevents.microsoft.com/CUI/InviteOnly.aspx?EventID=3A-78-05-A7-61-B7-4B-2B-08-41-98-B1-8C-3B-92-B4&Culture=en-US


Deploying Windows 7 VL with MAK (Multiple Access Keys) 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.

clip_image002

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.

clip_image004clip_image006

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

The second location is in the Specialize phase, specifically the x86_Microsoft-Windows-Shell-Setup_neutralProductKey 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.

clip_image009


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_neutralUserDataProductKey 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:

clip_image011

Task Name: Activate Client using VL MAK
Command Line: cscript.exe c:windowssystem32slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Start in: c:windowssystem32

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:

clip_image013

Task Name: Activate the machine using the VL MAK
Command Line: cscript.exe c:windowssystem32slmgr.vbs /ato
Start in: c:windowssystem32

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_neutralProductKey location in the Unattend.xml.

From the MDT Toolkit Reference document:

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:

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:
clip_image002[1]

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.


Sharing some simple HTAs

I was recently asked to share these files with a colleague, so I thought I would also share them with everyone via our blog.  I developed them a while ago for a deployment project and I have since used them a few times more.

Basically, they are 3 very simple HTA (HTML application) files that prompt the user for information in order to configure either a static IP address, change the local administrator password, or add a computer to a domain.  Of course, all of these actions can be accomplished directly via MDT, but I had to create them for a very specific reason where MDT could not be used to for this.  They were developed for a Windows XP deployment, so they have not been tested on Windows Vista but I can’t see why they would not work, as long as you ran them elevated.  You can be launch them directly from the task sequence in MDT by using the following command:

mshta.exe CUSTOM_Config_Network.hta HERE

CUSTOM_Config_Network.hta

image

CUSTOM_Config_PWD.hta

image

CUSTOM_Config_Domain.hta

image

I have attached the 3 files to this post in a zip file.  Please bare in mind that they are pretty simple and don’t have the error checking for every possible error that might occur, so use at your own risk!


Adding tools to Windows PE in an mixed x86 x64 environment

When creating both x86 and x64 Windows PE images, provide both x86 and x64 version of any tools that will be used.  MDT 2008 provides a method to add additional file to the Windows PE image using the Extras folder which is configured on the Windows PE tab of the deployment point properties dialog

image

There is only one folder that can be specified.  64 bit Windows PE has no 32 Bit WOW subsystem, tool executables for each architecture must be provided.

Here is a one line batch file that solves the problem:

@%SystemDrive%tools%PROCESSOR_ARCHITECTURE%%~n0.exe

Here are the steps to make makecab.exe available in Windows PE:

  1. Create an Extras folder add the path to the deploy point configuration.  i.e. e:Extras
  2. Create the e:Extrastools folder
  3. Create e:Extrastoolsamd64 and e:toolsx86
  4. Obtain 32 and 64 bit copies of makecab and place then in the correct folder.
  5. Create e:ExtrasWindows and e:ExtrasWindowsSystem32
  6. Create e:ExtrasWindowsSystem32makecab.cmd and add the single line @%SystemDrive%tools%PROCESSOR_ARCHITECTURE%%~n0.exe
  7. Use the MDT console and update the deployment point to create a new WIM and ISO

How it works

Anything added to the Extras folder goes into the root of the WIM and thus the root of X: when the WIM is booted.  The Processor_Architecture variable will contain the value amd64, x86, or IA64 (Note:  MDT does not support IA64). In a batch file the variable  %0 is the name of the batch file.  the prefix ~n modifies the variable %0 to by dropping the extension.  So in the example, the line in the batch file expands to x:toolsamd64makecab.exe in 64 bit Windows PE and  x:toolsx86makecab.exe in 32 bit Windows PE.

Notes

  1. When copying executables into toolsamd64 or toolsx86 make sure you copy all the required support files including any required MUI folders.
  2. Make sure that the tool is referenced by its basename i.e. makecab not makecab.exe
  3. Make sure the 64 bit tools folder is named amd64 not x64.

Thanks to :

Richard Trusson

Dave Hornbaker

Michael Niehaus


related post

Comments are closed.