Share via

Worst Practice: Adding a run-as profile to your seed discovery

  • Article

Most management packs have to perform an initial discovery to first determine if the product that the MP services is present on a given computer.  These initial discoveries are sometimes called "Seed" discoveries and are most often light weight registry key based discoveries.

A problem can arise with customer sites if you associate run-as profiles with discoveries that are your initial seed discoveries.  Seed discoveries need to be able to be run on every computer and should not require elevated or special permissions.  Since run-as profiles are the means by which you give your customers control over the credentials to use for your monitoring (to run sensitive monitoring in highly secured environments, for instance), if you inadvertently apply a run-as profile to every workflow defined in your management pack, then customers can have a painfully difficult experience when they try to get the management pack to work.

The challenge comes with the way that run-as account distribution functions.  There are two scenarios where run-as profile behavior becomes a point of "how does it work" focus.  These are:

 

  • The workflow has a run-as profile defined, but the customer imports the MP and doesn't bother creating a run-as account and then associating that run-as account with the run-as profile(s) in your management pack.
    • In this case - the Operations Manager agent checks with the Management Server to see if there is a credential defined that it should use to run the workflow, and if none is defined, the agent will readily use the default action account that each agent has
  • The workflow has a run-as profile defined, and the customer defines a run-as account for that profile after importing the management pack.
    • In this case, the Operations Manager agent checks with the management server, finds that there is a run-as account associated with the profile and then asks for the credentials that should be used.  If the agent is not permitted to have the credential, the agent fails the workflow and creates an error (alert) that indicates that it was not able to run the workflow.

The problem arises if the customer chooses "more secure" for the run-as account distribution. In the more secure mode, the customer must name all of the servers that are to be allowed access to the run-as account credentials.

So how does this impact your mp?  Well, let's assume the customer is security conscious, creates run-as accounts for your MP's run as profiles, and thinks they are done.  You made one small mistake and your seed discoveries that are supposed to execute on every server have been assigned the run-as profile.  In this case, if the customer has not defined every computer in their environment (or scope) to be allowed to get the run-as profile, each computer that is not permitted generates an alert.

Since for a given MP, the % of computers in the environment that actually have the product being monitored is a % of the total environment (usually), this means that after importing the MP and configuring it, some % of their computers (often a majority) start generating errors and alerts that trace back to the management pack's technology in the customers minds.  Since those computers aren't associated with the product, customers ask "why does the SQL server pool complain that they can't run the workflows for Exchange?  (hypothetical example with names changed to protect the unfortunate).

So, lesson learned - NEVER associate a run as profile unless you know you need to - and avoid having run-as profiles on your seed discoveries that the rest of your product MP bootstraps from.