Download Latest Microsoft Deployment Toolkit
Neomi Schlensker
This article provides an overview of the features, components, and capabilities of the Microsoft Deployment Toolkit (MDT). When you have finished reviewing this information, see Prepare for deployment with MDT.
MDT is a unified collection of tools, processes, and guidance for automating desktop and server deployment. You can use it to create reference images or as a complete deployment solution. MDT is one of the most important tools available to IT professionals today.
In addition to reducing deployment time and standardizing desktop and server images, MDT enables you to more easily manage security and ongoing configurations. MDT builds on top of the core deployment tools in the Windows Assessment and Deployment Kit (Windows ADK) with more guidance and features designed to reduce the complexity and time required for deployment in an enterprise environment.
MDT has been in existence since 2003, when it was first introduced as Business Desktop Deployment (BDD) 1.0. The toolkit has evolved, both in functionality and popularity, and today it's considered fundamental to Windows operating system and enterprise application deployment.
Many features in MDT support Lite Touch Installation (LTI) for Windows 10. An LTI deployment strategy requires little infrastructure or user interaction, and can be used to deploy an operating system from a network share or from a physical media, such as a USB flash drive or disk.
A deployment share is essentially a folder on the server that is shared and contains all the setup files and scripts needed for the deployment solution. It also holds the configuration files (called rules) that are gathered when a machine is deployed. These configuration files can reach out to other sources, like a database, external script, or web server to get more settings for the deployment. For Lite Touch deployments, it's common to have two deployment shares: one for creating the reference images and one for deployment. For Zero Touch, it's common to have only the deployment share for creating reference images because Configuration Manager deploys the image in the production environment.
Boot images are the Windows Preinstallation Environment (Windows PE) images that are used to start the deployment. They can be started from a CD or DVD, an ISO file, a USB device, or over the network using a Pre-Boot Execution Environment (PXE) server. The boot images connect to the deployment share on the server and start the deployment.
Using the Deployment Workbench, you import the operating systems you want to deploy. You can import either the full source (like the full Windows 10 DVD/ISO) or a custom image that you've created. The full-source operating systems are primarily used to create reference images; however, they also can be used for normal deployments.
Task sequences are the heart and soul of the deployment solution. When creating a task sequence, you need to select a template. The templates are located in the Templates folder in the MDT installation directory, and they determine which default actions are present in the sequence.
Post OS Installation task sequence: A task sequence prepared to run actions after the operating system has been deployed. Useful for server deployments but not often used for client deployments.
Selection profiles, which are available in the Advanced Configuration node, provide a way to filter content in the Deployment Workbench. Selection profiles are used for several purposes in the Deployment Workbench and in Lite Touch deployments. For example, they can be used to:
Windows 10 deployments using the Microsoft Deployment Toolkit (MDT) build 8456 fail when used with the Windows Assessment and Deployment Kit (ADK) for Windows 10, version 2004.
The BIOS firmware type is incorrectly identified as UEFI resulting in failures when refreshing an existing computer with a new version of Windows.
When this issue occurs, the smsts.log will record the following entry:
UEFI: true
Errors resembling the following are then recorded at the end of the process.
Open the Deployment Workbench, select the Deployment Share and choose the Update Deployment Share option, choosing to completely regenerate the boot image. Perform this step for each deployment share to ensure each one is updated with the correct binaries.
In this file, there is a section of code that checks to see whether or not it booted via PXE. In particular, one line reads the registry settings for the PXE server information. By changing sWDSServer = oShell.RegRead("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PEBootServerName") to say sWDSServer = oShell.RegRead("HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PEBootAddr"), it now pulls the IP address instead of the domain name, and the deployment continues as normal. Update the Deployment Share and import the new boot image into WDS, and you're good to go.
The Microsoft Deployment Toolkit task sequence is a series of steps that automate image deployment. It represents an essential capability of MDT because it allows almost any customization of the image. For example, you can use them to configure all the settings available in Windows SIM, add drivers or language packages, and start your own PowerShell scripts at any time.
I did noticed my bootstrap.ini had the error. But I fixed it and then updated my deployment. I just tried it again and I am still having the same error of it trying to connect to the old share. Do I have to delete the control folder too and then update?
Same issue happened to me and finding this post helped me also figure out that I had messed up the file permission on the deployment share for the user that was hard-coded into the deployment share rules.
Eventually you can create your deployment share using the UNC path of the Azure Files Share and do your typical MDT stuff like adding apps or your Windows 10 installation media. It may look like this:
Since Microsoft likes Github so much, you can even download ZTIWindowsUpdate.wsf (and ZTIUtility.wsf) as well and even edit to to your liking (ie. reducing the number of retries), you find it at -Deployment-toolkit-scripts/tree/master/Scripts
MDT 2013 Update 1 Preview should be uninstalled before installing the final MDT 2013 Update 1. Do not attempt to upgrade a preview installation or deployment share. Although the product documentation is not updated for MDT 2013 Update 1, the information on upgrading an installation still holds true.
First, we start a deployment using the Windows Deployment Wizard. After selecting my Build and Capture Windows 10 Task Sequence I get the option to select how I want to capture an image.
I choose not to capture an image by selecting the option Do not capture an image of this computer. This will make the deployment run normally and finish without doing anything afterwards. I do use the option Finishaction=REBOOT in my customsettings.ini to make sure the machine restarts after completion.
Now the machine will be started again using the LiteTouch boot media (in my case I use WDS) and wait until the deployment wizard is started once more. The reason why I do this is that my deployment share is available and accessible by the Z: drive which is automatically mapped. Pressing F8 opens the command prompt.
After a while the capture completes and a captured Windows 10 image is available in the Captures folder of the deployment share in use. This image can be used for deployment by MDT 2013 U1, System Center 2012 Configuration Manager SP2/R2 or whatever tool used for deploying .wim files.
For the sake of this blog, the corporate environment consists of Windows 8.1 devices which are domain joined. This means we can consider using Group Policy. Using Group Policy will meet the initial goal of keeping deployment and configuration separate. I was able to use the following reference to see how to use Group Policy to manage Google Chrome:
I guess I was lucky that at most projects in the past, the administrators told me which account to use since they already configured the required delegation for domain join. However, it was the first time that computer objects are pre-staged prior to deployment and I had to deliver the required permissions myself. Initially, I received the following error message:
At one my projects, I initially decided to create a single Driver Package for each family driver (or separate ones when required) which means that each package both contains the x86 and x64 drivers. Unfortunately, some models loaded the wrong driver. In my case, an x64 driver was loaded during a Windows 8.1 x86 deployment. This was not the behavior I was looking for.
Since the new server has a new name, and since the version has changed, the next step was to update the deployment share. I used the 'Completely regenerate...' option and the process completed without error. However, when trying to boot to the new image, a command prompt is launched on the client machine and nothing more. No scripts run.
So we have deployed a shell script (execute as program) during the deployment of the programs that intereclty asks for username, password, check if it's correct (net use .....if errorlevel like 0) set the winlogon registry settings to autologin and than reboot...
Getting the following Error after the OS installation. Running MDT/WDS 8456 - 1809 on a Windows 2016 Server. Windows LTSC 1809 is the OS to deploy. Once PXE starts up I am able to connect to MDT take the options to deploy the OS. The Hardware I am trying to push to are HP EliteDesk 800 G4 SFF and TWR. I can see the Installation Progress running Injecting Drivers, Applying Patches, Next Phase, Install Operating System... After it has been installed and after the reboot. I get the orange screen and the msg it did not complete. During the deployment process, 10 errors and 2 warnings were reported. See pic below.
What we came up with at a recent client of mine, was developed for a lab environment. To avoid this pesky screen, we added the LTICleanup script to to the WinPE load process to automatically clean up the drive for us every time we load WinPE. The obvious advantage is that we will never seen the above error. However you will also lose all your log files if you just had a failed deployment.
df19127ead