B2B – Integrating WDS and MDT Overview!

MDT and WDS Working Together

So this post is a testament to burnout, and how much it can hit you and how hard it can hit you. Granted, I had midterms, projects, assignments and everything piling up, but even in my free time, I knew that I had stuff to write about and I knew that I wanted to write on this website, but I just couldn’t. But to start back up, I’ve decided to do something short and simple, but also talk about something that I believe was a vital skill to learn! It’s not specifically about healthcare or anything like that, but it’s about the integration of two very important tools in the development and deployment of Windows images to machines! Instead of having to run and walk to each computer to install Windows, there is an automated tool that can do so for you albeit a few clicks and commands, in a sense, it’s a “Lite Touch” installation. Anyways, as you probably saw in the title and that header, I wanna talk about MDT (Microsoft Deployment Tool) and WDS (Windows Deployment Service), on its own they both can do similar things, but together, they work in perfect harmony!

Image Source

Above is a good image that kind of illustrates what is happening between WDS and MDT. In essence, WDS is a service that PXE boots and delivers a network-stored image that the machine can then “image”, meaning it’ll copy and write that Operating System Image, as its own operating system. It’s like back in the day, you would carry games on the Flash Drive, and whenever you went to a friend’s house or something, you could just copy that game over to them and you could then both play that same game. It’s the same concept, you have the original which is stored on the server, and each machine, can copy that OS-Image as its own. In the lab that I supported and helped manage, whenever we booted up a machine, we would go into its boot-menu, and choose the PXE-boot option, thus utilizing WDS, to help us spin up MDT, which deploys the image from WDS.

WDS – Supplies Boot Image over PXE Boot, if needed, it can deploy it as well, but as the “thick image”. Lacks customizability and is not as flexible. WDS, will store a captured image on its network, and allows PXE boot to load a miniature version of Windows, called the Preinstallation Environment. This is the “repository” that MDT pulls the correct image for deployment.

MDT – Typically takes the image that is delivered through WDS, and deploys it to the local machine. It injects drivers, installs applications, applies updates, joins domains among various other activities. MDT is essentially an automated tool that runs through a series of scripts to do all of these activities and more. Although WDS can create the image itself, MDT is a more robust tool that it can create the image itself but it can also take a “thin image”, where it is just the base installation, and MDT can be used to customize the image with drivers, applications, etc.

MDT itself is a task based deployment process, so as I mentioned before, it runs a series scripts, which are controlled by “task-sequences”. Although I mentioned the thin image, it can support a wide variety of deployment methods, a “Zero-Touch/ZTI”, “Lite-Touch/LTI”, and a “User-Driven/UDI” , all representing a different level of user interaction in the deployment process. In the lab, we utilized the Lite-Touch deployment process, however, we have looked into further automating and scripting everything by with the domain joining and machine naming processes! Anyways though, using a virtual machine, we would create the custom image that we would deploy for each class/purpose, and then use LiteTouch to capture that image where it would be stored on the Windows Server for WDS to use. MDT itself can’t deploy anything itself, it requires an image thrown to it from WDS, despite WDS being able to call and deploy an image itself, it just doesn’t have the same flexibility. WDS can do it all, but MDT provides additional customization capabilities.

Another beautiful capability that MDT brings is the concept of “injecting drivers”, with each machine and image, it all requires a separate package of drivers, which can be annoying to find and install each time. MDT, however, is able to automate that process, and given the hardware of the image which is queried during the early processes, it can inject the correct drivers after the image is deployed!

Article by Sir. Lappleton III

I'm a happy-go-lucky college student that started a blog as a way to not only document my education and my experiences, but also to share it with whoever stumbles upon my site! Hopefully I can keep you guys entertained as well as learn about a few things from IT as well as from my time and experiences as I plunge deeper and deeper into healthcare! A couple of my areas of focus is data management, system security (cyber security), as well as information technology policy.

Leave a Reply

Your email address will not be published. Required fields are marked *