Here is the last ported post from my old bog site. The vast archive of SCOM knowledge (3 full posts) have now been migrated to the new blog!
I’ve worked with a variety of management packs over the years. One headache that I have often encountered when implementing a new MP has been the inconsistency and lack of documentation related to the discovery scripts. Every MP has discovery scripts yet they all seem to take a different approach. A discovery can be based on a wide range of information not limited to data previously collected in SCOM, registry queries, WMI queries, internal scripts, external commands, or information collected by the monitored application itself. Often a management pack will use multiple methods to identify and categorize servers, roles, and components. Not only do the discovery methods vary by management pack but the overall structure of the discovery hierarchy, timing, and complexity of design varies significantly as well. As a result it can be difficult to identify and troubleshoot discovery rules.
Here are some recommendations to help you avoid, identify, and address discovery rule processing issues:
Read the MP guide in great detail.
I know this can be hard. I find it to be quite ridiculous that this is necessary but it is what it is. These guides are often incorrect, incomplete, similarly worded, and downright boring yet they often contain many useful nuggets of information. In some cases you will be completely lost without the MP guide. In addition to configuration steps there are often steps for optional configurations. Make sure to review the guide prior to any upgrades as well; though updates are usually sparsely documented. If you deal with multiple management packs, I recommend finding some way to extract and store the useful highlights for future reference.
Enable agent proxying on all agents.
Officially the proxy setting should only be enabled when needed but I’ve never heard a reasonable argument for not setting this as the default for all agents. The administrative overhead of managing this setting is reason enough but nearly all MP’s require agent proxying for proper operation and discovery. You will save yourself a world of frustration by setting this as the default. Simply run the following command from the SCOM shell: Set-DefaultSetting -Name HealthService\ProxyingEnabled -Value True
Learn the discovery hierarchy for every new MP.
This takes some effort but it can be very helpful. I recommend using Mpviewer to extract the MP into an Excel spreadsheet. This will give you a concise listing of the discovery rules. You may also want to extract a readable copy of the sealed MP (this is great for reading internal discovery scripts). Dig into the properties of these rules one by one and arrange the rules so you can start to visualize the workflow. You should see 1-2 core rules that branch out to rules for more specific attributes.
Here is an example of the command to extract a readable copy of a sealed MP:
Get-SCOMManagementPack -Name ” Microsoft SharePoint 2010 Products ” | Export-SCOMManagementPack -Path “C:\Users\admin\Desktop”
There are two reasons to deconstruct your discovery rules. First it helps to develop a deep understanding of the MP that will aid in troubleshooting and in proper targeting of additions and overrides. The second, and possibly the most important, benefit is arming yourself with the knowledge necessary to manage the timing of discovery processing. These rules often need to be optimized to reduce configuration churn by reducing the frequency of discovery rule processing.
Never assume your discovery rules are working.
Make sure your servers and applications are properly discovered after setup and following any additions or major changes. There is a risk that environmental changes could cause a break in discovery but it is more important to make sure everything is working first (how else will you know when something is broken?). The MP-specific state views are the best way to validate these discovery rules. If you are unfamiliar with the monitored application, get a SME to sit with you to review these state views. Validate that all of the servers and attributes are properly listed in the application MP views. Watch out for missing information, cross discovery of unrelated servers, or unexpected green circles with no check mark (green halo) as indications of a possible discovery issue.
Note: I experienced discovery obstacles when working with SCCM, Exchange 2010, and all instances of SharePoint and instant messaging services (LCS, OCS, & Lync). Legacy SharePoint in particular does some pretty goofy stuff to avoid cross discovery issues. Older MPs were particularly bad but occassionally someone repeats an old mistake.
Research you management packs online.
If you don’t have time for this, like most SCOM admins, turn to the web for assistance. At least take the time to do online research prior to implementing each new MP or update. The experience of others will be immensely helpful. It is not uncommon for the MP guide to be incorrect or incomplete. Recommendations on discovery rule tuning to reduce configuration churn are often readily available. Rushing forward with a new MP without prior research is tempting but is also a recipe for countless problems. Make use of your implementation momentum to push for those optional configurations…you know it will be much harder after everyone has settled in with the post implementation results.