Monitoring MDT Task Sequences with PowerShell

Using PowerShell with MDT

To use PowerShell with MDT requires installing the MDT console which will provide the PowerShell snapin support. For this article, I’ve used MDT 2012 Update 1. Either 32-bit or 64-bit should work.

I’m first going to set a couple of variables. In this instance, I’ve set the computer name of the target machine that I want to monitor and the path to the MDT deployment share. For this example, I’m using a local path because I’m running the PowerShell script on the server hosting the MDT deployment share. A UNC path will also work.

$target = "VM1"
$deploymentShare = "E:\Deployment"

1 2	$target = "VM1" $deploymentShare = "E:\Deployment"

To manage MDT we need to load the MDT snapin and create a PowerShell drive that will be used to access the MDT deployment share.

Add-PSSnapin "Microsoft.BDD.PSSNAPIN"
If (!(Test-Path MDT:)) { New-PSDrive -Name MDT -Root $deploymentShare -PSProvider MDTPROVIDER }

1 2	Add-PSSnapin "Microsoft.BDD.PSSNAPIN" If (!(Test-Path MDT:)) { New-PSDrive -Name MDT -Root $deploymentShare -PSProvider MDTPROVIDER }

Before starting the task sequence, I want to remove any existing monitoring data that might exist for the target machine. Duplicates are possible, so I want to remove all entries to ensure monitoring will be successful. The following line will remove any existing monitoring data for the machine specified by $target:

Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target } | Remove-MDTMonitorData -Path MDT:

1	Get-MDTMonitorData -Path MDT: \| Where-Object { $_.Name -eq $target } \| Remove-MDTMonitorData -Path MDT:

Once the target machine has booted into the Lite Touch WinPE environment, monitoring data should be sent to the MDT server; however we aren’t interested in that data yet because it will be pre-task sequence, which isn’t much use to us.

The screenshot below shows the monitoring data returned pre-task sequence. Typically, any machine name that starts with MININT will be the WinPE environment:

So, although we can start gathering data, we really need to wait or loop until the task sequence starts. When the task sequence has started, we can then get monitoring data for the target machine. The example below shows an in-progress task sequence:

To gather data, use the Get-MDTMonitorData cmdlet and save the output to a variable:

$InProgress = Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target }

1	$InProgress = Get-MDTMonitorData -Path MDT: \| Where-Object { $_.Name -eq $target }

The information returned proves interesting as it includes the percentage of the task sequence complete, the current step and the step name:

PS C:\> $InProgress

Name               : VM1
PercentComplete    : 30
Settings           :
Warnings           : 0
Errors             : 0
DeploymentStatus   : 1
StartTime          : 02/06/2013 17:05:23
EndTime            :
ID                 : 32
UniqueID           : c7b224e0-a918-4182-a370-96d5c9cb7410
CurrentStep        : 40
TotalSteps         : 131
StepName           : Install Operating System
LastTime           : 02/06/2013 17:05:39
DartIP             :
DartPort           :
DartTicket         :
VMHost             :
VMName             :
ComputerIdentities : {}

Using these properties and the Write-Progress cmdlet we can display the progress of the task sequence and some status info during execution of the script:

Putting this together, we need a script that will perform the following high level tasks:

Connects to the MDT share
Removes any existing monitoring data for the target machine
Waits for the task sequence to begin by interrogating the MDT monitoring data until the right machine data is returned
Monitors and displays the progress of the task sequence so that we can continue processing once the deployment is complete

The Complete Script

The script listing below put these pieces together and provides two loops – one that waits for the task sequence to begin and once it has, waits for the task sequence to complete.

$target = "VM1"
$deploymentShare = "E:\Deployment"

# Connect to the MDT share
Write-Host "Connecting to MDT share." -ForegroundColor Green
Add-PSSnapin "Microsoft.BDD.PSSNAPIN"
If (!(Test-Path MDT:)) { New-PSDrive -Name MDT -Root $deploymentShare -PSProvider MDTPROVIDER }

# Clean up the MDT monitor data for the target VM if it exists
Write-Host "Clearing MDT monitor data." -ForegroundColor Green
Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target } | Remove-MDTMonitorData -Path MDT:

# Wait for the OS deployment to start before monitoring
# This may require user intervention to boot the VM from the MDT ISO if an OS exists on the vDisk
If ((Test-Path variable:InProgress) -eq $True) { Remove-Variable -Name InProgress }
Do {
    $InProgress = Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target }
    If ($InProgress) {
        If ($InProgress.PercentComplete -eq 100) {
            $Seconds = 30
            $tsStarted = $False
            Write-Host "Waiting for task sequence to begin..." -ForegroundColor Green
        } Else {
            $Seconds = 0
            $tsStarted = $True
            Write-Host "Task sequence has begun. Moving to monitoring phase." -ForegroundColor Green
        }
    } Else {
        $Seconds = 30
        $tsStarted = $False
        Write-Host "Waiting for task sequence to begin..." -ForegroundColor Green
    }
    Start-Sleep -Seconds $Seconds
} Until ($tsStarted -eq $True)

# Monitor the MDT OS deployment once started
Write-Host "Waiting for task sequence to complete." -ForegroundColor Green
If ((Test-Path variable:InProgress) -eq $True) { Remove-Variable -Name InProgress }
Do {
    $InProgress = Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target }
    If ( $InProgress.PercentComplete -lt 100 ) {
        If ( $InProgress.StepName.Length -eq 0 ) { $StatusText = "Waiting for update" } Else { $StatusText = $InProgress.StepName }
        Write-Progress -Activity "Task sequence in progress" -Status $StatusText -PercentComplete $InProgress.PercentComplete
        Switch ($InProgress.PercentComplete) {
            {$_ -lt 25}{$Seconds = 35; break}
            {$_ -lt 50}{$Seconds = 30; break}
            {$_ -lt 75}{$Seconds = 10; break}
            {$_ -lt 100}{$Seconds = 5; break}
        }
        Start-Sleep -Seconds $Seconds
    } Else {
        Write-Progress -Activity "Task sequence complete" -Status $StatusText -PercentComplete 100
    }
} Until ($InProgress.CurrentStep -eq $InProgress.TotalSteps)
Write-Host "Task sequence complete." -ForegroundColor Green

$target = "VM1"

$deploymentShare = "E:\Deployment"

# Connect to the MDT share

Write-Host "Connecting to MDT share." -ForegroundColor Green

Add-PSSnapin "Microsoft.BDD.PSSNAPIN"

If (!(Test-Path MDT:)) { New-PSDrive -Name MDT -Root $deploymentShare -PSProvider MDTPROVIDER }

# Clean up the MDT monitor data for the target VM if it exists

Write-Host "Clearing MDT monitor data." -ForegroundColor Green

Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target } | Remove-MDTMonitorData -Path MDT:

# Wait for the OS deployment to start before monitoring

# This may require user intervention to boot the VM from the MDT ISO if an OS exists on the vDisk

If ((Test-Path variable:InProgress) -eq $True) { Remove-Variable -Name InProgress }

Do {

$InProgress = Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target }

If ($InProgress) {

If ($InProgress.PercentComplete -eq 100) {

$Seconds = 30

$tsStarted = $False

Write-Host "Waiting for task sequence to begin..." -ForegroundColor Green

} Else {

$Seconds = 0

$tsStarted = $True

Write-Host "Task sequence has begun. Moving to monitoring phase." -ForegroundColor Green

}

} Else {

$Seconds = 30

$tsStarted = $False

Write-Host "Waiting for task sequence to begin..." -ForegroundColor Green

}

Start-Sleep -Seconds $Seconds

} Until ($tsStarted -eq $True)

# Monitor the MDT OS deployment once started

Write-Host "Waiting for task sequence to complete." -ForegroundColor Green

If ((Test-Path variable:InProgress) -eq $True) { Remove-Variable -Name InProgress }

Do {

$InProgress = Get-MDTMonitorData -Path MDT: | Where-Object { $_.Name -eq $target }

If ( $InProgress.PercentComplete -lt 100 ) {

If ( $InProgress.StepName.Length -eq 0 ) { $StatusText = "Waiting for update" } Else { $StatusText = $InProgress.StepName }

Write-Progress -Activity "Task sequence in progress" -Status $StatusText -PercentComplete $InProgress.PercentComplete

Switch ($InProgress.PercentComplete) {

{$_ -lt 25}{$Seconds = 35; break}

{$_ -lt 50}{$Seconds = 30; break}

{$_ -lt 75}{$Seconds = 10; break}

{$_ -lt 100}{$Seconds = 5; break}

}

Start-Sleep -Seconds $Seconds

} Else {

Write-Progress -Activity "Task sequence complete" -Status $StatusText -PercentComplete 100

}

} Until ($InProgress.CurrentStep -eq $InProgress.TotalSteps)

Write-Host "Task sequence complete." -ForegroundColor Green

Hands off my gold image! A recap from Citrix Synergy 2013

2 Replies

Here’s an overview of my talk from Citrix Synergy 2013 – Hands off my gold image! If you were unable to attend Synergy or missed my session, this is a short version of the talk, but hopefully it will give you an idea of what was covered.

In this session I’ve covered three main topics – why I believe that automating your gold iamges is important, who is and who isn’t automating their gold images based on the results of a poll that I conducted earlier this year, and then an overview of how to achieve automation with the Microsoft Deployment Toolkit.

Why is automation important?

When talking about gold image automation, I think it’s worth putting this topic into some context by using where I work as an example of how build automation is important from a consultancy perspective. At Kelway, we have a particularly busy EUC architecture and consulting team and we deal with (what I think is at least) a large number of customers implementing hosted desktop solutions.

We typically see build automation used in physical desktops environments (although this isn’t always the case) but strive to encourage customers to utilise some form of automated deployment in both physical and hosted desktops environments. For the consulting team that is delivering solutions in the field, it’s important they have a delivery framework for that build automation and we’ve settled on the Microsoft Deployment Toolkit as our tool of choice. This is good, not only for those customers who do not already have a deployment solution, but enables us to provide a standardised approach the fits in with any deployment solution/ESD.

Using an industry standard framework, allows us to deliver consistency and dependability across deployments whilst being able to take advantage of improvements that Microsoft delivers with each new release of MDT.

How easy is it to achieve build automation? One of the great benefits of MDT is its simple architecture; however that doesn’t mean that build automation is an easy task. Easy implies a short learning curve and for anyone that has a few years deploying Windows and/or has some basic scripting under their belt, it’s not a big jump to being able to automate an install of Windows and a set of applications.

That said, there’s no way around it – automation takes time and effort. Automation requires discipline and process must be followed (perhaps even created to start with). Third party (or even in-house) application developers can make also automation particularly challenging on the Windows platform.

The reward though, is a better user experience and a lower total cost of ownership of the desktop environment. Build automation provides a management framework that will always beat (but never replace) documentation. An engineer can look into the build process and see exactly what has been delivered into an environment, because no guesses have to be made or documentation translated.

At what point though, do you spend too much time trying to automate the desktop environment?

For a solutions provider or consulting practice, build automation speeds many of the common tasks required for a desktop environment. This is why a framework such as MDT is so important – it provides faster deployment times but only as long as you’ve put the work in to start with.

In an engagement for smaller environments, automation can sometimes be a tough sell. There will invariably many additional tasks that might be time consuming to automate (typically application installs) and it’s not uncommon to find a single task that takes an inordinate amount of time to get right.

Perhaps in some environments, it’s important to strive to automate as much as is possible within a reasonable amount of time and deal with the remaining tasks manually, i.e. use the 80/20 rule to achieve the best bang for your buck.

Here’s an excellent example of where build automation can directly impact the user experience. Here’s the default user experience of a Windows Server 2008 R2 Remote Desktop Session Host server with the Desktop Experience feature enabled:

This is far from ideal from a user perspective – administrative tools are pinned to the taskbar by default, the wallpaper has Windows Server stamped on it and on first run of Internet Explorer the user is prompted with a first run wizard. This is just too noisy and creates a jarring experience for the user. Citrix provides a partial solution to this in XenApp 6.5, but this relies on Group Policy.

Most of these user experience issues could fixed with Group Policy; however that approach requires that Group Policy is processed at each logon (especially in a non-persistent desktop environment) and Group Policy typically enforces settings, instead of being a preference. If your goal is to reduce logon times, then move those settings in to your gold image instead. An automated build is an opportunity to ensure the default user experience (i.e. the default profile) is configured for first logon without a reliance on Group Policy or another UEM toolset.

Who’s doing it?

I received 100 responses to my poll which gave me a reasonable data set to draw some conclusions from; however given my audience I suspect the sample may not be completely representative of the broader hosted desktop deployments. The results are interesting nonetheless.

Here’s a breakdown of the hosted desktop / desktop virtualization solutions in use by respondents (multiple solutions could be selected). Citrix XenApp and XenDesktop were most popular by far, which is great for a presentation at Citrix Synergy.

Here’s how those hosted desktops are provisioned (multiple solutions could be selected). I could have removed the Other option from this question because in hind sight it didn’t actually make that much sense.

Here’s the tools used to creation the gold image for those desktops. The Other responses included solutions such as Matrix 42, RES Automation Manager and FrontRange DSM.

Finally, here what I was interested in – who is using automated build process and who is still manually building images from the Windows ISO.

I suspect that if we were to increase the data set, the percentage of manual builds would actually be higher than the 26% seen here.

So what about mixing this up a bit? Here’s the deployment types broken down by respondents using XenApp with Provisioning Services (at 23%):

And XenDesktop with Machine Creation Services (at 24%):

Again, I think the numbers of manual builds here are bit low if I compare against what I see in the real world. That said, my view is that 23/24% respondents using a manual build process is too high.

PVS and MCS are designed for delivery of the gold image, they are not a replacement for automating the creation of that image. What’s going to happen in those environments where the gold image has been built manually and it either needs to be recreated or the delivery mechanism needs to be changed? That manual image has become a black box that will be difficult to reverse engineer.

How do you do it?

By now, you must get the idea I’m a fan of the Microsoft Deployment Toolkit. Part of this reason is its simple architecture. At its simplest, MDT is just a share on the network.

It’s important to note that MDT provides light (or lite) touch deployments – user intervention is generally required to start a deployment. MDT is not agent based like System Center Configuration Manager and therefore does not provide any post-deployment management.

MDT has several major components:

MDT deployment share – a share on a network locations that supports SMB
CustomSettings.ini – this is used to control OS deployments and is a surprising flexible way of managing OS and application deployments and control of an end-point. If you are using
WinPE boot image – you can use the MDT console to create custom boot images used to start an OS deployment. Alternatively you could use Windows Deployment Services to boot the WinPE image across the network
The target PC – a single task sequence in MDT can be used to deploy Windows to either physical or virtual machines (on any hypervisor), providing consistency across machine types

I have spent quite some time building our MDT deployment share out to become not only a standardised framework but also a library of core application installs. MDT allows anyone to build this in their own environments.

I won’t go into too much detail on MDT here, instead here’s a short list of resources and blogs that are excellent MDT references:

I’ve previously posted the demos that I delivered during this talk, which you can view here:

Wrapping up

After last year’s version of this talk, I posted a basic set of instructions and downloadable components that you can use to automate the deployment of a XenApp 6.5 PVS gold image.

Finally, I’d like you leave you with the key takeaways:

Hands off my gold image! – Video: PowerShell, MDT, Atlantis ILIO and XenDesktop deployment

Hands off my gold image! – Video: Windows 8 zero-touch deployment

1 Reply

Here’s another demo that I showed during my Geek Speak Live session at Citrix Synergy 2013 at Anaheim yesterday.

In a 45 minute session on MDT and automating gold image deployments there’s not enough time for such a large topic, so perhaps I should have dropped this one; however this is interesting nonetheless. Using PowerShell to drive Hyper-V and MDT, this demo shows a full Windows 8 deployment from start to ready for user logon. This approach might be useful for persistent virtual desktops, or with a little more effort, using the image in a XenDesktop 7 desktop catalog created with PowerShell.

Here’s a flow chart that gives an overview of what the script does:

The video is available in HD resolution (720) so you can see the full details.

Hands off my gold image! – Video: automated PVS image deploy and capture

Aaron Parker

on application delivery and end user computing

Monitoring MDT Task Sequences with PowerShell

Using PowerShell with MDT

The Complete Script

Hands off my gold image! A recap from Citrix Synergy 2013

Why is automation important?

Who’s doing it?

How do you do it?

Wrapping up

Hands off my gold image! – Video: PowerShell, MDT, Atlantis ILIO and XenDesktop deployment

Hands off my gold image! – Video: Windows 8 zero-touch deployment

Hands off my gold image! – Video: automated PVS image deploy and capture