Monthly Archives: August 2015

Possible workaround for capturing a Windows 10 reference image with MDT 2013 Update 1

As most of us should know by now Microsoft release Microsoft Deployment Toolkit 2013 Update 1, see the announcement at

The main improvements are support for Windows 10 and integration of System Center 2012 Configuration Manager SP2/R2 SP1. Unfortunately, this release has quite a lof of issues that makes it either very difficult or impossible to properly capture a reference image. A list of know issues is available at

The issue that bothers me the most is the following, and I quote:

Do not upgrade from Preview to RTM

MDT 2013 Update 1 Preview should be uninstalled before installing the final MDT 2013 Update 1. Do not attempt to upgrade a preview installation or deployment share. Although the product documentation is not updated for MDT 2013 Update 1, the information on upgrading an installation still holds true.

Being a consultant which require me to be an early adopter and testing new stuff to allow myself to be ready when it’s released requires me to work with Preview versions of verious software. Also, as an ITPro which has an isolated environment available purely for Image Building purposes, I need to upgrade my deployment share frequently. While I can automate building new deployment shares, it takes time I don’t have to research and test these new technologies. So I don’t have much choice than upgrading my deployment share. I must admit that releasing this technology with so many known issues is quite sloppy to me. I can only assume that various scenarios may not have been tested thoroughly by time constraints and releasing this version was under a possible amount of pressure.

Trying to build and capture a Windows 10 reference image fails. The capturing itself fails with an error message that a certain script cannot be loaded. The MDT 2013 U1 environment I currently have is for image building purposes only so I don’t have that many customizations configured.

So knowing that the capturing itself fails I can do the capturing part myself. Knowing that image building is not something I expect you to every day the amount of administrative effort increases just a little bit but it’s quite easy to do.

First, we start a deployment using the Windows Deployment Wizard. After selecting my Build and Capture Windows 10 Task Sequence I get the option to select how I want to capture an image.


I choose not to capture an image by selecting the option Do not capture an image of this computer. This will make the deployment run normally and finish without doing anything afterwards. I do use the option Finishaction=REBOOT in my customsettings.ini to make sure the machine restarts after completion.

The next step is logging on with the local Administrator password to SYSPREP the machine by running the sysprep.exe /oobe /generalize /shutdown command.


Here we see SYSPREP is in progress. After a small while the machine is turned off.

Now the machine will be started again using the LiteTouch boot media (in my case I use WDS) and wait until the deployment wizard is started once more. The reason why I do this is that my deployment share is available and accessible by the Z: drive which is automatically mapped. Pressing F8 opens the command prompt.

All I need to is to start capturing an image using DISM which may look like the screenshot below (hmmm, makes me wonder why I chose that filename).


Now the capture can start.


After a while the capture completes and a captured Windows 10 image is available in the Captures folder of the deployment share in use. This image can be used for deployment by MDT 2013 U1, System Center 2012 Configuration Manager SP2/R2 or whatever tool used for deploying .wim files.

Basically the workaround consists of replacing the image capturing part with manual labour. I’m sure that other workarounds may be available but this one works for me. The image capturing should take less than 72 hours since that is the maximum time a WinPE session is allowed to run. Once the 72 hours are up, it will automatically restart the computer. This should be enough though to have the image file created.

Feel free to use this workaround. As usual, testing is required before using it in a production environment.

Let’s hope an updated release should have all these issues solved, the sooner the better…




Azure RemoteApp and App-V sequences: does it work?

Last year when Azure RemoteApp was announced at a conference, I asked the speaker about support for App-V 5 sequences running on the Azure RemoteApp platform. While the speaker actually questioned my question, I wasn’t really sure if App-V sequences are supported by Microsoft.

When Microsoft states a certain configuration is not supported, then they basically state two possible scenarios:

  1. The scenario has been tested and it really doesn’t work, a KB article will state why
  2. The scenario has never been tested at all

I wasn’t able to find any statement by Microsoft, this leaves me to believe it has never been tested.

Other projects limited my time to figure it out. This was fine as long as it was in Preview which allowed me to sit it out for a bit, until now…

Recently I was asked to deliver a masterclass regarding application provisiong using Azure RemoteApp. One of the participants asked me if App-V 5 sequences could be used. One of the other trainers, Alex Sweserijnen  (@AlexSweserijnen on Twitter), also started a healthy discussion with me about this feature. Since I’m more focused on application deployment than application scripting using MSI or App-V which is more Alex’ cup of tea, I am a strong believer in using App-V.

However, I am talking about App-V client in stand-alone mode because of my ConfigMgr background. I’m not so familiar with App-V streaming infrastructures. Since Azure RemoteApp is just a ‘black-box’ RDS server I see no technical limitations to run App-V 5 sequences as long as the following requirements are met:

  • App-V 5 client for RDS is configured in stand-alone mode, no streaming or ConfigMgr whatsoever
  • App-V 5 sequences are loaded and published prior to uploading the .vhd to Azure RemoteApp

Alex had a few small App-V 5 sequences available I could use for testing. I’d like to thank Alex for delivering them so I didn’t need to create them myself.

So I decided to find out if this scenario works. I used the following lab setup:

  • 1 VM configured as an RDS Session Host server which meets the requirements mentioned at
  • On the VM I installed App-V for RDS 5.1 in stand-alone mode
  • I added and published the App-V 5 sequences delivered by Alex, I used the following cmdlet for each sequence: Add-AppvClientPackage <whatever location>\package.appv | Publish-AppvClientPackage -Global
  • I shut down the VM using sysprep to prepare the .vhd for uploading

After uploading the image I created a RemoteApp collection by using the Quick Create option and I selected the image uploaded before. After taking a lunch break (provisiong takes quite some time) the RemoteApp collection was ready. So now I need publish some apps, the result is shown below:


As you can see , Azure RemoteApp is perfectly happy to publish applications sequenced in App-V 5.I adde some  The next question obviously is if they will actually work. So I need to test it on my client. So let’s start my Azure RemoteApp client.


So here are my apps published. Let’s start PuTTY to see what happens.


We can clearly see PuTTY is started as a RemoteApp.


Notepad++ works fine as well.

These test results show Azure RemoteApp is perfectly happy working with App-V 5 sequences. Keep in mind that applications sequenced must be able to run in a RemoteApp (basically RDS) environment. I can answer the question with YES: App-V 5 sequences can be run on Azure RemoteApp

I was kind of expecting this result since I see no technical reason why this shouldn’t work in the first place.

Feel free to play around with this yourself. The Azure RemoteApp environment allows you to test the environment by publishing the apps to a limited set of users before publishing them to all users who need them.


Azure RemoteApp template image creation: make sure ALL requirements are met

Building your Azure RemoteApp template images is quite a straightforward operation. You can create your image .vhd on-premises or you can use the Windows Server 2012 R2 Session Host from the Azure Gallery. The latter contains a complete script to check if all requirements are met before shutting down the VM with Sysprep (but doesn’t facilitate the requirement mentioned in this post).

Fortunately, Microsoft was nice to provide an overview with the requirements which must be met to prepare your template image(s) which is available at the following location:

Unfortunately, one requirement is missing which will cause the image upload process to fail. Before creating a generalized .vhd with Sysprep the file %SYSTEMDRIVE%\Windows\Panther\unattend.xml needs to be removed.

You can see in the Upload-AzureRemoteAppTemplateImage.ps1 file downloaded from Azure that the presence of this file is checked before the actual upload.

Below is the relevant part of the script that does this checking:

# verify unattend file locations

if(Test-Path -LiteralPath ($winVolume + “windows\Panther\Unattend\Unattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + $winDrive\windows\Panther\Unattend\Unattend.xml.”)

$validImage = $false


if(Test-Path -LiteralPath ($winVolume + “windows\Panther\Unattend\Autounattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + $winDrive\windows\Panther\Unattend\Autounattend.xml.”)

$validImage = $false


if(Test-Path -LiteralPath ($winVolume + “windows\Panther\Unattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + $winDrive\windows\Panther\Unattend.xml.”)

$validImage = $false


if(Test-Path -LiteralPath ($winVolume + “windows\Panther\Autounattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + $winDrive\windows\Panther\Autounattend.xml.”)

$validImage = $false


if(Test-Path -LiteralPath ($winVolume + “Unattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + ” Found: $winDrive\Unattend.xml.”)

$validImage = $false


if(Test-Path -LiteralPath ($winVolume + “Autounattend.xml”) -PathType Leaf)


Write-Error ($CurrentCultureTable[$UnattendFileError] + $winDrive\Autounattend.xml.”)

$validImage = $false




Too bad that Microsoft forgot to mention this in the requirements overview…



Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen