Collaboration

Exchange 2010 and SharePoint 2010 management packs: Best practice architecture

John Joyner explains how the management packs for Microsoft's Exchange and SharePoint 2010 can address configuration problems and help you implement best practices for your architecture.

The best network management solutions not only detect and even prevent problems; they should actually improve the availability, performance, configuration, and security of managed systems. I've seen recently this advanced capability well demonstrated by the relatively new Microsoft System Center Operations Manager (SCOM) management packs for Exchange 2010 and SharePoint 2010. Using these management packs, you get the benefit of deep configuration knowledge, without having to dive into hundreds of pages of design and best practice references.

Management packs encapsulate knowledge

SCOM is a management framework that uses add-on software modules called management packs to know how to monitor various operating systems, network devices, and applications. Microsoft and many hardware and software vendors write management packs to support their products. A management pack delivers business intelligence, encapsulating human thought and decision processes in health models. In the best situations, the authors of the management packs are embedded in the product teams they support, and the management packs capture rich information about best practices from a real-world knowledge base.

In the cases of both Exchange 2010 and SharePoint 2010, we have recently been able to help customers apply knowledge coming out of SCOM (using the management packs for those products) to align their architecture with best practice recommendations.  Configuring these advanced applications in an optimal manner can be complex and time consuming to research. This is a great solution for the generalist admin in the smaller to medium size IT shop, where there may not be any Exchange or SharePoint admins.

Exchange 2010 and DAGs: A learning curve

Providing for high availability of Exchange services evolved from conventional clustering with Exchange 2003, to hybrid Exchange 2007 technologies called Local Continuous Replication (LCR), Single Copy Clusters (SCC), Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR). With Exchange 2010, these methods of providing high availability and resiliency for mailbox databases are replaced by a new component called a Database Availability Group (DAG).

The DAG concept continuously replicates transaction log files to passive copies of the mailbox databases. DAGs have a critical need to always have sufficient disk space available for transaction logs waiting to be replayed by the mailbox store. In fact, Microsoft has determined that, for safety, the disk volumes containing Exchange 2010 DAG log files need a minimum of 50% free space at all times under normal conditions (it's a 25% threshold for volumes containing Exchange 2010 DAG database files).

A recent customer completed their Exchange 2010 deployment and added SCOM monitoring. This customer had a project goal of minimizing SAN disk space used by Exchange. The Exchange 2010 management pack soon generated an alert about low disk space on a particular Exchange 2010 log volume. While there was an initial puzzled reaction (why do we to ‘waste' so much disk space?), it brought the customer's attention to this relatively new best practice -- to leave extra free space on Exchange 2010 log volumes, compared to previous versions of Exchange.

After study, the customer decided to expand the SAN volume containing the log files to conform to the best practice suggested by the management pack. We were impressed that SCOM alerting delivered prescriptive guidance that influenced the customer to change and improve their architecture. Figure A (click to enlarge) shows off one of the nice-looking SCOM reports added by the Exchange 2010 management pack.

Figure A

Weekly SCOM report on Exchange 2010 Transport Statistics breaks down each day's traffic by message destination.

SharePoint 2010: So many pieces and parts

Part of SharePoint's appeal is how it can be customized and scaled massively, but these features add complexity. Network administrators trying to set up and support SharePoint 2010 can face an assembly of configuration and content databases, service front ends, farms, and applications they may not fully understand. Likewise, from the vantage point of the intranet developer(s) supporting SharePoint, the intricacies of network security and storage may not be appreciated.

To the rescue comes the SharePoint 2010 management pack for an end-to-end look at your SharePoint deployment. After you deploy SCOM agents to your SharePoint 2010 computers and the SQL servers hosting the SharePoint databases, views populate in the SCOM console that accurately reflect the topology and health of your SharePoint investment. For example, a diagram view will help you visualize the configuration database, services, servers, shared services, and web applications that together represent the complete SharePoint environment.

Another recent customer experience highlights the usefulness of SCOM's holistic approach to application management. A feature of the SharePoint 2010 management pack is to consolidate the status of the SharePoint Health Analyzer (SPHA) rules across your deployment; see Figure B (click to enlarge) for this view in the SCOM console. The customer had deployed SharePoint behind hardware load balancers, a sophisticated model for high availability.

There is an advanced configuration setting inside SharePoint (AlternateAccessMappings) that needs to be modified when using load-balanced front ends. Without this setting, any links returned in the page will be absolute URLs to a specific web front end, instead of relative URLs to the load balanced address, which will defeat the goal of load balancing. SCOM immediately brought visibility of this and other configuration issues to the customer, resulting in a more functional and secure SharePoint environment.

Figure B

The health states of SharePoint Health Analyzer (SPHA) Rules help you prioritize configuration issues

Management pack tips

Carefully read the deployment guides that accompany each management pack download to learn more about these special requirements:

  • The Exchange 2010 management pack installs a new service called the Microsoft Exchange Monitoring Correlation on your root management server (RMS). Download and install this management pack specifically on your RMS computer.
  • The SharePoint 2010 management pack will not discover any computers by default. There is a Configure SharePoint Management Pack task in the SCOM console that enables computer discovery.
Download the Management Packs:

About

John Joyner, MCSE, CMSP, MVP Cloud and Datacenter Management, is senior architect at ClearPointe, a cloud provider of systems management services. He is co-author of the "System Center Operations Manager: Unleashed" book series from Sams Publishing, ...

1 comments
langstonha
langstonha

I'm wanting to learn more about these two subjects. Do you know anywhere I can do some research. Thanks for talking about the management packs. They sound a little like .msi's