Notes from the field – Do I really need MDT integration?

For many years, in fact, since I started my own career with Configuration Manager, the tried and tested method of building task sequences was to integrate MDT.

MDT integration was seen to offer the best of both worlds, as MDT of course includes a lot of automation logic out of the box. The prospect of being able to assign roles, have your log files dropped into a share and simple things like determine if the machine running a test sequence was a laptop, was something that we all appreciated.

In this post though I am going to challenge is this something we still need today, with all the advances in the native Configuration Manager product.

MDT – A Great Solution

I recall reading about the benefits of MDT integration from books like Deployment Fundamentals from Johan Arwidmark and Mikael Nystrom, and thinking this is great, I simply must have this, and at the time of course, it was awesome.

Being able to place machines in the correct OU at deployment time, based on their IP gateway, naming them according to a naming convention that obtained the serial number, and being able to collect the deployment logs, was just a joy to behold.

At the time of course even the imaging process itself was something that favoured on the side of having MDT, in a process that perhaps even some new to OSD might be unfamiliar with, I am of course talking about “build and capture”.

Putting an image in the oven was often a term used when talking about when building a new reference image, the benefit of MDT of course was that you were able to perform a light touch (or zero touch with some scripting) process for initiating a VM boot, deploying the image, layering in applications, and finally patching, before capturing an image that you could then import into Configuration Manager.

The process was a thing of beauty back in the Windows XP & 7 days. Even today there are reasons why a “fat or golden image” with applications is still preferable due to the considerable deployment time that could be caused by injecting lots of applications.

Windows & Configuration Manager Advancements

Over the past three years in particular we have all benefited massively from the work of the Configuration Manager and Windows product groups in Microsoft. They have without question improved both respective products significantly, and with improvements has come change.

Today Configuration Manager for instance has native PowerShell support, which for many, was a game changer. This single feature encouraged many in the community to develop their own solutions, and automation steps as required.

Windows 10 update frequency steered us away from the build and capture process at the same time. Serving became more reliable and also something that many members of the community including David Segura (OSDBuilder) and our own Donna Ryan (WimWitch) have championed with their own solutions. In fact the advice was to move away from the heavy build and capture process, using the now, more frequently updated, Windows 10 installation WIM files.

With all of this combined, I’ll explain why in my opinion, MDT integration is something that we no longer necessarily need.

Do I Really Need All These Steps?

The primary issue the I see with MDT integrated task sequences, is not for the seasoned veterans of the deployment field, but for those who are new to the game.

Working as a consultant, I often see the look of horror (for want of a better word) on clients faces when you show them a finished MDT integrated task sequence.

From a client or newcomer perspective the other issue with MDT is that if they are unfamiliar with it. This means they have to learn a new product on top of the one they had employed your services for, not only that but they also need to maintain it afterwards. Providing the additional knowledge transfer required to understand the custom settings and boot settings ini files isn’t generally the issue of course, where it becomes an issue is with the MDT integrated task sequence itself, and the perceived level of complexity it brings.

Let’s not get tied down with what you can strip out of it (as I know some reading this will be saying OK, just get rid of what you don’t need) but let us just look at taking it out of the box and add those bits that we really need, i.e. drivers, patching and applications.

In the task sequence screenshots above there are a total of 148 steps, excluding those that are disabled, all of which have a purpose. Of course not all of the steps are followed, some are for bare metal and others are for refresh scenarios, never the less though there is a lot of information for someone to take on board. What I am saying here is that the task sequence looks “busy”.

Less Is More Right?

As I mentioned earlier, PowerShell support along with other improvements such as the regional settings options, has massively improved what Configuration Manager gives you.

At this point some of you might be again shouting “MDT provides automation steps in the product without scripting” , which is of course true, but when we consider that learning PowerShell is something that most administrators should be doing (for their own benefit), it then becomes a case of should you be learning something specific or something with broader potential.

So, let us look at the same type of task sequence that is native in Configuration Manager.

In the above example, the native task sequence achieves the same process in 62 steps. In that instance there is a saving of 86 steps within the task sequence, which is significant to say the least.

By virtue of the fact it is much smaller, it is also easier to follow for anyone who has to maintain the system. Anything custom within the task sequence can also including your own commenting (in your scripts for example).

But What Do I Lose?

Monitoring

One of the nice elements of MDT is the ability to monitor what is going on within your running task sequences. This element is build into the Deployment workbench and with a little help from people in the community (
Damien Van Robaeys for example – https://gallery.technet.microsoft.com/MDT-Web-Report-1e820997), you can render your running tasks as a web page.

This is obviously a nice to have, but the issue I have with MDT monitoring is that it is updated during the gather process.

Keeping it simple, in Configuration Manager, we can simply use the Status Messages to view a live state of a deployment (as Nickolaj Andersen covered on the blog already – https://msendpointmgr.com/2014/02/27/monitor-osd-with-status-message-queries-in-configmgr-2012/);

In my opinion this provides just the information I need, in real time, in order to troubleshoot or validate that deployments are happening in an environment.

Log Collection

The main lacking in the native task sequence at present is the log collection capability, something of course that your MDT integrated task sequence does well. This is something that is extremely useful when troubleshooting failed task sequences, as we are all aware a screenshot of a failure with a hex code is not overly descriptive.

Here we can of course just create our own log capturing script and include it in the task sequence, which is something that I opt for today when working with my clients.

All we have to to is

• Create a deployment log share and a service account with permissions to the share
• Add a “Connect to Network Folder” task sequence step to connect to the share
• Run a PowerShell script at key restart intervals within the task sequence and upon failure to capture the logs

In the above example I had packaged the PS1 script file, however, since Configuration Manager 1902 you can of course just past the entire script in, For example;

Below is a full copy of the log collection script;

In the end we have the deployment logs saved on a share within a folder created from the OSDComputerName variable;

Computer Naming

The customsettings.ini can of course easily provide a means of generating your computer name. This is of course based on logic that you can obtain from details on the device, if you need something more complex, then something like the ConfigMgr Web service can help.

In the below example we have an automated solution for populating the OSDComputerName variable based on the chassis type and a maximum of 9 characters from the serial number;

[Settings]
Priority=Init, ByDesktop, ByLaptop, Default
Properties=MyCustomProperty,ComputerSerial, ComputerTypeName

[Init]
ComputerSerialNumber=#Right(“%SerialNumber%”,9)#

[ByLaptop]
Subsection=Laptop-%IsLaptop%

[ByDesktop]
Subsection=Desktop-%IsDesktop%

[Laptop-True]
ComputerTypeName=LT

[Desktop-True]
ComputerTypeName=DT

[Default]
OSDComputerName=%ComputerTypeName%-%ComputerSerialNumber%

The result would be with LT-%SERIALNUMBER (First 9)% for a laptop and DT-%SERIALNUMBER(First 9)% for a desktop.

So lets look at how we can take this and translate it into something that we can use in a non MDT integrated task sequence. Here we would need to run something like the below;

$namespace = "ROOT\cimv2"
$classname = "Win32_SystemEnclosure"
Get-WmiObject -Class $classname -Namespace $namespace | Select-Object * -ExcludeProperty PSComputerName, Scope, Path, Options, ClassPath, Properties, SystemProperties, Qualifiers, Site, Container 

Running this we end up with output we can use for system type and for the serial number;

At this point we now have the chassis type, which we can then look up and associate a prefix with. Enclosure values are well documented here – https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-systemenclosure, Jordan Benzing has also recently tweeted about how to use SQL commands to discover computer types using these values – https://twitter.com/JordanTheITguy/status/1238230016678191104?s=20)

Here we are going to focus on the following values;

• 9 & 10 – Laptop
• 3,4,6,7 – Desktop

Taking this and adding it to the script we come up with something like this;

Resulting in an output like the below;

Conclusion

To be clear, I am not saying bin your MDT integration. I am not saying that MDT as a solution isn’t good, or that integration can be a good thing in some cases. In fact I still put it in where it serves a purpose as a solution and I do implement MDT for cases like OS rebuilds in an Intune / Autopilot environment.

What I am saying however, is that I have moved on from proposing integration. Native task sequences in my own opinion, offer a cleaner and more manageable solution in the majority of cases.

Keep it simple. Thanks for reading!