Archive

Archive for the ‘Exchange Server’ Category

Deploy Exchange 2013 using Service Templates!

October 20, 2013 Leave a comment

awesome post must see regarding how to  Deploy Exchange 2013 using Service Templates!

Overview of Forefront Protection 2010 for Exchange Server

July 21, 2011 11 comments

Microsoft acquired Sybari Software Inc. in 2005 and, with it, acquired its
Antigen for Exchange product line. Microsoft later released its first suite of
Microsoft-branded Antigen products in June 2006 — marking its first line of
antivirus products specifically for Exchange Server 2000 and Exchange Server
2003.

The next generation of this product — Forefront Security for Exchange Server — was
released shortly after the debut of Exchange Server 2007. This version was
enhanced to support the new role-based architecture and leverage the new
transport pipeline in Exchange Server 2007.

Forefront Protection 2010 for Exchange
Server
is the current generation and next evolution of antispam and antivirus protection
from Microsoft. Microsoft’s 2005 acquisition of FrontBridge Technologies Inc., a
managed services provider for corporate email compliance, security and high
availability, paved the way for its hosted security solution for Exchange, which
now includes Forefront Online Protection 2010 for Exchange Server.

Exchange 2010 built-in antispam
protection

When you deploy an edge transport server role, a wide range of
antispam agents are installed that leverage Exchange Server 2010’s built-in API
hooks. Exchange 2010’s antispam transport agents are derived from long-standing
Exchange Server technology (Figure 1).

A list of Exchange 2010's antispam transport agents

Figure 1. Exchange Server 2010 already has plenty of antispam transport
agents built in.

Transport agents were first introduced in Exchange 2007 and can directly leverage the
transport pipeline to allow antivirus and antispam applications to proactively
scan inbound and outbound email processed by the edge transport server before it
enters or exits an organization.

If the edge transport server isn’t deployed, the
antispam transport agents can be imported onto a hub transport server role using the
install-AntispamAgents.ps1 script. This allows any Exchange Server
deployment topology to benefit from antispam protection. Of course, an antispam
application will only address half of the problem; you still need an antivirus
product to protect the organization from malware.

Forefront Protection for Exchange Server (On-premises)
Forefront
Protection 2010 for Exchange Server (FPE) is an on-premises application that can
be implemented in the internal network on the hub transport and mailbox roles.
It can also be implemented in the perimeter network, on the edge transport or
threat management gateway (TMG). FPE was designed to provide three distinct
layers of filtering: connection filtering, protocol filtering and content
filtering.

Layer 1 – Connection filtering (Approximately 80% of inbound spam
rejected)

  • DNS Block List (DNSBL)
  • IP Allow/IP Block
  • Sender ID

Layer 2 – SMTP filtering (3% to 5% rejected)

  • Sender
  • Recipient
  • Global safe list
  • Global block list
  • Sender ID
  • Backscatter

Layer 3 – Content filtering (55% to 60% rejected)

  • Cloudmark
  • Automatic updates every 45 seconds

FPE can also be installed on the mailbox role. The table below lists
available configuration options when FPE is installed on a mailbox server.

Forefront solution Description
Forefront Endpoint Protection 2010 Malware protection for business desktop PCs, laptops and server
operating systems that is easier to manage and control
Microsoft Forefront Protection 2010 for Exchange Server Multiple-engine antimalware and anti-spam protection for
on-premises Microsoft Exchange Server environments
Microsoft Forefront Online Protection for Exchange Microsoft-hosted antimalware and anti-spam service offering
enterprise-class reliability for messaging security and management
Microsoft Forefront Protection 2010 for SharePoint File filtering, keyword blocking and antivirus scanning for
Microsoft Office SharePoint Server document libraries
Microsoft Forefront Security for Office Communications
Server
Virus scanning and content filtering for instant message
conversations and file transfers
Forefront Threat Management Gateway Web Protection Service URL filtering and Web antimalware update service for Forefront
Threat Management Gateway 2010

Microsoft Forefront Protection Server Management
Console (FPSMC) 2010

Microsoft Forefront Protection Server Management
Console (FPSMC) 2010, allows administrators to manage not only multiple FPE
servers within an organization but also the settings for FOPE, is available as a
free download. FPSMC has an intuitive graphical
interface that administrators can use for server discovery, configuration
deployment, reporting, and quarantine management.

FOPE administrators can also utilize FPSMC as it is integrated with Forefront
Online Protection for Exchange. FPSMC also includes some reports to help
administrators understand the nature and trends of malware and spam
protection.

The FPE Server Administrator Console does an adequate job of allowing you to
configure FPE and FOPE for an organization and is all that is really necessary
for single server deployments. The new dashboard view (Figure 2) makes it very
easy to track current activity and the status of the different components in
FPE.

A look at the FPE dashboard
Figure 2. You can manage FPE from its new
dashboard.

New Forefront features to look
for

Forefront Protection for Exchange Server has several features that
might be new to Exchange Server administrators.
Let’s take a look at some of the coolest new features and how they work.

DNSBL. This feature automates subscriptions to real-time block list
(RBL) services and enables configuration through a single mouse click. This is
possible because Microsoft has already subscribed to some of the most respected
RBL providers to create its own DNS block list (DNSBL). When you enable DNSBL,
you subscribe to the Microsoft list; enabling DNSBL will eliminate subscriptions
fees that are often required to transfer block-list information to your servers.
It can also eliminate the headache of managing and configuring your own
subscriptions.

Backscatter. This feature protects your organization from bogus
non-delivery report (NDR) messages. Prior to the release of FPE 2010, there was
no Microsoft solution that could prevent fictitious NDR messages from being
delivered to users’ mailboxes. When you enable Backscatter and generate a set of
keys, each outbound message will have an attached token that’s based on a hashed
tab to P1.MailFrom: in the email header. If the external messaging system
that receives the email must return a non-delivery report, the token will be
returned as well.

If the Backscatter feature on Exchange 2010 transport servers can validate
the hash, then the NDR will be allowed into the organization. However, if the
NDR is missing the hashed tag or Backscatter cannot validate the hash, then the
NDR message will be dropped.

Note: To prevent inadvertently dropping valid NDR messages, all
transport servers must have the Backscatter feature enabled. At the very least,
it should be enabled on all Internet-facing transport servers.

Cloudmark. You can license this antispam solution from Microsoft for
both FPE and FOPE. Once FPE is installed, it will replace the default antispam
connection filter engine with Cloudmark. Cloudmark has proven to have a 99.77%
catch rate. Microsoft guarantees a 98% catch rate in its server-level agreement
(SLA) for FOPE.

Third-party spam and virus protection
Microsoft claims that there
are four features in Forefront Protection 2010 for Exchange Server that
differentiates the product from third-party solutions.

1. FPE uses five simultaneous scanning engines.
2. It uses multi-layer
defense architecture.
3. FPE is easy to administer, monitor and report.
4.
The solution supports a hybrid model that integrates both on-premise and online
servers as well a singular solution.

Despite these advantages, however, it isn’t everything for everyone.
Sometimes you need a third-party antivirus or antispam solution. There are a
number of well-known antivirus and antispam vendors for Microsoft Exchange
Server. When it comes down to choosing the best one for your enterprise, which
factors should you consider? Key aspects to look for in a third-party antivirus
solution for Exchange Server 2010 are:

  • Support for latest VSAPI
  • Support for hub, edge and mailbox roles
  • Use of transport agents for scanning
  • Support for antivirus stamping
  • Support for multiple scanning engines

Can the cloud reduce your spam carbon footprint?
There is a
concept with antimalware and antispam prevention that suggests the sooner you
can eliminate the threat, the less it will cost your organization. To describe
this concept in today’s environmentally conscious landscape, some have coined
this as “reducing the carbon footprint of spam and malware.”

The last 10 years has seen an explosion in hardware appliances and
perimeter-based email security designed to prevent unwanted email from even
making it inside an organization. The downside to these solutions is that they
require additional security expertise to maintain and they must be kept up to
date in order to be effective. For many organizations, there is not enough staff
to meet these challenges. The consequences of a solution failing are too great
for many organizations, so they have begun to seek alternatives.

The use of cloud-based managed security solutions for email systems has
increased significantly over the last few years. Cloud-based security solutions
give companies the potential to maintain the smallest carbon footprint possible
for malware and spam because these solutions eliminate unwanted email in the
cloud — not in the perimeter.

When Microsoft acquired FrontBridge, it became one of the top email hygiene
providers along with Postini (Google), Message Labs (Symantec), SOPHOS and Trend
Micro. Today there are more than 10 well-known hosted email hygiene/security
providers to select from as well as several lesser-known vendors.

Microsoft’s technological advances with FOPE make it an excellent choice for
a managed security solution in the cloud and a strong competitor with the
predominant providers. The strongest argument for FOPE, however, is that it is
the only solution that is tightly integrated with its on-premises counterpart,
FPE. FOPE can also be enabled and provisioned with a few clicks of the mouse,
using the same tools you need to manage FPE.

Example deployment topologies
FPE and FOPE were designed to support
environments of all sizes. FOPE is a hosted solution, so it was designed to
scale support for even the largest enterprises. There are different ways to
deploy FPE and FOPE for an Exchange Server 2010 organization. FPE can protect
Exchange organizations with single servers with combined roles or with dedicated
server roles. FOPE can be leveraged by itself without FPE. However the most
comprehensive solution is to deploy both FOPE and FPE together.

  • On-Premises: Combined Exchange Server roles
    All Exchange Server
    roles are combined on a single server. Although the client access server role
    and unified messaging role are on the same server, FPE does not directly support
    them. All email and voicemail are submitted to the mailbox role; therefore, CAS
    and UM roles are indirectly protected (Figure 3).Forefront Protection for Exchange Server indirectly protects the unified messaging and client access server roles.
    Figure 3. Though not directly supported, the
    client access server and unified messaging roles are protected by FPE.
  • On-Premises: Dedicated Exchange Server roles
    FPE is installed on
    the edge, hub and mailbox server roles, but it isn’t necessary to install on the
    UM or CAS roles. This topology gives Exchange administrators the greatest level
    of flexibility when sizing each server to meet the resource requirements of both
    Exchange 2010 and FPE. A TMG was also deployed to provide protection for the CAS
    role (Figure 4).Forefront Protection for Exchange Server is installed on the edge, hub and transport server roles.
    Figure 4. FPE is installed on the edge, hub and
    mailbox server roles.
  • On Premises/Hosted: Hybrid
    FPE and FOPE are deployed as a holistic
    antimalware/antispam solution. The Forefront Protection Manager allows admins to
    centrally manage the antispam policy. There is an additional FOPE gateway server
    in this configuration. This function takes very little resources and is used to
    push the antispam policy to FOPE from the FPMSC (Figure 5).Forefront Protection for Exchange Server and Forefront Online Protection for Exchange Server may be deployed together as a hybrid solution.
    Figure 5. FPE and FOPE can be deployed together
    as a hybrid antispam/antimalware solution.

Deployment recommendations
There are a few general rules you should
follow when deploying Forefront Protection for Exchange Server.

  • Deploy FPE on an edge transport server.
  • Deploy FPE on all hub transport servers.
  • Deploy FPE on all mailbox servers.
  • Run all five engines, if possible, and run no less than two engines for
    fault tolerance.
  • During a malware outbreak, enable the Scan after engine update
    setting for real-time scanning on mailbox servers.
  • Optionally, deploy FPE on a Threat Management Gateway (TMG) instead of an
    edge server.
  • Use the Forefront Protection 2010 for Exchange
    Server Capacity Planning Tool
    .

Because running antivirus software consumes additional resources, it is
important to plan appropriately. The capacity planning tool let you select
reference architecture and customize the memory and hardware constraints. After
it runs, it will produce a summary of the hardware requirements and number of
servers that should be used, based on the specified constraints.

Viruses and worms of a decade ago seemed like the biggest threats to
messaging security, but when you consider what they have evolved into today, for
example: the latest phishing and malware attacks with criminal intent, it is no
surprise the security industry has evolved as well. Email administrators are at
the center of the malware and spam storm and have the greatest responsibility to
provide their organizations with appropriate levels of protection.

The good news is there are more antispam and antimalware solutions on the
market than there have ever been that are specifically designed for messaging
systems. Microsoft has even included several layers of antispam protection built
into Exchange Server 2010. As the industry moves forward, it seems that the more
noticeable trends are the managed security solutions. The managed security
solutions in the cloud are becoming more attractive to administrators that have
found the task of keeping pace with the exponentially growing threats to their
email systems more and more difficult to perform.

How migrating to Exchange Server 2010 can save money on storage

April 7, 2011 Leave a comment

When Steve Derbyshire, IT operations director at NEC Philips Unified Solutions UK, decided to implement Exchange Server 2010, he says he did so for three primary reasons: to get everyone on the same level of server software, to improve resiliency and to reduce storage costs, if possible.

Migrating to Exchange Server 2010 — More bang for the buck

Since migrating to Exchange Server 2010 in July 2009 as part of the Microsoft Technology Adoption Program, the company has increased its email system storage capacity by a factor of eight through the use of serial ATA (SATA) disks, Derbyshire said. This comes at only 25% the cost of new Fibre Channel (FC) disks, which would have been required if the company had maintained its mixed Exchange Server 2003 and Exchange 2007 environment, he added.

While NEC Philips’ small Exchange Server 2003 system had been on a single direct-attached storage (DAS) server, its Exchange Server 2007 environment was backed by a Fibre Channel storage area network (SAN). “We were nearing 80% or higher capacity on the SAN, and we would have had to extend it had we stayed with Exchange [Server] 2007,” said Matt Hawkins, consulting team leader at NEC Philips.

In terms of storage volume, NEC Philips had 500 GB of storage allocated to Exchange Server 2007. The company now has 6 TB for Exchange Server 2010 and spend only a quarter of what it would have to double the Fibre Channel SAN capacity to 1 TB, said Hawkins. “We’ve even done away with mailbox limits; we’ve got so much SATA that storage mailbox size is not a problem.”

“We knew going to SATA gave us the potential to do something like this, but until we got Exchange [Server] 2010 up and running, did all the calculations and made sure we had sufficient bandwidth between our two sites, we weren’t sure we were going to be able to do it,” Derbyshire added. “I thought we would [save money], but I hadn’t expected it to be quite as dramatic as this.”

To date, NEC Philips has saved roughly $3,000 in storage costs, but this is a drop in the bucket, added Derbyshire. “Ours is a small installation; extrapolate that up to a large organization and the numbers get interesting.”

More significantly, NEC Philips has eliminated third-party cold-standby and associated costs using Exchange Server 2010’s database availability group (DAG) capability. With DAG, NEC Philips can run a secondary, active server for disaster recovery. Using DAG on SATA will save the company roughly $19,000 a year, Derbyshire said.

Spinning up Exchange Server 2010 savings

Unlike its predecessors, Exchange Server 2010 offers disk input/output (I/O) that’s suitable for economical SATA disks. According to Microsoft, Exchange Server 2010’s latest mail server software lowers overall disk I/O by up to 70% compared to Exchange Server 2007.

“Exchange [Server] 2003 is a high I/O, read/write technology because it’s reading and writing all over the platter — wherever it finds open spots,” said Rand Morimoto, president of Convergent Computing, a Microsoft consulting firm in Oakland, Calif. “It’s designed that way because when it was built, there were no fast hard drives or large memory spaces. But now, when we can put 16 GB or 32 GB of RAM in a 64-bit computer and have four or eight cores for processing the information, that [technology] doesn’t make sense.”

In the background, Exchange Server 2010 defragments the disk and cleans up all open spots so that it writes information sequentially. “This might make it 20% to 30% slower to write, but the read time is 40% faster,” Morimoto said. At end of the day, this means storage cost reductions for enterprises.

“The fabric that organizations have to lay down for Exchange [Server] for storage went from $10,000 to $25,000 per terabyte of very high-speed Fibre Channel to $500 hard drives,” Morimoto said. “Do the math — $25,000 a terabyte or $500 a terabyte. Which one would you choose?”

Like NEC Philips, George Hamin, director of e-business and information systems at Subaru Canada of Mississauga, Ontario, also relishes that it no longer needs to invest in Fibre Channel drives for its Exchange Server environment.

“Originally, we had only a small portion of our user base email — basically for just the most important people, like directors and vice presidents — on the SAN, backed up and replicated,” Hamin said. “The rest of the user community had local storage. Now we’re in the process of moving everybody over to SAN without having to upgrade the SAN itself. We’ll have to add disk to accommodate the additional mailboxes, but the actual processor itself doesn’t need to change.”

This is the kind of capability that makes Exchange Server 2010 more affordable than Exchange Server 2007, which Subaru Canada migrated from per terms of its maintenance agreement, Hamin said.

SAN sensibility

With examples like these, Microsoft widely touts storage cost reductions among the chief benefits of migrating to Exchange Server 2010. In a return on investment/cost savings analysis Microsoft completed with 100 early adopters, the company found the average savings was in the 50% to 80% range, said Julia White, director of Exchange product management at Microsoft.

“We saw a ton of savings around the storage side, as well as high availability and the DAG architecture,” said White. “That’s where you see the hard-cost savings as companies look to increase mailbox sizes and use lower-cost storage to make that economically sensible,” she said.

As an example, White points to financial services firm BCG Partners. Once BCG Partners migrated to Exchange Server 2010, she said, the company was able to redeploy a $1 million SAN from email to another project, instead using a couple hundred thousand dollar DAS-based storage solution.

“Across all of early adopters that deployed on a lower-cost storage model, the numbers are pretty staggering,” White said. “Cost-savings, if not the first, is the second reason in terms of what’s compelling people to migrate to Exchange [Server] 2010.”

Morimoto, however, says he hasn’t seen cost savings from storage as a primary migration driver among his clients, although, he has no doubt that there are savings to be had. But migrating doesn’t come for free, added Morimoto, even if you’ve got a software assurance license for free upgrades.

Schultz is a longtime IT writer based in Chicago. You can reach her at bschultz5824@gmail.com.

Office 365 will change your job, not kill it

April 7, 2011 1 comment

Tony Redmond, an Exchange MVP, told IT managers that if they saw their future merely as Exchange administrators, they would be “toast,” asserting that many Exchange organizations are ready to consider hosted messaging services. Redmond said those who embrace and educate themselves about the cloud and Office 365 could prolong their careers.

Microsoft Office 365 bundles Microsoft Office, SharePoint Online, Exchange Online and Lync Online into a single package. The company plans to release it sometime later this year.

If willing and able, Exchange administrators can become Office 365 administrators. While Office 365 support takes care of things like backup and recovery, patch management and virus and spam prevention, enterprises will still need in-house administrators to focus on messaging records management, transport rules, email disclaimers, retention policies, role management and more.

So how can admins prepare for Office 365? Mike Crowley, an Exchange MVP and enterprise infrastructure architect with Planet Technologies, Inc., suggested admins regularly visit the Office 365 technical blog.

Other experts suggested IT staff familiarize themselves with remote PowerShell in order to modify user properties in Office 365. PowerShell commands also allow you to perform homegrown applications moves. At a separate DevConnections session, Crowley also mentioned you can use PowerShell to prepare Active Directory for a move to Office 365.

Crowley noted that admins, particularly those managing BlackBerry users, should be energized about Office 365, confirming that the product will offer free BlackBerry licenses to current customers. RIM will also offer a cloud-based BES service.

Event ID 1196, 1119 DNS operation refused Cluster Servers

January 27, 2011 10 comments

Error:

Event id 1196, 1119 FailoverClustering appearing on the clustered Exchange and SQL servers, although the cluster seems to be fine the errors are annoying. Cluster network name resource ‘SQL Network Name (MCCNPSQLDB00)’ failed to register DNS name ‘MCCNPSQLDB00.smtp25.org’ over adapter ‘Production VLAN 400’ for the following reason: DNS operation refused.

 

Cause:

The cluster name resource which has been added to the DNS prior to setup active passive cluster ( or any type) need to be updated by the Physical nodes on behalf of the resource record itself. When the active node owns the resources it want to update the A record in the DNS database and DNS record which was created won’t allow any authenticated user to update the DNS record with the same owner

Solution:

Delete the existing A record for the cluster name and re-create it and make sure select the box says “Allow any authenticated user to update DNS record with the same owner name “Don’t worry about breaking anything , this has “ZERO” impact to cluster simply delete the A record and re-create as it is suggested here.

the Exchange 2010 MP

January 17, 2011 1 comment

Significant Changes in Management Pack Design

The Exchange Server 2010 management pack includes a new Windows service component called the correlation engine. This service determines the best alert to raise by examining the Exchange 2010 health model through the Operations Manager SDK service. In short, this service maintains the Exchange health model in memory, reviews the faults for instances within the Health Model over the last 90 seconds and raises an alert for the fault lowest in the health model. The end result is fewer false alerts, as the correlation engine attempts to raise an alert for the source cause of the service impact or outage.

 

image

Figure 1 – The Exchange 2010 MP Correlation Engine

Things to Keep in Mind when working with the Correlation Engine

Disabling monitors of any kind changes how the health model behaves. This will interfere with the correlation engine in its attempt to identify source cause. Microsoft recommends against disabling monitors in the Exchange 2010 Management Pack for this reason.

Since the correlation engine communicates with the SDK, Microsoft recommends installing the correlation engine on the RMS. Because the correlation engine only examines the last 90 seconds of health state related activity, this should hopefully limit resource utilization on the RMS. However, we have no empirical data (hard numbers) from the field regarding scalability to share at this time.

NOTE: If your root management server (RMS) is clustered, the correlation engine can be clustered just like any other Windows service. While this is not mentioned in the Exchange 2010 Management Pack Guide, we understand Microsoft intends to add guidance for this scenario in the next version of the guide.

Why so many classes?

The service model (classes and relationships) of the Exchange 2010 management pack is much more detailed, consisting of more than 200 Exchange-related classes. MP authoring expert Brian Wren advises that classes are useful only when they have a unique purpose in monitoring. In this case, that unique purpose is granular targeting and root cause identification of Exchange failures with a higher degree of precision. This precision is facilitated by the very granular service model. In our opinion, the added complexity in this scenario is good for root cause analysis and mean time to recovery (MTTR) for service availability in general.

For example, in lab testing, when we dismounted the Exchange database the correlation engine only generated one alert — database down. There are many faults as a result of dismounting this database, including but not limited to failures in synthetic transaction monitoring. The fact that the correlation engine correctly identified the root cause is a good sign. Of course this lab environment is no doubt much simpler in design in your production Exchange organization. Therefore the standard warranty “your mileage may vary” applies here.

Alert Classification

Another new concept is that of alert classification. There are three possible classifications:

  • Key Health Indicator (KHI) – Represent critical issues ß most alerts fall into this category.
  • Non Service Impacting (NSI) – This are critical alerts for which impact is generally only one object or group of users or objects. These are issues that affect a subset of users, but not the entire organization. As an example, a duplicate Exchange alias would affect mail delivery for the two users with the same alias, but org-wide delivery would remain unaffected.
  • Forensic – Items in this category represent diagnostics that may not represent a specific problem, but may be helpful while troubleshooting an issue.

Let’s get down to the business of management pack installation and configuration.

How to Install the Exchange 2010 MP

It is important to address the critical prerequisites before importing the management pack and beginning configuration. There are several items of great importance before beginning to install the Exchange 2010 management pack.

Important Prerequisites

Install the update specified in Microsoft Knowledge Base article 971541 (Cumulative Update 1 to OpsMgr 2007) if you are running Operations Manager 2007 SP1. Install the update specified in Microsoft Knowledge Base article 974144 (Cumulative Update 1 to OpsMgr 2007 R2) if you are running Operations Manager 2007 R2. These updates resolve several critical issues that are more likely to occur when running the Exchange 2010 management pack. These updates resolve serious issues affecting state rollup using dependency monitors. These updates allow the Exchange Server 2010 management pack to accurately monitor whether Exchange databases are mounted. Failing to install the respective update on your RMS and all agent computers will also result in inaccurate availability reporting.

The Exchange Correlation service requires the following:

  • It must be installed on a computer running Windows Server 2003, or either the 32-bit or 64-bit version of Windows Server 2008 or Windows Server 2008 R2.
  • It must have network connectivity to the Operations Manager RMS.
  • The Operations Manager Administration Tools must be installed on the computer running the Exchange Correlation service.

Installation

When you extract the Exchange 2010 management pack (available HERE), the extraction wizard expects to do more than simply extract the sealed management pack files and accompanying documentation and to disk. The wizard also aims to install the correlation engine on the local machine where the installer was launched, as indicated in Figures 2 and 3 below. With that in mind, launch the MSI package on the system intended to install the correlation engine.

image

 

Figure 2 – MP Extraction and Correlation Installation Directories

As you see in Figure 3….”extraction” is really MP extraction and correlation installation.

image

Figure 3 – Correlation Engine Service Installation

And the resulting service appears in the Windows Service Manager.

image

Figure 4 – MS Exchange Monitoring Correlation Engine Windows Service

Once the correlation engine is installed and the management pack files extracted, you can import the Exchange 2010 management pack just as you would any other.

You should create an unsealed management pack dedicated to the storage of overrides and other customizations for the Exchange 2010 management pack, just as you would for any other management pack.

NOTE: When you attempt to import the MP, you will notice each has the warning symbol with a lock over it. As the warning message explains, this MP contains rules which have write actions. You can safely ignore this, as it is understood this is the case.

How to Configure the Exchange 2010 MP

There is surprisingly little to configure in the Exchange 2010 management pack, however there are several areas that deserve additional description. These are discussed next.

High Availability Exchange Architectures

It is worth mentioning here how the Exchange 2010 management pack discovers and monitors high-availability exchange of the structures. Most significantly, the Windows cluster management pack is not required. In fact, Microsoft recommends that discovery of cluster components in your Exchange infrastructure be disabled, is this information is not utilized for discovery or monitoring of high-availability Exchange configurations. This is largely due to the fact that the designers of the Exchange 2010 management pack are leveraging built-in functionality of OpsMgr and Exchange to accurately identify high-availability configurations, without depending on other management packs.

Note: this does not mean you should uninstall the Windows cluster management pack. It simply means you should disable the root discoveries of the cluster management pack for all Exchange servers.

Configuring Synthetic Transaction Monitoring

The Exchange 2010 management pack includes protocol level synthetic transaction monitoring that requires little configuration. In fact, the management pack guide in this release did not mention any required configuration for successful synthetic transaction monitoring. It was only after an alert was raised that we realized some configuration was required. (We also understand this oversight will be addressed in the next revision of the guide accompanying this management pack.)

Configuring synthetic transaction monitoring requires running the New-TestCASConnectivityUser.ps1 PowerShell script from the Exchange 2010 Command Shell. You will be prompted for a one time password. From that point on, the Exchange 2010 MP will handle the process for you.

Remember that the user running the New-TestCASConnectivityUser cmdlet needs to be a member of the Organization Management security group in Active Directory, which is found in the Microsoft Exchange Security Groups OU.

NOTE: Synthetic transaction monitoring requires the agent running as Local System. Anything else will cause synthetic transaction monitoring to fail.

Optional Configuration

The next sections discuss some optional configurations.

Enabling Event Collection for Synthetic Transaction Rules

The Exchange 2010 management pack uses synthetic transactions, such as the running of the Test-MapiConnectivity, Test-OwaConnectivity, and other commands, to scan your Exchange organization for basic connection responses and to test simple operations such as logging in to a mailbox. Whether these tests succeed or fail, their output is useful for investigating the state of the Exchange environment. However, since there is a significant amount of output for each task, the event output is not stored by default.

NOTE: Event collection increases database utilization. Do not enable unless you want a closer look at what’s happening behind the scenes, or you have some troubleshooting to do. Make use of the Top Generators reports in the OpsMgr 2007 R2 Core Monitoring MP. Read more on these reports HERE.

If you need to enable the event collection rules for synthetic transaction output, perform the following steps:

  1. In the Operations console, click Authoring.
  2. In the Authoring pane, expand Management Pack Objects, and then click Rules.
  3. In the Rules pane, click Change Scope.
  4. In the Scope Management Pack Target(s) by object dialog box, in the Look for box, type “Exchange Server 2010.”
  5. Click View all targets.
  6. Click Select All if it’s not disabled (it is only disabled when all rows are already selected).
  7. Click OK to close the dialog box.
  8. After the rules have loaded, type “Script event collection” in the Look for box near the top of the console.
  9. For each test task you would like to enable, perform the following steps:
    • Right-click on the rule and select Overrides > Override the Rule > For all objects of class: [class name].
    • Click the Override checkbox.
    • Set the override value to True.
    • Click OK.

NOTE: It will take some time for the overrides to be picked up by the agents and for events to appear in the built-in views.

Tuning / Alerts to look for in the Exchange 2010 MP

In this section, we need to address not only alert tuning, but alert tuning in the context of the correlation engine. There are a few things to be aware of before you start creating overrides. While the correlation engine evaluates faults in the context of the health model, it is not a black box. You can gain some insight into what faults the engine has evaluated in order to determine which alert to raise in the Operations console.

The following are some tuning guidelines to consider with regard to the management pack.

Disabling Monitoring – As mentioned in the first section of this discussion, wholesale disabling of monitors is discouraged by Microsoft. If you disable a portion of the state monitoring within the health model, you are eliminating a portion of the input the engine is expecting to reach an appropriate determination of root cause. Particularly, disabling monitors in the lower levels of the health model for services and components in use in your environment (database, services, etc.) could potentially disrupt the process.

For example, if you disable the monitor that watches to ensure the Exchange databases are mounted, root cause analysis would point to an incorrect root cause when a database is offline. However, if there are some alerts raised for components not actively utilized in your organization, you may well want to disable these monitors to eliminate alerts that are not actionable. For example, if you have databases that have been created but are not yet in use and mounted, you would likely want to disable monitoring for those database instances.

Additionally, because the Exchange 2010 management pack is designed with Exchange 2010 best practices in mind, there may special cases where Exchange has been deployed for a special purpose or perhaps in some unusual configuration, and some tuning and testing of non-standard scenarios will be required to ensure an accurate result.

Threshold Overrides – On the other hand, tuning of monitoring thresholds is a normal part of the tuning process. Upon closer examination, you may find thresholds of unit, aggregate rollup and dependency rollup monitors may need to be adjusted for your organizations specific configuration. However, the thresholds are designed to suit the needs of most organizations out-of-the-box.

In particular, it seems probable that some organizations may want to adjust the rollup percentages on the dependency rollup monitors use to gauge the health of distributed components and high-availability configurations. No doubt hardware sizing and load distribution introduce some environmentally specific variables that may require fine-tuning in some environments. With far fewer alerts raised as a result of the correlation engine, there are now definitely a much smaller number of false alerts that require tuning. There were a small number of alerts of which you should be aware which are described here:

Alert: The test mailbox was not initialized. Run new-TestCasConnectivityUser.ps1 to ensure that the test mailbox is created.

Issue: There is a bit of documentation currently missing from the guide related to configuration of synthetic transaction monitoring.

Alert: The required SCOM hotfixes for Exchange MP are not installed.

Issue: While it is good that an alert is raised for Exchange servers without the requisite hotfixes, the problem lies in the targeting. This monitor targets the Health Service class, which means it can potentially raise alerts for EVERY agent in your environment, regardless of what server applications they are running.

Resolution: Create a group containing the health service instances of Exchange 2010 servers. Disable the monitor for the Health Service class. Re-enable for the group of Exchange 2010 Health Service instances.

Alert: IMAP4 [and] POP3 connectivity transaction failure.

Issue: If you have not deployed those protocols in your organization, there is unnecessary alerting.

Resolution: Override the IMAP4 and POP3 connectivity transaction failure alerts on CAS servers where these services are not running.

Discovery Overrides – In a large environments where OpsMgr administrators are seeking to minimize the number of discoveries across all management packs, we noticed two Exchange 2010 discoveries to consider de-tuning in terms of the frequency of the discovery. These are the Microsoft.Exchange.2010.Mailbox.MdbOwningServerLocalEntityDiscoveryRule and the Microsoft.Exchange.2010.Mailbox.MdbOwningServerRemoteEntityDiscoveryRule. The default discovery of every 14,400 seconds (every 4 hours) might be extended by override to every 86,400 seconds (once per day).

Insight into the Correlation Engine

Because the correlation engine is itself a black box of sorts, a natural human response is to ask what exactly that engine is up to and how it works under the Hood. Questions we heard quite a lot at MMS 2010 and in the days since include “Why should I trust the correlation engine?” and “What faults did the correlation engine evaluate in raising this alert?”

These are both fair questions, so let’s consider them individually.

Why should I trust the correlation engine?

Microsoft might say “because we’ve been using this management pack to monitor the largest Exchange environments in the world for the last two years.” While that does provide some comfort, it does not alleviate the perception of the correlation engine as a “hands off” process. However, you do have some ability to review a fault interpreted by the correlation engine in raising an alert for the root cause of a given incident.

What faults did the correlation engine evaluate in raising this alert?

You can gain some insight to the correlation engine  from within the Operations console. In the properties of an alert, you’ll find an AlertContext tab. On this tab, you find some XML that reveals what fault the correlation engine has determined to be root cause versus those considered to be related issues — faults that were raised as a result of the fault considered to be root cause. The fault within the <RootCause></RootCause> tags is the one determined by the correlation engine to be the root cause of the incident, and the faults within the <RelatedIssues></RelatedIssues> tags are those determined by the correlation engine to have been raised as a result of the root cause. While this information is only available after the fact, it still provides some visibility into the data taking into consideration by the correlation engine before raising the alert for the cause of a given incident.

image

Figure 5 – Alert-context Tab of Alert Raised by Correlation Engine.

image

Figure 6 – Root Cause (within AlertContext tab)

image

Figure 7 – Related Issues (within AlertContext tab)

Certainly the discussion doesn’t end here. The introduction of the correlation engine raises questions as to what this portends for future releases of other management packs for large distributed applications, such as Active Directory and SharePoint. While the correlation engine may be a positive development in the quest for speedy root cause analysis, it raises concerns about the rise of multiple Windows-based engines that perform similar functions for other management packs. At what point does this correlation move from stand-alone services into the core product itself? Perhaps some light will be shed on this as Microsoft’s plans for Operations Manager vNext are revealed.

Conclusion

The Microsoft Exchange 2010 Management Pack brings some new thinking to the table. What do you think of these changes? What has your experience been with the Exchange 2010 management pack? We are eager to hear your thoughts, which you may leave a comment on this post. Questions, comments and any feedback on Exchange alerts or tuning guidance that you found helpful in your environment are welcome and appreciated

 

 

Microsoft UC vs Cisco UC

January 4, 2011 Leave a comment