Monday, September 21, 2009

Crucial OpsMgr Services explained. Part II: The SDK Service

Postings in the same series:
Part   I: The Basics.

As stated in Part I, the SDK Service is present on every OpsMgr Management Server but runs only on the RMS. Again I repeat myself: leave it disabled on the OpsMgr Management Servers. Only the RMS must have this service in a running state.

The SDK service in a nutshell: (Thanks to Maarten Goet, who corrected me on some points here)

  1. Provides access for the OpsMgr (Web) Console to the OpsMgr database
  2. Importing and storing Management Packs in to the OpsMgr database
  3. Stores Management Group information in to the OpsMgr database
  4. Viewing current state of a monitored object

Also good to know:

  1. Access for the OpsMgr (Web) Console
    Every launched OpsMgr (Web) Console connects to the SDK Service on the RMS in order to retrieve the data, no matter where the Console is being run from. So every opened OpsMgr (Web) Console causes an additional load on the RMS. The same goes for running the OpsMgr PowerShell extensions. This one also connects to the SDK Service.

    There is also a misunderstanding about the OpsMgr Web Console since many people tend to think that it doesn’t put that much of load on a RMS compared to the ‘full’ version of the Console. But that is not true. I saw a comment of Maarten Goet on a thread on the the Microsoft TechNet OpsMgr Forum where he explained it. I quote his words:

    …Anybody telling you that the webconsole "uses less memory on the RMS" is lying. The webconsole uses the SDK just as the 'full' console does. Listing the Active Alerts or Computers view (or anything else for that matter) uses the same API calls. Given that IIS hosts those web users you could even say that from a server perspective the Webconsole requires more resources…’ 

    This is something to reckon with when deploying an OpsMgr environment.

  2. Encryption Key 
    The SDK service is also the owner of the Encryption Key (information is stored in the registry of the RMS) for the Management Group. With this key the Run As Account information - stored in the OpsMgr database - is accessed. This Encryption Key is needed when promoting a Management Server to Root Management Server.

    Want to know more about the Encryption Key, how to make a backup of it? Go here. How to restore it when it is lost, or how to promote a Management Server to RMS? Check out this article.

  3. Keeping track of the SDK connections
    Even though it is not watertight (explained later) it still provides a way to see how many (approximately!) (Web) Console and OpsMgr PowerShell connections are running. It is based on a blog posting of Kevin Holman, found here.

    Open the Console go to Authoring > Rules > New Rule > Collection Rule > Performance Based > Windows Performance > Next 
    (Don’t forget to put this Rule in it’s own MP.)

    - Give it a proper Rule Name, select ‘Performance Collection’ as Rule Category, ‘Root Management Server’ as Rule Target and leave the rule enabled > Next

    - In the next screen hit the button Next and select the RMS as Computer, as ObjectOpsMgr SDK Service’ and as counter ‘Client Connections’ > OK
    - Leave the interval at its default setting (15 minutes) > Next

    - Here I do not use Optimized Performance Collection Settings because this will influence the accuracy negatively > Create

    - Go to Monitoring > SDK Connections > right click it, select New > Performance View > give it a proper Name and Description

    - Select as ConditionSelected by specific Rules’, click the link ‘specific’ in the Criteria Description box
    and select the earlier created Rule (SDK Connections) > OK > OK

    It takes some time (15 minutes timeframe) before some data is collected. For this screen dump I have lowered the Interval to 1 minute (don’t do this in production environments) and also altered the Time Range:

    Hmm. Strange. I have only one Console open, and already five connections are being shown? Well, apparently other connections/processes are at work here as well.

    First of all, you have the SDK service running on the RMS, which counts for one connection. The Console I run is also counted as one connection. This leaves three connections which seem to be unaccounted for.

    But that is not true. Underwater there are many processes busy which use the SDK service as well, like Connectors. So even though this Performance View delivers a better sight what is happening, it still needs some ‘translation’. Be aware of this.

    Another example, with – besides an open Console – also a running Web Console and the OpsMgr PS extensions running:

    - And yes, there is a report as well. Since it is a rule it collects (performance)data to be put in a report: Go to this blog posting of mine. At step 4 select the RMS as Windows Computer, at step 6 select as Performance Object ´OpsMgr SDK Service´ and as Counter ´Client Connections´ (contained within the earlier created rule) and click OK (twice).
    Select a date and run the report. Be aware though that the rule needs to run some time in order to collect sufficient data to be shown in the report.


LayneR said...

Hi Marnix. I believe Kevin Holman had a post about creating a performance collection rule to track SDK connections.

Marnix Wolf said...

Hi LayneR.

Thanks for your feedback. I should have known! :) I will update my posting with this information.

Best regards,
Marnix Wolf

Tom Martin said...

Hello Marnix,

I had a question regarding the performance hit on the RMS when a SCOM console is opened (either the Web console or the full console). Does the performance hit matter if the user has access to a scoped view as compared to full access? For example, say our environment has 150 management packs total and I've created two user roles: one scoped so the user only sees one management pack, and the other user has full admin access and sees all 150 management packs. Is the second user going to put more of a performance hit on the RMS?


Marnix Wolf said...

Hi Tom

Thanks again for visiting my blog. Again, a good question.

First of all, it depends on the version of SCOM. R2 has an engine which is much more intelligent. So the Views are loaded way much faster compared to RTM/SP1.

Having said that, a scoped View filters out certain or many items.

But it still uses an instance of the SDK service, no matter how many or less Views are scoped in to the Console.

And this instance has to be provided by the RMS.

Of course, a scoped View with only some MPs will be using the SDK instance to a lesser extend then a View where 100+ MPs are to be found. In the last situation much more 'browsing' will take place and thus having that SDK instance doing more work in order to show the Views being accessed in the Console.

Hope this helps.

Best regards,
Marnix Wolf