The Deployment Guys : Tips and Tricks

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

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

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

Keeping An Eye On USMT Progress v0.2

Daniel Oxley — Wed, 02 Sep 2009 18:41:00 GMT

Back in June I posted a script that I’d written that displays the progress of the USMT capture and recover phases in a neat HTML window off to one side of the screen; particularly useful if you are capturing/recovering large amounts of data because otherwise it looked like the USMT progress had hung due to the progress bar not moving along for quite some time.

While the script I wrote worked fine I was not 100% happy with it, mostly because it ate up too many CPU cycles, which could sometimes slow down the actual USMT progress; an effect that you would never want to happen! The problem was that there was no quick and easy way to parse the last few lines of a text file in VBScript without first reading in all the previous lines. This meant that as the log file grew, my script took longer and longer to run. So, I took it back to the drawing board, and reworked the innards of it to produce version 0.2!

This time, the script runs extremely quickly and it will barely register on the CPU, meaning that it shouldn’t slow anything else down. It still requires the same parameters to be passed to it when adding to the task sequence, which are detailed below. To add it to the task sequence, simply add the following Run Command Line action before the USMT capture or restore actions (or both):

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTCapture.prg”

cmd.exe /c “start /MIN cscript.exe Z:\Scripts\CUSTOM_USMT_Tracker.vbs C:\MININT\SMSOSD\OSDLOGS\USMTRestore.prg”

It also has one other very important dependency. You must download tail.exe from the Windows Resource Kit and place it in the Tools folder of the MDT deployment share, along with this script. You can get the tool here, it doesn’t matter that it is the 2003 version, I have tested it on Windows 7 and it works fine. If you don’t put tail.exe in the tools folder, then the script will fail.

The next update might take a while to get round to doing, but I want to remove the requirements for the command-line parameter, and have the script find the progress file on it’s own. Also, it would be good to display more information rather than just the current position in the progress, perhaps an extra line that informs what the current task is that is being run. Also, a few cosmetic changes wouldn't go amiss, but I am a techie not a graphic designer!

Attached to this post is the script file.

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

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.

Sharing some simple HTAs

Daniel Oxley — Thu, 26 Mar 2009 16:06:00 GMT

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

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

mshta.exe CUSTOM_Config_Network.hta

CUSTOM_Config_Network.hta

CUSTOM_Config_PWD.hta

CUSTOM_Config_Domain.hta

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

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

USMT Error Codes

DeploymentGuys — Wed, 14 Jan 2009 10:38:10 GMT

I was recently configuring the User State Migration Tool for a customer’s MDT server when, during the testing phase, the USMT began failing with an error code (‘return code’ or ‘rc’ when you read the MDT log files). I searched the USMT documentation on TechNet looking for the explanation of what the error code meant, only to discover that I could not find any information at all.

So, after a bit of asking around internally at Microsoft, I have managed to obtain the below list of error codes. I should point out though that this list of error codes is only for version 3.01 of the USMT, I don’t know if there are differences for any past or future versions of the tool.

Error code	Error text
0	USMT_SUCCESS
1	USMT_DISPLAY_HELP
2	USMT_MEMORY_FAIL
3	USMT_INVALID_PARAMETERS (Bad command line)
4	USMT_INVALID_STORE_LOCATION
5	USMT_NO_MORE_TOKEN
6	USMT_UNABLE_SET_SCRIPTFILES
7	USMT_UNABLE_GET_SCRIPTFILES (Can’t find XML file(s) specified in the command-line)
8	USMT_UNABLE_SET_STOREPATH
9	USMT_UNABLE_SET_USERS
10	USMT_UNABLE_FINDMIGUNITS
11	USMT_UNABLE_DOMIGRATION (A file is in use)
12	USMT_FAILED_MIGSTARTUP (Error in XML file ‘Bad XML’)
13	USMT_FAILED_SETMIGRATIONTYPE
14	USMT_FAILED_LOCALONLY
15	USMT_UNABLE_GET_WORKINGDIR
16	USMT_UNABLE_SETKEY
17	USMT_UNABLE_READKEY
18	USMT_TOO_LONG_KEYSTRING
19	USMT_UNABLE_SETCOMPRESSION
20	USMT_ERROR_INSUFFICIENT_RIGHTS
21	USMT_UNABLE_DELETE_STORE
22	USMT_UNABLE_SET_BENONADMIN
23	USMT_ERROR_INSUFFICIENT_STRINGBUFFER
24	USMT_ERROR_UNSUPPORTED_PLATFORM
25	USMT_ERROR_UNABLE_TOVERIFY_PLATFORM
26	USMT_UNABLE_SET_EFSMODE
27	USMT_INIT_ERROR
28	USMT_UNABLE_SET_LAC_LAE
29	USMT_ERROR_CORRUPTED_ENCRYPTED_STORE (Store is encrypted and no or invalid key has been specified)
30	USMT_ERROR_NO_INVALID_KEY (Store is only compressed but a key has been specified)
31	USMT_ERROR_CORRUPTED_NOTENCRYPTED_STORE
32	USMT_ERROR_LOGFILES_INSIDESTORE
33	USMT_INVALID_PLATFORM_FOR_TARGETXP
34	USMT_STORE_VALID_ONLY_FOR_XP
35	USMT_UNABLE_TO_READ_CONFIG_FILE
36	USMT_INVALID_CONFIG_FILE_FORMAT
37	USMT_ERROR_UNABLE_CREATE_LOGS
38	USMT_ERROR_USE_LAC
39	USMT_FAILED_TO_EXCLUDE_FOLDERS
40	USMT_ERROR_UNABLE_CREATE_PROGRESS_LOG
41	USMT_STATUS_CANCELLED

Most of the codes are pretty self-explanatory, but I have included some extra information for some of the more cryptic error messages.

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

User Experience for Configuration Manager Task Sequences - Part I

DeploymentGuys — Fri, 05 Dec 2008 02:24:00 GMT

Ever wanted to add your own user communication and interaction to a Configuration Manager task sequence? Below is an HTML Application (HTA) that has a user interface for the task sequence with information about the deployment, a button to cancel or pause the deployment and even a button for a desktop support person to get debug information. This first post will cover how to implement a User Experience HTA and how to send messages to it.

A Configuration Manager Task Sequence runs as SYSTEM and therefore anything launched from it will also run in the SYSTEM context . In WinPE, this will be visible to the user and you can simply launch the HTA from the task sequence. However, if you try to run a User Experience HTA from the task sequence, it will be invisible to your user in the Full OS. Fortunately, you can get around this with by launching your user experience application as a package that runs before the task sequence:

1. Download the sample HTA files provided in the link.

2. Create a package in Configuration manager with the files from (1) as the source files (in the exact directory structure, with CopyUE.bat in the root of the package and the UserExperience subfolder)

3. Create a program that runs the CopyUE.bat file included in the download. Use the following properties for the program

<Choose Allow users to interact with this program> and <Run the program as hidden>

4. Right click on the task sequence in Configuration Manager and choose Properties

5. On the Advanced tab choose "Run another program first" and browse to the Package/Program with the HTA

6. In your task sequence scripts add the following header:

                <script language="VBScript" src="OutputMessage.vbs"/>

7. In your script to output to the user experience screen use the following syntax in Vbscript:

                OutputMessage <severity>,<LeftColumnText>, <RightColumnText>

Where <severity> is either "Info", "Success, "Warning" or "Error"

               e.g. OutputMessage "Info", "Validating machine", "Please wait while your deployment begins"

8. Copy the OutputMessage.vbs file to the package where your script in (7) is located.

Feel free to try out the HTA and customize it as you please. Stay tuned for the future installments of this post that will talk about how to allow users to cancel a deployment, show debug information or perform other interactions.

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

Back to basics #3 – Branding the deployment and fixing the 0xc000000e problem

DeploymentGuys — Thu, 20 Nov 2008 11:57:00 GMT

Two more tips for the blog. Actually, one is a tip and the other is the solution to a common problem I see!

During the execution of a task sequence in MDT (normally while creating an image, or deploying one) the computer will display the Installation Progress window in the centre of the screen, on top of all others (see here and here for tips on how to move this window out the way). By default, this window says “IT Organization” in bold letters; something like this:

But wouldn’t it be good if you could change it to look like this?

By simply setting the variable _SMSTSOrgName in the customsettings.ini file, you can replace the text “IT Organization” with anything you like (as long as it is not longer than the width of the progress window!).

For example, the below customsettings.ini file will set the text to “Contoso – Windows Vista Deployment” in the progress window:

[Default]
OSInstall=Y
SkipProductKey=YES
SkipFinalSummary=NO
SkipComputerName=YES
SkipApplications=YES
Computername=%SerialNumber%
_SMSTSOrgName=Contoso – Windows Vista Deployment

If you wish to change the “Running: Lite Touch Installation” text on the window it is not so straightforward. You need to edit the line oEnvironment.Item("_SMSTSPackageName") = "Lite Touch Installation” (usually line number 599) in the script LiteTouch.wsf, replacing the text in the quotes with the text that you want to display. However, you should be aware that if you modify any of the out-of-the-box scripts that are provided with MDT you might no longer be eligible for any support from Microsoft; consult with your local Microsoft contact for more information.

These are one of the first questions I often get asked by customers who have existing MDT servers. While it might seem a rather basic and obvious configuration to some, a lot of people seem to have not found out how to change it and consequently believe that they have to maintain the default setting of “IT Organization”!

Recently, I was trying to use an external USB drive as a media deployment point to boot some computers in a laboratory. Nearly every machine booted fine, but a couple of them always failed with the same not-so-helpful error message:

Status: 0xc000000e
Info: An unexpected error has occurred

A rather poor quality photo of the error taken with the camera in a mobile phone!
Click on the picture to enlarge it.

Failure always occurred at the same point, just as the computer was about to boot WinPE from the RAM-disk, after loading the WIM file into it from the USB device. Initially, it was suspected that there was a problem with the WinPE WIM file that MDT had generated, but running the “Update” command on the deployment point a couple of times did not solve it. Then, memory was suspected, but this proved to be a functioning correctly as well. What was also strange was that the same files booted correctly on other computers. To make matters worse, some computers of the same make and model booted correctly, while other ‘identical’ machines did not??!?!?!

In the end, the problem was solved by upgrading the BIOS on the computer to the latest version published by the manufacturer. It seems that the manufacturer had supplied all new computers but with different BIOS versions, within the same shipment; once the BIOS was upgraded to the newer version the computer booted to WinPE correctly. A word of warning though, you should consult with the manufacturer/hardware supplier before performing any BIOS upgrades. And, don’t forget the adage: “If it ain’t broke, don’t fix it”. From experience, upgrading the BIOS on a machine that does not exhibit any problems may break something that you have already working.

Whilst I had seen the problem before, I never really was able to investigate it because the client always just gave me a new computer and took the old one away. So, thanks to a colleague of mine, David Marín, for solving this (after banging his head against the monitor for quite some time trying to work out what was going on!)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Porting Configuration Manager Task Sequences to a Different Environment

DeploymentGuys — Wed, 15 Oct 2008 23:27:00 GMT

Many scenarios arise in which you may want to port your task sequence from one environment to another. Common scenarios include promotion through Lab and QA environments and migration between disconnected hierarchies. Configuration Manager allows you to export task sequences into XML files as an out-of-the-box feature, however there are some things to remember when doing this.

Here is a checklist I like to follow:

1. Passwords: The exported task sequence will replace passwords in the task sequence for known steps before performing an export to ensure no clear-text passwords exist in the XML. This means any passwords in the "Apply Windows Settings" and "Join Domain" steps will replaced with ???????? . Remember to re-enter passwords when importing the task sequence or it will be set to 8 consecutive question marks.

2. Product Keys: Any product keys you enter will be blanked out in the "Apply Windows Settings" step. Remember to re-enter these for your XP task sequences.

3. Package IDs*: If the new Configuration Manager Site Server is not in the same hierarchy, you will have to re-associate all the steps in the task sequence to the packages in the new environment. You may also need to reassociate the boot image and any packages selected to run before the task sequence. Read below for a script to automate this process.

4. Inject Drivers in the Apply Driver Package step: If you have configured the task sequence with an Apply Driver Package step and chosen a boot-critical driver for Pre-Vista OSes, you will need to reselect this driver in the new environment.

5. Setup Windows and Config Manager step: If you are migrating to a new hierarchy, you will also want to see whether any of your Config Manager client properties need to be changed - such as reference to an FSP or SLP.

6. Domain references: You may have to also change any Join Domain steps you have in the Task Sequence to point to a new domain and use different credentials to perform the join.

7. MDT Database: If you are moving to a new hierarchy, the packageIDs in your MDT Database will still point to packageIDs in your previous environment. I am working on a script to help automate this and will post it once it is ready.

*Steps 3 can be a tedious process and often times can result in a manual configuration error. Luckily, we've created some powershell scripts to help make the process less manual:

Automated Scripts:

ExportTSRefs.ps1 - Exports the name, packageID and version of any referenced packages of a given task sequence to a RefIDsFile. This includes OS Packages, OS Install Packages, Driver Packages, Boot Image Packages and Software Packages. Note this only exports the refIDsFile not the packages or XML themselves.

Usage:

."ExportTSRefs.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -tsID <taskSequencePackageID>
For Example to Export the references of the CEN00001 TaskSequence Package:
."ExportTSRefs.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -tsID "CEN00001"
Running the script multiple times with different tsIDs and an existing refIDs file will append only unique packageIDs to the refIDs File.

ScrubTS.ps1 - Reads a RefIDsfile generated by the ExportTSRefs.ps1 script. It then scrubs all the Task Sequence XML files in the given folder for package IDs, looks up packages with the same name and version in the new environment and replaces the XML with the new package IDs. Note: packages in Configuration Manager and source files must already exist in the new environment.

Usage:

."ScrubTS.ps1" -sitecode <sitecode> -refIDsFile <filename> -delim <delimiter> -path <folderpath>
For Example to scrub the package IDs of all the XML files in the C:\ExportedTaskSequences folder
."ScrubTS.ps1" -sitecode "CEN" -refIDsFile "refIDs.txt" -delim "=" -path "C:\ExportedTaskSequences"

Remember the path is a folder name and the script will read all the .XML files in the folder. The new XML files will have the extension _scrubbed.XML.

For both scripts you can use any delimiter you like , I prefer "=" but feel free to experiment.

We are working on developing more scripts to add further automation around the promotion and migration process of task sequences. Stay tuned! As always try out the scripts and feel free to add any comments or contributions.

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

Placing your window on top during the WindowsPE stage

DeploymentGuys — Thu, 09 Oct 2008 21:41:56 GMT

Back in March, Richard Smith wrote a post about how to move the Task Sequence window to one side so that you can display a new window in the centre of the screen without it being covered up by the “Always On Top” Task Sequence window.

Richard’s solution works great, however if you try to use it during the WindowsPE stage of any task sequence it exhibits some rather peculiar behaviour. Basically, when launched in WindowsPE it tends to only work if you give the mouse a ‘waggle’ (yes, that is a technical term), i.e. the AutoIT code is executed but for some reason WindowsPE does not actually move the Task Sequence window until the mouse cursor is moved.

In order to make this work as expected in WindowsPE, you’ll need to bring the required application window to the top of the Z-order rather than move the Task Sequence window out of the way. The only downside to this is that it might not be immediately obvious to the user that a new window has appeared (particularly if it is quite small) as it will appear on top of the Task Sequence window, whereas Richards method does not have this problem.

In order to tweak Richard’s AutoIT code for WindowsPE, you’ll need to amend the following code:

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

To look like this:

If WinExists("MY WINDOW TITLE") Then
    WinSetOnTop("MY WINDOW TITLE", "", 1)
    WinActivate("MY WINDOW TITLE")
    Exit
Else
    Exit
EndIf

So, instead of moving the Task Sequence window aside, it is just looking for the specified window and then bringing it to the front.

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

Back to basics #1 – Locking the computer during deployment

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

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

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

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

rundll32 user32.dll,LockWorkStation

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

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

Logging All the Configuration Manager Task Sequence Variables

DeploymentGuys — Fri, 29 Aug 2008 18:31:00 GMT

When debugging a MDT based Configuration Manager Task Sequence, it is often helpful to know what certain built-in Configuration Manager variables are set to during a step in the task sequence. For instance, you may want to see if _SMSTSLastActionRetCode was equal to a certain value or perhaps which management point the client is using by checking _SMSTSMP. These variables and more are available in the Microsoft.SMS.TSEnvironment and you can easily log them using the script snippet below:

Dim sVar

Set osdV4 = CreateObject("Microsoft.SMS.TSEnvironment")

For Each sVar in osdv4.GetVariables()
oLogging.CreateEntry sVar & ":" & oEnvironment.Item(sVar), LogTypeInfo
Next

A list of the variables and their values can be found at http://technet.microsoft.com/en-us/library/bb632442.aspx .

The full ZTI-style script is included below. Add the script to the Microsoft Deployment Toolkit package and you can call this script as a task in the task sequence. The variables will be outputted to OutputTSVariables.log.

Try it out and feel free to comment.

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

Non-shrinking WIM files

DeploymentGuys — Tue, 26 Aug 2008 10:39:03 GMT

If you make regular changes to your WIM files with the use of the /MOUNTRW or /DELETE switches of IMAGEX, then you may have noticed that your WIM files do not shrink in size after you commit the changes back to the file. You could delete 500mb of data from an image file, only to see the file stay the same size, or even grow by a few megabytes. The reason for this is that the data in a WIM file are not actually removed from the file when deleted, rather the references to it's contents are simply removed; this is a bit like how deleting a file from your C: drive only deletes the reference to it in the allocation table rather than actually scrubbing all the files binary 1's and 0's from the disk sectors.

But don't worry, there is a solution to this which you can use to optimise the size of your WIM files! With the use of the /EXPORT switch of IMAGEX, you simply export the image from the WIM file into a new one, and you can even change the level of compression used. An example of the use of the command is:

ImageX.exe /export existing.wim X new.wim "My optimised WIM file" (where X is the number of the image file you want to export)

If you make regular manual edits to your existing WIM files then you might want to consider including the process of exporting the WIM to a new one into your work routine. However, it is probably not worth using export if you make infrequent or one off changes. One important thing to remember when using the export command is not to lose any of the /FLAGS settings during your export!

The question that clients always ask me about this subject is: why has Microsoft designed IMAGEX like this? The answer is logical, if not always obvious though at first glance. So, why does IMAGEX not optimise the file upon every commit action? Well, for a start, it would be very inefficient to have to do this each time you change the WIM file. Imagine that you add a 10kb file to a 12Gb WIM, then commit the changes. You'd have to wait while IMAGEX streams the 12Gb of data into a new WIM file, which would take a very long time.

Finally, I would not consider it good practice manually editing your WIM files on a regular basis. It would be better to use MDT to include any changes you need to make by incorporating them in future versions of your image files. Infrequent manual changes are fine, but if you are regularly having to manually edit your WIM files in order to include new files/registry keys etc. then you should be looking at automating this process in order to reduce this required manual administration. It will make work easier!

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.

How to Setup ConfigMgr 2007 on Windows Server 2008

DeploymentGuys — Thu, 07 Aug 2008 18:32:09 GMT

Installing ConfigMgr 2007 onto a Windows Server 2008 based server can be a challenge. Having recently been through the process for my own lab environment I thought I’d share the process in the hope that it will save you some time when you need to create this configuration. Before you begin you will need to gather the following components:

Windows Server 2008 Enterprise RTM (x86) and Licence Key
SQL Server 2005 and Licence Key
System Center Configuration Manager 2007 and Licence Key

You will also need to download the following components:

Microsoft WebDAV Extension for IIS 7.0 (x86) : http://www.microsoft.com/downloads/details.aspx?FamilyID=036269fa-0040-4ccd-ad3d-78da1ee132fb&DisplayLang=en
Windows Software Update Services 3.0 SP1: http://technet.microsoft.com/en-us/wsus/bb466190.aspx
SQL 2005 SP2: http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&DisplayLang=en
SQL critical update 934458: http://support.microsoft.com/kb/934458
ConfigMgr 2007 SP1: http://www.microsoft.com/downloads/details.aspx?familyid=5AAE62E8-4B7F-4AF7-BE01-AEFAA4BF059A&displaylang=en
ConfigMgr 2007 R2 - available from your Volume Licence web site

Step 1 – Install Windows Server 2008

Install Windows Server 2008 (x86) Enterprise on a machine with the following minimum specification:

Memory: 2GB
Hard Disk 2 x 70GB disks

This could be a physical machine or a virtual machine based on Virtual PC, Virtual Server or Hyper-V

Step 2 – Configure Windows Server 2008

Once the Windows Server 2008 installation has completed, log in as Administrator and carry out the following initial tasks:

1. Set a static IP address for the server

2. Unbind IPv6 from the network card (this is not a full fix for removing IPv6 - look out for a future post on this subject)

3. Enable the AD role as a new domain controller for your chosen domain (not required for ConfigMgr - it's just that all my lab machines are DCs)

Step 3 – Add Additional Windows Server 2008 Roles and Features

Additional Windows Server 2008 roles and features (through Control Panel > Programs and Features) are required to support the ConfigMgr 2007 installation:

1. Add the Windows Deployment Services (WDS) role with default settings (do not configure WDS as ConfigMgr will do that later)

2. Add the IIS role with the following settings (carry out the tasks in the order shown below):

Add ASP.Net Role. Accept defaults.

Add ASP (required for ConfigMgr Reporting Point to function - thanks to Jens Ole Kragh for pointing this out)

Add Windows Authentication

Add Static Content

Add IIS 6 Management Compatibility and all of the sub-components of it.

3. Add the Remote Differential Compression feature

4. Add the BITS Server Extensions feature

5. Install the Microsoft WebDAV Extension for IIS 7.0 (x86) (location for download listed at the beginning of this article)

Use the instructions at http://technet.microsoft.com/en-us/library/cc431377(TechNet.10).aspx to configure WebDav. You will need to follow Steps 4 and 5 in this document under the section “Install and Configure WebDAV”

____________________________________________________________________________________________________________________

WebDAV UPDATE: In some circumstances, WebDAV may not configure correctly when installed as per the instructions. This then causes the issue that clients cannot install via the push method. In this case follow these steps:

1. Open %windir%\system32\inetserv\config\applicationhost.config in your favourite text editor

2. Between the entries <add name=”optionsverbhandler…> and <add name=”staticfile…> (you will find these entries in the <handlers></handlers> section) add the following line

<add name="WebDAV" path="*" verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK" modules="WebDAVModule" resourceType="Unspecified" requireAccess="None" />

Your section should look like this:

<add name=”optionsverbhandler…...

<add name="WebDAV" path="*" verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK" modules="WebDAVModule" resourceType="Unspecified" requireAccess="None" />

<add name=”staticfile…....

3. Close the file and save it back as %windir%\system32\inetserv\config\applicationhost.config

I'm indebted to one of my MCS colleagues - John Husband for finding a fix for this issue and letting us know)

____________________________________________________________________________________________________________________

Step 3 – Add Additional Non Windows Server 2008 Components

Now that Windows Server 2008 is configured to install ConfigMgr 2007 we now have to add some additional software services for use by ConfigMgr 2007

1. Install Windows Software Update Services 3.0 SP1 32bit (location for download listed at the beginning of this article)

2. Install SQL 2005

3. Install SQL 2005 SP2 (location for download listed at the beginning of this article - carry out the tasks in the order shown below):

Stop the SQLServer service in preparation for SP2 installation. This is to avoid a system restart.

As suggested by SQL SP2 setup wizard, launch sqlprov

Run services.msc and re-start the SQL 2005 service.

Add a domain account to the SQL sysadmin role. This is unique requirement in Server 2008 environment.

4. Install SQL Critical Update 934458 (location for download listed at the beginning of this article)

Step 4 – Install ConfigMgr 2007

Now we are ready to install ConfigMgr 2007 – this is a two stage process to first install ConfigMgr 2007 RTM and then apply ConfigMgr 2007 SP1 – if you have access to the SP1 slipstreamed version of ConfigMgr 2007 then you can skip step 2 below.

1. Install ConfigMgr 2007

Extend the schema by running the \smssetup\bin\i386\extadsch utility. Run this under Enterprise Administrator credentials and review c:\extadsch.log for results.

Either use an Internet connection (for auto-download) or a pre-staged folder for setup update files required by ConfigMgr setup application.

2. Install ConfigMgr 2007 SP1 (location for download listed at the beginning of this article) and the ConfigMgr 2007 R2 components (if available via your licence agreement).

Either use Internet connection (for auto-download) or a pre-staged folder for setup update files required by ConfigMgr SP1 setup application.

NOTE: SP1 is the minimum requirement for running ConfigMgr 2007 on Windows Server 2008 - however ConfigMgr 2007 R2 will give you additional deployment features such as integration with Application Virtualization Management (APP-V), unknown computer support and multicast integration with Windows Deployment Services (Windows DS)

3. After installation, add the PXE Service Point and Reporting Point site system roles.

That's it - you are now ready to start using all the lovely features of ConfigMgr 2007 SP1 or ConfigMgr 2007 R2 based on a Windows Server 2008 platform - simple wasn't it? :-)

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

Task Sequence logic tricks using MDT variables

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

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

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

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

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

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

X86 – Architecture equals x86

Client - IsServerOS equals FALSE

Windows XP – OSVersion equals XP

Vista - OSVersion equals Vista

Server – IsServerOS equals TRUE

2003 - OSVersion equals 2003

RTM - SELECT * FROM Win32_OperatingSystem WHERE CSDVersion = ""

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

2008 - OSVersion equals 2008

X64 - Architecture equals x64

Client - Etc etc.

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

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