Network Installation with the Microsoft Deployment Toolkit – Part 3: Creating Task Sequences

This is the penultimate part of the article series. Part 1 is “Network Installation with the Microsoft Deployment Toolkit – Part 1: Notes, Preparation and Setup” and Part 2 is “Network Installation with the Microsoft Deployment Toolkit – Part 2: Service Account, Drivers, Software, Base Image Considerations”

Creating Task Sequences

There are several templates of task sequences at the MDT. These can be used for their respective purposes and usually require only minor adjustments. These templates are:

• Sysprep and Capture
• Standard Client Task Sequence (Standard Client Task Sequence)
• Standard Client Replace Task Sequence (Standard Client Replace Task Sequence)
• Standard Client Upgrade Task Sequence (Standard Client Upgrade Task Sequence)
• Custom Task Sequence (Custom Task Sequence)
• OEM Task Sequence with Minimal Input (Litetouche OEM Task Sequence)
• Standard Server Task Sequence (Standard Server Task Sequence)
• Standard Server Upgrade Task Sequence (Standard Server Upgrade Task Sequence)
• Post OS Installation Task Sequence (Post OS Installation Task Sequence)
• VHD Creation for Clients Task Sequence (Deploy to VHD Client Task Sequence)
• VHD Creation for Server Task Sequence (Deploy to VHD Server Task Sequence)

Most companies use the “Standard Client Task Sequence” for operating system installations. For an in-place upgrade as part of a Windows-as-a-Service (WaaS) strategy, the “Standard Client Upgrade Task Sequence” template can be used. You can find out more about Windows-as-a-Service (WaaS) in the article “Strategies for Windows as a Service – A Process-Oriented View”

Creating a Generic Task Sequence

First, we create a task sequence for the installation. In the first step, I use the previously imported image of Microsoft Windows 10 for this

The names are important, especially for error analysis. Labels or names like “Tasksequence1” are rather bad. If you plan to create different task sequences, for example for servers, it can be useful to create a folder structure beforehand. Then create a new task sequence.

For the installation, I use the “Standard client Task Sequence”.

When selecting the operating system, we use the added operating system.

The next step is to store the licence key for Windows 10. If you are using a Key Management Server (KMS) or Active Directory Based Activation (ADBA) to activate your Windows licenses, Find the appropriate KMS client keys in the post “Key Management Service (KMS) Client Serial Numbers [Updated 2019]“. If you are using “Multiple Activation Keys” (MAK), you can also enter it here. Otherwise, Windows 10 will be inactivated and run as a trial version for 90 days. I use this setting here to save my MAK key during my multiple tests. A note about MAK keys, the number of activations of a MAK key is finite and depends on your licence. If it is possible for you, you should think about implementing a KMS server to activate Windows. You can find more on this topic in the article “Key Management Service (KMS) – An Overview“. An alternative to this is Active Directory-based activation. Whichever of the methods you choose, the serial numbers for the respective clients are the same and you can find them in the article post “Key Management Service (KMS) Client Serial Numbers [Updated 2019]”

Now you can set the Full Name, Organisation and IE Home Page.

Now the Local Administrator Password must be set. If it is not set here, it will be requested during installation. Generally, the local administrator password should be different everywhere. I recommend the Microsoft solution “Local Administrative Password Solution” (LAPS). We will include the required client later as a software installation in the task sequence. If you use LAPS, you can first assign a generic password here. If you implement LAPS, I recommend you also take a look at the article “Using and auditing PowerShell scripts with Local Administrator Password Solution (LAPS)”

The next step is again the summary, followed by the actual creation of the task sequence.

After confirmation, the task sequence is created.

Now the example must be adapted a little.

Including the drivers in the generic task sequence

When including drivers, I take a different approach than the usual one in the template. The task sequence template uses Plug-n-Play to select the correct driver. This is not actually wrong, but it uses the latest version of the driver. This does not always have to be the right one for the hardware

It is possible that different OEMs have different versions of a driver. OEM B has used a higher version number so that its network card driver, which is optimised for its hardware, is used instead of the generic chipset driver of the network component manufacturer. Unfortunately, OEM A keeps the versioning of the original and passes the driver through without modification. Due to the optimisation of OEM B’s driver, it unfortunately runs unstably with OEM A’s hardware

It is also possible that certain hardware is no longer supported with current versions of a driver.

Therefore, I only install the driver package that is intended for the device. This also saves me the problem of having to install the manufacturer’s drivers first and reproducing the problem in the event of an error.

To do this, modify the “Preinstall” phase of the task sequence. Since you will probably have more than a few driver packages in the course of time, I recommend creating a folder in the place where the “Inject Drivers” step is now.

You can deactivate or delete the “Inject Driver” step.

Click on the folder you have created and then select the items “General” > “Inject Drivers” under the drop-down “Add”.

Now assign a suitable name, for example the model drawing of the unit. Select the “Selection Profile” that you have created for the appropriate drivers. Select the option “Install all drivers from the selection profile”. Then switch to the “Options” tab.

Now select the entry “If statement” in the drop-down “Add” and then select “Any conditions”. This way you can also use a driver package like a family pack for several models.

Then add the item “Query WMI” via the “Add” menu. Enter a WMI query suitable for your hardware model. Here in the example a Dell XPS 13 9365, the query for this is

SELECT * FROM Win32_ComputerSystem WHERE Model LIKE "XPS 13 9365"

Now you have added the drivers for the first model

Repeat the step for all models. If you like to have some generic drivers in hand, you can also make a selection with corresponding WMI queries that contain a “NOTLIKE” instead of “LIKE”. But then you have to maintain 2 entries for each new model.

Including Software in the Task Sequence

The next step is to include basic software that should always be installed.

To do this, we must switch to the “State Restore” branch in the task sequence. There you will find an entry “Install Application”. Here, the applications are installed that you can select in the LTI after booting, if you do not suppress this. We are interested in as few steps as possible, so we make a preselection here. I always use the option “Install a single application” for this. Importantly, you can do this with any application except LAPS. I explain that in the following.

Deactivate or delete the original entry again. Unless you want to use the query function.

To add the application, select the menu “Add” and then the entries “General” > “Install Application”

Enter a suitable name and select “Install a single application” and then click on “Browse”

Select the appropriate application and click “OK”.

And your first application is ready for installation in the task sequence.

Tip: If you want to install certain software only on certain hardware models, you can again work with WMI filters, just as with the driver installation in the task sequence.

You can also work with variables and other parameters. This gives you many possibilities to make the installation of software dependent on other options.

After you have added the desired software packages, you should activate the two Windows Update loops. This way, the operating system and the Microsoft applications are directly updated during the installation. If you want to define the configuration for Windows updates beforehand, it is best to do this via suitable group policies or registry entries that you set in the task sequence.

Including Local Administrator Password Solution (LAPS) in the Task Sequence

Why is Local Administrator Password Solution (LAPS) different from other applications, you may ask? Installing LAPS is no different, but LAPS changes the local administrator password. And this is required by the MDT until after the last reboot. Especially due to Windows updates or other steps, a few restarts are necessary in the task sequence.

Insert LAPS before the item “Apply Local GPO Package” in the task sequence, as you did with the other programmes.

Then, as this time, select LAPS as the application.

The task sequence is finished

Configuring the Deployment Share Rules

Before you can start, we should make a few settings to the rules for the deployment share. If you do not change anything here, the “Lite-Touch” will ask so many questions that you will be busy for a while. We answer these questions in advance in the rules. Freshly installed, they look like this:

[Settings]
Priority=Default
Properties=MyCustomProperty
[Default]
OSInstall=Y
SkipCapture=NO
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=NO
SkipBitLocker=NO

We change these a little for our needs

[Settings]
Priority=MacAddress,SerialNumber,Default
[Default]
_SMSTSORGNAME=InfrastructureHero
OSDComputerName=Win10-#Left("%SerialNumber%",9)#
OSInstall=YES
UserDataLocation=AUTO
TimeZoneName=W. Europe Standard Time
AdminPassword=*****
UserDomain=ADIFH
UserID=SRV-MDT-BA
UserPassword=******
MachineObjectOU=OU=Clients,DC=ad,DC=infrastrukturhelden,DC=de
DomainAdminPassword=*******
DomainAdmin=SRV-MDT-BA
DomainAdminDomain=ad.infrastrukturhelden.de
JoinDomain=ad.infrastrukturhelden.de
FinishAction=REBOOT
SkipCapture=YES
HideShell=YES
ApplyGPOPack=NO
;WSUSServer=https://update.ad.infrastrukturhelden.en:8531 
SkipAppsOnUpgrade=NO
SkipRoles=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipUserData=YES
SkipLocaleSelection=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipApplications=NO
SkipBitLocker=no
SkipSummary=YES
SkipCapture=YES
SkipFinalSummary=YES
UserLocale=en-DE
KeyboardLocale=en-DE

If you want to use a Windows Server Update Service (WSUS), remove the “;” in front of the entry “WSUSServer” and change the URL accordingly. For more examples of the Microsoft Deployment Toolkit (MDT) Deployment Share rules, see Microsoft Docs

I have the computer name generated automatically, in this example it consists of “Win10-” and the first 9 digits of the device serial number. This is achieved by the entry “OSDComputerName=Win10-#Left(“%SerialNumber%”,9)#”.

I have also not provided for a migration of the user data in my test lab. This is done by the entry “SkipUserData=YES”. If you want to transfer user data, take a look at the “User State Migration Toolkit” (USMT) from Microsoft. This is also free of charge and can be integrated into the MDT as well as addressed via scripts.

Adapt your rule accordingly. To do this, right-click on the deployment share and select “Properties”

Select the “Rules” tab and modify the entries accordingly.

In addition, the Bootstrap.ini must also be modified. This is part of the boot image and provides access to the network drive in order to establish the network connection. If you do not adjust the Bootstrap.ini, you must log on to the network before the task sequence can be selected. You can also set the keyboard layout directly in the bootstrap instead of always being asked. I would also suppress the MDT welcome message directly, which saves another unnecessary click.

Preparations for the first test

In order to test this now, the deployment share must first be updated. To do this, right-click on the deployment share and select “Update Deployment Share”

In the options, the setting “Optimise the boot image updating process” is usually sufficient, as this is the fastest way. Nevertheless, you should occasionally regenerate the image completely. Especially after extensive changes, it is best to start this process at the end of the day.

This is followed by the obligatory summary.

After you have confirmed the options, the share is updated. Now is a good time to get a coffee and have a chat with your colleagues in the coffee corner. Especially the first time takes a long time. After all, all previous steps are now inserted into the image.

At the end of this step, there is a summary. In the course of the update, the boot medium was also created to start the Microsoft Deployment Toolkit (MDT). If you have not changed anything, the ISO and the WIM file required for the Windows Deployment Server (WDS) were created in the Deployment Share in the Boot folder. These are not offline media, I will tell you how to create them in the article “Creating Offline Media with the Microsoft Deployment Toolkit (MDT)”

Now is a good time to test the task sequence with the ISO, for example with a virtual machine. Afterwards you will know if there are any gross errors in the task sequence. You will find the ISO files in the “Boot” subfolder of your deployment share.

Test installation with the task sequence

To test the task sequence, I take a Hyper-V VM and mount the boot iso. The VM is a Generation 2 VM with UEFI support, which is important because there is no new PC to buy without UEFI. After I have booted from CD, the query for the task sequence appears if the bootstrap.ini and the set of rules are correct.

Since I have switched off many of the LTI dialogues in the rules, only the query for the task sequence and the BitLocker appears in this example in this task sequence. I leave the BitLocker in the lab because some of the old test devices or VMs do not have a TPM, depending on the settings. I leave the query for the task sequence active so that I can select several without always having to make a computer-specific entry in the rules.

And then the installation begins with the individual steps.

The task sequence carries out the necessary restarts without any further interaction.

After the first steps and changes, the finished Windows also comes up and runs through the further steps of the task sequence. The logon takes place automatically, no further actions are necessary except waiting.

Then the last steps take place, updates

and software installation. Here, too, restarts take place automatically if required. If you need a dedicated restart after installing software, do not integrate this into the wrapper (e.g. with a shutdown command), but use a corresponding reboot step in the task sequence.

The last step is to reboot the system as defined in the rule “FinishAction=REBOOT” and it is then ready for use. If you want to pack the units directly after the reinstallation without still taking manual steps, use the value “SHUTDOWN” instead of “REBOOT”.

Continue in the last part: “Network Installation with the Microsoft Deployment Toolkit – Part 4: Integration of the Base Image and the Windows Deployment Service”