Discovery Does Not Work in ADFS 2012 R2 MP


UPDATE

Version 7.1.10100.1 of the management pack, published on June 16, 2014 has addressed the specific issue I called out in the post below.  I have tested this version and confirmed that (at least for my systems) discovery now works without my work-around.

I know there are other concerns raised for the MP, but in this blog post I'm only addressing the bug where discovery simply did not work at all.


This post refers to Microsoft.ActiveDirectoryFederationServices.2012.R2 (English Display String: Active Directory Federation Services 2012 R2)

Version:
7.1.10100.0

Date Published:
11/8/2013

The issue may be resolved in future versions.


The System Center Management Pack for Active Directory Federation Services 2012 R2 has two discoveries.  One is a simple, filtered registry discovery for the "seed" class, which works.  The other is a monolithic PowerShell script that targets the seed class.  It is intended to discover everything else, but it does not work.

The reason is a misunderstanding of how class instantiation of hosted classes works.

When you create an instance of a hosted class you:

  1. MUST add all key properties (if any) of the class.
  2. MAY add any non-key properties (if any) of the class.
  3. MUST add all key properties of any classes in the entire hosting chain.
  4. MAY add any non-key properties in the inheritance chain.

You DO need to explicitly create relationship instances for containment relationships.  You DO NOT need to explicitly create relationship instances for hosting relationships.

When a script returns a Data Item of type System.DiscoveryData, the entire data item is accepted or rejected.  If there are any mistakes in the Data Item, the whole thing is quietly disregarded.

The bug in the discovery is this line:

$artifactServiceInstance.AddProperty( "$MPElement[Name='Microsoft.ActiveDirectoryFederationServices2012R2.Authentication']/STSIdentifier$", $hostName )

The ArtifactService class is hosted by the Authentication class.  But the STSIdentifier property of the Authentication is NOT a key property, and therefore may not be discovered by the hosted class.

There are also eight cases where a hosting relationship instance is explicitly created by the script.

I am uploading a management pack with a work-around.  I disabled the original discovery script.  I then made an exact copy of the original discovery script.  I commented out the offending line, and I also commented out the needless hosting relationship instance creations.

This MP was written in the SCOM 2007 R2 Authoring console, so it is friendly to SCOM 2007 R2, SCOM 2012, and SCOM 2012 R2.

The original MP is found here: http://www.microsoft.com/en-us/download/details.aspx?id=41184

Microsoft.ADFS.2012.R2.FixDiscovery.xml

Comments (12)

  1. Anonymous says:

    Just checking back in, still seeing this issue, and it appears in the blog entry here there are 4 comments yet I only see 2, and then I guess 3 after I post this one 😉

  2. Anonymous says:

    UPDATE

    Version 7.1.10100.1 of the management pack, published on June 16, 2014 has addressed the specific issue I called out in the post below. I have tested this version and confirmed that (at least for my systems) discovery now works without my work-around.

    There are other concerns raised for the MP, but in this blog post I’m only addressing the bug where discovery simply did not work at all.

    Regarding the count of posts matching the number of posts seen here, I have no explanation. I have not moderated or removed any posts.

  3. Anonymous says:

    Mike,

    My farm servers all get detected, I just keep getting errors because the cmdlets are attempting to run on the not primary server. Does your xml address that issue?

  4. Anonymous says:

    Mike,

    I’ve installed 7.1.10100.1 and what I’m seeing is an issue where the MP attempts to connect to the secondary ADFS server and fails since it’s not primary. This then generates a warning, which falsely places my ADFS state to Warning, when this should not be
    the case.

    I would think that the script should detect that it’s running on the secondary and then stop.

    Here is the message I receive:

    PS0033: This cmdlet cannot be executed from a secondary server in a local database farm. The primary server is presently: adfs-01. To execute management cmdlets, either log onto the primary server or connect using PowerShell remoting. For more information see
    http://go.microsoft.com/fwlink/?LinkId=294129.

    Or, am I missing something here?

  5. Alexis Debloos says:

    Hello,

    That didn’t work for me, I import your Management Pack in our Scom 2012R2,then I restarted the Scom Agent on the ADFS 2012 R2 Server. There is nothing in our federation state view.

    Do you use a WID are a SQL cluster?

    Regards

  6. Anonymous says:

    Microsoft a publié une mise à jour de sont management pack concernant Active Directory Federation Services

  7. Anonymous says:

    Microsoft a publié une mise à jour de sont management pack concernant Active Directory Federation Services 2012 R2.

    Cette mise à jour concerne la résolution du bug concernant la découverte qui ne fonctionnait pas (plus d’informations ici : http://blogs

  8. William J says:

    I am getting the same error as Jeffery Patton. Any solution yet?

  9. Brandon C. says:

    Yep, same issue here as Jeffrey S. Patton and William J.

  10. Sunil_03 says:

    Hi ,

    I am facing the same issue with the latest version which is 7.0.8560.0. Nothing major in the event logs of agent managed systems. Any inputs here.
    Windows server platform is 2012 R2.

    Thanks
    Sunil

  11. pdc says:

    @Sunil_03 looks like you have the wrong MP.. the 2012 R2 MP is version 7.1.10100.1 the version you are referring to is the ‘non’ 2012 R2 version

  12. Douks says:

    I’m seeing the same "PS0033: This cmdlet cannot be executed from a secondary server in a local database farm…" issue with 7.1.10100.1 MP for 2012 R2.