This post is just a quick walk through on how to install and configure the Microsoft Deployment Toolkit for the first time. MDT helps you automate the installation of Microsoft Operating Systems including associated drivers, patches and software. It can be extended by using Windows Deployment Services to allow PXE booting to the boot image and automated to minimise user input to allow very Lite Touch installations.

In short, it’s a “free” version of those bits of SCCM that allow you to perform operating system deployments.

MDT 2012 requires two pieces of software to be installed:

1. The Windows Assessment and Deployment Kit for Windows 8.1
2. The Microsoft Deployment Toolkit 2013

These can be downloaded from here and here respectively but you may want to search for updated versions.

The 2013 version of the toolkit supports deployment of Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, and Windows Server 2008 R2.

First, we install the Windows ADK for Windows 8.1. When asked select to install the deployment tool, the Windows PE environment and the User State Migration Tool following the prompts to complete the install.

 

When installation has completed, we then install MDT 2013 selecting the default settings.

 

Installation of the ADK and MDT are supported on Windows 2012 / R2 as well as 2008 R2. Once installed we start the workbench application which can be found by searching for “Deployment Workbench”

 

The workbench contains 2 nodes, the Information Centre which contains documentation and Deployment Shares which is the engine of MDT with each share conta9ining a location from which operating systems can be deployed.

 

The first task is to create a new deployment share. This can be done by right clicking the “Deployment Share” node and selecting “New Deployment Share”.

 

Set the share location

 

A name for the deployment share

 

 

And a description

 

 

Next, we select options for the “deployment share”.

 

 

What these options will actually do is begin to make choices for the installation GUI experience. That is, which pages are shown in the installation GUI. In a subsequent post I shall show you how to amend these choices. For now the defaults can be accepted or amended as you see fit.

We can then accept the summary of information and proceed to create the deployment share.

Once the deployment share is created a folder shared with the above details will be created. This folder on the hard drive will contain a selection of sub folders:

This folder structure matches closely what you see within the Deployment Workbench but contains a few additional specialist folders.

MDT is now ready to configure. To make any configuration easier to understand, I first create a folder structure.

 

With our folder structure in place we are now ready to import an operating system. Below I show how to import Windows Server 2012 R2 operating systems ready for deployment but we can just as easily import desktop operating systems.

First, we mount our ISO image and copy the contents to the hard drive. I have created a folder called D:Sources to hold any source installation files.

With the files extracted, we right click the appropriate sub-folder under Operating Systems (in my case, the Servers sub folder) and select “Import Operating System”.

 

As I have a full set of source files I can select to import a full set of source files.

If we had previously created a reference image, we could then capture it as a master image at which point we would select “Custom image file” instead. If we had an existing WDS infrastructure, we could leverage our work to date and import those existing images using “Windows Deployment Services images”.

NOTE: If importing WDS images, we have to import ALL images. We do not get to select which ones to import though they can be subsequently deleted.

We then browse to the folder we extracted from the DVD. As the source files exist on the same volume as my deployment share I have selected to move the files instead of copying them to speed up the process. If it’s important that the original files are preserved for some reason then you can deselect this option to copy them. If you set the source location as the original DVD then you will have no choice other than to copy the files.

 

 

We can then give the folder to which the images will be copied a meaningful name and proceed with the import.

 

 

My source contains four editions of Windows Server 2012.

 

My source folder is emptied.

 

And the source files are moved to the folder name I selected in my deployment share.

 

The operating Systems now appear in the MDT interface and are available for installation.

 

 

Next, we import any necessary drivers. To create a reference image I shall be using a virtualised environment negating the need for drivers. However, drivers are imported in much the same way as operating system files. Firstly, download and extract the driver files from any executables to obtain the necessary inf files and other associated files. Where drivers cannot be extracted then they may need to be installed as complete applications. As a minimum you should endeavour to extract any network and mass storage drivers to enable the operating system to install and connect to the network.

To import the drivers we right click the appropriate node and choose to “Import Drivers”.

 

We browse to the location containing our extracted drivers (multiple sub folders can exist in this location, one for each driver or set of drivers).

 

 

We can choose to import drivers even if they exist elsewhere. This is useful if we have a structure as shown here (one folder for each model of machine) where multiple models may utilise the same driver. By allowing the driver to be reimported we can ensure that the driver exists in that folder. However, care should be taken when creating any task sequences that only the appropriate copy or version of the driver is installed.

 

 

Our drivers will then be imported.

 

 

We can also import software using the same process. I personally create at least two folders, one named global (top contain software to be deployed to all endpoints) and one name Departments or similar, which then contains a sub folder for each department holding the software appropriate to that department. Other folder structures can be used, you should use whichever method makes it easiest to navigate the structure, especially when it comes to installing end client software.

To install an application we simply right click the folder where we would like to locate the application and then select “New application”.

NOTE: An applications is different from a package. In MDT an application is a piece of software you install, a package is an operating system patch or language pack.

We are the presented with three choices:

 

An application with source files will allow you to install a “standard” application. An application witho9ut source files or one on the network is an “application” that is run directly from a share while an application bundle is merely a placeholder to group together multiple applications that must be installed as a single item.

Here I will install Foxit Enterprise Reader. I quite like this as a PDF reader as it’s faster and, I think, more functional than Adobe.

We complete the details about the application.

 

 

Browse to the location of the application, again selecting to move the application install files.

 

Again, we select a meaningful name for the folder in which the application source files will be placed.

 

 

We then enter the command line to silently install the software. As with all MSI packages, it may be that a transform file is required to install the software. Foxit has a number of switched which can be obtained by mailing the support department at Foxit. The ones we shall user are:

MAKEDEFAULT (When enabled, this setting will make Foxit Reader the default PDF application and will associate all .PDF files with Foxit)

LAUNCHCHECKDEFAULT (When application starts up it will verify that Foxit is the default browser)

VIEW_IN_BROWSER (This will allow PDF files to be read in your web browser)

STARTMENU_SHORTCUT (Place Foxit shortcut in Start menu)

DESKTOP_SHORTCUT (Place FoxIt shortcut on the desktop)
The installation command line we shall use is therefore

msiexec /i “
EnterpriseFoxitReader612.1224_enu.msi” /qn /norestart MAKEDEFAULT=1 LAUNCHCHECKDEFAULT=0 VIEW_IN_BROWSER=1 STARTMENU_SHORTCUT=1 DESKTOP_SHORTCUT=0

A log file of the installation can be taken using the standard msiexec switch /l*v if needed.

NOTE: Note the use of the /norestart switch. As an alternative for windows installer files/ we can use REBOOT=reallysuppress. The application being installed must NOT reboot the computer as part of the installation routine. Any reboots should be handled by MDT so that WinPE can prepare for shutdown and recover from restarts.

 

 

We can then follow the prompts to complete the import of the application. Once imported, it appears in our list of applications.

 

Accessing the properties of the application (by right clicking) exposes the settings we just provided. Here, we can also instruct MDT to reboot the computer after application installation if required.

 

Once we have our operating systems, applications and drivers imported we can move to using MDT to deploy computers or, in the alternative, creating a reference image to be imported which contains all our base software. The reasons for creating a base image containing the software are:

1. It reduces installation times as the installation (including all software) will be from an image (rather than using installers) and so a fully configured computer can be deployed in ~ 30 minutes rather than the 2 – 3 hours required when using installers (assuming multiple base applications).
2. It’s a trivial exercise to rebuild or recreate the reference image as the operating system files, drivers and application files already exist within MDT so if we need to update an item of software this is not onerous. This is compared to removing applications from the base build and using a task sequence to install all applications which can take far longer.

To prepare for installing operating systems with MDT we next create a boot image which the computers will use to boot to. This boot image will contain the executables for the MDT GUI and our network and mass storage drivers that we have imported. It also contains some command / configuration files which I shall detail in a later post.

To create the boot media we “update” the deployment share by right clicking the deployment share and selecting “Update Deployment Share”.

 

The WinPE image that ship with the ADK is the one used to create the boot image. Indeed, a number of boot images will be created in each of i386 and x64 variants. You are asked whether you would like to update the existing image to optimise the creation process or completely regenerate the image.

 

As this is the first image being created both options result in the same thing. Working through the process creates the boot image and this process takes around 15 – 20 minutes.

Once complete a number of files will be created in the Boot folder of the deployment share.

If integrating MDT with WDS then the .wim file can be used to boot to from PXE otherwise the .iso file should either be attached (when building a VM) or burning to a CD / USB thumb drive for direct booting.

The final thing we need to do is to create a task sequence for the MDT GUI to follow. This lists the tasks that will be followed to create a base image. For our purposes, a default task sequence can be used. I shall try and detail how to bespoke the task sequence in later posts.

To create a new task file we right click the appropriate folder and select “New Task Sequence”

We give the task sequence a name.

We next select a template to build the task sequence from.

 

 

If we have a pre-existing computer to use as a reference image we can just select “sysprep and capture”. If we have a pre-prepared VHD and don’t own SCVMM, we can select one of the later task sequences.

As I have a server O/S to deploy I shall choose “Standard Server Task Sequence”. If we were installing a desktop O/S we would simply select the very similar “Standard Client Task Sequence”.

We then select the operating system that we would like to install using this task sequence.

 

If using a KMS enabled copy of the operating system disk we can simply select not to use a key at this time

 

If we are using a retail disk (such as those from MSDN) then we can enter a retail key or if we have MAK keys then we can select the second option.

We next provide the standard Windows information – here I have set the IE home page to the internal intranet but for a server you may want to leave at the default “about:blank”.

 

Next, we can either specify a local administrator password (the default option) or choose to supply one at the time of deployment.

 

Once completed, the task sequence appears in the MDT GUI.

 

 

 

The physical files constituting the task sequence can be found in the Control folder of the deployment share.

 

 

 

We can now build and capture our reference machine. I do this in a virtualised environment to remove any reliance on network or mass storage drivers. We simply mount the LiteTouch ISO to the VM and boot it.

 

The VM will boot to the WinPE / LiteTouch ISO created earlier and the GUI start to enable installation.

 

You are presented with various options such as being able to set a static IP address if your virtualised environment does not connect to DHCP (as some production based server environments do not) or running the windows recovery wizard. If you need access to a command prompt, simply press F8. This will allow you to inspect the local hard drive or any installation logs.

NOTE: The computer will NOT reboot / the process will NOT complete while the command prompt it open. This should be closed when not in use to allow the build to complete.

If we choose to run the deployment wizard we are next asked for credentials to use to connect to the deployment share.

 

The wizard then ask which Task Sequence should be used to deploy the machine.

 

We are then asked if we would like to join a domain or a workgroup – for a reference image I would recommend joining a workgroup to ensure that no remnants of the domain membership are “left behind” once the image is taken.

 

 

We then set the language and time zone for the server.

 

 

Select any applications to be installed. Here I am selecting Foxit, as a demonstration, even though this is unlikely to be installed in a server reference image. For a client reference image you may want to consider installing items such as C++ redistributables, Silverlight etc.

 

 

As we are creating a master image (from the reference image we are deploying) I have selected to capture an image. Once this captured image has been imported as a reference image for deployment, we would simply select “Do not capture an image of this computer” to deploy additional machines.

 

 

As we are deploying to a virtual machine, the choice to deploy bitlocker is skipped over. We can now click on “Begin” to start the automated installation and capture routine.

 

 

And that’s it – a basic installation and configuration of WDS so that you can deploy, capture and redeploy desktops free gratis and for nothing (well, you will need a server to run the software but most organisations have capacity for this in their virtualised environment).

In part 2 of this series I run though automating the environment even more and show you how to cope when you have a variety of endpoints to deploy to.