In the first part of this three-part series, the basics of the Microsoft Deployment Toolkit were established: how to download and install it and how to populate the workbench with applications, operating systems and even special drivers that need to be installed on various machines in the network.
Part 2 described how to create a Windows Imaging Format file using MDT 2010. The WIM file format is required to put an operating system or application image in Microsoft Deployment Toolkit (MDT). That is, you can't put an ISO image in the workbench folders -- only WIM files will work. In MDT 2010, this is a fairly straightforward process. It's important to see how this all fits together before we get into configuration details.
Anyone who has been deploying Windows for long is aware of Sysprep. Think of MDT as Sysprep on steroids. Sysprep used an auto-answer file that you could modify and add detail to -- such as pointing to specific driver files or adding credentials -- so that when the target machine ran the sysprepped image, the answers to the setup questions were answered. If you forgot to include an answer to a question, the setup would prompt the user, so the admin could make it fully automated or allow the user to enter data. MDT implementation is very similar, but there are more capabilities.
Opening the MDT Deployment Workbench shows deployment shares defined, and each one has a set of configuration folders as shown in Figure 1. In this example, operating system and application WIM files, out-of-box drivers, etc. have been defined. These are required to proceed with the deployment.
In addition, one or more "Task Sequences" must be defined. This is a set of instructions that tells MDT which tasks will be executed, including installing an OS or app. It's fairly straightforward if you follow a few tips:
- Right-click Task Sequences and select New.
- General Settings --
- Task Sequence ID -- Make it short and meaningful because you will use this later. The name can be more descriptive.
- Select Template -- These are standard task sequences; choose one that fits your need. Note that some templates do not have the ability to install OS and have other restrictions, so it may take some experimentation to find the right one. For instance, the LiteTouchOEMSequence won't install the OS. If you select this option, the wizard will skip the OS configuration screens.
- In the Select OS option, you will see the OS WIM files populated in the Operating Systems folder.
- Fill in the remaining questions. Add more templates as needed.
Under the Advanced Configuration node, a database can be configured to hold information that can be used to apply applications, packages, operating systems and drivers to various categories of computers. To enable this feature, a database must be configured.
- Right-click on the Database node and select New.
- As shown in Figure 1, complete the database information. Note that a SQL database and instance must be available for this operation. Also, note that if the SQL server is located elsewhere on the network, use TCP/IP sockets for the Network Library.
- Complete the wizard. Figure 2 shows the completed DB properties. Note that this action will create four folders under the database node in the Tree: Computers, Roles, Locations, and Make and Model.
These new folders allow methods to be created and applied to various deployment targets. For each of these methods, just right-click on the folder, select New, and enter the configuration information. A few examples are included below.
The properties of each one looks similar, as shown in Figure 3 (locations, properties). The first tab, Identity, is mandatory. In the location properties, this is where the default gateway address and the name of the location are defined. The details tab has a plethora of values to be defined. In the old Sysprep days, you had to track down an article or a list of values from somewhere, and it was not nearly as complete as this list.
Note in Figure 3 that the domain admin account can be specified for domain join, and the password is encrypted -- unlike in Sysprep. Also notice that putting the cursor over an empty field will display details about what has to be filled in for that field.
Other tabs include Applications, which configures application packages (already loaded in the workbench); Roles, which allows defined roles to be applied to other options; and Administrators, which lets you define which admins have access to the deployment.
Each of the following options allows grouping deployment targets:
- Computers -- This allows identification of specific computers by Media Access Control address, universally unique identifier (UUID), asset tag and serial number. This is very restrictive, and only special cases would use this one-of-a-kind deployment because it requires a lot of configuration steps.
- Roles -- You can create various classifications of users, applications, etc. for applying to deployment packages. For instance, you might have "Win7 Laptop users" and "Win7 Desktop Users" to apply Windows 7 installs and maybe Office 2010 as a role that can be configured to push Office 2010 to certain computers or even all computers at a given location. Unlike other methods, Roles can be associated with other methods such as Location.
- Locations -- This option allows identification of an IP default gateway address to identify a location. For example, if you want to push certain deployment packages to Chicago computers, you could associate the Win7 Laptop Users role with that location. See the example in Figure 4. This is fairly easy to configure.
- Make and Model -- Here, you can create categories of types of computers by make and model. This is helpful to roll out driver updates to all HP EliteBook laptops, for example.
Hint: To find the make and model of any Windows computer, go to Start-Run, and enter MSINFO32. This will display very detailed information. Windows Management Instrumentation (WMI) can also be used to extract this information. Be sure to use the names that are shown here for the make and model identity.
To create a role, for example, perform the following steps:
1. Right-click on Role -- New -- Identity Tab -- and provide a descriptive name. Determine how you are going to use this role. In the example in Figure 5, Roles were created called Laptop Users and Office 2010.
2. In the Details tab, peruse the many properties that can be set. There are server properties, BitLocker properties, Dynamic Host Configuration Protocol and domain name server settings, ComputerName and so forth. For an OS install, go to the miscellaneous section, and in the BuildID property, enter the name of a Task Sequence that you defined previously. Also enter "Yes" in the OSInstall field (Figure 6). Note that all installation options can be configured here.
3. Important: The last section of the Detail tab list is "Wizard Control" (Figure 7). This controls whether the installation option will be presented to the user during setup. For instance, if you do not specify "Yes" in the Skip ComputerName field, the user will be able to change the provided computer name during setup. These must all be defined as "Yes" for a fully automated deployment.
4. On the Applications tab, a list of apps (WIM files) loaded into the workbench in the Applications folder will be displayed. Adding one or more of these will attach it to the role being defined.
Similarly, entries can be defined in the Make and Model folder to apply deployment packages to certain computers, as shown in Figure 8. Individual computers can be defined in the Computers folder.
Obviously, there are a lot of configuration possibilities here, and I've just scratched the surface. This is enough to get started, though. I would encourage admins to install and play with MDT to get a feel for its capabilities and then design these roles and options.
Making it all happen
To perform an actual deployment once all the roles and other options are defined and configured, you'll need to follow a couple of basic steps to actually push it out to the target computers.
1. Right-click on Database folder, and select Configure Database Rules. This defines queries that the deployment wizard will process when the client runs the deployment script. Read these carefully, and uncheck the queries that don't apply in order to reduce deployment time at each machine. For example, Figure 9 shows the queries for Short Message Service packages, and administrators to be assigned to these machines are cleared since they do not apply to this deployment. Do this for each of the selected options to make the deployment wizard more efficient.
2. The deployment is initiated by going to the target machine and
a. Go to Start -- Run and point to the Virtual Basic Scripting script desired, located on the deployment share. For example:
b. At this point, the wizard will start and begin processing the queries to find all the options you defined and determine which ones apply to the target machine. In Figure 10, a setup screen appears during this process. A couple of things are evidently missing from the configuration:
1) The Skip Domain Membership option in the Wizard Control portion of the role properties was not set to "Yes" (that's why this page appears).
2) The username, password and domain are missing from the properties definition.
Again, this is fundamentally similar to using Sysprep. It will take testing, experimentation and time to get a good deployment package, but with all the Advanced Configuration scenarios that are possible, this effort will be worthwhile. For even more details and instructions for this process, see John Baker's series of eight TechNet Videos on this topic.
ABOUT THIS AUTHOR:
Gary Olsen is a solution architect in Hewlett-Packard's Technology Services organization and lives in Roswell, Ga. He has worked in the IT industry since 1981 and holds an M.S. in computer-aided manufacturing from Brigham Young University. Olsen has authored numerous technical articles for TechTarget, Redmond Magazine and TechNet magazine, and he has presented numerous times at the HP Technology Forum. He is a Microsoft MVP for Directory Services and is the founder and president of the Atlanta Active Directory Users Group.
This was first published in August 2011