ConfigMgr MP not discovering distribution points RRS feed

  • Question

  • Environment:
      SCCM 2012 R2 (2 site servers, multiple distribution points, all server 2012)
      SCOM 2012 R2
      Configmgr MP version 5.0.7804.1000


    When running a Site discovery for Configmgr from SCOM, I get the following 21406 error

    The process started at 7:44:04 AM failed to create System.Discovery.Data. Errors found in output:

    C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 3\5300\SiteSystemRolesDiscovery.js(1136, 7) Microsoft JScript runtime error: 'Props' is null or not an object

    Command executed:      "C:\windows\system32\cscript.exe" /nologo "SiteSystemRolesDiscovery.js" {5EE5D007-B79F-F5F3-5E30-0CEC9189CA79} {B28A4A53-1B79-80FB-2265-CCEDB158B390} sccm1.domain.local STA 8b5b6f1d-fbcd-456c-881f-54c3da3a2aed STB 2 dp1.domain.local dp1.domain.local sccm2.domain.local 4 STA sccm1.domain.local 2
    Working Directory:      C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\Monitoring Host Temporary Files 3\5300\ 

    One or more workflows were affected by this.  

    Workflow name: Microsoft.SystemCenter2012.ConfigurationManager.SiteSystemRolesDiscovery 
    Instance name: dp1.domain.local 
    Instance ID: {B28A4A53-1B79-80FB-2265-CCEDB158B390} 
    Management group: TEST

    Troubleshooting Steps taken:

    I have agent proxy enabled for all SCCM servers, each agent is running as LOCAL System, I have deleted/reimported the MP several times.

    Site Servers, software update points are discovered, distribution points,pxe , other servers are not.
    Wednesday, June 25, 2014 12:29 PM


  • Sometimes in the SCCM management pack, you need to initiate discovery manually.  This has caught me out a couple of times and I wrote about it here: http://www.dreamension.net/?p=760

    Basically - you need to manually execute the Hierarchy Discovery Task and the Site Services Discovery task from the Services and Site Systems Roles section in the SCCM management pack, in the Monitoring section of the SCOM console.

    My post has full step by step details if you get stuck.


    • Proposed as answer by Noel Fairclough Wednesday, July 2, 2014 1:31 AM
    • Marked as answer by Yan Li_ Monday, July 7, 2014 2:00 AM
    Thursday, June 26, 2014 11:53 PM

All replies

  • Check permission that local system {SCOM Machine} allow to monitor SCCM. Also Verify that your antivirus software is not blocking Monitoring of SCOM

    Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question, please click "Mark As Answer" Mai Ali | My blog: Technical | Twitter: Mai Ali

    Wednesday, June 25, 2014 5:06 PM
  • Sometimes in the SCCM management pack, you need to initiate discovery manually.  This has caught me out a couple of times and I wrote about it here: http://www.dreamension.net/?p=760

    Basically - you need to manually execute the Hierarchy Discovery Task and the Site Services Discovery task from the Services and Site Systems Roles section in the SCCM management pack, in the Monitoring section of the SCOM console.

    My post has full step by step details if you get stuck.


    • Proposed as answer by Noel Fairclough Wednesday, July 2, 2014 1:31 AM
    • Marked as answer by Yan Li_ Monday, July 7, 2014 2:00 AM
    Thursday, June 26, 2014 11:53 PM
  • Thanks for the info. I tried it but I get the same results.  The site server has an 21406 event for every distribution point. So Iknow that it knows about the DPs, it's just not returning the data.
    Wednesday, July 16, 2014 3:59 PM
  • We had this problem in our environment (exactly the same jscript hierarchy discovery error) and spent a good two weeks trying to fix it. I'm not exactly sure how we resolved it but what I think fixed the problem for us was creating overrides for the object discovery rules contained in the MP. 

    See my blog on our implementation: http://damonjohns.com/2014/07/01/monitoring-configuration-manager-2012-r2-with-the-scom-2012-r2-management-pack/

    My blog contains a screen shot and all the values I changed.

    You may ask why we increased the rate at which the hierarchy discovery rule executed with an override? Well in part it was due to

    A. Us having the issue and

    B. I was sick of trying to trouble shoot the event log error that by default only registered every 6 hours.

    After I created the overrides, the MP started discovering data. It wasn't immediate though, it took another 6 hours or so for it to start working correctly. I think what might be happening is that one of the discovery rules is not completing correctly which causes the others to fail - hence no data. I have no idea why shortening the time on the discovery objects made any difference. But...it worked for me.

    I will be the first to say that there is no technical reasoning or science behind my changes. I was stuck on this issue and I started tweaking the object discovery rules. Hopefully this works for others.



    Friday, July 25, 2014 12:15 PM
  • Hello all, anyone had any update on this issue?


    Tuesday, October 28, 2014 12:33 PM
  • Hi,

    did you get a solution for this Problem? we have here exact the same issue... we tried to modify the sitesystemrolesdiscovery script on line 1136, but not really with success...

    regards adrian

    Thursday, January 22, 2015 7:24 AM
  • Hi all,

    It seems to be a bug in the SiteSystemRolesDiscovery.js script.
    I have the same error, none of recommendations helped for me. 
    So I've captured the script file and looked into it.
    The 1136 line is:  $.ForEach(cfg["Props"].toArray(), function() {
    The error is raised because of cfg["Props"] here is Null, and toArray() method can't be called and there's no handling of this exception.
    This value of "cfg" is obtained earlier in script from wmi query of SCCM wmi interfaces (from SMS_SystemResourceList as res JOIN SMS_SCI_SysResUse as cfg).
    The cfg[Props] should return array of objects of SMS_EmbeddedProperty Server WMI Class.
    I've queried this values manually for some of discovered "ConfigMgr Site System Information" objects and got lots of objects SMS_SCI_SysResUse, some of them having "Props", some not.
    Since the exception the script execution is aborted and further code discovering roles and returning data to scom is not executed.
    I think the solution is to wait for updated MP from Microsoft or try to fix the flaw in script handling this exception.


    Yeah! Wrapped problematic script part with  if(cfg["Props"] != undefined) {}

    and all roles start to discover.

    Monday, April 27, 2015 12:31 PM
  • Hi Roman,

    Would you please share the exact steps you applied in order to wrap the problematic script part ? I've got the very same problem and my conclusion is also that this is a bug in the product especially after none of the workarounds available on the Internet have helped.

    Since I'm not that experienced with SCOM scripts I would appreciate if you can send me some basic steps in order to apply your modification. I'm curious to see if your workaround would help out my environment too.

    Thanks in advance.

    Wednesday, June 10, 2015 1:12 PM
  • Hi asg2ki,

    Of course, here are steps I did:

    1. Remove original sccm MP files from scom
    2. Unseal them to get editable xml files (http://www.ingmarverheij.com/scom-unsealing-a-management-pack/)
    3. Find in unsealed Microsoft.SystemCenter2012.ConfigurationManager.Discovery.xml the text (approx line 2009):  $.ForEach(cfg["Props"].toArray()
    4. Wrap that ForEach block with if operator:
    if(cfg["Props"] != undefined) {

    the result should be:

    if(cfg["Props"] != undefined) {
          $.ForEach(cfg["Props"].toArray(), function() {
             if ($.EqualsIgnoreCase(this.PropertyName, "IsPXE") &&
                 (this.Value === 1))
                isPxe = true;

    5. To mark the difference from original MP pack, change the version in manifest/identity section of all 3 files, e.g.:


    6. Seal the library file Microsoft.SystemCenter2012.ConfigurationManager.Library.xml 
    7. Get the Public Key Token from sealed mp library file:

    "C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools\x64\sn.exe"  -T  Microsoft.SystemCenter2012.ConfigurationManager.Library.mp

    8. In the rest 2 xml files set new Version and Public Key Token on reference to Microsoft.SystemCenter2012.ConfigurationManager.Library 
    9. Seal these 2 files
    10. Import new MP files to SCOM.

    Note that this modified MP is incompatible for upgrade with future Microsoft updates of this management pack (if any). 
    You would reseal new original MP or delete current version from SCOM (losing overrides) and import new one.
    If you want I can send you unsealed and corrected xmls so you could start from step 6.

    Wednesday, June 10, 2015 2:44 PM
  • Hey Roman,

    Thanks for the detailed guide. I managed to create the modified MP after having some adventures in realizing how to do so. Basically this was my first MP sealing activity but anyway process went just fine including the import part in SCOM.

    I already implemented everything in my SCOM environment and so far the modified MP works well on the detection phase which means that my "Distribution Points" are being monitored, however the approach with the modified MP doesn't seem to be a long term solution due to problems with the SCOM views especially for the "Display Name" and "Name" columns from within the "Servers and Site System Roles" section.

    Right now the servers that originally were not identified properly are showing blank space on their "Display Name" column while the "Name" column is filled with the "Microsoft.SystemCenter2012.ConfigurationManager.SiteSystemServer" string all over.

    I can still identify the individual servers via the "Path" column but the modified MP certainly makes a problem when using the "Hierarchy Diagram" because the real server names are just no visible and instead I can see the "Microsoft.SystemCenter2012.ConfigurationManager.SiteSystemServer" string throughout the diagram. This doesn't make things neat at all.

    My conclusion so far is that the original MP might just not be buggy at all where the reason why the "SiteSystemRolesDiscovery.js" script didn't engage identification process is simply because it couldn't properly identify the objects behind by their mandatory properties. I might be wrong of course but at least this seems absolutely reasonable to me.

    So all in all I think the real question is why the individual servers are not populating their data properly in SCOM. Right now I managed to identify that this happens with all "Distribution points" including "PXE" servers as well as the "Database" servers. Not sure if it's relevant to the monitoring part but my "Database" machines are still indicating "Not Monitored" status and I assume the behavior might be related to the fact that my SCCM DB is hosted on a Clustered SQL instance.

    Anyway let me know your thoughts. Any further suggestions are highly welcomed.

    Wednesday, June 10, 2015 7:25 PM
  • Just a small update since yesterday...

    So basically nothing else has changed so far but I noticed that I still get Event ID 10000 messages on the SCCM machine:

    A scheduled discovery task was not started because the previous task for that discovery was still running.

    Discovery name: Microsoft.SystemCenter2012.ConfigurationManager.CentralSite.Discovery

    It's just a blind guess of mine but I have the feeling that the site discovery task might be the one responsible for filling out the necessary properties for each server that are respectively required prior the execution of the Site Roles scripts. Looks like the Central Site Discovery script get stuck somewhere.

    I would appreciate if anyone could help me out troubleshooting this issue further as I'm out of ideas on how to go next. Also it seems that this problem is widely spread and so far there is no final solution. Most people who reported success in their environment doesn't seem to have nailed down the exact reason why things suddenly started to work on their end which makes me think, that either one of the faulty scripts/tasks is timing out at some point and letting other tasks to run, or there is some sort of maintenance task inside SCOM which is responsible for fixing some of the issues with the missing props values from within the database.

    Either way one thing is for sure. Removing / Adding back MP's and clients to SCOM doesn't seem to change anything at this stage. I've done multiple agent uninstallation, cache cleaning, etc. similar tasks but so far nothing have helped, so I'm totally opened for additional suggestions.

    Thursday, June 11, 2015 7:46 AM
  • Alright everyone,

    I think I finally started figuring out what's happening with SCCM. At this time I have no reason to think this is a bug in SCOM, but purely a strange behavior in SCCM probably caused by some sort of bug in the product.

    While I was dealing with the SCOM management pack, I started a side approach in tracking down the "props" parameter for each of the affected servers and after searching for an answer how to query the it I finally got this done via "wbemtest" command. Once I started "wbemtest" I connected it to the "root\sms\site_s01" namespace (replace s01 with your own site). Then I hit the "query" button and typed in the following:

    select * from sms_sci_sysresuse where itemname like '%distribution%'

    I've chosen "distribution" in my case because that's where I have problems primarilly, so this listed out all DP and WDS servers in my environment. Once I double clicked on a particular item, from within the new window I scrolled down to "Props" parameter and it indeed was set to "NULL" instead of "<array of embedded objects>" .

    My next approach was to get this query done via PowerShell so I used the "Get-WmiObject" command and typed in the following in a bit more filtered way (replace "SCCMServer", "DPSERVER" and other parameters with your own):

    Get-WmiObject -computername "SCCMServer" -Namespace "root\sms\site_s01" -query "Select * from SMS_SCI_SysResUse where SiteCode='S01' and NetworkOSPath like '%DPSERVER%'" |fl NetworkOSPath,RoleName,Props

    (sorry my programming skills sux, but I hope you'll understand the approach)

    This will list out the corresponding "Props" assignments for the individual RoleName based on a particular server you chose via the NetworkOSPath parameter.

    Anyway I started wondering what may have happened so that the props parameters are not filled out and finally I made just a small modification to one of my WDS instances by ticking the "Specify an FQDN for this site system for use on the internet" option in it's site role followed by un-ticking it again. Now this definitely engaged some modifications in the SCCM database because the next WMI query had shown that the "Props" parameter is properly filled with the "{Server Remote Name, Server Remote Public Name, BITS download}" etc. strings which I guess is what SCOM is looking for.

    By making this modifications to all my DP and WDS servers I was finally able to get SCOM querying the servers, however the adventures are not over yet. My WDS servers lost their props again and while I was investigating further the issue, I managed to figure out that this happens exactly after I assign a non-SelfSigned certificate to them. The moment I import the certificates, the moment where "Props" parameter is reset back to "NULL".

    So all in all SCOM is rightfully looking for a set of parameters in order to be able to identify the individual entities from a distributed application but SCCM is just resetting those parameters and preventing it from doing its job. I've tested the identification with the unmodified Management Pack in SCOM and I confirm that it does work out of the box when "Props" parameters are not "NULL".

    At the same time I'm still not comfortable with the fact that SCOM is not displaying anything in the "Display Name" column for my affected servers while it does for some other such as "WSUS" and "Reporting". The "Name" column for all affected servers indicates "Microsoft.SystemCenter2012.ConfigurationManager.SiteSystemServer" regardless of whether or not the "Props" parameter is filled out properly or it indicates "NULL" but I guess this is another thing to be troubleshooted. Frankly I'm not even sure what exactly I would need to see in those columns but pure logic says that I should see the server names just as it is with the "WSUS" instance for example.

    Anyway... For me using SCCM with SelfSigned certificates is not an option and as I mentioned the external Certs are just reseting "Props" immediately which ultimately breaks SCOM monitoring for those instances.


    If you try my approach with modifying anything in the "Site System" role of a particular server, please keep in mind that it fully reset all my PXE related settings so I had to reconfigure those from scratch. I'm not sure why this have happened but I would say it might be related to some sort of bug in SCCM or at least I don't think this was normal behavior. Also when I modified my DP servers the same way, they automatically switched from HTTPS based traffic to HTTP only. This just doesn't seem to be right but I would appreciate if someone can confirm this behavior.

    Any additional thoughts / responses from Microsoft Developers would be highly appreciated.

    Also if anybody else has some additional ideas for toubleshooting further this whole matter, feel free to reply back.


    I'm testing this whole approach on a W2K12R2 based environment with both SCCM & SCOM patched to the latest available versions (SP1 R2 for SCCM and UR6 for SCOM). Also I'm using a Clustered SQL 2014 SP1 instance as a backend DB.
    Friday, June 12, 2015 5:55 PM
  • RR Med,

    Unfortunately I won't be able to open support ticket with MS because I don't have active support contract with them at this time, but it would be great if you or anyone else can do so. Let's hope MS engineers will fix the issue and if you don't mind please keep us updated on your findings with MS.

    Thanks in advance.

    Wednesday, July 29, 2015 1:08 PM
  • Hi,

    Did you manage to open a ticket with MS regarding this issue. If yes, can you please post some updates ?

    Thanks in advance.

    Sunday, August 23, 2015 11:23 PM
  • yes, we opened a ticket and the "solution" was to wait for SP1CU2, which should fix the issue with the Distribution Point Settings. but it did not. the issue in SCCM, and the (probably) resulting issue in SCOM both still exist. further queries to MS Support on this ticket are unanswered so far.

    RR Med,

    Any progress on this? Experiencing the same issue myself.


    Tuesday, March 8, 2016 9:33 PM
  • Same here, CU2 did not fix the issue. I'll be submitted a ticket as well in hopes that they find a fix for it.
    Saturday, March 12, 2016 7:00 AM
  • We upgraded to the latest SCCM build and still no resolution. Any ideas folks?


    Monday, March 28, 2016 1:52 PM
  • There was a new management pack released, it will probably address all of these issues - I haven't tested it though.




    Friday, April 1, 2016 11:01 PM
  • Hi Damon, all

    I have imported the new management pack (version 5.0.8239.1008) and there is still no state showed for "ConfigMgr Distribution Point", "ConfigMgr Management Point" under "Servers and site System roles".

    I manually ran Site Services Discovery task several times, but nothing happened.

    I checked Operations Manager EV Viewer logs on the SCOM server..nothing relating to SCCM2012.

    Do you have any other suggestions how to resolve this issue?

    Many thanks,



    Monday, April 4, 2016 2:42 PM
  • The new management pack (5.0.8239.1008) does not fix the problem in SiteSystemRoleDiscovery.js.  It still throws a 21406 error "C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State\[temp.location]\SiteSystemRolesDiscovery.js(1251, 13) Microsoft JScript runtime error: 'Props' is null or not an object"

    And as I read the rest of the thread -- all the management pack could have done was possibly trap and maybe handle the error condition.  It looks like the error is in SCCM.   I'll try to post more updates as I can.

    • Edited by Razmus Friday, April 15, 2016 8:01 PM Additional information
    Friday, April 15, 2016 7:29 PM
  • Any update on this Razmus
    Friday, April 22, 2016 3:17 PM
  • Only that I have an open ticket on this issue with Microsoft Premier Support.  I have it as a low priority item, because no production systems are down and I wish to keep it that way.  :-) (I'd hoped to make progress on this today, but alas... Monday is another day.)

    In my case, in addition to the Distribution Points not having a value in Props, SQL Server and Site Server also have NULL values. 

    Friday, April 22, 2016 8:07 PM
  • My support engineer has confirmed this issue as a bug in the product (SCCM), and was able to reproduce.  She's escalating it to the product team, and has given them a link to this forum with a request that they post here with an estimated date when the underlying issue will be addressed.
    Monday, May 9, 2016 1:10 PM
  • This issue is resolved by adding 'NT Authority/system' and the computer object accounts (domain\servername$) for your SCCM site servers to the SCCM 2012 console/Security Role "Operations Administrator". This will allow the remote dcom/wmi access needed for the hierarchy discovery scripts to work from your secondary site systems. I hope this helps...
    Friday, July 8, 2016 4:19 PM
  • It's the SCCM 2012 "Operations Administrator" role - found in the SCCM 2012 console under 'Administration >Overview >Security >Security Roles'. Grant "Operations Administrator" role access to the nt authority/System account and the computer object accounts for the site servers showing not monitored in SCOM. The jscript files used by this SCOM management pack for hierarchy discovery can connect properly once the access is tweaked in SCCM to allow for a SCOM service running as local system to remote connect through dcom/wmi to the primary sccm server.
    Friday, July 8, 2016 8:49 PM
  • Any solution for this?

    Tuesday, May 9, 2017 6:31 PM