The Deployment Guys

Run command line as domain user – Incorrect Function Error

DeploymentGuys — Tue, 24 Apr 2012 21:19:32 GMT

When deploying Windows clients using Configuration Manager 2007 and MDT 2010 Update 1, there is often a requirement to run task sequence actions as a domain user as opposed to the local system account. For example, in order to perform actions on a computer object in Active Directory (such as moving the computer object to a different OU). Usually, the OU security will be configured with the necessary ACLs to allow specific users or groups to perform computer object operations. Therefore when we attempt to automate this as part of the deployment process, it will fail as the action will be executed by the system account which will not hold the necessary privileges (default behaviour in Configuration Manager 2007).

Therefore the “Run Command Line” task sequence action provides the functionality to execute the command as a domain user account that will have the necessary privileges.

This has always worked perfectly for me, until recently when working on a Windows 7 deployment. The issue was that the task sequence would fail when attempting to run the command line action as a domain user. The error logs revealed the error “Incorrect Function”:

This is quite a generic error and can be caused by many different things, including a syntax error in the script or cscript unable to locate the script specified. However, in this instance this error occurred due a combination of Microsoft .NET Framework 1.1 installed on the system and the attempt to run the command line as a different user. More specifically the error was caused by the configuration of the following registry key:

HKLM\Software\Microsoft\COM3\REGDBVersion

The default value for this key is 1, however the installation of.NET Framework 1.1 modified the value. The solution is to re-configure the REGDBVersion DWORD value back to 1 during the task sequence, which will result in the command line action running correctly. This can be easily automated during the deployment process by creating a collection of actions to first backup the key, then modify the value and finally restore the original value as illustrated in the following steps.

Step One: Backup the existing registry values

Step Two: Set the REGDBVersion value to 1

Step Three: Run the desired script as the domain user

Step Four: Restore the previous registry values

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 Matt Bailey, a Consultant with Microsoft Services - UK.

Microsoft Consulting Services (MCS) UK is Hiring

DeploymentGuys — Thu, 22 Mar 2012 10:01:39 GMT

MCS UK are looking for a technical consultant to specialise in client deployment (Windows 7 and Windows 8), Systems Centre 2012 Configuration Manager, System Center 2012 Virtual Machine Manager and Virtual Desktop Infrastructure (VDI) – to view and apply for the position please see http://bit.ly/GI8Id2 or if you need additional information then please contact Sarah Moule (v-srake@microsoft.com).

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

Approval request notification for Systems Center 2012 Configuration Manager

Aly Shivji — Thu, 22 Mar 2012 04:22:00 GMT

My favorite feature in Systems Center 2012 Configuration Manager (Configuration Manager) is without a doubt the new and shiny self-service Application Catalog portal. The new Application Catalog feature is packed with benefits for both the application owner and the end user. As an IT department or Line of business (LOB) application owner, you can easily make all or some of your applications available to users via an internal web portal. As an end-user, if you need to obtain a new business application all you need to do is pay a visit to your company’s internal application portal, search or select the application you’re interested in and install it all by yourself.

However, Configuration Manager Application Catalog is not a free for all place where users can install any application they like. First, when end-users visit the application portal, they will only see those applications they’ve been granted explicit access to by the application owner. Second, for many reasons (licensing being one of them), corporations may require a manager’s approval before an end-user can install a particular application. This is where Configuration Manager Application Catalog’s approval workflow feature comes in.

If the application owner requires administrator or manager’s approval before a user can install a particular application, the user will be able to submit a request for approval directly from the application portal.

After submitting a request for approval using my lab, I quickly realized that, well I realized that nothing else happened. It was at that moment that I started pondering (just like you are now I am sure): If a user goes to the Configuration Manager Application Catalog portal and submits a request for approval but no one knows about it, did the request really happen?

You see, as of RC2, Configuration Manager has no ability to notify administrators/approvers when users submit requests for approval from the Application Catalog site. Firing up the Configuration Manager Console and navigating to the “Approval Requests” section is the only way to see and manage (approve/deny) user requests. See below.

Now, before you head out to find your pitch forks and shovels, you may want to consider that Configuration Manager provides a very handy API that allows developers to easily query the Application Catalog for new user requests. The bad news here is that there’s no built-in mechanism to notify administrators of new requests but the good news is that you can build your own and have it do anything you like. J

For instance, I was able to build a VB.NET Windows service that queries Configuration Manager at a configurable time interval and retrieves any new user requests.

To obtain the list of requests from Configuration Manager, you simply query the UserApplicationRequest class and retrieve all entries that have the CurrentState property set to 1.

The following sample WMI query retrieves all user requests from Configuration Manager 2012:

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\SMS\site_P01")

Set colItems = objWMIService.ExecQuery( _

"SELECT * FROM SMS_UserApplicationRequest",,48)

For Each objItem in colItems

Wscript.Echo "-----------------------------------"

Wscript.Echo "SMS_UserApplicationRequest instance"

Wscript.Echo "-----------------------------------"

Wscript.Echo "Application: " & objItem.Application

Wscript.Echo "UniqueID: " & objItem.CI_UniqueID

Wscript.Echo "RequestGUID: " & objItem.RequestGUID

Wscript.Echo "CurrentState: " & objItem.CurrentState

Wscript.Echo "Comments: " & objItem.Comments

Wscript.Echo "ModelName: " & objItem.ModelName

Wscript.Echo "LastModifiedBy: " & objItem.LastModifiedBy

Wscript.Echo "LastModifiedDate: " & objItem.LastModifiedDate

Wscript.Echo "User: " & objItem.User

Wscript.Echo "RequestHistory: " & objItem.RequestHistory

Wscript.Echo "UserSid: " & objItem.UserSid

Once I have the list of user requests, all I need to do is send a notification email to the application approvers using the provided email address or Distribution List. Lastly, I store each Request GUID in a text file with today’s date so that approvers are notified only once-per-day.

After the approvers receive the notification email, they can fire up the Configuration Manager Console and approve or deny the user requests.

I know, I know. You’re thinking that now that you solved the email notification issue you still have to use Configuration Manager’s Console to manage these requests. You may also be thinking of creative ways to deploy the console across your organization to all your approvers and administrators. A daunting task, no doubt!

Luckily, once again, there’s no need to panic. Using the same API, you can create a custom (web) interface to allow approvers and admins the ability to manage user requests without having to rely on the Configuration Manager Console. However, that as they say, is a topic for another day and will be covered on my next blog post on the topic. For now, thank you for your time and I look forward to seeing you again soon.

This post was contributed by guest author Rafael Dominguez, a Senior Consultant with Microsoft Services USA specializing in Windows and Office deployment using Configuration Manager and Microsoft Deployment Toolkit

Using MBAM to start BitLocker Encryption in a Task Sequence

David Hornbaker — Mon, 20 Feb 2012 22:18:00 GMT

The script has been updated to abort if the TPM is not Active and to create Endorsement Key Pair if it does not exist on the TPM.

Microsoft BitLocker Administration and Monitoring (MBAM) provides features to manage BitLocker encryption of computers in an enterprise. More information on MBAM can be found here.

BitLocker creates recovery information at the time of encryption and MBAM stores that information in the recovery data store. While MBAM can update its recovery data store when the agent is installed on a system that is already encrypted, it is preferable to have MBAM control the encryption process. MBAM Encryption is controlled by Group Policy. Group Policy is not applied during a SCCM Task Sequence. It is possible to have MBAM start encryption during the task sequence, the techniques are described in the following whitepaper Using MBAM Data Encryption With MDT http://go.microsoft.com/fwlink/?LinkId=229053

Manually starting BitLocker Encryption with MBAM

Manually starting encryption with MABM requires five steps:

Install the MBAM Agent.
Stop the MBAM agent
Import registry settings that will instruct the agent to start encryption.
Wait for encryption to start
Remove the most of the imported registry settings

Installing MBAM Agent

The MBAM agent can be installed during Windows 7 Image creation.

To install MBAM during the deployment, just create a SCCM package/program to install the agent.

Creating the registry import files.

Create a .reg file that contains the required MBAM entries. There is a template in Program Files\Microsoft\MDOP MBAM\MBAMDeploymentKeyTemplate.reg. This template will become the basis for the AddMBAMRegEntries.reg file.

Do the following on an unencrypted system with the MBAM Agent installed(from an elevated command prompt):

Net Stop MBAMAGENT
reg import “c:\Program Files\Microsoft\MDOP MBAM\MBAMDeploymentKeyTemplate.reg”
using regedit make the following changes:

Change the KeyRecoveryServiceEndPoint key to have the URL of the MBAM recovery server.
Add NoStartupDelay as a DWORD with a value of one.

Export the MBAM key to a file (AddMBAMRegEntries.reg)

Next, create a .reg file to remove the entries

Copy AddMBAMRegEntries.reg to RemoveMBAMRegEntries.reg
Open RemoveMBAMEntries.reg in notepad
Delete the line: "Installed"=dword:00000001
for all the other keys in the file replace everything after the equals sign with a minus sign (E.G. "NoStartupDelay"=dword:00000001 becomes "NoStartupDelay"=-)
Save RemoveMBAMRegEntries.reg

Note: More information on creating and editing .reg files is available here.

At this point test that the .reg files are correct by starting the MBAM agent (net Start MBAMAGENT), encryption will begin within a couple of minutes. After encryption begins, run the removeMBAMEntries.reg file to remove the unneeded entries.

For encryption to begin, the MBAM agent needs to talk to the server. If this server communication fails the encryption will not start. If there is a problem, verify that the URL is correct and the MBAM server is functioning correctly.

Sample AddMBAMRegEntries.reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM]
"Installed"=dword:00000001
"KeyRecoveryOptions"=dword:00000001
"UseKeyRecoveryService"=dword:00000001
"KeyRecoveryServiceEndPoint"=hex(2):68,00,74,00,74,00,70,00,73,00,3a,00,2f,00,\
2f,00,63,00,69,00,73,00,35,00,33,00,33,00,76,00,6d,00,6d,00,62,00,61,00,6d,\
00,2e,00,61,00,76,00,6e,00,65,00,74,00,2e,00,63,00,6f,00,6d,00,2f,00,4d,00,\
42,00,41,00,4d,00,52,00,65,00,63,00,6f,00,76,00,65,00,72,00,79,00,41,00,6e,\
00,64,00,48,00,61,00,72,00,64,00,77,00,61,00,72,00,65,00,53,00,65,00,72,00,\
76,00,69,00,63,00,65,00,2f,00,43,00,6f,00,72,00,65,00,53,00,65,00,72,00,76,\
00,69,00,63,00,65,00,2e,00,73,00,76,00,63,00,00,00
"DeploymentTime"=dword:00000001
"NoStartupDelay"=dword:00000001

Sample RemoveMBAMRegEntries.reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM]
"KeyRecoveryOptions"=-
"UseKeyRecoveryService"=-
"KeyRecoveryServiceEndPoint"=-
"DeploymentTime"=-
"NoStartupDelay"=-

Automating the process with a script

StartMBAMEncryption.wsf is a MDT 2010 style script that will automate the last four steps To use this script create a folder that contains StartMBAMEncryption.wsf, ZTIUtility.vbs from the MDT toolkit, and the two .reg files created above.

To start Encryption run the following from an elevated command prompt:

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg

How does the script work?

Make sure that MBAM is installed, do a WMI query for the MBAMAGENT service. If the service does not exist, fail.

Set oServices = objWMI.ExecQuery("Select * from win32_service where name='MBAMAgent'")
TestAndFail (oServices.count = 1), 10005, "MBAM Client Agent is not installed"

The service exists, stop the service. Using the result of the previous query, call the StopService method. Note that the query will return at most one item.

    'Stop the service
    for each oService in oServices
      oService.StopService()
    Next

Use the REG IMPORT command to import the AddMBAMRegEntries.reg file, this will give the MBAM agent instruction to start encryption.

    sCMD = "Reg IMPORT """ & sAddRefFilePath & """"
    iRetVal = oUtility.RunWithHeartbeat(sCMD)
    TestAndFail iretVal, 10006, "Importing AddRegFile: " & sAddRefFilePath

Now, using the result of the original WMI query again, start the MBAM agent

    ' Restart the MBAMAgent Service
    for each oService in oServices
      oService.StartService()
    Next

Since BitLocker information is in a different Namespace, the script must create a connection to that Namespace.

    strConnectionStr1 = "winmgmts:{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!root\cimv2\Security\MicrosoftVolumeEncryption"
    On Error resume Next
    Set objWMIBDE = GetObject(strConnectionStr1)
    on error goto 0
    TestAndFail Err, 10007, "Unable to connect to Bitlocker WMI Object - bitlocker not installed"

Using the object just created, query for a Win32_EncryptableVolume for the C: drive. Once that object is obtained, go into a loop sleeping 30 seconds, updating the Task Sequence progress bar, and checking to see if the encryption is in progress. Note that the script is checking for both in progress (EncryptionStatus = 2) and Encrypted (EncryptionStatus = 1). This loop will wait 10 minutes for the encryption to start. In testing the encryption has started within 2 minutes.

    iCount = 0
    iLoopCount = 0
    oLogging.CreateEntry "Waiting for Encryption to Start", LogTypeInfo
    Do
      oLogging.ReportProgress "Waiting For Encryptiont to Start", iLoopCount/20
      wscript.Sleep 30000
      Set colEnVol = objWMIBDE.ExecQuery("Select * from Win32_EncryptableVolume where DriveLetter='C:'")
      for each oEncVol in colEnVol
      oEncVol.GetConversionStatus iEncryptionStatus, iPercentComplete
      Next

      ILoopCount = iLoopCount + 1
      If iLoopCount >= 20 then
        TestAndFail False, 10008, "Timeout: Encryption did not start"
      End If
    Loop Until ((iEncryptionStatus = 1) or (iEncryptionStatus = 2))
    oLogging.ReportProgress "Encryptiont Started", 100
    oLogging.CreateEntry "Encryptiont Started", LogTypeInfo

All that is left to do is cleanup the registry by importing the removeMBAMEntries.reg file

    sCMD = "Reg IMPORT """ & sRemoveRegFilePath & """"
    iRetVal = oUtility.RunWithHeartbeat(sCMD)
    TestAndFail iretVal, 10009, "Importing RemoveRegFile: " & sRemoveRegFilePath

Creating the MBAM Support Task Sequence Package

Create a new folder and add the two .reg files created above, a copy of ZTIUTILITY.VBS from the MDT scripts package, and StartMBAMEncryption.wsf. In you SCCM console, create a new package, and program. The program command line will be:

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg

Or, to wait until encryption is finished, before the task sequence continues, the program command line will be:

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg /WaitForEncryption:true

Changes to the Task Sequence

TPM Issues

The Trusted Platform Module (TPM) must be visible to the OS and enabled. making the TPM visible, varies by hardware vendor and system. There is a script that will check if the TPM is visible Here. For information on how to enable the TPM from a task sequence see the table below.

Lenovo	http://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-68488
Dell	http://en.community.dell.com/techcenter/os-applications/w/wiki/how-to-enable-trusted-platform-module-using-a-configmgr-2007-task-sequence.aspx
HP	http://itbloggen.se/cs/blogs/micke/archive/2010/10/18/enable-tpm-via-task-sequence-on-hp-boxes.aspx

Disk Partitioning

BitLocker requires an unencrypted partition that will hold the Boot files and boot database. This partition has to be at least 100MB, but it is recommended that it be 300MB. A 300MB partition will allow recovery environment (WinRE) to be copied to the unencrypted drive. WinRE is automatically copied when BitLocker is enabled if there is enough space on the boot partition.

For Bare Metal deployments, the partition can be created during the Partition Disk step.

Create a 300MB primary partition and mark it Active (Make Bootable)
Create a primary partition that uses 100% of the remaining disk Assign a variable to this disk (OSDISK)
Change the Apply Operating System step to put the Operating System on the disk specified in the variable OSDISK

For refresh from XP or Windows 7 system that does not have a separate boot partition, use the following steps:

The following steps should be added before the step that installs the MBAM support package created above.

Using ZTIBDE.WSF (from MDT)

Add a Run Command Line step that runs ZTIBDE.WSF

Cscript %ScriptRoot%\ztibde.wsf

Using BdeHDCfg

Add a Run Command Line step with the following command line:

BdeHdCfg -target default -quiet

This will create a 300MB partition for the boot files.

Add a Reboot System step following this step.

Additional information on BitLocker, Configuration Manager 2007, and disk partitions can be found on the Configuration manager Support Team blog http://blogs.technet.com/b/configurationmgr/archive/2011/01/20/solution-the-enable-bitlocker-task-fails-to-run-during-a-configmgr-2007-task-sequence.aspx

Join the Domain

The computer system must be in a Domain in order for MBAM to escrow the BitLocker Keys.

Joining a domain is required for this process to work correctly.

Enabling BitLocker

To enable BitLocker, simply add an install software step to install the package/program created above. It is recommended that this be one of the last steps in the Task Sequence because encrypting the disk will consume many system resources until the disk is fully encrypted.

Waiting for Encryption to Finish

To ensure the highest security level, the system should not be released to a user until the disk is completely encrypted. The /WaitForEncryption:True option will force the script to wait up to 5 hours for the encryption to finish. If the encryption doesn’t finish within 5 hours, the fact will be logged but the script will not abort. This option can be useful if there are business requirements that the system be fully encrypted before any data is restored.

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg /WaitForEncryption:true

This post was contributed by David Hornbaker, a Senior Consultant with Microsoft Services - U.S. East Region.

Special thanks to Manoj Sehgal, Senior Support Escalation Engineer, Platforms core, Microsoft Services, and William Lees, Principal SDE, Microsoft Corporation, for their assistance with this post.

Expiring Outdated Stand-Alone Media

Brad Tucker — Wed, 15 Feb 2012 17:30:00 GMT

In my previous post ‘How to Limit or Restrict the Use of Bootable Media Devices for OS Deployment Using SCCM’, I showed you how to limit or restrict outdated boot media devices. As promised, I am now going to offer a solution for stand-alone media.

I need to start by saying that there or MANY possible ways to resolve this issue. This is but one, but I have found it works pretty well.

As a little background, I will tell you that this solution came about because my customer at the time asked for a way to keep stand-alone media from being deployed after it was no longer current. They wanted this to work for non-networked devices. This meant I couldn’t point back to a file on a network share and check its contents/properties. It all had to be contained within the media.

Once it was implemented they decided to use this same solution for networked devices as well that use stand-alone media.

I created a script called ExpiredUFDCheck.vbs. The purpose of this script was to check the creation date of the policy.xml file on the media itself. This file contains the task sequence information and is created when the media is generated. My customer wanted to refresh the reference image and task sequence every quarter, so I added logic in the script that checked to see if the policy.xml file was older than 3 months old. If it wasn’t, the task sequence would launch and run as normal. If it was, the script would pop up a message box notifying the tech that the task sequence was expired and would then shutdown the box and not launch the task sequence. Pretty simple, right?

' // ***************************************************************************
' //
' // File:      ExpiredUFDCheck.vbs
' //
' // Version:   1.0
' //
' // Purpose:   Check to see if stand-alone media is expired
' //
' // Usage:     cscript ExpiredUFDCheck.vbs
' //
' // ***************************************************************************

On Error Resume Next

' // ---------------------------------------------------------------------
' // Find the environment variable %configpath% for location of UFD
' // ---------------------------------------------------------------------

'Set objShell = CreateObject("WScript.Shell")
'Set objExecObject = objShell.Exec("%comspec% /c echo %configpath%")
'configPath1 = objExecObject.StdOut.ReadAll()
'configPath = Mid(configPath1, 1, Len(configPath1) -2)

' // -----------------------------------------------------------------------------------------
' // Find the environment variable %TEMP% for location of tool files (e.g. shutdown.exe)
' // -----------------------------------------------------------------------------------------

Set objShell = CreateObject("WScript.Shell")
Set objExecObject = objShell.Exec("%comspec% /c echo %temp%")
temp = objExecObject.StdOut.ReadAll()
tempdir = Mid(temp, 1, Len(temp) -2)

' // ---------------------------
' // Find driver letter for UFD
'// ----------------------------

Set FSO = CreateObject("Scripting.FileSystemObject")

Set Drives = FSO.Drives

For Each DiskDrive In Drives
If DiskDrive.DriveType = "1" Then
USBPath = DiskDrive.Path
End If

Next

' // -----------------------------------------------------------------
' // Query WMI for creation date of the Policy.xml file on the UFD
' // -----------------------------------------------------------------

strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

' // ----------------------------
' // Media Check - Policy.xml
' // ----------------------------

Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where Name = '" & USBPath & "\\SMS\\Data\\Policy.xml'")

' // -----------------------------------------
' // Set the date 3 months ago from today
' // -----------------------------------------

dt3MonthsAgo = DateAdd("m", -3, Now)

' // -----------------------------------------------------------------------------------------------------------
' // If the Policy.xml file creation date is less than the date 3 months ago from today, it is an expired UFD.
' // -----------------------------------------------------------------------------------------------------------

For Each objFile in colFiles
    dtCreationDate = WMIDateStringToDate(objFile.CreationDate)
dtEndDate = DateAdd("m", 3, dtCreationDate)
    If dtCreationDate < dt3MonthsAgo then
        Set WshShell = CreateObject("WScript.Shell")
        Command = TEMPDIR & "\scripts\Shutdown.exe /s /t 0"
        MsgBox "This task sequence expired on " & dtEndDate, vbMsgBoxSetForeground, "Expired Task Sequence"
        Set oExec = WshShell.Exec(Command)
    Else
        WScript.Quit(1)

    End If
Next

' // -----------------------------------------------------------------------------------------
' // Converting the WMI date query response to a simple date format. (e.g. 09/21/2010)
' // -----------------------------------------------------------------------------------------

Function WMIDateStringToDate(dtmInstallDate)
WMIDateStringToDate = CDate(Mid(dtmInstallDate, 5, 2) & "/" & Mid(dtmInstallDate, 7, 2) & "/" & Left(dtmInstallDate, 4) & " " & Mid(dtmInstallDate, 9, 2) & ":" & Mid(dtmInstallDate, 11, 2) & ":" & Mid(dtmInstallDate, 13, 2))
End Function

Now comes the fun. I had to make sure the script ran on the media. We also wanted it to run before the task sequence fired.

Inside WinPE itself, there is a file on the root called TSConfig.ini (X:\TSConfig.ini). This file is a ‘pre-execution hook’ file and determines if any extra actions are required when WinPE is launching and initializing. I mounted the WinPE wim and copied my script file to the root. Then inside the TSConfig.ini file I set the command to launch my script.

[CustomHook]

CommandLine=”cscript.exe X:\ExpiredUFDCheck.vbs”

When a machine is booted with an expired UFD, the following message box will be displayed during the WinPE initialization…

Hitting OK, will shut down the computer.

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States

Internet Explorer 6 Migration Roadshow events - UK

DeploymentGuys — Wed, 08 Feb 2012 18:32:34 GMT

Microsoft is working with a number of compatibility partners to host Internet Explorer 6 Migration Roadshow events around the UK. With support for Windows XP coming to an end on the 8^th April 2014 and IE6 standing in so many people’s way of migration, this is an opportunity to gain understanding on how to deal with problem web applications.

Microsoft have teamed up with Camwood, Citrix Systems and Quest Software to deliver events through February, March and April - there are a range of dates to choose from, each offering a slightly different spin and all promising to be informative!

Who, Where & When?
Tues 21^st February
Microsoft & Quest Software
Manchester United Football Ground (Old Trafford)
09:30 – 14:00 (+Stadium Tour!)
More Information & Registration
Thurs 22^nd March
Microsoft & Citrix Systems (Including newly acquired AppDNA)
Chalfont St. Peter (Easy access via the M40 & M25 as well as rail)
09:00 – 16:00
More Information & Registration
Tues 3^rd April
Microsoft & Camwood
London, Cardinal Place
More Information & Registration coming soon
Thurs 19^th April
Microsoft & Quest Software
Reading Football Ground (Madejski Stadium)
09:30 – 14:00 (+Stadium Tour!)
More Information & Registration

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

Dynamically Installing ‘Computer Specific’ Applications Using Configuration Manager with MDT

Brad Tucker — Fri, 03 Feb 2012 05:54:00 GMT

There is a little known component of the MDT database that, when used with Configuration Manager, can automatically re-install applications that were previously installed on a device. It is not well known, simply because it isn’t readily visible from the database view within the Deployment Workbench.

I decided to write this entry, to explain the MDT PackageMapping table and RetrievePackages stored procedure.

This process is sometimes, unofficially, referred to as Zero Touch Applications. ZTA refers to the unattended application installation process integrated into Zero Touch Installation. It utilizes the Add/Remove Programs (ARP) data from the ConfigMgr database and maps that to a manually maintained “PackageMapping” table that is hosted on the MDT database server. When the ZTIGather is run, it queries the ConfigMgr database for all application names associated to the MAC address that is passed from the machine. It then attempts to match these to entries in the PackageMapping table in the MDT database. If there are matches, they are then used to populate the PACKAGES variable for use in the Install Software step of the task sequence.

The PackageMapping table maintains a list of mappings. The column ARPName refers to the legacy application and the column Packages refers to the package ID and program name of the new package to be installed. Many of my customers will use this to map a new, Windows 7 remediated application to an old application name, so that when the image is deployed, it will automatically install the new version via a dynamic upgrade.

I should point out that the following uses ConfigMgr 2012, but the process is the same on ConfigMgr 2007, even though the console look and feel may be different.

The configuration of the process is as follows…

First, make sure your package and program exist in ConfigMgr. You will notice I have a package called Project Professional 2010 with a package ID of CO100014. It also has a program named ‘Silent Install Project 2K10.’

Second, identify the name that ConfigMgr recognizes for the application to which you want to map. You can do this by launching SQL Management Studio and running the following query against the ConfigMgr database. Notice the DisplayName0 is ‘Microsoft Office Project Professional 2010’. Also, notice the ProdID0 is a GUID. This will be explained momentarily.

Now you need to modify the PackageMapping table. Notice I have added the previously queried DisplayName0, ‘Microsoft Office Project Professional 2010’ in the ARPName column. I have also added the ConfigMgr package CO100014:Silent Install Project 2K10. The format for the Packages column must be PACKAGEID:Program Name.

Now we need to modify the RetrievePackages stored procedure. This can be found in the Programmability node under the MDT database. Right-click this stored procedure and select Modify.

CREATE PROCEDURE [dbo].[RetrievePackages]

@MacAddress CHAR(17)

SET NOCOUNT ON

/* Select and return all the appropriate records based on current inventory */

SELECT * FROM PackageMapping

WHERE ARPName IN

(

SELECT DisplayName0 FROM [HYD-SRV1].CM_CO1.dbo.v_GS_ADD_REMOVE_PROGRAMS1 a,

[HYD-SRV1].CM_CO1.dbo.v_GS_NETWORK_ADAPTER n

WHERE a.ResourceID = n.ResourceID AND

MACAddress0 = @MacAddress

)

Notice I have added [HYD-SRV1].CM_CO1. in front of the two ConfigMgr views that are being referenced in the query. This represents my [SCCM_Server].SCCM_Database. There is also another change I like to make in order to make it easier to identify the applications. The ‘SELECT DisplayName0…’ in the original stored procedure is really ‘SELECT ProdID0…’. Remember when we ran our query earlier, I had you look at the ProdID0. It is a GUID. The DisplayName0 is what shows in the Add/Remove section of the operating system, so it is easier to reference. Once all changes are made, click Execute.

Now that we have done all that, we have to modify the customsettings.ini file so that it will run the stored procedure during the ZTIGather. Here is a sample customsettings.ini file with the changes needed in yellow…

[Settings]

Priority= RetrievePackages, DynamicPackages, Default

Properties=MyCustomProperty

[DynamicPackages]

SQLServer=HYD-SRV1

Database=MDT

StoredProcedure=RetrievePackages

NetLib=DBNMPNTW

Parameters=MacAddress

SQLShare=DeploymentShare$

[Default]

…

When I run my task sequence, the ZTIGather.log now looks like the following…

Notice that the SQL query has returned CO100014:Silent Install Project 2010 and assigned it the PACKAGES variable as PACKAGES001.

DONE!!

NOTES:

My lab environment is Windows 2008 R2 with Configuration Manager 2012 RC1, MDT 2012 Beta 2 and SQL 2008 SP2 CU6 . This process, however, is the same on MDT 2010 Update 1 with SCCM 2007 .

My lab has the MDT and ConfigMgr databases on the same server. If this is not your environment, you will need to setup the ConfigMgr server as a linked server in the SQL Management Studio.

Manipulating the PackageMapping table is manual out of the box. You could also script to pull the ARP data from ConfigMgr and then manually map, or you could produce a front-end application that helps users map the applications.

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States

Finding All References to MDT Variables in a Deployment Share: VariableDocumentor v1.0

Aly Shivji — Fri, 20 Jan 2012 23:41:00 GMT

MDT is very flexible in the ability to define and use variables inline and in different locations. However, this also means that if you forget to assign a variable a value it may lead to unintended consequences that you might not easily discover. There are many different places in which you could find references to a variable:

Task Sequence Variables- You can use variables in a task sequence in two ways:
- Directly used in the command line with the notation %variable%
- As a condition on a particular step in the task sequence
ZTIGather.xml – This file defines the variables and lists that are declared by MDT for the Gather step of the Task Sequence to use and process for rules. It also defines whether variables are re-writable.
Within MDT scriptsvariables are called in different ways
- In VBScripts you may see a reference to an oEnvironment.Item or an oEnvironment.ListItem
- In Powershell you may see references to tsenv: or tsenvlist:
- In cmd and batch scripts you may see references to %variable%
In a CustomSettings or other INI file you could see references to variables in the “Properties=” field

In order to help manage all of these variables, the following PowerShell script scours a given deployment share

and returns the results of all references from scripts, task sequences and ZTIGather of variables in that deployment share. It saves it to a Variables.XML with a built in XSL transform in the working directory:

You can also specify a parameter to update a given INI to see any variables missing from the properties section.

To use it – download the attached Powershell and XSL and point to the same folder.

This post was contributed by Aly Shivji, an Architect with the Datacenter & Private Cloud Center of Excellence in Microsoft Services

Windows 7 Deployment Options for Small and Midsize Businesses

Daniel Oxley — Thu, 12 Jan 2012 10:11:48 GMT

Happy new year to everyone! It looks like I am making the first blog post here for 2012 :-)

To get the year rolling I thought I'd share anexcellent resource that I stumbled across this week, even though it was published back in November. If you follow the link below you can download a printable overview poster of the Windows 7 deployment options that has been specifically designed for small and midsize organizations. As you can see in the small extract below each option is shown as a simple diagram and then the advantages and limitations of each one are discussed in detail further on. Also included in the poster are the limitations, basic requirements and helpful links to tools and further guidance, as well as a step-by-step overview of the Windows 7 deployment process.

I hope it is of use, and if you know of any other similar resources (both Microsoft and non-Microsoft) feel free to share them with our readers using the comments section below. See here for more information and the download links.

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

MDT 2012: New Features – Hide Shell

Ben Hunter — Fri, 02 Dec 2011 04:35:05 GMT

Here is a common scenario. You are deploying an operating system using MDT Lite Touch, during the deployment you install some user specific applications. However the users think that the deployment is completed an they close the application installs or perhaps start messing with the machine while it is still logged in as the local administrator. Now you could simply inform the user that they should not touch the computer until the deployment is completed. However in my experience this “don’t touch” approach has not always been 100% successful.

Well now we have a better way, you can hide explorer shell while MDT is “doing it’s thing”!

So how do we do this? It is simple, just add the following line to the customsettings.ini file:

HIDESHELL=YES

I have included before and after shots below:

Look explorer…

No explorer…. that’s better!

P.S. The exclamation marks are for you Rod

This post was contributed by Ben Hunter, a Senior Program Manager for MDT with Microsoft

MDT 2012: New Features– GPO Packs

Ben Hunter — Fri, 02 Dec 2011 00:11:00 GMT

There are many new features of MDT 2012 but one that I particularly like is the ability to apply GPO Packs created using Security Compliance Manager (SCM) during the deployment process.

SCM is a great tool that allows you to create and manage group policy baselines in an easy to use interface. These polices are then able to be applied at the domain level or as “Local GPO Packs”. MDT can now deploy these “Local GPO Packs” during deployment.

MDT provides four default GPO packs for the following operating systems that are applied by default during deployment. The correct GPO pack will be applied based on the operating system that is deployed. If an operating system matching the GPO pack is not found then no GPO Pack will be applied.

1. Windows 7 SP1

2. Windows Vista SP2

3. Windows 2008 SP2

4. Windows 2008 R2 SP1

All GPO packs are stored in the Templates folder within the Distribution Share. For example <Distribution Share>\Templates\GPOPacks\<GPO Pack Folder>. When you specify your own GPO Pack you must override the default GPO pack using the GPOPackPath variable in the customsettings.ini file. This is a relative path from the <Distribution Share>\Templates\GPOPacks\ folder. For example

GPOPackPath = Win7-HighSecurity

If you do not want to apply any GPO Packs then task sequence step can be skipped by setting the variable ApplyGPOPack to NO in customsettings.ini.

You can create your own GPO packs using the following process.

1. Use SCM to create an SCM baseline

2. Export the baseline using a GPO backup

Now we need to turn the baseline into a GPO pack, this is a simple process.

3. Open to an existing GPO pack and copy the following files to the backup - GPOPack.wsf, LocalPol.exe, LocalSecurityDB.sdb

4. Copy the GPO Pack to the <Distribution Share>\Templates\GPOPacks folder

3. Update the GPOPackPath variable in the customsettings.ini file to point at the new GPO Pack

Each ofthe default GPO Packs updates the local policy with the settings in the attached excel file.

This post was contributed by Ben Hunter, a Senior Program Manager for MDT with Microsoft

MDT 2012 Beta 2 Released

DeploymentGuys — Fri, 11 Nov 2011 08:33:24 GMT

The latest version of MDT is now available on Connect (Join the MDT 2012 Beta 2 Connect program here!)

MDT 2012 Beta 2 offers new User-Driven Installation components and extensibility for Configuration Manager 2007 and Configuration Manager 2012 as well as integration with the Microsoft Diagnostics and Recovery Toolkit (DaRT) for Lite Touch Installation remote control and diagnostics.

Key benefits include:

Full use of the capabilities provided by System Center Configuration Manager 2012 for OS deployment.
Improved Lite Touch user experience and functionality.
A smooth and simple upgrade process for all existing MDT users.

New features For System Center Configuration Manager customers:

Support for Configuration Manager 2012 (while still supporting Configuration Manager 2007)
New User-Driven Installation components for Configuration Manager 2007 and Configuration Manager 2012
- Extensible wizard and designer, additional integration with Configuration Manager to deliver a more customized OS experience, support for more imaging scenarios, and an enhanced end-user deployment experience
Ability to migrate MDT 2012 task sequences from Configuration Manager 2007 to Configuration Manager 2012

New features For Lite Touch Installation:

Integration with the Microsoft Diagnostics and Recovery Toolkit (DaRT) for remote control and diagnostics
New monitoring capabilities to see the progress of currently running deployments
Support for deploying Windows to computers using UEFI
Ability to deploy Windows 7 so that the computer will start from a new VHD file, “Deploy to VHD”
Improved deployment wizard user experience

MDT 2012 Beta 2 will be available for beta download through to January 2012.

Already using the Microsoft Deployment Toolkit? the MDT team would like to hear about your experiences. Please send comments and suggestions to satfdbk@microsoft.com.

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

BitLocker Protection Status

DeploymentGuys — Fri, 04 Nov 2011 13:55:00 GMT

I have recently been working with a customer on a Windows Vista to Windows 7 migration. During the Refresh deployment task sequence, BitLocker is suspended on the C and D partitions. On occasion we had issues where by protection was not always successfully being suspended on the D partition, which caused the user to be prompted for the recovery key to access D once the deployment had completed. This led me to write a script that checks the protection status of the drives before continuing with the deployment.

A brief overview of the script:-

Firstly we need to use WMI to select the objects from Win32_Volume. This allows us to use the DeviceIDs to establish the protection status.

The \root\CIMV2\Security\MicrosoftVolumeEncryption namespace contains the Win32_EncryptableVoulume class, from which we can select the DeviceID property and use the GetProtectionStatus method.

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2\Security\MicrosoftVolumeEncryption")

Set objEncryptVol = objWMIService.Get("Win32_EncryptableVolume.DeviceID='" & strDeviceID & "'")

Set objOutParams = objWMIService.ExecMethod("Win32_EncryptableVolume.DeviceID='" & strDeviceID & "'", "GetProtectionStatus")

The protection status can then be evaluated based on the integer values returned. Windows 7 uses the following protection status values:

· Protection Status 0 : Protection OFF

· Protection Status 1 : Protection ON (Unlocked)

· Protection Status 2 : Protection ON (Locked)

This post was contributed by Matt Bailey, a Consultant with Microsoft Services UK

ZTI MDT Debugger 1.0

Daniel Oxley — Fri, 04 Nov 2011 11:34:00 GMT

I've had this tool sitting in a folder on my laptop half-finished for a few months but after a particularly frustrating problem with a script in a ZTI deployment I was encouraged to finish it!

The original MDTDebugger that I wrote is a great help for debugging tasks running in a litetouch (LTI) deployment task sequence, but it doesn't work for zerotouch (ZTI) deployments. The reason for this is that it needs to be able to display a window on the desktop of the computer that is running the task sequence; something that Systems Center Configuration Manager actively prevents. Well, this is no longer a problem because now there is a version of the MDTDebugger for ZTI deployments! This tool works in the same way as the LTI version but with a key difference: you open the debugging window on a different computer. In order to achieve this, I split the tool into two parts, the first part is the launcher that runs from the task sequence, and the second is the GUI that you use to help with the debugging.

To use this tool you'll need to do the following:

Download the ZIP file that is attached to this post and extract it's contents.
Copy ZTI_MDTDebugger_Launcher.exe into the scripts folder of the MDT package you created on your Configuration Manager server
In the MDT Task Sequence, edit the task you wish to debug by prefixing it's command line with the following: %deployroot%\scripts\ZTI_MDTDebugger_Launcher.exe - an example is shown below
Run the deployment

When ConfigMgr reaches your task, it will run the process as normal but will then pause (all you will see on the computer is that the task is still running, it won't state that it is paused). On a different computer, launch the file ZTI_MDTDebugger_GUI.exe, and you'll see the below window appear. Now, to start debugging you simply enter the remote computer name (the one running the task sequence) in the text box and press "Connect". Once connected, you will be able to debug your task in a similar way to how the LTI version of this tool works, and any failures will be captured by the debugger, preventing the task sequence from failing!

The above screenshot shows an example of the tool in action

To be able to use the tool successfully, you will need to be running the GUI portion of the tool with an account that has full administrative rights on the remote computer. Also, in order to be able to connect to the remote computer, you may need to temporarily disable the Windows Firewall via Control Panel. I've tested and used this tool successfully in deployment labs and it has no issues, but if you do find a bug or issue with it please post a comment here and I'll try to fix it! Also, if you have any feature suggestions then please also let me know.

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

Deployment Mindmaps

lutz seidemann — Sat, 10 Sep 2011 00:57:00 GMT

"Why deployment is so hard?", “Where can I find all related information?” What else I need to consider?”

Those or similar questions are normal during my customer projects. After getting the same questions again and again,
I’ve decided to create a Mindmap with all common links you need to know if you in the deployment space.
Since few weeks I’m sharing them now with the project teams and the amount of Questions I get is drastically reduced :-}

Hope this helps.

This post was contributed by Lutz Seidemann, a Architect with Microsoft Services - APAC.

Co-existing PXE Boot for MDT standalone Image Capture & ConfigMgr Image Deployment Environments

DeploymentGuys — Wed, 07 Sep 2011 15:10:47 GMT

The Microsoft Deployment Toolkit is great for building and capturing your reference images because allows you to use the copyprofile technique to configure user settings. System Center Configuration Manager 2007 is great for Zero Touch Deployments of you enterprise image. But what if you have a lab environment with one server and you want to have PXE boot work for both? Co-location of Image Engineering and Image Deployment environments usually only occurs in a lab environment on an isolated network. Here’s how to switch machines to boot from one or the other:

Install the PXE service point role on the WDS Server.
Configure the WDS Server to respond only to known clients as below:

WDSUTIL /Set-Server /AnswerClients:Known
You can setup both the LTI and ZTI scenarios to use the same WDS server to PXE boot by changing the provider order in the registry :

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\ProvidersOrder
Restart the WDS Service.
If the DHCP server is located on a different box – you can do two things:
a) Authorize the WDS Server in DHCP and set up an IP Helper to the WDS Server
b) Set up the DHCP Scope Options to redirect to the WDS Server as below:
Clients will PXE boot to the ConfigMgr PXE Service Point (ZTI) unless configured otherwise. To configure a client to PXE boot to the Image Build environment (LTI) use the following command to add the reference machine to the WDS database:
wdsutil /add-device /device:<computername> /ID:00-00-00-00-00-00
(where 00-00-00-00-00-00 is the Mac address of the reference machine)
To re-configure clients to PXE boot to the ConfigMgr service Point (ZTI) remove the machine account from the ConfigMgr DB or from Active Directory.

(It is not recommended to build your reference images attached to the enterprise network as the reference operating system task sequence still needs to patch the deployment with the latest updates during the process.

This post was contributed by Aly Shivji, an Architect with the Datacenter & Private Cloud Center of Excellence in Microsoft Services

Adding Configurations to the Applications Pane using AppDescriptors

DeploymentGuys — Fri, 02 Sep 2011 16:12:00 GMT

Often times when you are presenting applications to install in the LiteTouch wizard of MDT, you may want to present configurations for each of these applications. These could include installing application features, configuring parameters like computer name, language or parameters that link to other computers.

Below is an example of Office and Windows 7 Configurations added to the Applications pane

Each of these configurations will become Task Sequence variables which you can use to control the task sequence or leverage in your scripts. To express these configurations, you can use an XML file called an “AppDescriptor” as below:

Then edit the LiteTouch wizard to call a script when rendering the Applications Pane – this script will apply an XSL transform to your AppDescriptor and format it as HTML for the wizard.

To make all this work:

1. Download the scripts below.
2. Make a backup of the Control and Scripts folders in your Deployment Share
3. Copy the downloaded files to your Deployment Share (Control to Control folder, Scripts to Scripts folder).
4. You can then add configurations by following the schema above.
5. You can also change the style of the HTML by editing formatter:

This post was contributed by Aly Shivji, an Architect with the Datacenter & Private Cloud Center of Excellence in Microsoft Services

Getting more into DVD Media Based Deployment

DeploymentGuys — Fri, 02 Sep 2011 10:38:00 GMT

One of the great features of MDT 2010/2012 is the ability to create a media based deployment – this media based deployment can be placed on a USB based memory device (HDD or Fob) or onto a DVD. This allows the MDT based deployment to run from this removable media which is great for badly connected environments or portable build requirements.

Many customers I work with like to use DVD media based deployment as MDT 2012/2012 automatically creates a .ISO file that can be burnt to DVD and in most cases this gives them up to 8.5 GB on a dual layer DVD – it’s also a cheap deployment mechanism. However there are some occasions where this amount of DVD space just isn't enough and a combination of image size and MDT distribution share content pushes the requirement for storage over the limit of the DVD. You could at this point switch to using USB based devices or you can read on and use the solution discussed in this post.

The DVD Exchange tool is an application designed to extend the DVD based media deployment to a second DVD. Before you get too excited – this doesn't mean that you can split the ISO created by MDT 2010/2012 across two DVDs – but instead allows you to shift the application install source (which is usually in the applications folder of the MDT distribution share and which can be a large amount of data) from the MDT generated media deployment (which we will call DVD1) to a second DVD (which we will call DVD2). DVD2 can then be used to copy the application source to a temporary location on the local hard disk during task sequence execution – where you task sequence can then install the applications from (instead of from the applications folder on DVD1) – which in turn frees up space on DVD1 for bigger images or more drivers.

To achieve this a number of challenges need to be overcome:

Challenge 1 - we need to pause the task sequence and eject the MDT media distribution (DVD1) from which the task sequence is running

Challenge 2 -we need to manage the insertion of DVD2, run a script to copy the contents of DVD2 to a local folder on the hard disk

Challenge 3 - when the copy of data from DVD2 has taken place, we need to prompt for the re-insertion of DVD1 so that the task sequence can continue

The idea behind the DVD Exchange tool is that it allows you to create an MDT media distribution (DVD1) to which you then add a task to your task sequence to run the DVDExchange.hta (attached to this post). This HTA handles the ejection of DVD1 (the MDT media distribution) and prompts for DVD2 (pausing the task sequence). When DVD2 is inserted, DVDExchange.hta runs a script that you place on the DVD2 called cache.vbs (attached to this post) which copies all of the content from DVD2 to a cache folder on the local hard disk (C:\DVDCache). When this is complete the DVDExchange.hta then prompts for DVD1 to be re-inserted and the task sequence then continues. You can then add tasks (after the DVD exchange has run) to install applications from the newly created data that was copied from DVD2 to C:\DVDCache

Steps for use:

1. Create DVD2 (you can use the in-built DVD burning software provided with Windows 7 or your favourite DVD burning software – the DVD does not need to be bootable). Add your required application packages (these would usually be application install folders with the source for each application contained within each folder). Place the cache.vbs and DVD2.ID files (from the ADD TO ROOT OF DVD 2 folder in the zip file attached to this post) in to the root along with you application source folders. The root of DVD2 should look something like this:

The cache.vbs file (which is run by DVDExchange.hta) will copy all folders and data from the DVD2 to a folder on drive C: called C:\DVDCache and will then hide this folder.

2. Copy the DVDExchange.hta and the Images folder (from the COPY TO MDT SCRIPTS FOLDER in the zip file attached to this post) to your MDT Distribution Share\Scripts folder. Note the DVDExchange.hta file and the Images folder need to be together

3. Add a task to your task sequence to run the DVDExchange.hta at the point at which you want to create the cache (this is usually towards the start of the System Restore phase in the task sequence). You can achieve this by adding a RUN COMMAND LINE task to run %ScriptRoot%\DVDExchange.hta or %DeployRoot%\Scripts\DVDExchange.hta

4. After the task that you created to run the DVDExchange.hta, add additional tasks to your task sequence to install the applications that will now be available in the C:\DVDCache folder (using this folder as your root path)

You may want to consider adding a task to the end of the task sequence to delete the C:\DVDCache folder if you don't want the source to remain on the local hard disk.

5. Create a Media deployment folder in MDT by using the New Media menu option on the Media node in the Advanced Configuration node of the MDT Workbench. Run through the wizard to create a staging folder for the media deployment. Note – this does not actually create the media deployment at this time as you need to run step 6 to copy the files and create the .ISO file.

6. When the Media deployment folder has been created place the tag file DVD1.ID (from the ADD TO ROOT OF DVD 1 folder in the zip file attached) into the CONTENT folder – then return to the MDT Workbench and right click the Media Deployment Share (it is shown in the MDT Workbench \ <Your_Distribution_Share> \ Advanced Configuration \ Media node as a CD icon and by default is called MEDIA001) and choose Update Media Content from the right-click context menu) – this will copy all of your files from your working distribution share to the media deployment folder and will create an .ISO file based on this folder structure - which can be burned to DVD – this will be DVD1 – when you have burned the .ISO file generated by MDT to a DVD, the root of DVD1 should look like this (notice the DVD1.ID file is in the root of the DVD because you added it to the CONTENT folder in the Media deployment folder):

You can now run the installation by starting your build from DVD1 – at the point in the task sequence where the DVDExchange.hta runs – the application will load.

You will be prompted to swap DVDs (DVD1 > DVD2 > DVD1) while DVDExchange.hta will manage:

Pausing the task sequence
Identifying the DVDs (from their DVDx.ID files)
Ejecting the DVDs
Running the cache.vbs script to copy all data from DVD2 to C:\DVDCache
Logging actions to C:\MININT\SMSOSD\OSDLOGS\DVDExchange.log

DVDExchange.hta will then exit when DVD1 has been re-inserted and the task sequence will continue

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

Replace Scenario alternative for USMT Migration

Andres Springborn — Thu, 01 Sep 2011 13:44:00 GMT

While USMT 4.0 in a Refresh Scenario provides some great advance by using Hardlinking in a Replace Scenario customers still face multiple operational challenges and potential capital costs during large scale deployments because user data needs to make its way from the legacy computer to the new computer. Managing that data and its transfer can be an expensive task.

System Center Configuration Manager does provide some help in Replace Scenarios with their State Migration Point role, but with that approach comes several operational and hardware requirements. In the short term, when managing an enterprise wide migration of a desktop operating system, as many customers are facing with Windows 7, the state migration point can potentially become a bottleneck during the migration. There is a need for more storage capacity for USMT Data on the server. Without it only so many migrations can be run at any one time. There may be additional disk subsystem IO performance requirements as well which if not addressed could slow capture and restore of USMT data. The data also needs to be transferred twice over the network which costs additional time and could make the NIC of the SMP server a potential bottleneck. In remote offices transferring USMT data over WAN links would also potentially slow down network links impacting other business functions and increasing the time a given migrations may take. Managing and tracking all of these risks is one more thing IT admins have to take into account for a migration.

Some alternative approaches that enterprises use is a more manual method where a technician uses either Easy Transfer or USMT’s core tools, Scanstate.exe and Loadstate.exe, with a USB hard drive/stick to ports the user data from the legacy computer to the new one. Those approaches do work, though operationally they can be very labor intensive and thus does not scale well when an organization is facing hundreds if not thousands of systems to migrate.

There is a third approach to consider. Both Scanstate.exe and Loadstate.exe, the core utilities for USMT have input parameters for where to save and restore data. Using that functionality, data could be captured from the legacy OS and saved directly to the new computer over the network. The benefits to this are numerous. It would defuse the network and Disk IO load across many more computers and each of their NICS and hard drives thus avoiding potential bottlenecks of a centralized server. USMT data would only have to be moved once across the network. The process could still be zero touch without the need for any manual processes beyond delivering the new computer to the end user’s desk. There would be no need to purchase additional storage or manage it for state migration points. This isn’t to say there are no costs associated with the approach, but that the engineering and infrastructure required to make it happen should be weighed carefully against other options. For some organizations this approach does make sense and if so you’ll be interested in the processes I have outlined below to make this work.

Please note the steps below are very SCCM centric as I mostly work with large enterprise customers, but they could be leveraged for Lite Touch deployments as well.

I’ll break out the tasks to get this working into 4 sections:

Section 1: Prepare for the build

Operationally this is the most challenging step after the engineering is complete.

Environmental/Infrastructure Preparations Requirements:

- A build workbench/build center with enough network ports to support the number of systems you want to deploy in a given time is a hard requirement.

- This process is dependent on having both the legacy and new computer on the network at the same time.

- As both computers would be on the network concurrently, validate your DHCP scopes have enough leases to support this.

- Power and Cooling for the workbench/build center must also be taken into consideration.

- In order for the XP system to connect to the new computer, the DNS infrastructure needs to be up to date otherwise the legacy computer will not connect properly to the new computer. In fact you’ll see in the steps below that I tend to take a “trust by verify” approach to confirming I’m connecting to the correct computer.

Associating the new and legacy computer:

Each time a computer is deployed in a Replace Scenario build the relationship to the new computer must be determined and defined. This work is required regardless of whether a State Migration Point is used (thus required Computer Association) or a manual approach is taken (take USB Storage Device from computer A to computer B). This work isn’t new but how it done is bit different than the other approaches.

The key to redirecting where USMT captures data and where it restores it from is based on the Variable OSDStateStorePath which both Capture and Restore steps in SCCM Task Sequences can leverage to determine where to save and restore USMT Data. The variable is also used by MDT’s ZTIUserState.wsf and ZTIBackup.wsf scripts so WIM backups and Lite touch deployments can leverage it as well.

Example for the additional steps describe below:

Let’s say you’ve determined a computer named “Desktop1XP” will be your legacy computer to be replaced by a new computer called “Laptop1-W7”. You will now need to setup computer variables. This could be done via an MDT Database (thus getting pulled in via a Gather step) or in SCCM by a computer variable put directly on the computer. Mass importation of variables/computer creation is possible via the SCCM SDK, but that is a topic probably better left for another blog posting.

For Laptop1-W7 a computer variable named LegacyComputer with a value of “Desktop1XP” should be created. This will be leveraged at multiple points for validation and preparation purposes.

For Desktop1XP a computer variable named NewComputer with a value of “Laptop1-W7” should be created. This will be used to send USMT data to the new computer.

Section 2: Update your build computer task sequence

In your Deploy Windows 7 task sequence at the end of the build process, or as close to the end as possible add a group step for the new steps to prepare the new computer to accept USMT data. This should be at the end of the build because if the build fails and you are planning to rebuild the system you don’t want the capture process to potentially see the computer on the network and start the capture to a system you are planning to rebuild anyway or multiple additional reboots for things like application install requirements will occur before the build is complete which could break your USMT capture.

Steps to add:

Step 1: Run Command Line Step

Command: cmd.exe /c md c:\USMT

Rational: Create the Directory to keep the USMT Data

Step 2: Run Command Line Step:

Command: net share USMT$=c:\USMT /grant:%DomainName%\%LegacyComputer%$,Change

Rational: Set Permissions so only the legacy computer account has rights to access the share. Note this assumes the computer is domain joined. If it isn’t then this will fail.

Step 3: Run Command Line Step:

Command: cmd /c copy %_SMSTSLogPath%\smsts.log c:\USMT\%OSDComputerName%-%LegacyComputer%.log

Rational: This is an inelegant solution to providing for validation checking and allows techs to easily see the computer relationship without SCCM access for troubleshooting.

Other considerations:

- If the new computers have multiple hard drives you may want to configure your build scripts to put the user data on a drive other than C. If that is the case Section 3 and 4 will need updates to support that as well.

- You may want to add additional permissions to the share so that administrator can access the share to testing/troubleshooting purposes.

Section 3: Update your Capture USMT task sequence

There are a few steps you would need to add to the task sequence you use to capture USMT data from the legacy computer. These steps are both for validation and redirecting USMT to save directly to the new computer.

Steps to add at the top of your task sequence:

Step 1: Set Variable Step

Command: OSDStateStorePath=\\%NewComputer%\USMT$

Rational: Set Variable for OSDStateStorePath to be used USMT Capture Process and validation step below.

Step 2: Run Command Line Step

Command: cmd /c copy %_SMSTSLogPath%\smsts.log %OSDStateStorePath%\2-USMT-Validation_successful_%_SMSTSMachineName%.log

Rational: Validate that new computer is on the network, name resolution is working correctly and permissions were setup correctly on the new system.

Steps to add after the USMT Capture steps:

Step 1: Run Command Line Step

Command: cmd /c copy %_SMSTSLogPath%\scanstate.log %OSDStateStorePath%\scanstate-%OSDComputerName%.log

Rational: Puts the scanstate log file onto the new computer for future review and as a marker that the USMT capture has completed successfully.

Other considerations:

Sometimes to ensure better results for USMT captures the following additional steps after the validation step and before USMT Capture are completed should be run:

- Run Command Line Step: FSUTIL dirty set c:

- Reboot to OS

The FSUtil step tells the OS to do a chkdsk on reboot. By doing this and rebooting the computer, issues which can cause Scanstate failures/skipping of files such as memory fragmentation, fix disk corruption issues and applications locking files are avoided.

Section 4: Updates for USMT Restore

The following steps can be added into the build under two different methods:

- Run as a separate task sequence that just does USMT Restore steps. I generally create this by taking a standard MDT build template task sequence and removing all the sections above State Restore and removing most steps within State Restore which are not related to USMT (minus things like Gather and Use Toolkit Package). This can be beneficial if as part of your deployment process you build a lot of computers ahead of time and want to put systems back on the network closer to the migration time to get USMT data.

- As part of the build task sequence if you can code a loop waiting for the existence of the scanstate-%OSDComputerName%.log file you could eliminate the need for another task sequence entirely. I haven’t provided code for this, but it is very possible. Note: for this approach to work the new computer would need to stay on from the time of build to the after the capture and the task sequence should be set to unknown/unlimited run time (so it will not time out).

Steps to add before the USMT Restore Task Sequence Steps:

Step 1: Run Command Line Step

Command: cmd.exe /c copy c:\usmt\scanstate-%LegacyComputer%.log c:\usmt\starting_loadstate.log

Rational: Validates that USMT Capture has completed successfully.

Step 2: Set Variable Step

Command: OSDStateStorePath=c:\USMT

Rational: Set Variable for OSDStateStorePath to be used USMT restore process

Steps to add after the USMT Restore Task Sequence Steps:

Step 1: Run Command Line Step

Command: net share usmt$ /Delete

Rational: remove share no longer needed.

With all of this in place USMT data in a Replace scenario can be done without a State Migration Point or manual processing.

This post was contributed by Andres Springborn, a Senior Consultant with Microsoft Services - U.S. West Region.

Querying MDT/ConfigMgr Logs in MDT Scripts

Michael Murgolo — Mon, 29 Aug 2011 21:06:00 GMT

The Lite Touch Deployment Process end in a Summary Wizard pane that displays any warning or errors that were logged in the MDT master log (BDD.log).

This is a great feature but customers have pointed out that this summary is not preserved after the Summary Wizard is closed. If you accidentally Finish before reading everything, you now have to open the log and start trawling through it.

So what I was initially going to do to preserve this information was to change Summary_scripts.vbs (the part of the Summary Wizard code that does the work) to write the same information to a text file. However, as I pondered this I realized that there was no general purpose function for querying logs in SMS format. So instead of just changing Summary_scripts.vbs I decided to create such query functionality and then use that.

The log format used by MDT and the ConfigMgr client/task sequencer has been around since Microsoft Systems Management Server. It is an XML-like format with entries that look like this:

<![LOG[Successfully finalized logs to E:\SMSTSLog]LOG]!><time="06:20:42.077+240" date="05-23-2009" component="TSBootShell" context="" type="1" thread="908" file="tslogging.cpp:1635">

The actual message text is found inside the <![LOG[…]LOG]!> tags and the other information about the entry (time, date, component, type, etc.) is found in XML-like attribute entries within the second <…> braces. The message text may be a single line or multiple lines of text. The closing ]LOG]!> and the attributes block will always be on the last line of the entry.

Since Summary_scripts.vbs was already doing part of the parsing of this log format, I used that code as a starting point. The result is a new VBScript class script, MDTQuerySMSLog.vbs, to use with MDT scripts. This SmsLog class in the script has three public methods. The most useful is ConvertToXmlObject. This method converts the contents of an SMS-format log file into an XML object representation. This allows you to query the contents using standard XPath queries. For example, a log consisting of the single entry below:

<![LOG[Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS]LOG]!><time="10:24:21.000+000" date="06-04-2010" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">

will be converted into the following XML data:

<?xml version="1.0" encoding="utf-8"?>
<LogEntries>
<Log id="1" line="1" time="10:24:21.000+000" date="06-04-2010" component="ZTIGather" context="" type="1" thread="" file="ZTIGather">Property LogPath is now = C:\MININT\SMSOSD\OSDLOGS</Log>
</LogEntries>

Every log entry is turned into an XML Log node where the message text is the node text and the entry attributes are the node attributes. There are also two additional attributes added: id which is the log entry number from the original log file and line which is the line number on which the entry started in the original log file.

Another method, ConvertToArray, converts the log contents to a two dimensional array where each row in the array contains the same attributes and message text that the XML version contains. The last method is LogDateTimeToVBDate which takes the SMS log date and time attributes and returns a VBScript Date value.

To illustrate how to use this class I’ve included a sample script, MDTErrorWarningSummary.wsf, that uses ConvertToXmlObject, LogDateTimeToVBDate and XPath queries to create a more detailed version of the error and warning entries (type="3" and type="2" repectively) summary that the Summary Wizard creates. It creates this summary in ErrorWarningSummary.log in the MDT logs folder. The contents looks like this:

Total number of entries logged in C:\MININT\SMSOSD\OSDLOGS\BDD.log: 48
Number of errors logged in C:\MININT\SMSOSD\OSDLOGS\BDD.log: 1
Number of warnings logged in C:\MININT\SMSOSD\OSDLOGS\BDD.log: 1

Warning
=======
Log Entry: 3
Log Entry stating line number: 3
Date/Time: 8/2/2011 2:16:18 PM
Component: ZTIMyComponent
Message: This is a warning message.

Error
=====
Log Entry: 9
Log Entry stating line number: 9
Date/Time: 8/2/2011 2:16:18 PM
Component: ZTIMyComponent
Message: This is an error message.

You can launch this script at the end of the task sequence or add an oShell.Run call to Summary_scripts.vbs to launch the script.

If you use this class with your own custom script, be aware that ConvertToXmlObject creates a point in time capture of the log contents. So if you wanted to use this for something like repeatedly checking a log for a particular message as the log changes, you would need to call ConvertToXmlObject in each iteration of you loop to recapture the full contents.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

Back to basics #6 – Application Compatability: Things You Shouldn't Do But Are Tempted To

Daniel Oxley — Tue, 23 Aug 2011 08:40:05 GMT

I can't profess to be an Application Compatibility guru like Chris Jackson or Aaron Margosis, but I do work on a lot of deployment projects where I am tasked with helping the client with this area. As such, I have compiled a list of the top 5 most common Application Compatibility mistakes/not-recommended practises that I see out in the field; this list is likely to differ from the next guy though :-)

Most of the items in this list are actually quick-fixes that people think are the result of one (or a combination) of the following:

It seemed a good idea at the time
Not understanding completely the problem, or the future consequences that the great "solution" will have
The desperate need for a quick fix

If you know of any other common ones, feel free to add them in the comments section!

Make users local administrator on their computer in order to eliminate errors associated with a lack of permissions – Tracking down exactly what permissions are required can be a complex task to complete, but is always a better option to making users administrators on a computer.
Disable User Account Control (UAC) – The UAC can be a valuable tool for protecting a computer from unwanted changes. However, it is often disabled because it is perceived as being too verbose. But, if configured correctly, this verbosity can be reduced without compromising security.
Open up ACLs on Folders and Registry Broadly – This is a valid solution to an application compatibility problem if executed correctly, by only making changes where absolutely necessary. However, ACL changes are often made much higher up the tree, and then applied on all sub-objects. This grants a user too many permissions on what might be files or registry keys that should be protected.
Disable Internet Explorer Protected Mode – One of the hardest compatibility problems to solve is when an application requires a specific version of a browser to work, and is not compatible with later versions; usually because security is stricter in the later version of the browser than the application expects. A common approach to alleviating this issue is to lower the level of security in the browser, commonly by disabling the Protected Mode in Internet Explorer or using the Internet Zones feature. The Protected Mode feature of Internet Explorer can provide a user with a high level of protection from all the "bad stuff" lurking out on the Internet, and should be correctly configured rather than simply disabled.
Software add-ins/plug-ins are often overlooked – These components are equally as important as the rest of the applications, but are commonly overlooked. Not considering and evaluating these components at the right stage can result in a situation where a user has been deployed a newer version of an application, such as Microsoft Office 2010, but subsequently discovers that a business critical add-in they need/require/use in Office does not work in Office 2010, leaving them stranded!

There are two tools though which are indispensable when beginning any Application Compatibility assessment, the Microsoft Application Compatibility Toolkit, and the Microsoft Assessment and Planning Toolkit. These tools are extremely helpful in getting started and working out the best approach to a problem. Also be sure to check out the Application Compatibility section of TechNet.

I recognise that pointing out the problems but not giving any solution to them is easy to do. I am unable though to provide any alternatives to these quick-fixes in a single blog post as every single Application Compatibility problem is unique, and the solution to it will also be unique and personalised. Some solutions can take extremely long times to identify and then develop, and sometimes it is also just down to a little luck. The best approach in my opinion is that, if you really don't understand the problem or the solution, then get help; don't apply a heavy-handed solution such as those mentioned above because you will be creating a future problem for yourself further down the road. More often than most people realise an application compatibility problem can be resolved correctly without resorting the one of the fixes above and compromising security, you just need to understand the problem better and be aware of all the options! I strongly recommended regularly reading Chris and Aaron's blogs (I provided the links above) as they both provide some great information on Application Compatibility and Microsoft Windows.

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

Windows 7 Background Customization

lutz seidemann — Mon, 22 Aug 2011 08:58:00 GMT

One of the most requested windows7 customization in every deployment projects is the OS branding. Here is a quick step by step guide.

Windows Background Picture:

If you want to assign a Win7 Background & Logon picture based on the size of the Monitor we recommend to create a picture that looks good with the FILL
option on different screen sizes. Here are the recommendations for a nice looking picture

Create a picture with a resolution of 2560x1440
Use the attached win7 background template

The black lines defines the different sizes
The best place for customer Logo is in the middle white area
The top and bottom area (marked with the red line) should not contain any information , this is a cut off area based on the screen size

Push the picture to your clients via GPO

"\User Configuration\Policies\Administrative Templates\Desktop\Desktop\Desktop Wallpaper"
Enable the Active Desktop Setting as described in KB977944

- Or you could use a .reg file:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Control Panel\Desktop]
"Wallpaper"="C:\\Windows\\Web\\Wallpaper\\MyWallpaper.jpg"

where "Wallpaper"="<path to your wallpaper>"

Windows Logon Screen:

The graphics in the “Windows 7 Login Screen Templates. zip” file show the different resolutions

Ensure you don’t change the names, only on the default file you can have a higher resolution
Again, don’t add information, logos , etc in the red area because those can have an overlapping with windows default elements
Copy the jpg files to %windir%\system32\oobe\info\Backgrounds. You need to create the folder if it does not exist.
Open the Registry Editor
Navigate to (If you cannot find the path or the key go ahead and create it)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background
Navigate to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background
, If the key does not exist, create it
Double click on key named OEMBackground and change its value dword:00000001 If the key does not exist, create it.
If you use Themes (including win7 default Theme), ensure that in the [Theme] area SetLogonBackground=1 is set.
This will prevent any change of the Logon screen. You can also tie your login background to a specific theme if you change themes frequently but always return to your standard.
To do this open your favorite .theme file with a text editor (notepad will do), which, if you've saved your theme, you will find in the folder at C:\Users\Your User Name\AppData\Local\Microsoft\Windows\Themes

[Theme]
; Windows 7 - IDS_THEME_DISPLAYNAME_AERO
DisplayName=Woodgrove IT Theme
SetLogonBackground=1
BrandImage=%systemdrive%\Windows\System32\OOBE\Info\Backgrounds\Windows 7 Background.png

This post was contributed by Lutz Seidemann a Architect with Microsoft Services - APAC. Inspired by the work of german collegue Lars Iwer.

Supporting different build types using a single deployment share

DeploymentGuys — Wed, 17 Aug 2011 14:10:10 GMT

I have recently been working with a customer deploying Windows 7 using MDT. One of the requirements the customer had is to be able to use a single deployment share to capture and deploy images without having to use the MDT database. Using a single deployment share is complicated by the requirement to specify different configurations depending on whether the deployment type is a capture of a reference build or the deployment of the standard image. For example, during the deployment of the reference image, the capture settings dialog should not be displayed.

The customer used a set of Virtual Machines to perform captures of the reference build, therefore we could use information specific to those Virtual Machines to determine whether a capture or deployment was taking place. We used a simple user exit script to determine whether the MAC address of the client was linked to a Virtual Machine and if so set configuration options for a capture build. Otherwise, the build was treated as a standard deployment. Below are examples of a customsettings.ini and user exit script.

CustomSettings.ini

[Settings]

Priority=Default, Role

[Default]

UserExit=role.vbs

Role1=#Role(“%MACADDRESS%”)#

[ReferenceBuild]

SkipCapture=NO

[StandardBuild]

SkipCapture=YES

DoCapture=NO

Role.vbs

Function UserExit(sType, sWhen, sDetail, bSkip)

UserExit = Success

End Function

Function Role(strMac)

If strMac = “00:00:00:00:00:00” Then

Role = “ReferenceBuild”

Else Role = “StandardBuild”

End If

End Function

This post was contributed by Matt Bailey, a Consultant with Microsoft Services - UK.

Dynamic Computer Naming in ZTI Deployments

DeploymentGuys — Fri, 05 Aug 2011 02:29:00 GMT

For a while I have been meaning to write up a solution around dynamic computer naming in Zero Touch. Many people have emailed or commenting on how useful this would be – so here goes.

Zero Touch Installation relies on a combination of System Centre Configuration Manager (ConfigMgr) and Microsoft Deployment Toolkit (MDT) 2010/2012. The MDT guys wrote a great integration tool that gives the ability to add extra functionality to ConfigMgr such as new tasks, task sequence templates and a new wizard for creating boot disks.

The integration also allows for the MDT environment to be accessed from within the ConfigMgr task sequence through the use of MDT packages that are created by an MDT task sequence wizard installed in the ConfigMgr console. This also gives the ability to access the MDT Deployment Database from within the ConfigMgr environment to set deployment variables (as opposed to setting them as collection variables).

The dynamic computer naming process I will outline in this post uses these integration points and the ability to run something called UserExit scripts which allows for the extension of the MDT inbuilt logic. The UserExit script that is attached to this post will dynamically build the computer name, but a UserExit script can be used to accomplish any task(s) you need to carry out where variables need to be combined or adapted - as the UserExit script exits, it returns its output to the task sequence process as a variable. The computer name generated by the UserExit script will be based on a location ID (two characters added as a custom property in MDT Deployment Database), the computer chassis typed (L for laptop, W for Workstation, V for Virtual and X if the chassis can not be identified), and the first 7 characters of the computer serial number (removing spaces and replacing them with minus (-) for situations where the serial number contains spaces such as virtual machines serial numbers). These three properties are then glued together and provided as the OSDComputername variable for use in the deployment process so you end up with a computer name such as: UK (location ID) L (Chassis ID) 1234567 (Serial Number ID).

For the dynamic computer naming to work, we need carry out the following task

Create a new property in the MDT Deployment Database (for the two character location ID)
Configure the CustomSettings.ini file (in the MDT settings package) to query the MDT Deployment Database and run the UserExit script
Create the UserExit script that does the generation of the computer name and add it to the MDT Toolkit package

The instructions below assume that you have:

Installed MDT 2010/2012 (probably on your central site server) and setup an MDT database.
Run the MDT Integration (accessed through the MDT start menu folder and running Install ConfigMgr Integration)
Created a task sequence in ConfigMgr using the MDT integration and utilising the MDT supplied client task sequence template – if you walked through the MDT task sequence wizard you should have also created the MDT support packages (MDT Boot Image, MDT Settings, MDT Toolkit and MDT USMT packages).

Step 1 - Create a new custom property in the MDT Deployment Database (for the two character location ID)

The MDT Deployment Database provided with MDT 2010/2012 on the surface looks very simple – but is actually very powerful. In this database we can store all of the variables that we used in the MDT Lite Touch world as well as extra OSD based variables for use in Zero Touch and server build task sequences. The MDT Deployment Database contains four main areas for storing variables – Computers, Location, Roles and Make/Model. In the underlying structure of the database a separate table stores the settings that are then made visible through the DETAILS tab in each of these areas.

To add a custom property to the MDT Deployment Database we need to edit this table. Open your MDT Deployment Database using SQL Admin Studio and navigate to the dbo.Settings table – right click and select New Column

At the bottom of the column list create a new column called LocationID and set the data type to nvarchar(10) – this will give you a field of up to 10 characters (you may want to limit this to two or three characters in production depending on the naming convention you use and how many letters represent location)

Save the settings to the database (using the save icon on the toolbar in SQL Admin Studio) – although you have added the new container for your Location ID to the settings table – it will not be visible in the MDT database interface (within the MDT Workbench) until you open a query and execute the following stored procedures

EXECUTE sp_refreshview '[dbo].[ComputerSettings]'
EXECUTE sp_refreshview '[dbo].[LocationSettings]'
EXECUTE sp_refreshview '[dbo].[MakeModelSettings]'
EXECUTE sp_refreshview '[dbo].[RoleSettings]'

Your new LocationID entry point should now be visible on all of the tables in the MDT Deployment Database viewed through the Advanced Configuration\Database node in the MDT Workbench – the LocationID entry point will be at the bottom of the form in the Custom area. Now you can create a new record in the locations table based on your networks default gateways – include any location specific settings such as locale, keyboard and time zone and then add your two character location ID to your new LocationID column

Step 2 – Now that the MDT Deployment Database has the location part of the computer name that we need, we need to configure the CustomSettings.ini file to query the MDT Deployment Database, store the custom property added in step 1 and run the UserExit script to glue the LocationID gathered from the MDT database to a chassis ID and the adapted serial number.

When you ran the MDT task sequence wizard from within the ConfigMgr environment, you would have gone through quite a long wizard (this is accessed by right clicking the task sequence node under OSD in the ConfigMgr console and choosing “Create MDT based Task Sequence”). The wizards job is to import an MDT developed task sequence template in to the ConfigMgr environment and to walk you through creating the packages required to support this task sequence. One of the packages that is generated as part of the wizard is the MDT settings package. The settings package contains a template CustomSettings.xml file and the unattend.xml that are used throughout the execution of your chosen task sequence template.

Our first task is to replace the template CustomSettings.ini file in your settings package with one that contains the MDT database queries that we want to run to pull in the LocationID (and any other settings you have added to the location record). This can be achieved by right clicking the database node in the MDT Workbench and running the Configure Database Rules wizard. This wizard will help to create the queries for each of the tables in the MDT database. In this post we are interested in the LOCATION options, however you can choose any queries to be added to Customsettings.ini if you are using other MDT variables.

Deselect the options in the COMPUTER options and click next. On the LOCATIONS options, adjust so that only the first two options are ticked.

You can deselect all of the queries on the MAKE/MODEL options and the ROLE options (if they are not needed) and click through to the end and select Finish. This will update the CustomSettings.ini file stored in the Control folder of your deployment share – open this folder and open the CustomSettings.ini file. It should look like the example below with the MDT Deployment Database queries added.

The next task is to adjust the CustomSettings,ini file to deal with the new LocationID value and to run the UserExit script that will create the OSDComputerName. With the newly adjusted CustomSettings.ini file open add the following lines to the file.

In the [Settings] section on the Priority line add BuildComputerName to the end of the line (after all of the database entries but before Default)

It line should now read Priority=Locations, LSettings, BuildComputerName, Default - you may have more queries on this line if you left additional queries ticked in the Configure Database Rules wizard.

in the [Settings] section on the Properties line add BuildComputerName and LocationID after MyCustomProperty

this line should now read Properties=MyCustomProperty, BuildComputerName, LocationID

Create a new section under the Properties line called [BuildComputerName] and configure as follows:

[BuildComputerName]
UserExit=MachineNameExit.vbs
OSDComputerName=#BuildComputerName()#

Your CustomSettings.ini file should now look something like this (but containing the connection information for your MDT Deployment Database environment):

Save your newly edited CustomSettings.ini file and then copy this file (from the control folder) to the source location of your MDT Setting Package – The source location is the folder that would have been set during the MDT Wizard in ConfigMgr and is the location where the MDT Settings Package get its source files from – replace the CustomSettings.ini file in the source folder and then replicate the settings package to your distribution points in ConfigMgr.

Step 3 – Now that the MDT database is set, and the CustomSettings.ini file is configured to query the MDT Deployment Database and run the UserExit script, the final piece of the jigsaw is to add the UserExit script itself to the MDT Toolkit Package (again this should have been created when you setup your task sequence using the integrated MDT task sequence template and the package wizard). Open the source folder where your MDT Toolkit Package is stored and add the MachineNameExit.vbs file attached to this post into the SCRIPTS folder

Replicate your MDT Toolkit Package (with this new file added) around to your ConfigMgr distribution points using the ConfigMgr console.

Outcome

When the task sequence runs, the normal gather process that MDT uses will poulate the deployment variables with environmental information about the device being built as well as variables queried from the MDT database (as setup in the queries in CustomSettings.ini). The sample script provided will then be run as a UserExit funtion which in turn will run a function called BuildComputerName. This function has all of the logic to obtain gathered variables found during the gather process. The variables we are interested in are:

oEnvironment.Item("LocationID")
oEnvironment.Item("isLaptop")
oEnvironment.Item("isDesktop")
oEnvironment.Item("isVM")
oEnvironment.Item("SerialNumber")

The script then glues the pieces together as follows:

Character 1 and 2 - Letters pulled from the MDT database LocationID attribute during the gather process (this will be XX if nothing is set in the database)
Character 3 – A single letter based on the chassis of the device which was discovered in the gather process (L for laptop, W for Workstation, V for Virtual and X if the variable is empty)
Character 4 to 10 – The last seven characters of the serial number (recorded in the gather process) of the machine with spaces replaced with dash (-) The replacement of spaces is required because some virtual machines tend to have the serial number set to a GUID with spaces - the script takes care of dealing with this.

NOTE - You could change from using the serial number to using the machines asset tag (if this has been set in the BIOS) by changing the code in the script to get the asset tag attribute instead of SerialNumber – to do this simply change the line

sSerialNumber = oEnvironment.Item("SerialNumber") to sSerialNumber = oEnvironment.Item("AssetTag")

The script then passes back the compiled computer name to the UserExit as BuildComputerName which is then converted and stored as OSDComputerName for use later in the task sequence

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

How to Limit or Restrict the Use of Bootable Media Devices for OS Deployment Using SCCM

btucke31 — Thu, 04 Aug 2011 14:15:00 GMT

I have been on quite a few customer engagements where I have been asked to develop a process that will restrict the use of legacy media devices, such as DVD or UFD, to deploy OS images. Many of these customers come from legacy environments where they are used to building a unique image on DVD and must have a way to ensure an outdated image is no longer able to be deployed.

I will post later on how I was able to do this with a rare, non-networked, stand-alone media device, but for this post, I will focus on bootable media. Thankfully, SCCM makes this pretty easy for us.

Here, I have a selected my task sequence and have selected Create Task Sequence Media and will create Bootable Media.

On the Security page of the Task Sequence Media Wizard, you will notice that Create self-signed media certificate is checked by default with a 1-year expiration date. However, since this fictional customer renews there boot images once a quarter, I have set the expiration date to 3 months in the future. I could also set a HARD date that may not be the full 3 months, but will end when the customer chooses to archive this particular boot image.

It is also important to note, that if you have a PKI infrastructure, you can import your own certificate.

Once my media is created, you will notice the self-signed certificate now shows up under Site Settings>Certificates>Boot Media.

IMPORTANT: This is only visible/manageable from the site the bootable media is created from.

When I want to expire this boot media, I can highlight this certificate and choose ‘Block’. It is also important to note, that if the customer has a HARD date to expire all boot images, for example, on 09/01/2011, when a new one is released, we can select all of these certificates with a Start Date prior to 09/01/2011 and block them all at once.

The next time this bootable media device is run, it will fail.

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States