Just quoting my recent blog post on "mDOPING" your SCOM Console performance with some simple SQL tips you can find here.

Enjoy, and hope it helps!

Scenario:

After setting up your SCOM 2012 Management Group you later on decide to define a custom and friendly FQDN name for your SCOM Web Console to connect to it instead of to the server name where it is actually running.

You think you have done everything right… but… Boom!!! You get the following alert in the console:

And then you may say… WHAT???

Yeah it could end up happening…

I could imagine that someone out there may be struggling a bit with this issue so with this post I hope to provide some help on how to fix it and more importantly some easy ways of troubleshooting this things.

Additionally this is a very good sample scenario to show the real benefit of a new feature in SCOM 2012: The On-Demand Discoveries!

Hope you enjoy!

Starting briefly by what you most probably have configured

You went to DNS and defined your custom ALIAS:

You went to IIS Manager and you defined your Bindings appropriately:

You event went to the SCOM Console and you defined the Web Console address:

After all that you even tested the Web Console:

You feel proud of yourself because you did a good job.

Nice one!

HOWEVER…

Even though everything seemed to be working fine you experience the alert I've mentioned above.

Just to recap:

Looking into the alert properties (in the Alert Context tab) you see that it is actually testing something else:

And then you may say again… WHAT???

And you may think: SCOM it's not working properly!!!

Well… to be honest… kind of… anyway; bottom line it's actually a custom setting right?

Let me explain you …

How to troubleshoot this?

Open the SCOM Console and click the Monitoring button. Then select Discovered Inventory on the navigation pane.

Then right-click the results pane in the middle, type in as shown, and select Web Console Watcher.

You'll see the red state for the instances of that class and see that the Web Console URL is incorrect:

Now that we have a clue, from where this data comes from?

Check Object Discovery

Click on the Authoring button and on the navigation pane select Object Discoveries.

Scope your console to just the Web Console Watcher class:

And select the rule as shown:

Right-click it, open its properties and select the Configuration tab:

Now you can see that the data is actually coming from the registry on your Web Console Server.

Checking that you see (below) that the URL's are incorrect (not only the Web Console but the AppAdvisor and AppDiagnostics consoles as well, the last two are related to Application Performance Monitoring for those who didn't know yet…).

How to Fix it?

Update all three values accordingly:

Well done! That's it.

BUT…

You may ask: Based on the Discovery rule configuration now I have to wait 1 day??

No!

How to get this done and showing as fixed? … By triggering a SCOM 2012 On-Demand Discovery

… will be indeed the easiest and quickest way!

To do it, open a SCOM Powershell console and run the following (remember we saw the discovery name earlier on…):

Get-SCOMDiscovery | where {$_.DisplayName -eq 'Discovery rule that populates Web console watchers'}

Take note of the Id value. Which was a101fce3-925e-24d5-d430-0b32aa6b1433 as you can see on the screenshot above.

Then click the Monitoring button and select Management Servers State on the Navigation Pane:

Then select the server as shown and click Trigger On Demand Discovery:

Select the DiscoveryId parameter and click override:

Type in the new value as shown:

Click Override and the Run.

Wait for it to complete:

Going back to Discovered Inventory you may still see the Web Console Watcher as unhealthy although the URL could be already updated as shown:

After a few moments the monitor is kicked and you should see the Watcher finally Healthy:

YAY!

You could get the Windows Azure SQL Database Management Pack for System Center 2012 version 1.5.4.0 from here.

It enables you to monitor the availability and performance of applications that are running on Windows Azure SQL Database however bear in mind that it's only supported in SCOM 2012.

My two cents will be:

In case you also didn't know yet; there is a new MPViewer v2.3 available here (Thanks go to Daniele Muscetta)

With it you can now have a look over this or other SCOM 2012 MP files.

It's always interesting to have an insight beforehand over what an MP does, specially the discoveries right? J

Enjoy!

How about if my Operations Manager agents are in maintenance mode and I want to run a task against them by using Operations Manager?

The answer is:

Yes they will run. Either the Agent tasks (below left) or the Console tasks (below right) would run as you could see on the screenshot.

What I would like to add is:

Bear in mind that tasks run with less priority and they could potentially be postponed on an Operations Manager 2007 R2 Management Group where the RMS is heavily processing Configuration or pushing out Management Packs.

How about in SCOM 2012?

Although there are now Resource Pools enabling for sharing the workload between their members the tasks are still less priority.

It's unlikely that on a SCOM 2012 Management Group you face the issue stated above however…

The recommendation:

Based on a recent scenario I've faced on one of my customers which was still using SCOM2007 R2 my best recommendation would be:

If you want to trigger a very important task that should finish ASAP on an Agent or group of Agents, always ensure the required task workflow is performing well by triggering a simple task of the same type (Console or Agent) against them.

Only if successful trigger the critical one.

If you could not trigger any tasks at all: you should carefully review the capacity of your environment and overall performance of the Management Group.

The root causes could vary and further investigation would be required to identify the issue.

That would most probably include capturing Operations Manager trace logs on all the SCOM Management Servers, SCOM Gateways and the Agents involved.

Info on Diagnostic tracing in Operations Manager: https://support.microsoft.com/kb/942864

Hope this helps!

https://blogs.technet.com/b/kevinholman/archive/2008/04/15/opsmgr-security-account-rights-mapping-what-accounts-need-what-privileges.aspx

As it was so useful just thought of bringing in an updated version of it but aligned with System Center 2012 Operations Manager SP1.

Hope you guys find it useful!

OpsMgr 2012 SP1 Security account Matrix v1.0.xls

You may think that those Discoveries don't work?

That's not in fact true…

Whilst the "typo" on the Management Pack Guide and other resources doesn't get sorted a Possible Way Of helping you to get it to work is telling you:

Where to enable Agent Proxy?

• Central Administration Site (CAS)
• Primary Sites

If not enabling Agent Proxy for the Health Service on the machines with those Site Roles you will also see 33333 events on the related Management Server as well.

Also:

You might need to override Microsoft.SystemCenter2012.ConfigurationManager.SiteSystemRolesDiscovery (Which targets Site System Information class hosted by the CAS to avoid it to timeout.

Default setting is: 300 seconds. Carefully override it in multiples of 30 seconds until it works.

Resuming: In the current MP Guide the highlighted text below should not be read.

Agent Proxy

For the Configuration Manager monitoring pack to discover objects, you must turn on Agent Proxy on every site server except for the primary site and the central administration site.

This was one Possible Way Of getting it to work and Hope This Helps somehow!

Note: You should be able to find a copy of this blog post here as well.

• Create new user accounts in Active Directory
• In case the user already exists you need to create a new distinct SAM account name
• The new SAM account name should be incrementally named in case another ones exists

If you use a Get User activity and multiple instances are returned that could cause an error in your Runbook.

In this example the Get User activity will check for the existence of an account that contains a specific username we are about to create (in this case SVC-OPSMGR-DB) which could return multiple instances:

In the scenario as there were two instances it will trigger the actions twice, this is by design, so naturally the first action created the requested user but the second one fails:

Checking in AD the user that was requested got created and incrementally named (SVC-OPSMGR-DB2):

The user name was processed this way:

Basically: In case we find a user with same name the next account will be appended with 1, if we find two it will be appended with 2 and so on…

So one Possible Way Of dealing with the multiple instances that may come from the Get User activity could be flattening the data that gets published from it:

After that is just about comparing the total number of accounts returned:

And define the SAM Account Name in the Create User (Alternative) appending the count:

Then the new user SVC-OPSMGR-DB3 got created without errors in the runbook:

The Runbook for this example looked like this:

This was one Possible Way Of doing it and Hope This Helps somehow!

Note: You should be able to find a copy of this blog post here as well.