In Part 3 of this series we looked at Selection Profiles and how to target the injection of drivers as part of a task sequence. As promised this post will show you how to enable 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.

Monitoring is enabled per Deployment Share by accessing the properties of the deployment share in the deployment workbench. To enable monitoring we simply tick the check box and apply.

 

 

The necessary firewall ports are open by default.

 

 

If you change the port numbers, an additional firewall rule will be created leaving the original ports exposed.

 

 

As well as creating the firewall rule, enabling monitoring also does two other things.

1. A new service (the Microsoft Deployment Toolkit Monitor Service) is created. This service receives in events from the computers being monitored and displays them in the monitoring node of the deployment workbench.
2. The CustomSettings.ini file is also modified to add a new entry specifying the URL to be used for monitoring.

 

 

As the customsettings.ini file is updated there is no need to update the deployment share (nor the WinPE boot images) when enabling monitoring as this setting is read in post boot as part of the deployment process.

When deploying machines you will now be able to track the build process within the workbench GUI.

 

 

Right clicking the status and selecting properties provides further details so that you can see which step the deployment has reached.

 

 

Once the installation has completed the GUI is updated.

 

If you access the properties of the monitoring report you can then connect to the machine by RDP (if remote desktop has been enabled) or using VMConnect.exe if the Hyper-V tools have been installed on the machine running the deployment workbench.

 

 

Monitoring can definitely make your life easier as you will know when a machine has completed building. In that way you can work on something else and only return to the machine when everything is ready.

Another thing that can make your life easier is being able to build machines while disconnected from the network – perhaps in secure areas of the network or in remote sites with a low number of users which don’t warrant a local server and / or where remote sites have a small or unreliable connection.

Media can be created as an ISO or to place on a USB thumb drive to allow it to be booted to. In larger deployments, this may mean that there is a large amount of files, installers, drivers and other items to include in the build media. To reduce the amount of data placed in any media created the creation of media leverages Selection Profiles to select which items should be included. For example, we can include just the Windows 8.1 operating system, HP drivers, general applications and any task sequences required to drive the installation.

We therefore create a new Selection Profile to select the items to be included in the media. The process for this is detailed in Part 3 of this series.

 

 

As you can see, it is not possible to select individual items and so creation of your folder structure is paramount, especially regarding items which may consume large amounts of space in the media image. For example, when we imported the Windows Server 2012 R2 images, it imported all 4 images into a single folder. While these will not take any more room than a single image (because of the way in which Windows 2012 R2 is packaged) I use this as a device to demonstrate how adding multiple items to a single folder can lead to large media sets being created.

Once we have a Selection Profile created specifically for our Media we can create the Media. To create our media we right click the Media node under Advanced Configuration in the deployment workbench and select “New Media”.

 

 

We specify a location to create our media in and also the Selection Profile created to state which items to include.

 

 

NOTE: Do NOT use a path under the deployment share. If we choose to replicate our share then this will mean the data being shipped twice.

The media creation process is very quick taking a few seconds. A Media object is created under our media node.

 

 

And a folder structure is created in the path we specified.

 

 

Just as with our Deployment Share, the media created can be configured to dictate how the installation process will run. By right clicking the media and selecting “Properties” we can access an interface similar to that used for the Deployment Share.

 

 

Above you can see that both an x86 and an x64 boot image have been selected to be created. The size of the created media can be reduced by only creating one type of boot image. The important thing to remember is that any build process started using this media will NOT be automated unless the rules section (media specific customsettings.ini and bootstrap.ini files) are updated to configure that automation.

 

 

Note: The bootstrap.ini file should NOT contain a DeployRoot value as all required content should be contained in the created media rather than being accessed from a Deployment Share.

 

 

Once the customsettings.ini and bootstrap.ini files have been modified to suit requirements, the media folders can be populated with data and the boot files created. To write the items included in the Selection Profile to disk we need to update the media by right clicking the media object created and selecting “Update Media Content”.

 

 

This process will take much longer, the length of time required dependent upon the specific items included in the Selection Profile.

 

 

 

Once complete, two sets of media will have been created. An ISO file (LiteTouchMedia.iso) and a content folder containing all the files needing to be written to a bootable USB drive.

 

 

In my example media, the ISO file has grown beyond the 4.7GB that can be held on a standard DVD drive. While it can still be used to build virtual machines you may need to use a USB thumb drive to create physical machines.

To create a bootable thumb drive you will need a physical machine (to plug the USB drive into) or a solution that supports USB over IP. My personal preference is to create the bootable USB drive in a Windows 7 or 8 workstation or laptop. The steps to create bootable MDT media on a USB drive are as follows:

1. Open a Command Prompt with Administrator privileges in either Windows 7 Pro or Windows 8 Pro.
2. Insert the target USB boot media device into an available USB port.
3. Type “DiskPart” in the command prompt.
4. Type “List Disk” (make note of the disk number of the target USB drive).
5. Type “Select Disk X”, where X is the target USB drive noted in step 4.
6. Type “Clean”.
7. Type “Create Partition Primary”.
8. Type “Select Partition 1”.
9. Type “format FS=fat32 quick”.
10. Type “Active”.
11. Type “Exit”.
12. Copy the contents of the “Content” folder from the media location specified above to the USB drive.

 

 

Note: The above commands set the file system to be fat32. This supports a maximum disk size of 8 terabytes.

You can then test your bootable media on your central site by powering down your MDT server or disconnecting it from the network and ensuring that clients can build to completion before sending the media to remote sites.

Note: Neither the ISO or the USB thumb drive will be password protected meaning anyone having access to the media will be able to read any usernames or passwords used in the customsettings.ini and boostrap.ini files. In addition, use of media does not allow for versioning meaning that, as MDT is updated, your old media may still be available and un use around the estate.

That brings us to the end of this post which has demonstrated how to enable monitoring and also how to deploy machines in more remote locations. In the next part of this series we’ll cover off Linked Deployment Shares to enable deployment in remote sites where there is sufficient requirements to place a localised deployment share.