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!

Advertisement