Possible Way Of: Having SCOM 2012 to monitor properly your custom Web Console URL

 

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!