- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
The case for VM test clients ^
The fastest and most efficient way to test a deployment is through the use of VMs. With Hyper-V, you can host VMs on Servers, desktops or laptops. VMs allow for anywhere access, remote visual control of the BIOS and PXE options, and the ability to instantly revert back to a saved state. Physical hardware certainly is still required to test and manage driver installations but your MDT life will be a whole lot easier with a VM as a test client.
Booting Up ^
So we have a configured deployment share, WDS loaded with our boot images, and a ready VM. We decided to keep most of the default options in our CustomSettings.ini. Let’s see what happens:
Our Default CustomSettings.ini file
Once we start our VM and tell it to PXE boot, it will contact our WDS server and downloaded the specified boot image (LiteTouchPE_x86)
The TFTP transfer of the MDT boot media
After 30 seconds or so, your boot image should be downloaded. The Windows PE OS will begin to load into a virtual X:\ drive. Because this X:\ drive is stored within RAM, it is volatile. If you do any manual customizations during the Windows PE stage, keep in mind that these settings will be lost after a reboot. For example, a manual drive mapping to a file share will disappear when the client is rebooted.
Depending on your version of Windows PE, this screen may appear differently.
Once the Windows PE is fully loaded, MDT will launch the Windows Deployment Wizard (BDDRun.exe). This wizard will look at the machine to establish variables and check the CustomSettings.ini file for input. Because our CustomSettings.ini file is pretty bare, a good deal of user input is required. First, we must select our Task Sequence (even if we only have one listed). Notice the number of windows that we will need to proceed through (Task Sequence, Computer Details, Locale and Time, Ready).
Displayed here is the Task Sequence Name. The Task Sequence ID is not shown in the wizard.
After selecting our Task Sequence, we are taken to the Computer Details section. We can either accept the default generated name or provide specific one. We can also provide information to join the domain. By doing these two steps before imaging, we do not have to visit the machine after the Task Sequence has completed.
The Computer Details windows in the Deployment Wizard
In the screenshot above, notice that we now have a few additional steps until the imaging starts. These extra steps are due to tasks in our Task Sequence. For example, we do not have an Application Selection window because we specified Office as our single application within the Task Sequence.
The Install Applications Task in our Windows 8 Task Sequence
After proceeding through the next several screens and filling out any required steps, we are ready to image!
Deployment Wizard Input Summary
While that process only took a minute or two, imagine the time wasted doing this on a large scale or the possible mistakes that could be made (such as the Time Zone selection). Let’s streamline this a bit by adding these additional lines to our CustomSettings.ini.
TimeZoneName=Eastern Standard Time
By adding the lines above, we went from 18 prompts requiring input down to just a single required prompt – the computer name!
Enter Computer name
With MDT, you can steer down a User Driven Installation (person at the client selecting the imaging options such as a specific task sequence) or a Zero Touch Installation. With our current setup, all that is required of us is the computer name. In our next post, we are even going to automate that.