In Part 2 of this series we looked at automating installations further using the customsettings.ini file and bootstrap.ini file. In this post we will look at Selection Profiles, what they are used for and automating the assignment of drivers to boot images and within a task sequence.

Selection profiles allow us to :

• Group drivers and packages together to inject into the WinPE boot disks so that the drivers and updates are there for when we need to boot to different sets of hardware
• Group drivers together so that we can install (inject) them during a task sequence
• Group items together to control what items are included in media we create for offline installations
• Group items together to replicate linked deployment shares

We’ll look at the first two of these items in this post, the other two I’ll reference in later posts where I show you how and why you would want to create media and linked deployment shares.

Selection Profiles are found under the “Advanced Configuration” section of the MDT workbench. Six Profiles exist by default but you are free to create your own. This is simply a matter of right clicking “Selection Profiles” and clicking on “New Selection Profile”.

We give the profile a name.

 

 

And then select the folders that should form part of that profile.

 

We then click through to the end and our selection profile is created. Updating the selection profiles updates the SelectionProfiles.xml file held in the “Control” folder of the deployment share.

You can see from the above image that I have selected the M4500 folder so only drivers from that folder will be held in the selection profile I created. If I create a new folder under the M4500 folder in my “Out-of-Box Drivers” section then that new folder will automatically be included in the selection profile.

 

This is important to remember as if I had created a selection profile at the “Dell” level, any new Dell drivers would be added to my selection profile. The above is all there really is to creating selection profiles. The real beauty of them comes in how we use them. The two places we will look at in this post are placing them in our WinPE images and using them in task sequences.

Using Selection Profiles in WinPE Boot Images

To use the selection profile in our task sequences we access the properties of our deployment share, select the “Windows PE” tab and then the “Drivers and Patches” tab.

 

We can simply choose the set of drivers to use by updating the “Selection Profile” selection box. However, what you should note is that the Drivers and Patches tab is specific to a single platform, either the 32-bit x86 boot images or the 64 bit x64 boot images controlled by the “platform” selection box.

When applying a selection profile to our boot images we therefore have to select the platform as well as the selection profile as illustrated below.

 

 

As you can see, applying one set of drivers for one machine type to a boot image for one platform does not make sense. For this reason, many people create additional folders within the “Out-of-Box Drivers” section to split the 64 Bit and 32 Bit drivers and in this way limit the size of the drivers injected into the image.

 

By doing this it is then possible to create selection profiles for 32 bit and 64 bit drivers and assign those to the individual boot images.

 

 

NOTE: Any changes made here will not be deployed until the deployment share has been updated by right clicking and selecting “Update Deployment Share” and any updated image deployed to DVDs / USB drives or WDS servers.

While updating your WinPE images you may also want to take a moment to increase the scratch size space to 128MB and possibly the background image.

The default location for the background image is %installdir%Samplesbackground.bmp where %installdir% refers to the installation location for MDT. This is usually c:Program FilesMicrosoft Deployment Toolkit.

 

Finally, you can also install roles inside the WinPE disk which may be important if you have a secure network (802.1x) or perhaps want to run PowerShell scripts from within WinPE.

Again, any changes here will only be activated once you update the deployment share and re-distribute the boor files created.

 

Using Selection Profiles in Task Sequences

 

As well as using selection profiles to inject drivers into WinPE images, they can also be used to install or inject drivers into any endpoint builds by updating the task sequence used. Be default the task sequence includes an item named “Inject Drivers” in the Postinstall section of the task sequence (this can be accessed by right clicking the task sequence and selecting “Properties”).

 

This item is actually a “Run Command Line” task that runs the “ZTIdrivers.wsf” script which installs what it believes are the best available drivers from all of the Out-of-Box Drivers into the operating system. This behaviour can be overridden as follows:

1. Select the options tab of the “Inject Drivers” task and choose to “Disable this step”.
2. Next – choose to add a new task and navigate to the “Inject Drivers” section.
3. This will create a new task labelled “Inject Drivers” which can be confusing so rename it to state the type of drivers being injected.
4. Select the Selection Profile containing the drivers to be injected.You can also choose just to install only matching drivers or install all drivers if you believe that there may be an issue with driver matching.
5. To ensure that these drivers are only injected for the type of computer concerned, click on the options tab and insert the WMI query below changing the model of machine to the correct value as discovered using the ZTIGather.wsf script.On the options tab click on Add | Query WMIEnter the query below swapping Precision M4500 for the model of your endpoint, click on OK and then Apply.

   Select * from Win32_ComputerSystem where Model like “%Precision M4500%”

   The model name for the computer must EXACTLY match the value found using the ZTIGather.wsf script including any full stops (periods) or spaces. If you do not want to copy this script and associated files across to an endpoint then you can discover the model by running the following command from an administrative command prompt.

   wmic computersystem get model
   
   

6. Click away from the Inject Drivers task and click on it once more and its values will be updated in the GUI.
7. Your drivers will now be injected for that model type.

 

You can simply rinse and repeat the above steps to use the same task sequence to build multiple types of hardware from a single task sequence. If you want to have a “default” set of drivers applied if no specific drivers exist for a model then we need to track whether or not drivers have been installed. To do this we create a “Property” within our customsettings.ini file and use that to track whether or not we have installed the drivers.

In the customsettings.ini file make the following changes:

[Settings]

Priority=Default

Properties=DriversApplied

[Default]

DriversApplied=NO

Here we have created our own custom variable named “DriversApplied” and set its initial value to NO. We can then update that value to YES when we install drivers in the task sequence. If it still remains at NO at the end of the task sequence we can then run the built in ZTIdrivers.wsf script.

To do this, we create a folder (New Group) for each type of driver within our task sequence and place the step to inject the drivers using a selection profile within that folder.

 

We use the Up | Down buttons to place the group (folder) in the correct place and also top indent the inject task underneath (inside) the folder.

We then associate our WMI query with the folder (rather than the inject task) so that all steps in that folder are run if the WMI filter is matched.

 

We then add a new task to set the task sequence variable “DriversApplied” to be “YES” if any drivers have been injected.

 

 

We repeat this step for each of the driver injection stages. The final step is to set the Unknown Computers folder to only be used if DriversApplied still equals “NO”. We do this by applying a filter (the same as for the WMI query above) to check if the task sequence variable is still set to NO.

 

 

 

 

As you can see, we can now use the same task sequence (and associated base operating system) to install multiple models of machines. We can use our customsettings.ini file to therefore make other decisions around automating our build, for example, still using different task sequences or perhaps the same task sequence but different sets of applications.

In the next part of this blog series I’ll discuss enabling monitoring to track installations as they occur and also creating media so that computers can be deployed offline when the MDT server cannot be contacted or where the link to the MDT server is small or unreliable.