MDT Task Sequence for Building Remote Desktop Session Host with Desktop Experience

When using an MDT  Task Sequence to build/deploy a Server with the Desktop Experience component there are a few issues you may encounter.  Firstly, I would highly recommend you make use of the “Install Roles and Features” MDT step which uses the ZTIOSRole.wsf to install your selected Roles and Features and perform a reboot for each one if necessary.  It works well.  You can happily select all of the Roles and Features you need from the one step.  Secondly, be aware however that if choose to install the “Desktop” Experience Role (and possibly others) this requires some Component Based Servicing actions that trigger a hard reboot when the Task Sequence isn’t expecting one and your Task Sequence will fail.  You might not realise it has failed as the server will simply be sat at the CTRL+ALT+DEL screen.

I read a few blog posts, one of which in particular related to using DISM to manually install each role, with a reboot step between each and a set of commands for temporarily disabling the TrustedInstaller service.  I didn’t like the idea of that, and for me, it didn’t work anyway – when the service was re-enabled and the server was rebooted it simply triggered the hard reboot anyway.  You might get different mileage.

My solution was simply to ensure that there is a “Restart Computer” step immediately following the “Install Roles and Features” step that installs the “Desktop Experience” role – to restart back into the running OS with a 60 second countdown.  I actually had two “Install Roles and Features” steps, the first does .NET 3.5 and 4.5 and the second step has all of my RDS related Roles and Features selected (Ink, Media Foundation, Session Host, Licensing Diag tools, Desktop Experience). I think it is important that you have selected the “User Interfaces and Infrastructure” node too.

I found this fairly reliable in that when the Desktop Experience Role is installed along with other roles and the server is rebooted gracefully by the ZTIOSRole.wsf, the Task Sequence engine started back up again quick enough to trigger the next “Restart Computer” step and whilst the countdown was occuring the TrustedInstaller initiated the hard reboot within the first 30 seconds.  The Task Sequence continued without error.

After wasting many hours getting this all working using Server 2012, I wanted to capture this build using Capture media – however the PrepareOS step failed with an 80004005 error about unbcl.dll (c:\windows\system32\sysprep\panther\setuperr.log).  This doesn’t happen if you run SYSPREP manually or if you are using Server 2012 R2 – it looks like this is as a result of the Task Sequence running the SYSPREP utility under SYSTEM credentials (as it is a Capture Task Sequence basically.)  For the moment, I am having to resort to performing manual Prep of the Configuration Manager Client, SYSPREP manually and boot into WinPE from a USB/ISO and perform a manual capture using ImageX (well, GImageX actually.)

ConfigMgr 2012 R2 MultiCast issue smsts.log showing HRESULT=800705B4)

I have had the satisfaction of getting MultiCast working within a customer environment, which is rare among many customers that almost bring their networks to its knees by way of incorrect switch configuration.  Their network guy was a real credit and absolutely knew his subject – so I felt I had to demonstrate a similar level of ability with Configuration Manager when the problems encountered getting MultiCast working seemed to fall into my ball park.

The SCCM Distribution Point was enabled for MultiCast and the OS Image package was enabled for MultiCast distribution.  Firstly, I hit a seemingly common problem where the MultiCast session would fail to start, causing an error HRESULT=8004005 in the smsts.log.  The English text accompanying that error suggested that the MCSKey could not be properly obtained or was invalid from the MultiCast enabled DP.  So I followed these steps outlined in several other forums;

  1. Un-checked Allow this package to transfered via multicast at package/image properties.
  2. Cleared SerializedMCSKey and SignedSerializedMCSKey in registry (HKLM\Software\SMS\MCS).
  3. Unchecked enable multicast at dp properties.
  4. Checked enable multicast at dp properties.
  5. Checked Allow this package to transfered via multicast at package/image properties.
  6. Checked transfer this package only via multicast

I have no idea how, or why this works, I can only assume that the initial configuration of the MultiCast DP doesn’t work and that only when you clear out the Registry keys mentioned and follow the process above do things get set correctly.  Randomness.  After giving a few minutes between each step and a few minutes after to let things settle,  I started the testing process again.

I was now seeing a different error, HRESULT=800705b4 in the smsts.log accompanied by text stating that the hash value was incorrect. The hash value was of course incorrect but only because the file downloaded was empty, so I judged that this was not your typical remove/re-distribute package task.  The download of the .wim file never started so I figured it must be something file location / permissions related.

In many of my customer implementations, I consciously choose to enable the “Allow anonymous connections” setting on the Distribution Point – as this alleviates quite some load off IIS authentications and quietens down the mass of W3SVC logs an awful lot – but I had a little voice in the back of my mind asking me to consider if MultiCast might be impacted by this setting.  In all but the most security conscious environments I do not see enabling this option as a particularly big issue – given that the content on SCCM Distribution Points is generally open to any Domain Joined machine or Domain User that wants it.  Configuration Manager is usually always configured with one or more  “Network Access Account” to accommodate the download of files by systems during Windows PE phase of Operating System Deployment but I couldn’t be sure that MultiCast would play by the same rules and work anonymously, so to speak.

I disabled the option on the Distribution Point for “Allow anonymous connections” and started the deployments again and this time we saw the full glory of MultiCast among the 5 test systems being built.  The Performance Monitor on the Distribution Point clearly showed that when the client systems were all participating in the MultiCast session for the Operating System Image the Network data being transmitted only to a single MultiCast IP Address at a healthy rate.  The test systems had 1Gbps connections and all finished the “Apply Operating System Image” step in approximately 15 minutes.

I do like to see technology working!