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!

Policy Evaluation Failed. Error Code 0x87d00267.

I have recently been engaged on a customer site who have been having all manner of random and frustrating problems with Operating System Deployments.  Sometimes the OS image would fail to download, sometimes the ConfigMgr Client would fail to download or install, sometimes any given application would fail to install.  Failure Status Messages include the below;

Install Software failed, hr=0x80070001. The operating system reported error 2147942401: Incorrect function.

 

Failed to configure OSD setup hook (0x80091007)
Configure hook failed with error code (80091007).
Failed to install setup hook (80091007). The operating system reported error 2148077575: The hash value is not correct.

 

Installation of image 1 in package P0100198 failed to complete.. 
he hash value is not correct. (Error: 80091007; Source: Windows). The operating system reported error 2148077575: The hash value is not correct.

 

They had been through all the usual Refresh DP/Validate/Remove/Re-add nonsense that sometimes fixes corrupt applications to no avail.  This all added up to something that is usually very unlikely to be the fault of Configuration Manager, the way it is configured or the applications within.  This had plagued them for weeks, months perhaps.

In the scenario where one or more of these errors were occuring when deploying physicsal clients from a physical distribution point, they found that something unusual was happening with their Riverbed setup – which was that whenever the task sequence rebooted and proceeded to try and install the next application, the HTTP session was somehow being interfered with by the Riverbed device – resulting in the client being unable to request policy after the reboot.  They took the Riverbed out of the equation and that resolved some physical > physical build issues.

Where we were experiencing one or more of the errors above in the VMware environment, it was discovered that most (if not all) of the VMware test client systems and VMware Distribution Point servers were configured with either the E1000 or E1000E ‘legacy’ Network Adapter.  Changing the client systems to use the E1000E didn’t help and we are not at a convenient point to include the VMXNET 3 adapters in the boot images (nor does the VMXNET 3 adapter support PXE Boot.)  It was therefore decided (by me, lol) to take a punt on re-configuring the Distribution Point Server to use the VMXNET 3 adapter.

Success!  VM DP to VM Client and VM DP to Physical Client deployments all taking place without any such random nonsense occuring.  A quick Google session revealed the use of the E1000/E adapters in VMware is generally bad Ju-Ju and so I implore you all to consider making sure that where possible you use the VMXNET3 adapter (Requires VMware tools installing) on your VM Distribution Points.


Task Sequence Install Applications 80074005, HTTP 401 Unauthorized

Always use the FQDN when specifying your Network Access (and possibly other) accounts within Configuration Manager, ie: “DOMAIN.COM\NetAccess”.  I found that this can resolve issues where you are building WORKGROUP or UNTRUSTED DOMAIN systems and they are failing to obtain content from the Distribution Point.  In short, it appears that IIS/Kerberos does not appreciate systems from other domains coming in and specifying the NETBIOS domain name as part of the Network Access Account, ie: “DOMAIN\NetAccess”.  This may be because systems in those domains have a different DNS suffix and/or are unable to resolve the NETBIOS domain name.

Failed to Sync Update. Error: The Microsoft Software License Terms have not been completely downloaded and cannot be accepted.

I was seeing the above error in the Configuration Manager 2012 SP1 wsyncmgr.log in a customer environment and I suspected this was as a result of SQL services being interrupted during the WSUS syncronisation process – which is never a good thing.  Despite trying to remove classifications and removing/reinstalling the SUP role the problem persisted.  When I loaded up the WSUS console and filtered for all updates I noticed that around 12 updates were showing that their content download (the EULA) had not been successfully downloaded.  I simply highlighted the affected updates, right clicked and chose to “Retry Download” and these changed to Pending Download and eventually all was OK.  A re-sync in Configuration Manager then resulted in a happy wsyncmgr.log and a successful sync event.

There is apparently a hotfix available for this issue which might be worth a try if you encounter this issue when proxy credentials are required;

http://support.microsoft.com/kb/2838998

Task Sequence step fails with ‘Incorrect Function’

This is just a quick post to help anyone out understanding what this error actually means.  In a task sequence, particularly an MDT integrated one, there will be tasks which use command line tools such as cscript.exe or xcopy.exe and when these fail to run you often get a traditional MSDOS based error code such as 1, 2, 3, 5 etc.  Error 1: Incorrect function, is usually when you have something that is running something like “cscript.exe myscript.vbs” but the script specified cannot be found to be ran.  Check your script location and paths.

.NET Framework failed to register Configuration Manager dll’s

I had a recent interesting experience where Configuration Manager 2012 SP1 setup completed successfully however there were problems lurking under the hood.  It was only until I proceeded to configure the environment and add additional roles that these came to light.  Several of the component installations failed, in particular those of the newer roles which require .NET 4.0 and their respective logs showed some very unusual errors I had never, ever, seen before.  The CloudMgr.log was absolutely full of instance creation errors.

At first I put this down to the Windows Server 2008 R2 virtual machine – it was based on an image and provided to me in a bit of a rush and with some history of a power failure/unexpected shutdowns – however a fresh DVD installation of the Operating System resulted in the same errors.  My attention then turned to the ISO media provided on the server that I extracted and performed the installation from – perhaps it was corrupt?  Not quite, but it was the cause of the problem.

The ISO file had been copied up to the server by somebody else over the network and for some reason the server took to marking the file in it’s properties with “This file came from another computer and might be blocked to help protect this computer” and gave me an unblock button.  I hadn’t noticed this and the result was that all of the subsequent extracted files were all marked the same.

windows-server-2012-unblock-file

The problem here is that the regasm.exe utility of .NET Framework 4.0, in it’s default configuration, will not permit the registration of dll’s that it perceives as coming from remote sources such as unc paths.

The answer here is not to proceed with the .config file editing solution offered by the only blog post I found regarding this error, it is simply to ensure that this attribute/property is not applied to any of the files from the Configuration Manager 2012 media before you start installation.  Attempting to patch the installation back together I am sure would be a futile and unsupportable task – there are simply too many possible errors introduced into the installation.  I even found that when you provision site roles on other site systems, the file attribute traveled with the dll’s copied to the remote site system and introduced role issues there.

It’s incredible, how something so random and inert could cause so many issues.

Follow

Get every new post delivered to your Inbox.