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

Error:

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.

Observations
Site Servers, software update points are discovered, distribution points,pxe , other servers are not.

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

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.

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.

same error in our infrastructure

Microsoft JScript runtime error: 'Props' is null or not an object

SCCM2012R2-UR2, SCOM2012R2-UR2

the answer marked in this thread should be unmarked, it does not solve the issue.

• Edited by RR Med Friday, July 25, 2014 9:50 AM

same error in our infrastructure

Microsoft JScript runtime error: 'Props' is null or not an object

SCCM2012R2-UR2, SCOM2012R2-UR2

the answer marked in this thread should be unmarked, it does not solve the issue.

• Edited by RR Med Friday, July 25, 2014 9:50 AM

same error in our infrastructure

Microsoft JScript runtime error: 'Props' is null or not an object

SCCM2012R2-UR2, SCOM2012R2-UR2

the answer marked in this thread should be unmarked, it does not solve the issue.

• Edited by RR Med Friday, July 25, 2014 9:50 AM

same error in our infrastructure

Microsoft JScript runtime error: 'Props' is null or not an object

SCCM2012R2-UR2, SCOM2012R2-UR2

the answer marked in this thread should be unmarked, it does not solve the issue.

• Edited by RR Med Friday, July 25, 2014 9:50 AM

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.

Cheers

Damon

• Edited by Damon A. Johns Friday, July 25, 2014 12:25 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.

Cheers

Damon

• Edited by Damon A. Johns Friday, July 25, 2014 12:25 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.

Cheers

Damon

• Edited by Damon A. Johns Friday, July 25, 2014 12:25 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.

Cheers

Damon

• Edited by Damon A. Johns Friday, July 25, 2014 12:25 PM

thanks for the suggestion, i followed it 1 by 1, but this did not change or solve the problem.

we still get the same error message for each and every site server in our infrastructure:

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

i opened a bug report with microsoft support

the technician told me that the bug is known to MS but no further information is available for now.

Hello all, anyone had any update on this issue?

Thanks

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

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.

• Edited by Roman Annenko 16 hours 8 minutes ago

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.

• Edited by Roman Annenko Monday, April 27, 2015 3:01 PM

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.

• Edited by Roman Annenko Monday, April 27, 2015 3:01 PM

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.

• Edited by Roman Annenko Monday, April 27, 2015 3:01 PM

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.

• Edited by Roman Annenko Monday, April 27, 2015 3:01 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.

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.:

<Identity>
	<ID>Microsoft.SystemCenter2012.ConfigurationManager.Discovery</ID>
	<Version>5.00.7804.1001</Version>
</Identity>

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.

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.

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.

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.

Caution:

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.

FYI,

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.

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.

Caution:

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.

FYI,

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.

• Proposed as answer by RR Med 18 hours 35 minutes ago

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.

Caution:

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.

FYI,

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.

• Proposed as answer by RR Med Wednesday, July 29, 2015 12:36 PM

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.

Caution:

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.

FYI,

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.

• Proposed as answer by RR Med Wednesday, July 29, 2015 12:36 PM

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.

Caution:

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.

FYI,

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.

• Proposed as answer by RR Med Wednesday, July 29, 2015 12:36 PM

asg2ki,

thank you for this incredibly detailed post. the effect "distribution point properties reset" already happened to us sometimes in SCCM and we were wondering what was the cause of it. now thanks to the information that you provided it is clear and reproducible.

to clarify, i followed your mentioned steps:

Open site system properties in sccm console servers and site system roles
uncheck the checkbox specify an FQDN for this site system for use on the internet
press apply
reopen the same properties and put back the FQDN, and apply.

effect:

after some time all settings of the distribution point are reset. pxe support is disabled, HTTPS switched back to HTTP, content validation is off. we found out when helpdesk complained they no longer can reach the PXE server... :)

we will open a bug ticket with MS, because I do not think they are monitoring this forum. I would recommend you to do the same or anyone else with this issue.

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.

Hi,

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

Thanks in advance.