SCCM Multicast - MCS SignedSerializedKey is empty
Hi All, W2K8R2, SCCMSP2R2, Mcast configured, either with static mcast cope or via dhcp errors in deploying - no matter whether autocast or not. Seems there's an issue with the Multicast Namespace - how do i fix this ? Thanks in Advance and kind regards, Jan Update - June 2nd 2010 - Deinstalled Multicast and Reinstalled Multicast Role - No Change - Above AND removed PXE Role and added it back - No Change - Above AND removed WDS and Reinstalled WDS - Worse now - WDS not starting anymore - Above AND removed/renamed the RemoteInstall Folder - No Change I'm getting quite angry - this is not how an Enterprise Class System should function in the Year 2010. WIll probably call PSS on Friday and declare a Hot Site ;-) Updated again - June 2nd 2010 Manually ran the MSI for the PXERole and it installed and configured the WDSService - so all this is now fine and in top shape. Unicast Deploys as before. MCS Errors are now of a different Variety. LOG Snippet from MCSISAPI.LOG ========== BEGIN: IsapiThread ========== smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) Query string to parse: 'op=keyinfo'. smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) Got MCS Certificates smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) MCS SignedSerializedKey is empty smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) KeyRequest::HandleMessage failed with errorcode (0x80040805) smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) Failed to process KEYINFO request for client smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) MCSRequestHandler::HandleMessage for Op KEYINFO failed with server errorcode 2053 smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) ========== END: IsapiThread ========== smsmcs 6/2/2010 9:05:15 PM 3336 (0x0D08) What gives ?
June 1st, 2010 6:09pm

Got it fixed - PXE and Multicast are now running. Here's what I did: Check that: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\MCS\SerializedMCSKey and HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\MP\SerializedMCSKey are the same. Then copy HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\MP\SignedSerializedMCSKey into HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\MCS\SignedSerializedMCSKey and reboot the server.
Free Windows Admin Tool Kit Click here and download it now
June 2nd, 2010 10:49pm

Hello Jan, I searched the internet for a solution and why the key is not populated and couldn't find any helpful information. As the signing is necessary for roles like MCS, SMP, etc. I had to investigate some time to figure it out why this happens. I found the problem why that happens and the workarround: if the SignedSerializedMCSKey will not be populated their is an issue with the site system connection to his parent site and the secure key exchange between the site systems. Manually updating the entry will only work if you have no hierarchy or only one SiteSystem with one MP! Furhtermore all systems are installed on the same machine! The certificates will be send from the highest hierarchy down to the connected primary site systems. As long as this is broken no signing of site systems in downlevel sites will happen and some roles will not work. There is only one way to get it fixed automatically! 1. Open hman.log 2. Open Configmgr navigate to site Management, select Site system, right click select properties and set parent site back to Central Site. Verify that the setting Parent site: is set to "None". 3. Check hman.log Now, you will see an entry "Signed MP Cert xxxxxxxx" directly after "Starting processing MP Certificates". All site system which are currently registered and in use will be informed that their is a new certificate. 4. Open the registry on the site system with the MCS Role Verifiy the SignedSerializedMCSKey. It should be populated now. 5. Reconnect site system to parent Just select the parent site system under the properties tab on the primary site server and verify that configuration in the hman.log file. Hope this helps to solve the problem. It took me two nights to figure it out and get my MCS,SMP Roles running in the whole hierarchy!Tarkan Koemuercue
May 2nd, 2011 9:35am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics