SCOM 2012 has some nice new dashboards.   The average IT user or application owner often doesn’t want to learn the SCOM console.  They just want to know that state of their application.  With 2012 we now have the ability to create dashboards for these users and show the state of their application in SharePoint.

I start by looking over the TechNet instructions here:

http://technet.microsoft.com/en-us/library/hh212924.aspx#bkmk_howtodeploytheoperationsmanagerwebpart

 

Then I create a basic dashboard that I want to show in my SharePoint site.

Next I copy the SharePoint folder from the installation media d:\Setup\amd64\SharePoint over to my SharePoint server c:\Temp.

The user I am logged on as is a Farm Administrator so I have all the SharePoint permissions I need.

On my SharePoint server I open the SharePoint 2010 Management Shell as an Administrator

I navigate over to the temp location where my files are located and type the following command.

.\INSTALL-OPERATIONSMANAGER-DASHBOARDVIEWER.PS1 “C:\Temp\SHAREPOINT”

*Note: If you get an error you may have to run “Set-ExecutionPolicy Unrestricted”

It prompts me for a Siteurl.  I just click enter so that it install into all my sites.

*Note: In a large environment I would put in a specific Siteurl.

It takes about a minute to install in my environment.

Now I need to configure SCOM in my SharePoint Environment.

First I open up a web browser from my SharePoint server to my Operations Manager environment.

http://scomms1/OperationsManager/default.aspx

It prompts me to install Silverlight so I go ahead and install it.

 

Now I open up the SharePoint 2010 Central Administration site.  Under Site Actions I select View All Site Content

Under Lists I select Operations Manager Web Console Environments.

Then I select Operations Manager on localhost.

A dialog box opens and then I select Edit Item

Where it says HostUri I type in the web address of my Operations Manager Web console but I leave off the default.aspx

http://scomms1/OperationsManager/

I click Save.

Now I browse to the actual SharePoint site where I want to display my dashboard.

Under Site Actions I click Edit Page

I Check Out the page

Under Insert I select Web Part.  Then I select Microsoft System Center, then Operations Manager Dashboard.  Then  I click Add

I see the web part is on the page.  Now I have to edit it.

I hover over the text and then select the down arrow on the right side.  I select Edit Web Part

 

Over on the right hand side I see Operations Manager Dashboard Viewer Web Part

 

I now need the URL for the Dashboard that I want to display. Leaving the SharePoint site open, I open up another web browser and type in the URL of my SCOM Console.

Then I browse to the dashboard I want to display.  I copy the URL of my dashboard.

http://scomms1/OperationsManager/default.aspx#/dashboard(type=Tim!UIGenerated_6658ef51239849e4ac681226c0522df4_Perf)

Back to my SharePoint site browser window I paste in the dashboard location and click OK

I now see the dashboard open in the SharePoint site.

I check in my changes and I am done.

Another thing to note is that I could also setup this site to used shared credentials.  What this means is that instead of controlling permissions from SCOM I can setup one user ID so that anyone who wants to see this dashboard can view it using a common ID.  Instructions are here http://technet.microsoft.com/en-us/library/hh212924.aspx#bkmk_howtodeploytheoperationsmanagerwebpart

 

Customers often have Management Servers in remote locations.  It seems like a logical decision as they have AD and File servers in their remote locations.  But with Operations Manager 2007 R2 and 2012 this is a really bad configuration.  Management servers write directly to the DB and DW and the data is not compressed.  Even with a large fast pipe there are be a latency issues and it is generally not recommended. 

 

 

With a remote location you have two options

1.  Have the remote agents report directly to a management server.  While this may seem a little scary the agents were actually designed for this.  If the connection goes down the agents will queue alerts and performance data. 

 

2.    The second option is to setup a gateway server.  Gateway servers were originally designed for DMZs but are often used for remote locations, even if the servers are on the same domain. 

 

Using a gateway server for a remote location has these benefits.

• The agents send data to the Gateway server and the data gets compressed before it’s sent over the wire to the management server.
• Firewall Port 5723 will only need to be opened up between the remote Gateway and the Management server.
• If the connection goes down the gateway server will also queue alert and performance data, giving you extra buffer time.
• When Cumulative Updates are pushed to agents in the remote location they will be pushed from the Gateway server and not over the wire.

 

But there is also a downside to using a gateway sever for a remote location. 

• It becomes a single point a failure for servers in the remote location.
• It is recommended to setup two gateway servers in the remote location.  PowerShell scripts can be use to set the agents to failover between the two gateway servers.
• It’s another manual component to manage and update.

 

So at what point does it make sense to setup a Gateway server for a remote location?

 

# of Server in Remote location

0-20 servers – Gateway not worth implementing

20-50 servers – Gateway possibly worth implementing (depends on what is monitored)

50+ Servers – Gateway definitely worth implementing