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 Object ‘OpsMgr 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 Condition ‘Selected 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.