Information Systems:Workstation Imaging With WDS And MDT

"Imaging" is when a prebuilt operating system, with or without applications, is transmitted over the network to 1 or more workstations that are either a tower desktop or laptop.

When new desktops or laptops are purchased they come from the manufacturer with what is called an OEM image installed in a "never booted" state. The OEM image is created by the manufacturer and has all of the device drivers and manufacturer branded applications built in. The manufacturer then mass copies the OEM image to thousands of desktops and laptops in a state that when the machine is powered on for the first time, the image is finalized with the "out of box experience". The OOBE is the wizard that starts when the machine is powered on for the first time and it prompts for basic information such as time/date settings and to acknowledge the EULA. This OEM image will always use an OEM license of Windows and will always include all the device driver files and manufacturer specific application installers in a folder on the hard drive. It is absolutely critical that the folder with the drivers and apps is copied or moved off the hardware before work starts on creating a custom image. The driver and application files need to be saved as they are needed in the process of creating a custom image, which includes a step to delete all existing partitions on the said hard drive.

The reason why the OEM image is not used is because it will never use the volume license of Windows that can be installed multiple times. The OEM image will also never include all, or even any, of the programs uniPHARM staff need to use on a daily basis. The is nothing technically wrong with using the OEM license and manually installing our needed programs by hand, it's just very time consuming, inefficient and not a best practice.

Microsoft provides the software tools to create a custom image for free, except for the actual Windows client license and the Windows server license that is needed to host the image(s). The 2 main tools are Windows Deployment Services (server role on both 2008 and 2012) and Microsoft Deployment Toolkit. Known as WDS and MDT, they work in tandem to create and serve images to desktops and laptops. WDS is the software that contains the unaltered original copies of the Windows DVDs and the boot and capture images that are used during the process of making a custom image. WDS also stores the final versions of the custom images that are used whenever a workstation needs to be wiped and re-imaged. The WDS server is listed in the DHCP scope as a PXE boot responder so that when a workstation boots from the network, the WDS server makes the expected response. MDT is much more focused on the customization and assembly of the image as well as keeping an inventory of device drivers and applications.

As of the summer of 2016, the WDS server is Thermoprofile and MDT is installed on the same machine. All of the images and drivers and apps are on the D: of Thermoprofile and were setup during the creation of our initial set of images, in 2012. A better setup would be to have WDS and MDT in a VM and not on a server with other programs installed.

MDT is where device drivers and applications are combined into a base Windows DVD image so that the customized image can be captured and saved into WDS. The first step is to import all the saved device drivers that were copied off the OEM image. MDT can scan a large folder full of drivers and put them into the MDT database. The list of drivers for all the hardware is then viewable with version numbers in MDT. When you are making an image for lots of different models of desktops and laptops, it is very important to make sure that all the drivers that are needed are available in MDT. Collecting drivers for lots of different models can be very time consuming unless they are copied off from the OEM image. At the absolute minimum, the most critical drivers are network card and hard drive controller drivers. Without both, the image cannot be applied to the hardware. Obviously having drivers for all the different components is better than just having the minimum.

MDT can also catalog applications in the same way that it does for device drivers. The idea is that all of the installer files for all of the needed programs is imported into MDT so that they can be installed programmatically during the customization process, just like the device drivers. In theory this does work but in the real world not all program installers are available as .msi files. MDT works best with .msi files that can take a silent install parameter. Installers that are .exe files or some sort of Java garbage don't really work gracefully with MDT. For example, Microsoft Office can be a customized silent install with MDT while the ASW GUI cannot because it is an exe. Complex programs like Lotus Notes may wrap an .msi inside of an .exe and you have to decide if it's worth the effort to untie that knot.

To be continued