About 6 months ago, Kerrie and Cameron presented at TechEd 2007. While we were there, we did a podcast for Microsoft (see http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!187.entry) and also several for our publisher, Pearson Education, who publishes the SAMS Unleashed series among others. The Pearson ones are now released (timed to be near the release of the OpsMgr 2007 book), and are available at

http://www.informit.com/content/podcasts/8/ON_MIC_MeylerFuller_01.mp4 and http://www.informit.com/content/podcasts/8/ON_MIC_MeylerFuller_02.mp4

(If you are wondering what "DAD" is in OpsMgr 2007, you will be interested in reading Chapter 15, "Monitoring Audit Collection Services.")

Normally we don't duplicate information between this blog and the cameronfuller.spaces.live.com blog, but we are so excited to see the podcasts available that this information is here as well as at http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1082.entry.

We were asked not too long ago what would be the top reasons to recommend clustering on the OpsMgr database servers versus other options for high availability. Since "doing clustering" is something that is often just assumed to be THE only high availability approach, the topic seemed worthy of a blog article.

Clustering is a fault-tolerant, high-performance, and scalable approach for database availability. It provides automatic failover and does not degrade overall SQL Server performance.

Other possible availability options might be log shipping, database mirroring, and manual recovery.

The advantage of clustering over these is you set it up and you don't have to do anything manual. Manual recovery methods are of course ... manual. In addition, if you don't maintain the transaction log, manual recovery and log shipping don't do you much good. By default the OpsMgr Operations database does not support forward recovery using the transaction log, although you can change this option which would allow you to implement log shipping. Due to the high processing requirements of the ACS database, we do not recommend log shipping this database.

Then there is database mirroring, which is new starting with SQL Server 2005 Service Pack 1. It, like log shipping, uses a standby server, so there is no savings in hardware cost with these options versus using clustering. Both these methods also add performance overhead to maintain the transaction information on a standby server. Microsoft does not support SQL 2005 database mirroring functionality for any of the OpsMgr databases.

However, some organizations are hesitant to use clustering if they are not already familiar with the technology. Clustering does present increased complexity when supporting the database server in areas such as patch management. It also doesn't help in cases of data corruption. Probably the most fail-safe approach for high availability would include clustering and using RAID 5 (or 6).

What's the best approach?

On a per server basis, you can minimize server failure and data corruption by using redundant drive storage (RAID 5/6) and server class hardware - with active support agreements! Your goal is to make it as redundant as is viable, and supportable as well. Clustering will give you failover capabilities if the server itself dies.

It really comes down to your business requirements. Generally for environments where high availability is required, we recommend clustering, which is best for performance and is a more proven technology than mirroring or log shipping.

So where have we been, you might ask? Finishing content on our forthcoming book, Microsoft System Center Operations Manager 2007 Unleashed! Its off to production now.

In August 2006, we published an article titled In a Nutshell: 10 Compelling Reasons to use MOM. As a precursor to our OpsMgr 2007 Unleashed book, we are listing ten reasons to use OpsMgr 2007. (While some of the reasons may sound familiar, the fact that many have changed only points to the large architectural differences between the two versions of Operations Manager!)

Ten reasons to use OpsMgr 2007:

1. The bulk of your department's budget goes towards maintaining current systems and services, rather than using the bucks to hire people to manage those assets or develop new systems.
2. You realize system monitoring would be much easier with a single view of the health of your environment, including the applications and services running in production.
3. You feel stuck in the IT version of the movie Groundhog Day - you solve the same problems over and over again every day in exactly the same way, except unlike in the movie, here you and your systems can really die. Plus, this is not a particularly efficient way to maintain operations.
4. You don't have enough internal manpower (or brainpower) to solve problems as they come up, and consultants aren't cheap.
5. You find out there are problems when users (or upper management) start calling you. While this mechanism is actually quite effective in getting your attention, it's somewhat stress inducing and definitely not proactive.
6. You realize that even though your servers are humming along just fine, you have no idea how your client applications are actually performing against what is running on those servers. This makes it tough to know if there are latency issues.
7. Complying with regulations such as Sarbanes-Oxley takes up all the time you once used to do your real job.
8. You would be more productive if you weren't monitoring your production environment all day ... and night. Plus during lunch and vacation.
9. Your production environment is so diverse and widespread that when there's a problem, you don't even know where to start looking!
10. You don't have the time to write down all the troubleshooting information that is in your brain, and your boss is concerned you might be hit by a truck (or want to take that vacation). This probably is not the best way to run a production environment.

While these ten points contain some humor and a bit of satire, if any of these themes resonate with you, you really owe it to yourself to investigate OpsMgr 2007. These "pain points" are common to almost all users of Microsoft technologies, and System Center Operations Manger 2007 resolves them to a great degree.

With SP1 close to release - including 20 fixes and usability improvements (as of the RC, see the fix list at http://support.microsoft.com/kb/944443) - you will want to read about how to use OpsMgr 2007 for monitoring your enterprise and solving your operations management challenges. Check out our forthcoming book, listed on Amazon at http://tinyurl.com/27mqnm.