The Deployment Guys : BDD 2007

Back to basics #1 – Locking the computer during deployment

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

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

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

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

rundll32 user32.dll,LockWorkStation

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

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

Documenting Your Task Sequences Automagically

DeploymentGuys — Sun, 17 Aug 2008 08:53:00 GMT

Often times, after creating an MDT or SCCM task sequence, you need to document it for yourself or your customers. Usually, this involves creating a table with the groups and steps, extracting their descriptions, identifying conditions and denoting the step actions and variables and then having format it all nicely and with indents denoting hierarchy. All of this information is usually already in the XML of the task sequence and all you're really doing is formatting. You can automatically format XML documents by using an XSL transform with the right logic. In order to do this:

1. Copy the attached file at the bottom of the post to the same folder as your task sequence.

2. Open your task sequence in your favourite text editor.

3. After the first line which should look something like this:

<?xml version="1.0"?> or <?xml version="1.0" encoding="utf-8"?>

enter the following as the second line:

<?xml-stylesheet type="text/xsl" href="tsDocumentorv1.xsl"?>

4. Save your task sequence file and open it in Internet Explorer. Presto! The XSL takes care of formatting, indents and sizing.

Your Task Sequence should look like this:

You can even change the styles of groups and steps easily.

1. Open up the tsDocumentorv1.xsl file

2. Edit the following section:

<STYLE TYPE="text/css">
TD.group { background-color:teal;color:white }
TD.step { background-color:beige }
</STYLE>

Change the colours or any other css properties you choose!

The XSL should work with task sequences created with BDD 2007, MDT 2008 and SCCM 2007.

Please try it out and post comments.

This post was contributed by Aly Shivji a consultant with Microsoft Services - U.S. East Region. Credit to Michael Murgolo for initial idea and effort.

Useful Script Number 6 - Pausing the Task Sequence

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

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

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

Dim strTime, strSName, IntTime

ZTIProcess=1

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

strSName=oUtility.ScriptName

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

strTime = oUtility.Arguments("Time")

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

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

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

IntTime = strTime * 1000
End if

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

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

wscript.sleep intTime

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

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

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

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

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

Useful Script Number 4 - Silent Installation of Windows AIK 1.1

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

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

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

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

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

#include <Constants.au3>

;Set variables and constants
Dim $Item
Dim $sCmd

;Check the CPU architecture
$Item = @ProcessorArch

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

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

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

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

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

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

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

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

Exit

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

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

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

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

Getting help when you are really stuck

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

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

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

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

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

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

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

BDD 2007 Lite Touch and SMS 2003 Zero Touch Video Walkthroughs

DeploymentGuys — Thu, 03 Apr 2008 14:51:00 GMT

I have had a number of emails and comments requesting the location for the video walkthroughs featuring BDD 2007 Lite Touch and BDD 2007/SMS 2003 Zero Touch Setup, so I have re-posted them to the Deployment Guys SkyDrive for download:

The BDD 2007 Lite Touch Video Walkthrough download pack (23.5 MB) contains the following videos - view them in the order they are listed to see the overall process.

1. Lite Touch Configuration.wmv
2. Lite Touch Office 2007 Configuration.wmv
3. Lite Touch Client NEW COMPUTER.wmv
4. Lite Touch Client REFRESH COMPUTER.wmv

View all of these walkthroughs on-line at Deployment Forum!

The BDD 2007 Zero Touch Video Walkthrough download pack (22.3 MB) contains the following videos - view them in the order they are listed to see the overall process.

1. Zero Touch Configuration.wmv
2. Zero Touch Client NEW COMPUTER.wmv
3. Zero Touch Client REFRESH COMPUTER.wmv

View all of these walkthroughs on-line at Deployment Forum!

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

"Up-ping" the uptime of your Lite-Touch server

DeploymentGuys — Mon, 31 Mar 2008 13:10:00 GMT

I like the lite-touch installation (LTI) feature of MDT, it think it's great and is very impressive as it allows clients to easily see the benefit that they will gain by using MDT to create and deploy their images. I can go on-site with a customer to demo the product and have a basic MDT server configured to deploy Windows Vista and Office 2007 (both with the most basic of configurations) over the network in their laboratory, all in one day. Admittedly, the setup won't do much else because it lacks all the details but, as a demo, it works well. However, one thing that LTI does not offer is 'high-availability'; something that Systems Center Configuration Manager excels at.

In one of my previous posts I wrote about using DNS to create 'distribution points'-like behaviour in LTI scenarios. That post got quite a bit of feedback, so with this post I want to 'steal' another Configuration Manager feature so that it can be applied to a LTI scenario, namely, making your MDT server highly available. With this post you will be able to improve the reliability of your deployments by ensuring that your single point of failure (your MDT server) is always available, simply by clustering your MDT distribution share. As before, I once again recommend Systems Center Configuration Manager as the product of choice if you need a highly-available platform for installing your images as it really is the best option available; the content offered in this post could never replace the functionality offered by Systems Center Configuration Manager.

Windows clustering has been around for many years now, and most people understand how it works; the basic concept is shown in the image below. An active server provides services to the network with a passive server in standby waiting to take over from the active server if it ever stops responding. The change-over, or more correctly called: failover, happens very quick so most people would not even notice that a server has failed. With each version of the Windows Server operating system Microsoft has improved the cluster service, so I will try and stay as generic as possible with this post.

Figure1: a generic diagram showing a typical cluster configuration

With this in mind, an excellent way to improve the availability of your MDT server is to copy the distribution$ folder onto a cluster! All your client computers would then connect to the virtual name of the cluster and use the distribution point for the installation of your operating system image, rather than connect to the MDT server. The only change that you would need to make would be to edit the bootstrap.ini file from your MDT configuration in order to include the virtual name of the cluster rather than the hostname of the MDT server; you'll need to make this change manually because MDT will put it's own hostname there by default. Note that even if you installed MDT onto one of the nodes of the cluster, it would still place the hostname of that node into the bootstrap.ini file rather than the cluster virtual name. This is because MDT is not a cluster aware application.

Example of the bootstrap.ini file for use on a cluster:

[Settings]
Priority=Default

[Default]
DeployRoot=\\MYVIRTUALCLUSTER\Distribution$

You will need to create a cluster shared folder resource that shares the folder as "distribution$", without this part it won't work! Also, you will need to manually synchronise any changes you make on the MDT server with the files on the cluster, MDT won't do this for you.

Finally, one important thing to bear in mind is that, in the event of a failover, any existing deployments *might* fail depending on where they are in the process and what they were doing at the time of failover. If a client computer is applying the WIM image when the active server fails, then the process will also fail. If however, the active server fails over during a point in the deployment process when a client computer was not actually using the deployment point then you may find that the process will continue seamlessly, although your mileage will vary with this as it really is an unknown due to various factors in play during failover.

In a follow-up post I will explain how to work with the files on the cluster directly from MDT, so that MDT can update the files onto the clusters shared storage without the need for you to copy the files over manually when you make changes. Stay tuned!

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

Useful Script Number 2 - Move the Task Sequence Window

DeploymentGuys — Wed, 19 Mar 2008 13:33:00 GMT

Have you ever created a build and had to pop up a message to the user/technician? - or had to start an HTA application to request some kind of user input during the build or deployment process? If you have then you will know that the task sequence window sits centre screen and everything else pops up behind. This is because the task sequence windows is fixed to the top of the Z-order so that no other window can overlap it...

Recently I had to create an DVD based deployment for a customer where I wrote an HTA application that prompted the user to switch DVDs. I hit this issue where my app was popping up behind the task sequence window and users were missing the prompt - so I set about developing a solution - and the solution I came up with was to move the task sequence window to the top left corner of the screen every time the task sequence starts - I soon found that it wasn't as simple as it initially sounded....

I set about creating a script in Autoit (http://www.autoitscript.com/) to move the window to the correct co-ordinates based on current screen resolution. I like to use Autoit for window manipulation tasks as it has a whole raft of inbuilt functions for automating desktop tasks - which usually makes it easier and quicker than writing the equivalent in VB script.

The Autoit code is listed below:

#NoTrayIcon

;zCFG-MoveTaskWindow
;Version 2.0 March 2008
;Reruns itself and returns - only works when compiled

If $CmdLine[0] = 0 Then
    ; Rerun ourself and let this copy return to the task sequencer
    Run('"' & @AutoItExe & '" rerun')
    Exit
EndIf

Sleep(5000)        ; Time for the first script to return
If WinExists("Systems Management Server") Then
    $size = WinGetPos("Systems Management Server")
    Mousemove($size[0]+50, $size[1]+50)
    MouseClick("left")
    WinMove("Systems Management Server", "", 0, 0)
    Exit
Else
    Exit
EndIf

The first line #NoTrayIcon stops the Autoit icon appearing in the system tray when the script runs. The next section:

If $CmdLine[0] = 0 Then
    ; Rerun ourself and let this copy return to the task sequencer
    Run('"' & @AutoItExe & '" rerun')
    Exit
EndIf

configures the script to re-start itself after returning control to the task sequencer (i will explain why later in the post) before running the code to carry out the window move - having access to Autoit creator and fellow UK MCS consultant Jon Bennett really helps in these situations :-) and Jon came up with this re-spawning code.

The final section:

causes the script to pause for 5 seconds before looking for the existence of the task sequence window (using the Autoit function WinExists). The title of the windows is Systems Management Server, so if found the script gets its position (using the Autoit function WinGetPos). The script then move the mouse to the location of the window +50 pixels on each axis so that the mouse pointer is inside the task sequence window - it then clicks (Autoit function MouseClick) to select the window before the WinMove function moves it to the top left of the screen

The reason for re-spawning the script is to return control to the task sequence, which in turn means that the compiled executable that Autoit creates from this script can be added to the task sequencer in the same way that any other script is run:

The script only works when it is compiled so i have added the script (.au3 file) and the compiled Autoit executable (.exe) to the download location below:

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