The Exchange 2010 Database Availability Group (DAG) is an important feature that provides high availability. Therefore, monitoring the DAG replication network is an important part of keeping the high availability in your environment as healthy as possible. Replication of Exchange 2010 databases in your messaging environment has specific network requirements outlined in this TechNet document. The best scenario is to use two network adapters per DAG node member. One adapter supports the MAPI Network which is used by other servers, for example other Exchange 2010 servers or directory servers. The other adapter is for the DAG replication network which is dedicated for database replication. With all this said, Exchange 2010 is smart enough to switch replication from the replication network to the MAPI network in the event of a communications problem on the DAG replication network.
The Cisco IronPort E-mail Security Appliance (ESA) makes various statuses available in an XML format and you can use PowerShell to parse the XML data and get some useful information. With this technique you can create a report about the IronPort delivery status in your environment. Forget about trying to force PowerShell into using some sort of SSH connection method. I’ve tried it and it isn’t pretty. There is a security concern with the following method but it is a proof of concept that may work well in your environment. Here are the ingredients to get you started:
- A Cisco IronPort E-mail Security Appliance (ESA) and a need to access the status pages.
- An account that can authenticate to the ESA, preferably with the guest role.
- A locked down environment that will reduce attack surfaces within your organization.
The methodology is rather simple, use PowerShell to grab an XML status page and parse it into an object that can be massaged for your benefit. Think of having a script send you a periodic report about the IronPort delivery status of your appliance, awesome! To illustrate, I’ll be looking at the tophosts status since I really want to know about my partner organizations that could be having problems. Why not automate and be proactive at the same time?
Waiting for a script to gather data can be a frustratingly long experience at times. A common task when using PowerShell cmdlets with Exchange 2010 is to enumerate mailboxes on a database. If you are counting the number of mailboxes per database using Get-Mailbox, it’s possible to speed things up. A faster method is to use Get-MailboxStatistics, although the cmdlets return different data, the mailbox count per database is what we want in a speedy manner. I’ve created two scripts with a timer built into each so that the speed of mailbox enumeration can be effectively illustrated. We are doing the following:
- Comparing Get-Mailbox versus Get-MailboxStatistics.
- Using a timer to illustrate the speed difference of counting mailboxes per database.
The test environment consists of 48 DAG databases with about 400 mailboxes on each, spread across four servers.
If your Exchange 2010 deployment utilizes a DAG in two or more Active Directory sites you may have run into situation where the Primary Active Manager (PAM) is unexpectedly located on a DAG node that resides in another site. The PAM, aka the “cluster group” will shift around as necessary among the members of your DAG for various reasons. So you ask, “Who moved my PAM?”:
- You may have moved it as part of DAG maintenance.
- There was problem with the DAG node hosting the PAM, such as errors in the ESE or a storage problem, and the role moved to a server in an alternate site.
- A network communications error occurred, affecting the cluster service heartbeat, causing the PAM to move to what it believes is a surviving member of the DAG.
Unfortunately there is no way to add a server preference to the PAM role. It would be nice to be able to tell the PAM to try and stay on a server at a preferred active directory site. The only thing that you can do is to block a DAG member from having database copies activated on it with the following command:
If you have a large amount of DAG databases you may want a quick way of identifying which Exchange mailbox role is hosting the active copy of your databases. Sure you can take a look at the EMC but I have a quick way for you to determine if each database is mounted on the mailbox server specified with an activation preference of 1. Credit for this script is to René van Maasakkers on his blog.
Start out with filtering down the databases that are part of a DAG and not recovery databases. Then run a ForEach loop that will capture the name of the database, server on which the database is mounted, and the activation preference of the database. Finally use Write-Host to enumerate the names grabbed earlier and use IF ELSE logic to output the status of the mounted database.
Setting up DAG replication is extremely important as outlined in Tim McMichael’s TechNet post, Exchange 2010: Collapsing DAG Networks. Even when you correctly disable the MAPI network from log shipping, Exchange 2010 will still resort to log shipping on the MAPI network if there is a communication problem on the replication network. Once you become aware that there has been a communications problem between DAG nodes on the DAG replication network, the next thing you should do is to check a few things out.
- Determine the location of the PAM if your DAG is split across two or more active directory sites.
- Verify that databases are mounted on the correct mailbox server.
- Verify the value of the OutgoingConnections property on active mailbox databases.
- Verify the value of the IncomingLogCopyingNetwork property on passive database copies.
Do you need an automated process to migrate from a legacy Exchange environment to Exchange 2010? This article is step two of a two step migration process that involves separate PowerShell scripts to accomplish an Exchange 2010 migration. This is the second script that resumes the migration of legacy Exchange mailboxes and distributes them evenly across existing Exchange 2010 databases. The bulk of this script deals with reporting the results of the migration for later review and analysis. I’ll break down the script in detail so that you can understand what is happening. (Part 1 can be found here)
The script executes the following:
- Selects the pending move requests based on a batch name.
- Verifies that status of move requests are acceptable and then resumes the migration.
- Waits until all resumed migrations are completed or completed with warnings before starting to build a report.
- Creates a report about all the mailboxes moved.
- Writes report to CSV and sends the report via email.
Do you need an automated process to migrate from a legacy Exchange environment to Exchange 2010? This article is step one of a two step migration process that involves separate PowerShell scripts to accomplish an Exchange 2010 migration. The two part migration process will allow you to begin migrations during the work day and then cut over the mailboxes to Exchange 2010 at a convenient time. This is the first script that migrates legacy Exchange mailboxes evenly across existing Exchange 2010 databases. I’ll break down the script in detail so that you can understand what is happening. The script executes the following:
- Selects a set of mailboxes to migrate based upon membership of a distribution group.
- Selects the Exchange 2010 databases that you want to target.
- Creates a data table to hold the mailboxes to be migrated.
- Creates a data table of target mailbox databases that will be used to select the optimal database target based on various criteria.
- Queries the target Exchange 2010 databases to see how the databases are populated and considers various criteria.
- Queries the source mailboxes and assigns them to target Exchange 2010 databases for a move request.
- Submits new move requests.
- Loops until all mailboxes are in an auto suspended state or failed state.