How to move data using PowerShell when migrate to Exchange 2010

You’ve made the decision to migrate to Exchange Server 2010. After you’ve brought Exchange Server 2010 into your existing Exchange organization and properly prepared Active Directory, the next step is to move mailboxes, public folders and PST data from your old Exchange servers to your new Exchange 2010 servers. You’ll need PowerShell to accomplish these tasks.

Note: You can move content between mailbox servers using the graphical user interface, but it’s usually easier to use Exchange Management Shell commands because you can perform bulk moves using a single line of code.

Moving mailboxes to Exchange 2010 using PowerShell
In Exchange Server 2010, mailbox moves are performed using move requests. A move request requires the name of the mailbox being moved as well as the name of the target database. If you don’t specify a target database, Exchange will select one at random.

For example, if you wanted to move a mailbox named User1 to an Exchange 2010 database named DB1, you could use the following command:

New-MoveRequest –Identity User1 –TargetDatabase DB1

Now that you know how to move a single mailbox, a more efficient approach is to move allof the mailboxes from an entire mailbox database with a single command. For example, to move all of the mailboxes from DB1 to DB2, use the following command:

Get-Mailbox –Database DB1 | New-MoveRequest –TargetDatabase DB2

It’s also possible to create a detailed report of the moves after they’ve been completed. The report can be written to a text file or to a CSV file. To create a move report and write the output to a file named C:MOVE.LOG, enter the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, TotalItemSize, TotalMailboxItemCount, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

If you don’t want to wait to check the status of the move, you can also generate a report to find out how it is progressing. If you want to see how far along the move is, use the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, PercentComplete, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

When all your mailbox moves complete, you must terminate the move request. If you don’t, you won’t be able to move the mailboxes again should the need arise. To terminate a move request, use the Get-MoveRequest | Remove-MoveRequest command.

Moving public folders to Exchange 2010 using PowerShell
Public folders are not a requirement in Exchange Server 2010 unless you plan on having an Exchange 2010 mailbox server that supports clients running Outlook 2003 or earlier. That said, if you have public folders on your legacy Exchange servers that contain useful data, you can move them to Exchange 2010 using PowerShell.

To move all of the public folder replicas from one Exchange server to the other, open the Exchange Management Shell, and enter the following commands:

Set-ExecutionPolicy Unrestricted
CD
CD “Program FilesMicrosoftExchange ServerV14Scripts”
./MoveAllReplicas.ps1 –Server <old server name> -NewServer <new server name>

When the process completes, set the execution policy back to RemoteSigned by entering theSet-ExecutionPolicy RemoteSigned command.

Importing PST files into Exchange 2010 using PowerShell
Exchange Server 2010 is the first version of Exchange to support personal archive mailboxes. Many organizations place archive mailboxes onto dedicated mailbox servers that are equipped with low-cost storage, so that user archives do not affect the performance of the primary user mailboxes.

Archive mailboxes offer a great alternative to PST files, and many organizations have begun moving PST file contents to archive mailboxes as a part of the migration process. Note, however, that this method works only for Exchange 2010 SP1. The RTM release of Exchange 2010 used a different PowerShell cmdlet that was buggy. You should also know that this cmdlet doesn’t create the archive mailboxes; so make sure that the archive mailboxes actually exist before using it.

To import a PST file into an archive mailbox, use the New-MailboxImportRequest –FilePath <the path to the PST file> -Mailbox <mailbox name> -IsArchive cmdlet.

How to improve your Exchange 2010 Backus

Some Exchange administrators don’t employ best practices when backing up Exchange Server, resulting in a less-than-optimal backup experience. These tips reduce the impact of the Exchange 2010 backups and minimize the time required to perform restorations.

1. Offload your Exchange backup consistency check

Volume Shadow Copy Service (VSS) backups are the only type of online backup that Exchange 2010 supports. Because of how VSS snapshots work, the backed-up data may not be consistent. Therefore, certain backup applications perform consistency checks as part of the backup process.

Consistency checks vary from one backup product to the next. Some applications run a consistency check directly on the mailbox server. This increases the load on the server and causes the backup to take longer than it should.

If possible, offload the consistency check from your mailbox server to your backup server. Not all backup products offer this option, but if you can offload the consistency check, you greatly improve your backup’s efficiency.

2. Modify your Exchange mailbox server maintenance schedule

If you perform daily backups, you know that they usually run late at night to lessen the impact on users. Since Exchange Server 2010 also runs resource-intensive maintenance tasks each night, backup operations and maintenance tasks end up competing for server resources.

The most obvious way to avoid this is to schedule the maintenance tasks and backups so that they don’t overlap. The other option is to increase the window for maintenance tasks.

Maintenance tasks often do not complete within the allotted time frame and pick up where they left off the next night. If you increase the window to allow the maintenance tasks to complete within a single night, you’ll find that the maintenance eventually requires less time. Also, keeping your databases small helps decrease the amount of time necessary for proper maintenance.

3. Perform DAG backups with caution

I recently wrote an article saying that Exchange 2010 backups may not be necessary in organizations with large database availability groups (DAGs). Additionally, some companies choose not to back up their DAGs because the whole process is quite complicated.

Remember, you can only backup a DAG member if it contains active databases. If even one passive database resides on the DAG member, it cannot be backed up. Therefore, if you plan to back up your DAG members, be certain to arrange your active and passive database copies so that backups are possible.

4. Confirm Exchange 2010 backups

No doubt you’re aware that testing your backups is important. However, you may not test backups as often as you should.

Aside from actually testing your backups, you can find out if Exchange is successfully backed up by checking your backup software logs. You can also get backup-status information directly from Exchange.

Enter the Get-MailboxDatabase <database name> -Status | Select LastFullBackupcommand to check the last time a mailbox database was backed up. Compare this information with your backup software logs to make certain that both Exchange and your backup software acknowledge the latest backup.

5. Keep your Exchange databases manageable

Many Exchange administrators try to simplify things by placing all of their users’ mailboxes in a single database. However, when it comes to backup best practices, you should have several small databases instead of one large database. If a failure occurs and you need to restore a database, small databases can be restored quicker than large ones.

Run Exchange 2010 backup or skip this

When Exchange Server 2010 RTM hit, some IT pros suggested that database availability groups in Exchange 2010 make traditional backups unnecessary.

I initially scoffed at the idea. However, Exchange 2010 has been available for a while and the idea of a “backup-less” Exchange server makes sense in some environments.

The concept behind ‘backup-less’ Exchange
A backup is nothing more than a point-in-time copy of your data. It is this deceptively simple definition that led to the idea of running Exchange 2010 without backups.

Some say running Exchange 2010 without backups is safe because of the way database availability groups (DAGs) work. A single DAG can contain up to 16 mailbox servers and an individual mailbox database can be replicated to any combination of mailbox servers within the DAG.

The argument against backing up Exchange 2010 boils down to how many copies of data you really need. If you already have 16 replicas of a mailbox database, do you really need a seventeenth copy as backup?

Important Exchange backup considerations
While the argument against backing up Exchange 2010 in environments with DAGs sounds logical, there are a number of important factors to consider before ditching your backup system.

• DAG size
  While you can include up to 16 mailbox servers in a DAG, you can also create very small groups. Therefore, you must consider the size of your DAG before abandoning backups. Microsoft recommends that you only consider going without a backup if you have three or more mailbox servers in your DAG.

• Transaction logs
  Typically, when you back up an Exchange mailbox server, the contents of transaction logs are committed to the database as part of the backup process. If you never perform a backup, the transaction logs accumulate until the volume runs out of disk space. Because of this, organizations that do not back up Exchange 2010 must enable circular logging to prevent log file accumulation.

• Offsite storage
  It’s easy to think of a backup-less Exchange organization in the same way as a disk-based backup solution because database contents are replicated to other servers.However, organizations that depend on disk-based backups usually adopt a disk-to-disk-to-tape solution where the disk-based backups are periodically copied to tape and stored offsite. If the data center burns down, the backups remain safe.

  If you’re considering operating Exchange without backups, it’s smart to place a few DAG members in a remote data center. That way, your data remains protected even if something happens to your primary data center.

• Point-in-time recovery
  The biggest disadvantage to running Exchange 2010 without backups is that you lose the option of accurate point-in-time recoveries. For example, imagine that your entire company became infected with a virus.In this situation, you could restore a backup that was made prior to the infection, rather than trying to remove every infected message from your mailbox database. This is simple with a traditional backup, but isn’t practical if you go without.

  Notice that I didn’t say that it’s impossible to perform a point-in-time recovery without a backup. Microsoft does let you create lagged database copies that log files are not immediately replayed on. That way, if you need to revert to a particular point in time, you can activate a lagged copy.

  The problem is that there’s a lot of guess work involved in the process. You must know exactly when the problem began in order to get rid of all of the transaction logs that were created after the problem occurred. This is accomplished by replaying the transaction logs that were created prior to the problem. Unfortunately, there isn’t an easy way to figure out which transaction logs should be used and which should be deleted.

  As you can see, it’s perfectly feasible to run Exchange 2010 without traditional backups in certain situations. That said, I advise backing up Exchange as you always have. If an unforeseen set of circumstances leads to data loss, you won’t have to explain to your boss or management that you don’t have backups.

Server load balancing in Exchange 2010 hub transport

Microsoft encourages failover clustering to provide fault tolerance and redundancy for Exchange Server. However, neither the client access server nor the hub transport server roles support failover clustering in Exchange 2010 — only mailbox servers may be clustered.

To provide fault tolerance and redundancy for your hub transport servers, you must deploy one or more additional hub transport servers. When you do, Exchange 2010 automatically distributes the workload across your hub transport servers. This way, you don’t have to worry about building a cluster or configuring Exchange to use the new server.

While providing redundancy for the hub transport server role in Exchange 2010 is fairly simple, there are a couple of important factors to remember when it comes to effective load balancing.

Each mailbox server requires a hub transport server

The hub transport server resides at the Active Directory-site level. This means that every Active Directory (AD) site that contains an Exchange mailbox server also needs at least one hub transport server. You can’t set up a single hub transport server and expect it to service a multi-site.

Exchange Server deployment.

Because the hub transport server functions at the AD-site level, redundancy and fault tolerance must also occur there. Deploying redundant hub transport servers help provide load balancing and fault tolerance for a single site, not the entire Exchange Server organization.

The importance of Exchange Server 2010 Service Pack 1

The other important thing that you need to know about protecting the hub transport server role is that if you’re using Exchange Server 2010 and have hub transport servers in multiple sites, Exchange 2010 Service Pack 1 (SP1) is essential. If you haven’t installed Exchange 2010 SP1, a hub transport server failure will result in uneven workload distributions.

When Exchange 2010 routes messages to another AD site, it uses a technique similar to domain name system (DNS) round robin to distribute the load among the hub transport servers in the remote site. For example, if a remote site contains five hub transport servers, each server receives approximately 20% of the messages sent from the local site.

With that in mind, imagine that one of the five hub transport servers fails. The hub transport servers in the local site are completely unaware of the failure in the remote site. Therefore, the servers continue distributing the workload to all the remote hub transport servers. The connections to the offline hub transport server fail, but once the failure is detected, Exchange routes the messages to the next hub transport server.

The problem here is that the next hub transport server in line must take on the failed server’s workload in addition to its own. This behavior is normal for sites with only two hub transport servers, but for sites with three or more hub transport servers, it results in uneven load balancing. Consider our example: If a failure occurred in a site with five hub transport servers, one of the remaining servers would need to handle 40% of the total workload, while the three remaining servers still received only 20% of the total workload.

Exchange 2010 SP1 is essential because it includes a feature called the Healthy Server Selector, which tracks which Exchange servers are available. If a hub transport server in a remote site fails, the Healthy Server Selector discovers the failure and prevents the local hub transport servers from sending messages to the failed server until it comes back online. This helps Exchange ensure that workloads are evenly distributed among the remaining hub transport servers.

Best practices for virtualizing Exchange 2010 server roles

When virtualizing Exchange Server 2010, it’s important to correctly configure virtual machines (VMs) that will host certain Exchange Server roles – otherwise a few gotchas will surface. For example, you’ll need to assign the correct number of processors to the appropriate amount of RAM. This tip gives more advice for correctly configuring VMs for optimal performance.

Client access and hub transport servers

Even in small Exchange environments, the Client Access Server role and the Hub Transport Server role are commonly collocated with the Mailbox Server role on a single computer. For organizations with hundreds or thousands of mailboxes, this is an all-in-one configuration.

Resource requirements for the CAS are usually less than what the hub transport server traditionally needs. Since every piece of mail in an Exchange Server 2010 organization flows through the hub transport server — for routing and messaging policy application purposes — it bears a heavy load.

Microsoft states that each role should be given a minimum of 2 GB of RAM, with a recommended setting of 1 GB per core for the hub transport server and 2 GB per core for the client access server. Comparative requirements for the client access server can be larger in environments that heavily rely on Outlook Web App (OWA).

As a rule, virtualization environments work best when VMs are configured with the smallest number of processors possible. The processor power requirements of your Exchange 2010 environment will determine that number. Starting small and working up is the best rule of thumb.

Microsoft suggests eight cores for the hub transport server and four cores for the client access server to support an organization of several mailbox servers and thousands of mailboxes. Organizations with fewer mailboxes and lower levels of non-MAPI client traffic could start with as few as two cores.

Edge transport servers

Edge transport servers typically consume lower levels of resource utilization. This level can depend on the rate of inbound and outbound mail flowing through your Exchange organization, along with your level of rejected mail. If your organization deploys spam filtering from an upstream provider, this reduction in traffic can affect edge transport resource utilization.

Microsoft also suggests configuring edge transport servers with a single processor core and up to a maximum of twelve cores — if your virtual platform will support them. RAM requirements start with a minimum of 2 GB with 1 GB per core. You can always add more memory later if you experience excessive paging, poor performance or an email build-up in messaging queues.

Unified messaging servers

This is easy — don’t virtualize unified messaging servers. Microsoft does not support them. Unified messaging servers require substantial processing power and have little tolerance for processing latency. Microsoft’s suggestion for even a small Exchange organization is a minimum of two to four cores and 4 GB of RAM, with 2 GB per core of RAM. If you’re using unified messaging, I advise that you steer clear of virtualization for now.

Mailbox servers

Mailbox servers are the heavy-lifters in any Exchange infrastructure; they are where resources are used in larger quantities. You might want to consider virtualizing mailbox servers last. While they can be virtualized, they require careful evaluation before beginning. Experience gained from virtualizing Exchange’s other less-challenging roles will help.

Microsoft states that a four-core mailbox server should be able to support several thousands of mailboxes. The RAM recommendation for that server starts with 4 GB of RAM plus an additional 3 to 30 MB per mailbox. Virtualizing any mailbox server will consume a large share of your virtual host’s available RAM resources, so plan accordingly and don’t oversubscribe your virtual infrastructure.

Exchange Server 2010 virtualization gotchas

Exchange Server organization’s mail usage characteristics have more to do with these calculations than any RAM or core numbers suggested here. Measuring your existing metrics on physical servers is the first step in preparing to virtualize Exchange Server. Measured over time, those metrics are necessary to determine your starting points for processor and memory resource assignment.

Microsoft states that relying on someone else’s numbers is a flawed assumption. In Understanding Server Role Rations and Exchange Performance, Microsoft notes, “A significant percentage of the server processing is associated with the overhead of analyzing connections and scanning accepted messages. For this reason, it’s not possible to provide a sizing metric based solely on the number of messages sent and received per second….”

While this quote relates specifically to the activities within the edge transport server, it’s also good advice for the other roles. If you don’t correctly determine a baseline for your Exchange 2010 server role performance before you begin a virtualization project, any or all of the roles may cause trouble.

How To prioritize backups for virtualized Exchange 2010 servers

xchange Server 2010 includes a variety of policies throughout its infrastructure that limit and control storage. Sent and received message sizes can be limited; individual mailbox sizes can be limited. You can even limit mail and attachments coming from outside an Exchange organization.

Database backup and restore is another reason why controlling mailbox size is important to the health of your Exchange Server 2010 organization. As your databases grow, so does the amount of time you need for backup or restore, as well as any related task.

Exchange admins often focus more on the backup half of backup and restore. Yes, ensuring good backups is important; however, IT pros often spend too much time watching backups to complete and waste too much effort complaining that this process takes too long.

These activities are important for preserving data, but the most important metric actually has less to do with the time required to back up data than the time required to restore it. Restore time greatly factors into backups in a virtualized Exchange environment. This is especially true with Exchange 2010’s specialized databases.

Backups for your virtualized Exchange 2010 servers can live in several places:

1. On the mailbox server — From the mailbox server, backups occur much like traditional backups in a physical environment, offloading data to tape file-by-file. This process ensures that Exchange Server’s databases pause correctly so that they back up without data corruption. One problem you may run into is that agents installed here tend to put a strain on virtual environment performance during operation.

2. On the virtual host – From this location, the .VHD or .VMDK file becomes the backup unit. Here the backup agent must interact with another agent inside the VM to ensure the successful quiescence of Exchange’s databases. VHD and .VMDK backups are famous for simple point-in-time restore of entire VMs or databases. However, retrieving a single email or lost mailbox might require you to restore an entire database first, which can significantly increase restore time.
3. Servers outside the virtual environment — Encapsulating Exchange 2010 mailbox databases into .VHD or .VMDK files may create enormous files on disk, particularly when multiple databases are contained within a single disk volume. Configuring data partitions as raw disk mappings (RDMs), pass-through disks, or iSCSI connections keeps mailbox databases in a more raw format. With the correct tools, these files can be backed up directly from storage LUNs. The obvious concerns about proper database quiescence remain here.
4. On a"Backup 2.0" solution — These solutions gather backups through a file system filter driver located on the virtual host. Backup data is then deposited onto disk rather than tape. This approach reduces the storage requirements of backup while providing fast entire-server, entire-database or even single-item restore. While this is a relatively new approach, product options in this space are growing quickly. With this approach you may need to completely rethink — and potentially repurchase — your backup solution.

Unfortunately, none of these options completely solves the problem without additional cost, effort or performance degradation. To avoid making backup and restore mistakes when virtualizing Exchange, take a long look at what types of restores are important to you and how quickly you need those restores to complete.

For example, if entire database restorability is more important than restoring individual items in Exchange 2010, placing backups on virtual hosts or on servers outside your virtual environment (options two and three above) are your best bets.

Some businesses have decided that individual item restores are not an option. These environments prefer to designate more time before permanently removing deleted items. This prioritization is also useful for journaling and archive databases, where the preservation of all data is more important than individual item restorability.

Other Exchange organizations find that restoring individual email messages, mailboxes or calendar items is just as critical as protecting an entire Exchange database. Placing backups on your mailbox server or a backup 2.0 solution (options one and four above) provide the necessary functionality for these environments. Backups residing on the mail server leverage the tried-and-true interfaces of traditional backup solutions. A backup 2.0 solution trades those interfaces for added flexibility of what is being backed up.

The Exchange 2010 High Availability – Active Manager

On each Exchange 2010 mailbox server there is a process running inside the Microsoft Exchange Replication Service (MSExchangeRepl) called Active Manager which is the high availability brain in Exchange 2010. Active Manager manages failover and switchover (known as *over) on DAG members by selecting the best database copy to be activated. It also frequently checks the Active Directory topology on each mailbox server for any changes.

On each DAG member we find either a Primary Active Manager (PAM) or a Standby Active Manager (SAM). All DAG members will have a SAM except on the node that owns the quorum that will be running a PAM. One of the Active Manager functions is to monitor the database and information store health. If the database fails on a DAG member, SAM informs the PAM about this failure to take action.

SAM also responds to queries from Client Access servers and Hub Transport servers for the active mailbox database owner. When a user connects to a CAS, the CAS queries the Active Manager on a DAG member for the active mailbox database where the user mailbox is located, to connect the user to. The SAM responds with the server on which the database is active.

If the quorum owner failed, the Active Manager on the node that obtains the quorum becomes the Primary.

If an active mailbox database fails, and if the database is configured for replication, the PAM is notified to select the best database copy to be activated on another node. This is done as follows:

• The Best Copy Selection (BCS) algorithm is run.
• After selecting the best copy, the PAM notifies the selected server to become the next database master.
• The Microsoft Exchange Replication Service on the selected server will try to copy the logs from the previous active database master through the Attempt Copy Last Logs (ACLL) process. ACLL will query other servers where there is a healthy database copy with the highest log generation number by checking the LastInspectedLogTime.
• After completing the ACLL, the PAM notifies the selected server to mount the database. If all the logs were copied successfully, the database mounts without any data loss. Otherwise if some of the logs could not be copied then the database will only be mounted if the number of missing logs (copy queue length) is less than the value configured for the AutoDatabaseMountDial parameter.

  The AutoDatabaseMountDial parameter can be set to BestAvailability, GoodAvailability orLossless. If the value is BestAvailability, which is the default, the missing logs must be less than or equal to 12 for the database to be mounted automatically. If the value is GoodAvailability the missing logs must be less than or equal to 6 for the database to be mounted automatically. If the value is set to Lossless all the logs should be copied to the selected server for the database to be mounted, in other words, the number of the missing logs must be 0.

• If the database could not be mounted on the selected server, the next candidate mailbox server obtained by the BCS process will be selected (if any). If there is no other mailbox server to be selected, the administrator has to manually mount the database and accept the data loss.

There are other reasons because of which the mailbox database might not be mounted on the selected server. A property can be configured for each DAG member to limit the number of simultaneous active databases on it. If the limit is reached, no other database copy can be activated or mounted on this server and the PAM will repeat the process of selecting the next database master again. This limit can be configured using the Set-MailboxServer cmdlet with the -MaximumActiveDatabases parameter.

Set-MailboxServer -Identity <MailBoxServer> -MaximumActiveDatabases <number>

Another case when the server selected to be the next database master will not automatically activate and mount the database copy is that when the automatic database activation is disabled on the server; i.e. theDatabaseCopyAutoActivationPolicy for the server is set to Blocked using the command:

Set-MailboxServer -Identity <MailBoxServer> -DatabaseCopyAutoActivationPolicy Blocked

Now after we described what happens after the best copy is selected, we need to know how the PAM selects that best copy. What is behind the BCS algorithm? This is what we will discuss next.

Best Copy Selection process

The BCS algorithm results in a list of database copies that represent a good candidate for activation. This list is then sorted based on (in order):

Primary key:

1. The lowest Copy Queue Length CQL (the highest LastLogInspected)
2. The lowest Reply Queue Length RQL
3. Content Index CI status (Healthy or Crawling)

Secondary Key:

1. The lowest Activation Preference (which you specify when adding a database copy to the mailbox database)

The previous selection criteria is applicable for both Exchange 2010 RTM and Service Pack 1. But in Exchange 2010 SP1 if the AutoDatabaseMountDial parameter for the mailbox server is set to Lossless then the list is sorted based on the Activation Preference as a primary key.

There will be ten possibilities based on the above mentioned criteria, they can be summarized as:

1. ( CQL < 10 ) and ( RQL < 50 ) and ( CI is Healthy )
2. ( CQL < 10 ) and ( RQL < 50 ) and ( CI is Crawling )
3. ( RQL < 50 ) and ( CI is Healthy )
4. ( RQL < 50 ) and ( CI is Crawling )
5. ( RQL < 50 )
6. ( CQL < 10 ) and ( CI is Healthy )
7. ( CQL < 10 ) and ( CI is Crawling )
8. ( CI is Healthy )
9. ( CI is Crawling )
10. If none of the nine set of criteria are met by the database copies, then the PAM will try to activate a database with a status of Healthy, DisconnectedAndHealthy, DisconnectedAndResynchronizing, or SeedingSource.

CQL – Copy Queue Length
RQL – Reply Queue Length
CI – Content Index

Example

In our example we have a DAG with members (EX14MBX1 – 4). The mailbox database Main-DB01 has copies on these four members. The status of the database copies is as shown in the following figure:

Main-DB01 is currently active on mailbox server Ex14MBx1. If Ex14MBx1 failed and the content index status of the database copies on the other three mailbox servers (using the command Get-MailboxDatabaseCopyStatus) is:

Also let’s assume that the AutoDatabaseMountDial for all servers is set to GoodAvailability (copy queue length must be less than or equal to 6), and server Ex14MBx2 is configured to host no more than two active mailbox databases at the same time (MaximumActiveDatabases is set to 2).

Now if server Ex14MBx1 fails, the PAM, after being notified, will start the BCS process:

1. Because the AutoDatabaseMountDial is not set to lossless a list of servers based on the lowest copy queue length is created. The list will be: Ex14MBx2, Ex14MBx4, Ex14MBx3
2. The list will be sorted based on the above mentioned criteria.
   • Ex14MBx2: (CQL<10), (RQL<50) and (CI is Crawling) – match criteria 2
   • Ex14MBx3: (CQL<10), (RQL<50) and (CI is healthy) – match criteria 1
   • Ex14MBx4: (CQL<10), (RQL>50) and (CI is healthy) – match criteria 6

   So the resulted list is

   1. Ex14MBx3
   2. Ex14MBx2
   3. Ex14MBx4
3. ACLL will now try to copy the missing log files from the previous database master Ex14MBx1 to the first server in the list which is Ex14MBx3. However Ex14MBx1 is down and cannot be contacted. Furthermore since the AutoDatabaseMountDial is configured to GoodAvailability (copy queue length must be less than or equal to 6) and the actual copy queue length on server Ex14MBx3 is 8 (see above screen shoot) then Ex14MBx3 will not activate Main-DB01.
4. The next server in the list Ex14MBx2 will be notified. The copy queue length is 5 so this database can be mounted on this server but Ex14MBx2 is configured to activate only 2 databases (MaximumActiveDatabases = 2) so it will not be activated on this server.
5. Server Ex14MBx4 will be notified. Copy queue length is 5 and content index status is healthy. ACLL will notify PAM that the process succeeded on server Ex14MB4. PAM will notify Ex14MB4 to mount and activate the mailbox database Main-DB01.

In case none of the database copies can be mounted, then the administrator has to manually activate a database copy on one of the servers and accept the data loss.

Summary

Today we looked at the Active Manager role. Running on each Exchange 2010 mailbox server, it controls High Availability and monitors Database Availability Groups . On DAG members it controls switchover and failover by selecting the best candidate to activate the database copy on it based on a set of criteria. Finally we saw an example describing how the active manager selects the best database copy to mount and activate.

Exchange 2010 Database Availability Groups

Exchange 2010 Database availability groups allow replication of mailbox databases for redundancy. It uses various Microsoft technologies to provide this service. DAGs take advantage of Windows server 2008 clustering, Log shipping technology, Shadow Redundancy and Incremental Reseeding. Exchange 2010 DAG uses Windows clustering that is different from Exchange 2003 and Exchange 2010. It uses Windows clustering to monitor heartbeat of each other; Exchange 2010 does not require the administrators to manage them at the cluster level.  Unlike Exchange 2007, in Exchange 2010, since a single mailbox database can be replicated across multiple servers, it is required that all mailbox database names are unique. Shadow Redundancy is similar to the Exchange 2007 transport dumpster function. Message that is sent to hub transport role was saved in the transport dumpster.
Requirements for Exchange 2010 Database Availability Groups:

1. Two or more Windows Server 2008 Enterprise Servers
2. Two or more NICs per server
3. Exchange server 2010 Enterprise
4. One File share witness per DAG

Exchange 2010 File Share Witness

Exchange 2010 DAGs are more of a replication technology than a traditional cluster but still uses some Server 2008 clustering functions to track each other heart beat. File Share Witness acts like a voting mechanism in a cluster. To create a File share Witness share, simply create a share on any server. DAG configuration will configure the permissions automatically.
How to create Exchange 2010 Database Availability Groups:

• Open Exchange Management Console.
• Organization Configuration > Mailbox.
• Choose “Database Availability Group” tab.
• Choose “New Database Availability Group.”
• Follow on screen instructions.
• DAG is created, but it has no member, follow below instructions to add member mailbox servers.
• Organization Configuration > Mailbox.
• Choose “Database Availability Group” tab.
• Right click the properties of recently created DAG and choose manage database availability group membership.
• Click Add and choose the mailbox server from the list. Then click manage.
• Click finish.
• Organization Configuration > Mailbox.
• Right click on the database you want to replicate.
• Choose “Add mailbox database copy.”
• Follow on screen instructions, click finish.

Exchange 2010 Database Availability Group

Database Availability Group (DAG) is the new Exchange 2010 high availability feature. This feature provides data availability together with service availability. DAG now is the only built-in way to protect data in Exchange 2010.

This article is composed of an introductory section where we look at the key facts of Database Availability Groups and a walk through the implementation of DAG. The introductory sections where authored after researching various TechNet articles and here I am reproducing salient information taken from TechNet. This information was restructured for Administrators to have a central reference point rather than having to go through many TechNet articles. So credits for the article introduction go to TechNet.

In Exchange 2007, we have Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Single Copy Clusters (SCC) and Standby Continuous Replication (SCR). Exchange 2010 combined on-site data replication (CCR) and off-site data replication (SCR) to produce one method to protect mailbox databases.

DAG is a group of up to 16 mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Those mailbox servers can be geographically dispersed to replicate mailbox databases across sites. Any server in a DAG can host a copy of a mailbox database from any other server in the DAG.

Storage groups no longer exist in Exchange 2010. The mailbox database name is unique within an Exchange 2010 organization, they are now global objects and, as a result, the primary management interfaces for Exchange databases has moved within the Exchange Management Console from the Mailbox node under Server Configuration to the Mailbox node under Organization Configuration. Also continuous replication now operates at the database level because of Storage Group removal from Exchange 2010.

In Exchange 2007 the Microsoft Exchange Replication service on the passive node connects to the share on the active node and copies, or pulls, the log files using the Server Message Block (SMB) protocol. In Exchange 2010 SMB is no longer used for Log shipping and seeding. Instead, Exchange 2010 continuous replication uses a single administrator-defined TCP port, by default DAG uses port 64327. Also, Log shipping no longer uses a pull model where the passive copy pulls the closed log files from the active copy; now the active copy pushes the log files to each configured passive copy.

Another good enhancement is that seeding is no longer restricted to using only the active copy of the database. Passive copies of mailbox databases can now be specified as sources for database copy seeding and reseeding. In addition, Exchange 2010 includes built-in options for network encryption and compression for the data stream.

There are two editions of Exchange 2010, standard and enterprise editions. Both editions include DAGs, but standard edition is limited to 5 databases per server while the enterprise edition can host up to 100 databases per server. Note that if you want to use DAG with failover clustering, you have to install Exchange 2010 on the enterprise editions of Windows Server 2008. And all DAG members should run the same operating system, either Windows Server 2008 on all members or Windows Server 2008 R2 on all members.

Creating and Configuring DAG

There are specific networking requirements that must be met for each DAG and for each DAG member. Each DAG has a single MAPI network, which is used by other servers (e.g., other Exchange 2010 servers, directory servers, witness servers, etc.) to communicate with the DAG member, and zero or more Replication networks, which are networks that are dedicated to log shipping and seeding. However, unlike previous Exchange versions, database availability group configuration is supported using single network.

An IP address (either IPv4 or both IPv4 and IPv6) must be assigned to the DAG. This IP address must be on the subnet intended for the MAPI network.

You can assign static IP addresses to the DAG by using the DatabaseAvailabilityGroupIpAddresses parameter. If you use the Exchange Management Console (EMC) to create the DAG, or if you use the New-DatabaseAvailabilityGroup cmdlet without the DatabaseAvailabilityGroupIpAddresses parameter, the task will configure the DAG to use Dynamic Host Configuration Protocol (DHCP) to obtain the necessary IP addresses. If you don’t want the DAG to use DHCP, you can use the Set-DatabaseAvailabilityGroup cmdlet to configure one or more IP addresses for the DAG after it has been created.

Now we will create the DAG. In EMC | Organization Configuration | Mailbox. Click the Database Availability Groups tab, right-click and select New Database Availability Group:

Type a name for the DAG. Remember that the DAG must have a unique name inside the Exchange organization and it can consist of up to 15 characters. I will select the server that hosts the Hub Transport and Client Access server roles as a witness server, and define C:DAG1-WS as the witness directory

Click Next to start creating the DAG:

After DAG has been created, we can run the command “Get-DatabaseAvailabilityGroup DAG1 | fl” to see the default properties of the DAG:

Note that the DAG has no IP addresses configured. I don’t have DHCP in my test environment, so we have to configure an IP address for the DAG. To do so, we will use the command:
Set-DatabaseAvailabilityGroup DAG1 -DatabaseAvailabilityGroupIpAddresses 20.20.0.6

Now you can add servers to the DAG. In EMC | Organization Configuration | Mailbox, click the Database Availability Groups tab, right-click the DAG you want to manage, and then click Manage Database Availability Group Membership:

Click Add then select the servers you want to add. I will chose one server then add the second server using Exchange Management Shell.

Click Manage to add the server as a member to the DAG

Now we will configure the DAG networks to allow the replication on one subnet other than the MAPI network subnet. From the Database Availability Groups tab, select the DAG. At the bottom pane we can then configure the network properties for the selected DAG.

I will add an IPv4 subnet and remove the IPv6 subnet. Also make sure that the Enable replication check box is selected to allow the replication to happen over this network

Next we will disable the replication on the MAPI network. Open the properties of the second network which is configured with the IP of your internal network, uncheck Enable replication check box

Now we will add the second server using the command:
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer Ex14Mbx2 -Verbose

The -Verbose parameter instructs the command to provide detailed information about the operation.

To check the memebers after we have two members in the DAG, we can use the command:
Get-DatabaseAvailabilityGroup

Adding Mailbox Database Copies

Now that we have configured the DAG, we will continue by adding mailbox database copies to start protecting our databases.

We will configure the following scenario:
In all we have two mailbox servers, Ex14Mbx1 and Ex14Mbx2, with two mailbox databases, Main-DB01 and Main-DB02. Ex14Mbx1 holds the active Main-DB01 database copy and a passive copy of Main-DB02, the same applies for Ex14Mbx2; it holds the active Main-DB02 database copy and a passive copy of Main-DB01.

From EMC | Organization Configuration | Mailbox, click the Database Management tab, and right-click the database for which we want to add a copy

In the Add Mailbox Database Copy window click browse and select the DAG member that you will configure to host the database copy

In the Add Mailbox Database Copy window, there is an Activation preference number. This value is used when multiple database copies are added for one database and all the copies meet the same criteria for activation. In this case the copy assigned the lowest activation preference number will be activated.

Click add and wait for the command to complete successfully

After the copy has been created, we can check the health of the database copy using Exchange Management Console. In Exchange 2007 we had to use the Exchange Management Shell to check for mailbox databases and replication health. Now we can use the Database Management tab and look at the Copy Status colomn

Mailbox Database Switchover

The Mailbox server that hosts the active copy of a database is called the mailbox database master. Sometimes you may need to take the mailbox database master down for maintenance. In this case we need to move the active mailbox database to another mailbox server. This process is called a database switchover. In a database switchover, the active copy of a database is dismounted on the master and a passive copy of that database is mounted. The active mailbox database is mounted on another mailbox server which in its turn becomes the master.

To activate the mailbox database on another server, in EMC | Organization Configuration | Mailbox, click the Database Management tab, at the bottom pane right-click the copy that is hosted on the server on which you want to activate the copy

The following drop down list will appear to select from:

The options in the list are:

• Lossless If you specify this value, the database doesn’t automatically mount until all logs that were generated on the active copy have been copied to the passive copy.
• Good Availability If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 6. Exchange will attempt to replicate the remaining logs to the passive copy and then mounts the database. If the copy queue length is greater than 6, the database doesn’t mount.
• Best Effort If you specify this value, the database automatically mounts regardless of the size of the copy queue length. Because the database will mount with any amount of log loss, using this value could result in a large amount of data loss.
• Best Availability If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 12. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than 12, the database doesn’t automatically mount. When the copy queue length is less than or equal to 12, Exchange attempts to replicate the remaining logs to the passive copy and then mounts the database.

Click ok to start activating the copy on the second server. When the process finishes we can see the results in the console:

We can also activate the mailbox database copy on another server through Exchange Management Shell using the command:
Move-ActiveMailboxDatabase -Identity Main-DB02 -ActivateOnServer Ex14Mbx1

Conclusion

In this article we went through a brief overview of database availability groups. We introduced DAG, created and configured DAG to include two member servers. We created mailbox database copies within the DAG and tested moving the database copies between member servers.

Exchange Server 2007 High Availability Part 5

Standby Continuous Replication

What is Standby Continuous Replication?

Standby Continuous Replication (SCR) for Exchange Server 2007 is a feature that was introduced with Service Pack 1.  SCR occurs between two servers – a source server and a target server.  The source server holds the active storage group and mailbox database, while the target server holds a replica of that storage group and mailbox database.

Exchange storage group and mailbox database information is replicated between the source and target server using asynchronous log shipping.  I described asynchronous log shipping in part one of this series on the fundamental concepts of Exchange Server 2007 high availability.  The same log shipping occurs in Local Continuous Replication and Cluster Continuous Replication.

SCR does not work like a cluster with automated fail over, rather it is much like LCR in that manual intervention is required in the event that the SCR source server experiences a failure.

There are many considerations when deploying SCR, but these are a few of the important ones:

• SCR is available in both Standard and Enterprise edition of Exchange Server 2007 with Service Pack 1.
• The SCR source server can be a standalone mailbox server or either an SCC or CCR cluster, however it cannot have LCR enabled on the storage group being replicated.
• The SCR target server can be a standalone mailbox server or either an SCC or CCR cluster as well.
• Unlike SCC and CCR, SCR does not in itself prevent a mailbox server from performing other Exchange roles such as Client Access server or Hub Transport server.
• SCR can be used for Public Folder databases as long as only one Public Folder database exists in the organization. Otherwise Public Folder replication is used instead.
• An SCR source can have multiple target servers; likewise an SCR target can have multiple source servers.
• A server can be both an SCR source and target at the same time.
• SCR target servers require a matching disk layout (eg drive letters) and disk capacity as the source server.

How to Enable Standby Continuous Replication

In this example two Exchange mailbox servers have been configured:

• EXCHCMS is a CCR cluster and will be the SCR source server
• EXCHMAILBOX is a standalone server and will be the SCR target server

All SCR operations are performed using the Exchange Management Shell.  Some of these commands can be run on either the source or target server, but some can only be run on the target server, therefore we will run all commands on the target server.

[PS] C:>Enable-StorageGroupCopy "exchcmsFirst Storage Group"
 -StandbyMachine EXCHMAILBOX

Initial replication will typically take 24 hours to begin because log shipping does not commence until there are at least 50 log files on the source server, and the default log replay interval is 24 hours which means that none of the logs will be written to the replica database until that time.  Once replication is fully operational you can check the status.

[PS] C:>Get-StorageGroupCopyStatus -Server EXCHCMS
 -StandbyMachine EXCHMAILBOX

Name                SummaryCopy CopyQueue ReplayQueue
                    Status      Length    Length

----                ----------- --------- ------------

First Storage Group Healthy     0         11

*** Activating the SCR Target Server

In a disaster situation the SCR source server may be unavailable, and the organization will want to activate the SCR target to continue email operations.  First we must make the replica database viable for mounting.

[PS] C:>Restore-StorageGroupCopy "exchcmsFirst Storage Group"
 -StandbyMachine EXCHMAILBOX -Force

Note that the -force parameter is required when the SCR source is unavailable.

Next we create a new storage group and mailbox database.  These must be created in disk locations other than the path of the SCR replica files.

[PS] C:>New-StorageGroup "SG1" -SystemFolderPath D:SG1Logs
 -LogFolderPath D:SG1Logs

Name    Server      Replicated Recovery

----    ------      ---------- --------

SG1     EXCHMAILBOX None       False

[PS] C:>New-MailboxDatabase "Mailbox Database" -StorageGroup
 SG1 -EdbFilePath "D:SG1DataMailbox Database.edb"

Name             Server      StorageGroup Recovery

----             ------      ------------ --------

Mailbox Database EXCHMAILBOX SG1          False

Now we can move the paths for the new storage group and database to match the location of the replicated log files and database from the SCR source server.

[PS] C:>Move-StorageGroupPath EXCHMAILBOXSG1
 -SystemFolderPath "D:SG1First Storage Group"
 -LogFolderPath "D:SG1First Storage Group"
 -ConfigurationOnly

[PS] C:>Move-DatabasePath "SG1Mailbox Database"
 -EdbFilePath "D:SG1First Storage GroupMailbox
 Database.edb" -ConfigurationOnly

Note that the use of the -ConfigurationOnly parameter means that only the attributes of the object are changed, no actual files are moved.

Next, set the mailbox database to allow it to be overwritten by a restore.

[PS] C:>Set-MailboxDatabase "SG1Mailbox Database"
 -AllowFileRestore $true

The database can now be mounted.

[PS] C:>Mount-Database "SG1Mailbox Database"

Now that the database has been brought online for the SCR target server the user mailboxes must be re-homed so that they can connect to the new server name.

[PS] C:>Get-Mailbox -Database "EXCHCMSFirst Storage Group
Mailbox Database" |where {$_.ObjectClass -NotMatch
 '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}|
 Move-Mailbox -ConfigurationOnly -TargetDatabase
 "EXCHMAILBOXSG1Mailbox Database"

Clients that are running Outlook 2007 will automatically connect to the new server thanks to the Autodiscover service.  Clients on earlier versions of Outlook will only automatically connect if the old server is still online to redirect them, otherwise they will require a manual update of their Outlook profile.

Other Considerations for Standby Continuous Replication

SCR is a useful disaster recovery feature of Exchange Server 2007 but requires careful planning and operation.  If not properly configured SCR can cause backup problems for your Exchange environment.

Also, after an SCR target has been brought online an organization may need to take extra steps to re-add high availability to the Exchange environment, such as by configuring a new SCR target for the server or by expanding the server to a cluster configuration.