First published on TechNet on Sep 16, 2013
For Part II, please see the following:
Getting Started with Microsoft Deployment Toolkit for Windows Server 2012 R2 and Windows 8.1: Part ...
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Mark recently wrote a birthday post for Windows NT . It was even picked up by Mary Jo Foley over on ZDNet . We’re all in awe of Mark’s newfound stardom. However, all stargazing aside, in Mark’s post, he mentioned two very important dates for end of life for Windows XP and Windows 2003 Server.
So now that upgrading is on your radar (if it wasn’t already before), where do you go from here?
Well, there is System Center Configuration Manager which is a true enterprise Zero-Touch deployment solution. However, what if you don’t have the budget or the infrastructure to support System Center Configuration Manager?
Well, that’s where Microsoft Deployment Toolkit (MDT) comes into play. Mark has been switching between flogging me daily and begging for me to start this series for the past year. I won’t say which was more effective, but one of them was, so here goes.
WARNING: You're in for a LONG post. Make sure your data plans can handle it before reading further. :)
First a couple key points about MDT
Key Point #1:
It is a free “Solution Accelerator” which basically means a bunch of scripts on the back-end and organized on the front-end with a GUI interface. The goal of a Solution Accelerator is to make your life easier. To quote the Microsoft Solution Accelerator homepage:
“Use the Microsoft Deployment Toolkit (MDT) to accelerate and automate deployments of Windows 8, Windows Server 2012, Windows 7, Office 2010, and Windows Server 2008 R2.”
MDT can be downloaded here .
Key Point #2:
It can be fully automated if you want or prompt for key items like server name. It’s not Zero-Touch like System Center Configuration Manager. It’s what we call Lite-Touch. So if it can be fully automated, why is it still Lite-Touch? It’s because MDT is a pull deployment method, not a push deployment method. Instead of advertising the deployment through System Center, someone has to initiate the deployment. Whether that’s through PXE boot, by booting from USB or other external media, booting from DVD/ISO, or connecting to a deployment share; it is entirely up to you.
Key Point #3:
MDT can be integrated with System Center Configuration Manager should you implement ConfigMgr in the future. In fact, some enterprises integrate MDT with ConfigMgr to prompt for items like server name because as previously mentioned, ConfigMgr is Zero-Touch. That means with its native capability, it does not have the ability to prompt for anything…unless you integrate MDT.
So let’s get you started
If you’re installing MDT on a current operating system (read 2008 or later), the only two things you really need to download are:
- MDT (well, duh)
- Windows 8 Assessment and Deployment Kit (ADK) OR Windows Automated Installation Kit (AIK)
Let’s talk about the Windows ADK vs. the Windows AIK for a minute.
I highly recommend going with the Windows ADK. It has a number of performance enhancements that will speed up your deployments, even for Windows 7 and Windows Server 2008 R2.
But there’s one gotcha. It doesn’t support Windows Server 2003 or XP. Hopefully you’re not still deploying these operating systems and if you are, you’re making it as difficult as possible for the person insisting on them. But if you absolutely must, then you need to use the Windows AIK or better yet, create a separate deployment share for legacy deployments like Windows XP and Windows Server 2003 so that it doesn’t slow down deployment of the newer operating systems.
The Windows ADK is another free download and can be downloaded here .
You’ll also need the following:
- A machine on which to install MDT
- Virtual machine for deploying and capturing a custom image and for testing of the MDT deployment process. This virtual is not for installing MDT, but for testing out your deployment process and for capturing a custom image.
- A couple physical machines that are an example of the hardware you deploy to for testing purposes
- Source ISOs or DVDs of the operating systems you mean to deploy
- Source files for any applications you would like to deploy as part of your build process
- Drivers for physical hardware, most importantly any storage drivers or NIC drivers that are not built-in to the operating system
Some other considerations:
- Ideally, you want to setup the MDT share on a server class operating system and hardware for obvious reasons. You’re going to potentially have many connections to the MDT share for your deployments.
- You want to make sure you have enough storage. MDT itself doesn't take up much space (about 1GB) for the program files, but it does require at least 4GB free space required on the drive containing the %TEMP% folder which is used when creating ISOs or Media deployments. But you also need to consider the size of each operating system you plan to deploy (custom and default), any applications you plan to deploy, packages, language packs, etc. Additionally, if you’ll be using the User State Migration Tool (USMT) for clients and storing the data on the MDT share, you’ll need to account for space for that too.
Let’s start setting up MDT!
I’m assuming I don’t need to walk you through the MDT or ADK installation. Just double-click and walk through the wizard. Once you have it installed, open up Deployment Workbench. It will look something like this:
There are a couple things I would like to call your attention to under the Information Center.
1) There’s a nice high-level overview diagram of the MDT setup and deployment process:
2) The Documentation section has links to a lot of good documentation including the MDT .chm help files which are a great source of information on how to do various tasks, how to automate various things, and custom various things. I use this .chm help file all the time. The documentation found under the Deployment Process section will be especially helpful as you build out your deployment solution.
Creating the MDT Deployment Share
This is simple. Right-click on Deployment Shares and walk through the wizard.
We prompt for the following during the deployment share creation process:
1) Path to the share – if you want to place the deployment share on a drive other than C:\, this is where you do it.
2) Share name – this is where we specify the share name. Notice that by default it is a hidden admin share. You could potentially be typing this a lot. So I like to keep it short and generally lessen the default name of DeploymentShare$ to something shorter like Deploy$.
3) Descriptive name for the share – If you will have separate shares for Test and Production or Server and Client, you might want to label the share accordingly.
4) Options – the options seen here start customizing which wizards we will and will not see during the MDT LiteTouch Wizard. You can change these later on the Rules tab of your deployment share (which is also called the customsettings.ini).
With my customers, for their server deployments, they often like to prompt for the local Administrator password and not prompt for computer backup and BitLocker. So we go ahead and change it here to something like this:
The rest is just the Summary, Progress, and Confirmation. On the Confirmation screen, we have an option to View Script. The View Script option opens notepad with the PowerShell script used to create the deployment share using the options we specified.
MDT management tasks like creating shares, updating linked deployment points, creating task sequences, etc. can all be automated using PowerShell. However, most of the underlying deployment mechanisms still rely on VBScripts at this time.
So now our deployment share is created and if you expand it, you’ll see something like this:
Isn’t it pretty? Just kidding. I’m not THAT sappy. :)
So let’s work from the top down.
If you right-click on your deployment share, you’ll notice the following options:
We need to update our Deployment Share, but let’s not do so just yet.
If you select Properties, you’re presented with the following:
Much of this information is based on what we specified during the Wizard when creating our deployment share. If you need to change anything, you can do so on these tabs.
Deployment Share Rules
The Rules tab is used to configure the rules or configuration settings for our deployment. The actual rules and settings are stored in the customsettings.ini file on our deployment share. These rules are unique to each deployment share and media deployment. Looking at this tab, any options we configured during the creation of our deployment share are specified. Additionally, we can add additional rules and countless other configuration settings here. The Skip settings are directly associated with the options we configured during the creation of our deployment share and are used to skip various wizard pages during the Lite Touch deployment wizard:
There’s TONS you can do with the Rules which we’ll get into in a later post, but I personally like to add all the possible wizard pages that potentially show during the Litetouch Deployment Wizard. I can then toggle them to yes or no as desired. I’ve included them below in case you too would like to do this.
' // Wizard Pages
SkipWizard=NO
SkipAppsOnUpgrade=NO
SkipDeploymentType=NO
SkipComputerName=NO
SkipDomainMembership=NO
SkipUserData=NO
SkipComputerBackup=NO
SkipTaskSequence=NO
SkipProductKey=NO
SkipPackageDisplay=NO
SkipLocaleSelection=NO
SkipTimeZone=NO
SkipApplications=NO
SkipAdminPassword=NO
SkipCapture=NO
SkipBitLocker=NO
SkipSummary=NO
SkipFinalSummary=NO
SkipCredentials=NO
SkipRoles=NO
SkipBDDWelcome=NO
Some of these are going to apply only to client deployment and some of these are going to apply only to servers. For example, SkipUserData is a client rule relating to USMT. SkipRoles is a server rule relating to roles and features on the server. I have these all set to no at the beginning until I determine which wizard pages I wish to automate. You can search the MDT .chm file on any of settings to find out what information we need to provide in order to automate that specific wizard page. For example, if you SkipLocaleSelection, you need to also specify SkipTimeZone and then provide the following information (called Properties) on the Rules tab:
KeyboardLocale
UserLocale
UILanguage
TimeZoneName
Here’s an example of what this would look like for the U.S. keyboard layout and Central Standard time zone:
TimeZoneName=Central Standard Time
UILanguage=en-US
UserLocale=en-US
Systemlocale=en-US
KeyboardLocale=0409:00000409
Once filling out these Properties, you can set SkipTimeZone and SkipLocaleSelection to YES. Additionally, if you would like to set these as the defaults, but still display the Wizard page which would then give the user running the deployment an option of changing these settings, you can leave SkipTimeZone and SkipLocaleSelection to NO and by providing these settings, you simply set the defaults.
Here’s what the Wizard page looks like BEFORE:
By setting up these rules and still displaying this page, this is what it it looks like after:
So alright. It’s not a HUGE change. After all, we default to English language and US keyboard anyway, but has anyone else ever been annoyed that we always default to Pacific Time??? Sheesh. Randomize it or something. Give us other time regions some love once in a while.
Getting back on topic…
Here’s a table from the MDT .chm file that lists the available wizard pages and which properties need to be configured in order to skip each wizard page:
|
Skip this wizard page |
Using this property |
Configure these properties |
|
Welcome |
SkipBDDWelcome |
|
|
Specify credentials for connecting to network shares |
Skipped by providing properties in next column |
|
|
Task Sequence |
SkipTaskSequence |
|
|
Computer Details |
SkipComputerName, SkipDomainMembership |
–or–
|
|
User Data |
SkipUserData |
|
|
Move Data and Settings |
SkipUserData |
|
|
User Data (Restore) |
SkipUserData |
|
|
Computer Backup |
SkipComputerBackup |
|
|
Product Key |
SkipProductKey |
Or
Or
|
|
Language Packs |
SkipPackageDisplay |
|
|
Locale and Time |
SkipLocaleSelection, SkipTimeZone |
|
|
Roles and Features |
SkipRoles |
|
|
Applications |
SkipApplications |
|
|
Administrator Password |
SkipAdminPassword |
|
|
Local Administrators |
SkipAdminAccounts |
|
|
Capture Image |
SkipCapture |
|
|
Bitlocker |
SkipBitLocker |
|
|
Ready to begin |
SkipSummary |
– No property required |
|
Operating system deployment |
SkipFinalSummary |
– No property required |
|
Operating system deployment did |
SkipFinalSummary |
– No property required |
Bootstrap.ini
Now you may noticed the button to edit the bootstrap.ini on the Rules tab. If you did miss it, I’ll highlight it here:
This tells us where to connect to when booting from the MDT Lite Touch boot media:
By default, all it contains is the share name as seen above, but you can also supply credentials here, if you’re so inclined. My customers typically elect not to for obvious reasons.
Deployment Share Windows PE Settings
The Windows PE tab allows us to modify the Lite Touch Boot Image settings. For those of you new to MDT, our Lite Touch Boot Image is what we boot from to kick off the deployment. You can initiate a deployment via the following methods:
- Boot from Lite Touch Boot image on USB/external drive
- Boot from Lite Touch ISO
- Boot from Lite Touch DVD
- PXE boot from Lite Touch boot image on a Windows Deployment Services (WDS) server
Additionally, you also have the option of connecting directly to the MDT Deployment share from within an existing version of Windows and kicking off Lite Touch.
A couple of important notes.
- You can deploy x64 bit operating systems using an x86 boot image, but not vice versa.
- If you’re not deploying any 32-bit operating systems, you can elect to not generate the 32-bit version of the ISO and vice versa. This saves you some time when updating your deployment share and a bit of space. Simply uncheck the box to generate whichever ISO you do not wish to create.
- There are separate settings for the 32-bit vs. 64-bit versions. By default, we show the 32-bit version. If you would like to modify the 64-bit version, click on the drop down:
- You can add additional files, scripts, etc. to the boot image for use within the Lite Touch Windows PE session…scripts to reinitialize the network, re-launch Litetouch, reboot, shutdown, etc. are very popular.
- You can also modify the Lite Touch bootable ISO name and description. I recommend using some form of versioning, especially if you’re distributing this out.
- You can customize the background. Lots of my customers get really silly with this. Have fun!
- Occasionally, you’ll run across a network card that requires a special NIC driver just for Windows PE. If you’re running into errors such as the following, make sure you’ve added a driver to MDT Out-Of-Box drivers. If that still doesn’t work, then check with the vendor for a driver specific for use with WinPE.
Monitoring
The last tab is to enabling monitoring. We’ll talk about this in a later post.
Update Deployment Share
Now that we have our Lite Touch boot image customized the way that we’d like, right-click on your deployment share, select Update Deployment Share, and walk through the wizard.
This will take some time, but it gives you a good running status of what it’s updating along the way.
Since this is our first time, it’s essentially creating our Lite Touch boot images for the first time as well as the ISOs.
Up until this point, if you glanced at the contents of your deployment share, you wouldn’t have seen much more than a folder structure. If you looked through any of the folders, they’re mostly empty.
However, after we have finished updating, if you look in the MDT deployment share boot directory, you’ll notice we now have the following:
The ISO files are what we’re after. These can be burned to a CD or mounted to a virtual machine. Additionally, you could copy the contents of the ISO to a properly formatted USB key and boot from that (see Create Bootable Devices from MDT Boot Images in the MDT help file). Lastly, you could add the .wim file to a WDS server and PXE boot.
You can now boot to Lite Touch, but until we have at least added an operating system, and created a Task Sequence, we won’t have anything to deployment. So let’s start working on that.
MDT Workbench Folder Structure
Before I start adding anything to MDT, I like to setup my folder structure. This is important for use with Selection Profiles, which we’ll discuss later.
One of the things you’ll realize, if you haven’t already, is that deployment is largely based on preference. I personally like things very organized and very controlled. So my folder structure is very organized and very controlled. It’s easy to create folders (right-click, new folder) and it only takes a few minutes of your time, but could save lots of headache down the road.
Here’s an example of the folder structure for one of my deployment shares:
A good folder structure is important for more reasons than just keeping you organized, including the following:
- Controlling which drivers are used by WinPE/Lite Touch boot image creation
- Controlling which drivers are used during your Task Sequence (and avoiding potential driver conflicts)
- Controlling what is a part of your Media deployments
- Controlling what is copied to linked deployment shares
I suspect I’ll dive into avoiding driver conflicts, smart uses of selection profiles, etc. in a later post. No sense in this initial blog being 50 pages long. *grins*
FINALLY, it’s time to start populating MDT
It’s fairly obvious where you add the various components that are part of your deployment process. Just right-click and select New Application, Import Operating System, etc. and walk through the wizard.
A couple notes:
- Applications must install silently. Any prompts will or reboots initiated by the application will break the deployment process. Best practice is to take the command line you plan to use with MDT and test it out from a command prompt on a test machine prior to adding it to MDT.
- You need a minimum of one operating system added, naturally.
- If you do not like the name given, right-click and rename it. I do. For example, I rename "Windows Server 2012 SERVERDATACENTER in Windows Server 2012 SERVERSTANDARDCORE x64 install.wim " to "WinServer2012 STD Base" (without the quotes). See how much shorter that is?
- Save yourself some space and delete any SKUs you do not plan to deploy.
- You need at least the network driver and storage driver for the hardware you plan to deploy to. Many will be built-in, but some will not be. This 'RAID Controller drivers' here.
- Packages refers to Microsoft language packs and Microsoft updates. It does not refer to packages you create for applications.
- Applications belong in the Applications node.
MDT Task Sequence
MDT has many built-in Task Sequences. Think of these like your installation instructions for a specific operating system and SKU (Enterprise, Standard, Core, etc.). These combined with your more global settings in the Rules tab automate and customize your deployment.
Let’s walk through the Task Sequence creation process for a minute.
When you right-click and select New Task Sequence, a wizard pops up like on the other nodes.
The Task Sequence ID is a unique ID that can be alpha or numeric, but it must be unique.
The Task sequence name is the name that appears when you are prompted to select a Task Sequence during the Lite Touch Deployment Wizard. You want this to be descriptive to help the user select the appropriate Task Sequence (if you’re giving them that ability). Comments also appear too, if you so desire.
After you click next, you’ll be prompted to select the Task Sequence. There are many, but they’re fairly self-explanatory:
Next, you’ll be prompted to select the operating system. So yes, the operating system needs to be added to Workbench prior to create the Task Sequence.
I keep the default not specify a Product Key as I use KMS or Active Directory Based Activation for volume activation .
The OS Settings can be customized for your organization.
For the Admin Password page, you can either specify one here or you can not to specify an Administrator password at this time and we’ll prompt for it during the Lite Touch Deployment Wizard:
Once you click next and Finish, you’ll have a nice new Task Sequence waiting for you.
To customize the Task Sequence further, right-click, select Properties, and select the Task Sequence tab.
The possibilities are endless which will be the topic of a later blog, but here’s a quick customization that almost everyone does as an example.
Under Preinstall --> New Computer --> Format and Partition Disk, by default, it is set to the following:
This is easily modified per your build standards.
If you highlight OSDisk (Primary) and click on the icon that looks like a hand holding a sheet of paper, it will bring up the partition properties screen seen below.
If you do not want your C:\ partition using 100% of the disk, you can change that here. Most use a specific size, say 60GB. You can also change the partition name if you’d like, but leave the variable alone (unless you know what you’re doing) as MDT references this in later tasks.
So what do you do with the remaining free space? Well, create another partition. Click on the yellow asterisk to do this. You can choose a specific size or do what most do and use 100% of the remaining free space as shown below:
So now I have two partitions.
Notice that Create extra ‘Active’ partition option shown above? This directly correlates to the “extra” system partition created by default on Windows 7 and Windows Server 2008 R2 and later.
This partition is a BitLocker requirement, is not encrypted, and holds the operating system files necessary to boot your system. If you don’t plan on using BitLocker (and don’t plan to in the future), you can uncheck this box and we won’t create it.
This is just one example of countless possibilities. I expect to discuss other customizations during later posts.
Kicking off a deployment
Now that we have the bare necessities added to MDT, let’s kick off a deployment and see what that looks like. Prior to deploying to any hardware, I test my deployments in a virtual machine. I also capture any custom images from a virtual machine. It’s cleaner.
To kick off my “test” deployment, I attached my LiteTouchPE_x64.iso (you know, the one from the deployment share boot directory) and started the VM. Here’s what it looks like by default with no modifications. There are eight wizard pages in all (if you count the credential prompt).
1st Screen: MDT Welcome Screen
2nd Screen: Prompt for credentials to connect to MDT deployment share
3rd Screen: Select Task Sequence
4th Screen: Prompt for Computer Details
5th Screen: Prompt for Locale and Time Zone
6th screen: Prompt for Administrator Password. This will be the password of the local administrator’s account post-deployment.
7th Screen: Prompt to Capture an Image
8th Screen: Summary. After clicking begin on this screen, you can walk away and come back. The operating system will be fully deployed and waiting for you.
Remember
All of these wizard pages can be automated. Also, you may have additional wizard pages depending on how you configure the rules for your deployment share. Additionally, you can make your own wizard pages as well using the MDT Wizard Editor which is free for download from http://mdtwizardeditor.codeplex.com/
What I tell my customers
1) Start with the basics. Setup MDT and don’t go crazy with the customization when you are first getting started until you have the process down and the deploying working as expected.
2) Have your build process and operating system standards handy.
3) Boot to Lite Touch, see what you want to customize or automate, and go from there.
4) It’s not a difficult process. It does require a bit of legwork in the beginning, but will save you loads of time in the future.
MDT “Jumpstart” Engagement
There’s a thing I do for some of my customers. I come onsite, deliver a day and a half of MDT training, and then for the next day and a half; I work with them on setting up MDT in their environment per their build process. I call this my MDT “Jumpstart”, but my colleagues often refer to it as a boot camp as it is a lot of work crammed into three days. I’ve done a dozen of these over the past year, mainly for server deployments, but this can apply to clients as well. Typically, during this time period, we’re able to do the following:
- Get MDT setup (including everything mentioned in this blog and more)
- Customize the Task Sequence and Rules to some degree to meet the requirements of the organization
- Capture an image
- Test deploying that image to several physical servers and/or clients
We generally only have time to customize one image deployment (Windows Server 2012 for example), but my goal is that with the training, and hands on of doing the first one; customizing additional images is a cake walk.
If you’re interested in this sort of “jumpstart” and you are a Premier customer, contact your TAM and ask for me. If I’m available, I’ll be happy to come out. Otherwise, I’ll make sure you get someone just as worthy.
;)
Charity “Deploy happy” Shelbourne