So you just finished installing OpsMgr successfully and now it is time to begin using it. This post has a collection of post-installation tasks that I use in every environment prior to deploying the first agent. As always, these are recommendations and suggestions. I hope you find them useful.
- Configure User Roles. Please see Security Considerations – Controlling Access (Part 1 of 2) and Security Considerations – Controlling Access (Part 2 of 2)
- Backup the RMS Key. Don’t store it only on the RMS. USB key is perfect. In fact, open a Hotmail account and e-mail it to yourself.
- Configure Data Warehouse Retention. One strategy I use is to of course get all disk space needed but I do not use it all at once. For example, lets say, based on my retention policy, I need 100GB for the OperationsManagerDW database. Also, by default, the data warehouse retention policy is 400 days. Until the environment is completely tuned and all operational practices and procedures, as they apply to Reporting, are worked out, start with a 30 day retention policy. If at, say 29 days, all is well, then reconfigure to 60 days. Simply, what this does is to ensure working with the data warehouse remains easy. There is no loss in data or performance overhead. Also, you may quickly see you , in fact, don’t necessarily need 400 days. I recommend using dwdatarp.exe courtesy of Daniel Savage. http://blogs.technet.com/momteam/archive/2008/05/14/data-warehouse-data-retention-policy-dwdatarp-exe.aspx
- Configure and test a SQL Backup job for the OperationsManager database. Use whatever works for you, just back it up nightly AND, hopefully you have a lab. If not, build one, even if it is virtualized and test the restoration. This is always overlooked and it always comes back to haunt someone.
- RMS Recovery. It is no secret I am not for clustering the RMS. I can recover a designated Management Server extremely fast and the 5-10 minutes of downtime does not typically justify the expense and support effort of an RMS cluster. Regardless, in your lab, test and document the procedure. The Microsoft documents are fine, but take the 30 minutes to modify the ‘Operations Manager 2007 Backup and Recovery Guide’ to meet your client’s specific environment. I have seen many DR scenarios fail because of a missing switch or wrong syntax. It is well worth it. Test and retest in the lab until it is second nature. Execute partial and full DR scenarios until all the mystery is gone.
- Import the SQL Server 2000/2005 Management Pack – 6.0.6278.8 This is for the SQL components OpsMgr requires. It is also going to be a prerequisite for the OpsMgr Health Check Management Pack I almost have completed. (This management pack will focus on database performance from an I/O level in addition to several other critical performance objects.
- Import Windows Server Operating System Management Pack – 6.0.6278.22
- Identify and deploy agents to all servers that are required to act as a proxy. Active Directory domain controllers and certain Exchange servers apply.
- Configure agents to ‘Act as a Proxy’. If you have a large number and wish to enable in ‘bulk’, you can do so with a PowerShell script. Please see Enable Agent “Act as a Proxy” in bulk via Powershell for additional details.
- Import my General Diagnostics Management Pack – 1.0. This management pack is a collection of views very useful when tuning a Management Group. It is not sealed so you can do as you wish with it. I’ve attached a screen shot of the views as well as the MP.
My only other suggestion is to focus on getting the management packs to workperfectly before worrying about who gets e-mail notifications as well as who gets consoles. Its tough enough tuning a MP in a large environment let alone being ping’ed by many people asking “what’s this?” all at the same time.