In the past when the SQL server for SCOM had been down for whatever reason (installing updates, downtime and so on) the RMS would have trouble re-connecting to the database and thus having trouble to start running again. Actually I have only seen this happen in the larger SCOM setups and with a bit more downtime than just a cluster failover on the SQL side. But when it does happen you might want to use an optional feature that was introduced in SCOM 2007 R2 CU4.
Kevin Holman explains the feature and how to enable it, but the procedure is pasted below for your convenience:
To enable this feature - On the RMS – create two new registry entries:
Under the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\DAL” key, create two new DWORD values, as below:
DALInitiateClearPool should be set to Decimal value “1” to enable it.
DALInitiateClearPoolSeconds should be set to Decimal value “60” to represent 60 second retry interval.
You can refer to Kevin’s post for the whole story:
Back to the SCOM Tricks general list
Using a SCOM gateway server (SCOM GW) can be very helpful. Mostly a reason to use a gateway is because you want to monitor a domain which has no Kerberos trust with the domain where your management servers are located. In this case you can just setup a certificate trust between the SCOM MS and the SCOM GW and have the gateway talk to the other agents in his domain. Of course there are some other advantages as well, such as compression of data between the gateway and the management server, you only need to open 1 firewall port for one server if you find the need to cross firewalls, you can have the gateway add a site name which you can use to separate agents and alerts coming from that location. I think Satya Vel had a very good post about the ten reasons to use a gateway at http://blogs.technet.com/b/momteam/archive/2008/02/19/10-reasons-to-use-a-gateway-server.aspx.
All information on how to setup a gateway is in the documentation as mentioned in trick 1.
Marnix Wolf has a very nice article on when to use a dedicated gateway server
There is a nice article on how to use multiple gateways by Anders Bengtsson:
And yet another good article from Marnix about some of the advantages of a gateway:
In SCOM 2007 the root management server (RMS) uses an encryption key to be able to decrypt secure data in the SCOM database. When you first install SCOM at the end of the step to install the first management server (RMS) you will get the option to backup the encryption key. This is a good start to make a backup of it and you will provide a password. But there is also a way to create a backup of the encryption key after the installation. In most cases I would use the same password as the SDK/config/dataaccess account is using. Just something that works for me as I can remember that I use this most of the times and most of the times I know the SDK account. You will need to have this backup of the encryption key when you need to restore your RMS or when you need to promote another management server to RMS. One more reason why it is a good idea to also store the key backup on another location (for instance on the second management server), as you will use it when your RMS is dead most of the times.
So how to backup the key:
Of course it is also nice to list how to restore it:
In a few cases we have seen somebody get an error like this:
could not load file or assembly 'Microsoft.mom.Common, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
In that case copy securestoragebackup.exe to the program files directory for scom where Microsoft.mom.common.dll lives and run backup from there from an elevated command prompt.
When starting out with a new SCOM deployment or sometimes after running some time you might find yourself asking for an estimation of what resources are needed to run SCOM.
To start with I would suggest using the SCOM design guide:
Next check out the Operations Manager 2007 R2 sizing helper:
These will help in giving an idea of what you will be up against for SCOM deployments of different sizes. I would suggest always using some margin with this. Reason is because you might find yourself adding more and more to the monitoring. For instance cross platform monitoring, network monitoring, hardware and storage and so on can give a performance hit on the SCOM servers and increase the size of the databases.
Back to the SCOM Tricks general list
One of the things that is most often unclear with Microsoft software is licensing. There are people who have studied it for years. So, what options are there for SCOM and System Center? I hope these will point you in the right direction.
Here is one page from Microsoft with some resources:
Malcolm Bullock on System Center licensing:
Graham Davies using the back of a napkin for the SCOM licenses:
Posts from Ian Blyth:
At some point you might run into the need to move one of the databases related to SCOM to another server. In case you do you can start your migration plan with reading some of these posts.
Let’s start with the TechNet pages related to the subject:
How to move the operations manager database:
How to move the operationsmanagerdw database:
How to move the operationsmanagerac database:
How to move the report server:
Now for some posts from our favorite Microsoft PFE’s (although Kevin is now a TSP):
One of the solution accelerators Microsoft released is the Service Level Dashboard. What it does is create a dashboard on top of Windows SharePoint Services which shows service level objectives you have set.
There are a few very good resources out there and I will link them here.
The TechNet page:
A post by Marnix Wolf:
After monitoring operating systems there might also be a wish to monitor Oracle. Of course Oracle has a bit more to offer than a database server. I will list a few links and products here that monitor the database and some that monitor other components.
First of all I want to mention the first Oracle that I was asked to monitor. It turned out to be Oracle Linux operating system. We found that this OS actually made itself known as RedHat Linux and that the SCOM discovery wizard also saw it that way. So we can pick it up as a Linux server with cross plat monitoring.
Next here are a few links to monitoring solutions for Oracle:
NiCE has a great management pack for monitoring Oracle NiCE website. They have been building on this pack continually. Feel free to request information or a trial.
Bridgeways has a management pack for Oracle Database:
There is also a beta version for Weblogic there. However it has been in beta for some time now, not sure when they are going to release it.
ComTrade has an Oracle Siebel management pack:
Quest has a management pack for Oracle Database:
And a connector to link Oracle Enterprise Manager to SCOM
Monitor an Oracle database with a SCOM OleDB watcher
Kristopher Bash has also been working on a management pack:
When monitoring operating systems and server applications you will probably get to thinking you would like to monitor a bit more from the hardware as well. Well this is possible in a few ways depending on the hardware and also depending on the operating system running on it.
In many cases, like with Dell and HP there are hardware monitoring and management agents installed on the server which get used by management packs to talk to.
So let’s go with some of the links I have listed (some might be more than just the server hardware, but I am guessing you wont mind seeing an additional link):
Dell Server Management Pack Suite v4.0
Dell PowerEdge/PowerVault Servers, Dell Remote Access Controllers (DRAC) and Chassis Management Controllers (CMC). See below for a newer version.
Dell MD Storage Array Management Pack Suite v4.0
Supported Storage Arrays: MD3000, MD3000i, MD1000 daisy chained to a MD3000 or MD3000i
Dell Printer Management Pack v4.0
Dell Client Management Pack v4.0
Check out this page for some of the latest links which are also listed above (but perhaps get updated more often):
Create Dell hardware reports in SCOM
HP Insight Control for System Center
HP Storage works MP
HP EVA management pack
Outside of what the cross plat agent can monitor you can add to this by adding the Solaris machine as a SNMP network device and pick up the xSNMP MP and add the Sun monitoring bits.
As we want to monitor everything with SCOM we also want to pull in the network devices. There are several different ways to do this in SCOM 2007 R2. Let’s go from very simple basic monitoring to more extensive monitoring. Here are a number of possibilities:
You can ping the machines with a free ping management pack.
You can add the network device to SCOM if you have an SNMP read string on that device in the SCOM console (Administration – device management – network devices). This will basically just check if SNMP gives a reply on the device.
You can check if the xSNMP management pack created by Kristopher Bash (free) does what you want. In many cases this is suitable and is a lot deeper than the previous methods. You can find it at: http://xsnmp.codeplex.com/ . I like this MP a lot.
Of course it is always possible to first add a network device as mentioned previously and create SNMP monitors yourself. If you know your way around SNMP you could do this.
Jalasoft offers the Xian Network Manager IO R2 enabling deep monitoring of network devices:
Opslogix bring us both the free Ping management pack http://www.opslogix.com/ping and the Network management pack http://www.opslogix.com/network-management-pack . The last one also offers deep monitoring of network devices.
JaxMP also offers network monitoring: http://www.jaxmp.com/
In the next version of SCOM, the SCOM 2012, we will also get network monitoring built in. We will see more and more information regarding this in the coming months. And of course I will be blogging about it in a while.