Move Arbitration Mailboxes In Exchange 2010

Quite simple really. I have found that in certain situations, (help in backup) I have needed to delete databases (perhaps several databases exist on a single drive). You can move mailboxes from one database to another simply by typing the following cmdlet:

[PS] Get-Mailbox –Database TheDatabaseID  | New-MoveRequest –TargetDatabase TheDatabaseID

Now this will move the ‘regular’ mailboxes but not those marked as arbitration mailboxes. You can identify those by using the following:

[PS] Get-Mailbox –Database TheDatabaseID –Arbitration

Now you know what mailboxes to look out for, move them to the database of preference.

[PS] Get-Mailbox –Database TheDatabaseID –Arbitration | New-MoveRequest –TargetDatabase TheDatabaseID.

And then check that the arbitration mailboxes have been moved to an alternative database. You can also check out the move requests themselves:

[PS] Get-MoveRequest

Now that the mailboxes (hidden ones included) have been moved, try deleting the database now. It should work but remember that you will still have to remove the database files manually.

For Matt and Mark!

Exchange 2010 MountDial

The setting is set per server. You can determine the value on your server by typing the following cmdlet:

[PS] Get-MailboxServer | FL Name,AutoDatabaseMountDial

MountDial determines if a passive copy of a DAG can automatically come online based on how many log files being copied to it. If you run the above command, you will see one of several values for AutoDatabaseMountDial including:

1. BestAvailability
2. GoodAvailability
3. Lossless

These mean the following:

BestAvailability

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 mounts the database.

GoodAvailability

If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to six. 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 six, the database doesn't automatically mount. When the copy queue length is less than or equal to six, Exchange attempts to replicate the remaining logs to the passive copy and mounts the database.

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.

BestEffort

This will mount no matter the copy queue length. Be careful with this setting as you could loose a lot of mailbox data!

 

To manually switch from passive to active type the following cmdlets:

[PS] Move-ActiveMailboxDatabase DB4 -ActivateOnServer MBX3 -MountDialOverride:None

As the MountDialOverride property is set to ‘none’ whatever is currently set (probably the default) remains. 

The default on my server is GoodAvailability. So, replace none with one of the three options listed above to change this.

Read an earlier post regarding DAGs 

Ref.

Exchange 2010 Performing Database Management Pt 4

 

Manage Database Redundancy
Mailbox databases have now been moved to the organizational level as mentioned in Pt 1. Exchange 2010 introduces a radical new method of providing database redundancy. Databases can now be kept as multiple copies on different servers.

• A logical group of mailbox servers is called a 'Database Availability Group' or DAG for short.
• The DAG can contain 16 mailbox servers (which can also include other exchange roles)
• These servers can be on different subnets
• A DAG can have up to 16 copies of a database (with up to 100 databases per server)
• Within a DAG, one copy of the database is active while the other copies are passive.
• When a change is made to the active copy changes are recorded to the transaction log. When the log becomes full, it is closed and replicated to the passive copies on other servers. The replicated transaction logs are replayed into the passive databases which keeps the passive copies up-to-date (log shipping and replay)
• If the active database is lost a passive copy will failover automatically and become the active copy. This can also be administrator activated. This is called a switchover.

This section deals with how to create a DAG and how to configure database failover using two servers.

Create a DAG

A DAG consists of three primary components

1. Name
2. IP address
3. Witness location

The name follows NetBIOS convention and the the IP address can be granted using DHCP (not personally recommended) or set statically. If the servers are on different subnets the IP address should include those networks. Because the DAG is using Server 2008 clustering features, the quorum model used is based on a file share witness. The file share witness is used when the number of nodes in the cluster is even. It has a vote in deciding which node should be active. The location of the witness can be on any server (but not servers in the DAG) and its path is configurable.

The following commands can be used to construct a DAG:

[PS] New-DatabaseAvailabilityGroup -Name DAG1 -DatabaseAvailabilityGroupIPAddress 192.168.2.100

You might now receive an error. Perhaps like the following:
WARNING: The operation wasn't successful because an error was encountered. You may find more details in log file "C:\ExchangeSetupLogs\DagTasks\dagtask_2010-02-28_21-56-49.338_new-databaseavailabiltygroup.log". The task was unable to find any Hub Transport servers without the Mailbox server role in the local Active Directory site. Please manually specify a witness server.

You will have to manually establish the witness location. If you add the location to a DC the “Exchange Trusted Subsystem” security group has to be added as a member of the local administrators group of the server and add the DC computer account to the Exchange Trusted Subsystem Group. This is not ideal. Best practice recommends that it is placed on a Hub transport server (not in the DAG!). The other thing to mention is do NOT create the folder share ahead of time and just let the cmdlet do all the work.

To set the witness location as well as creating a DAG, type the following:

[PS] New-DatabaseAvailabilityGroup DAG1 -WitnessServer SRV1.compulinx.com -WitnessDirectory c:\DAG1witness -DatabaseAvailabilityGroupIPAddress 192.168.2.100

 

Add Servers to the DAG

We now must add mailbox servers to the DAG just created. As mentioned, these exchange servers could infact be multiple role holders. The servers should have two network cards. One NIC is used to transfer replication traffic between servers and the other for MAPI traffic. Remember that the CAS server role now is the RPC endpoint for Outlook clients. These email clients will connect to CAS servers and they in turn will communicate with mailbox servers (very different from Exchange 2007) by RPC. This connection to CAS servers is now possible because they now run the RPC Client Access Service. This will be discussed in another post (CAS arrays).

By typing the following you add a server to your DAG

[PS] Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer SRV210

This should take about 20-40 seconds to complete. This will automatically install the Failover Clustering component. This is a feature on Windows Server 2008 R2 and is unavailable on Standard Ed. You will require Enterprise Ed. servers.

Now add your second server to the same DAG:

[PS] Add-DatabaseAvailabilityGroupServer DAG1 -MailboxServer SRV211

If you need to change the location of the witness resource:

[PS] Set-DatabaseAvailabilityGroup DAG1 -WitnessServer SRV212 -WitnessDirectory c:\somelocation

So far we have created a DAG, defined the location of the witness and added two servers to the DAG. The next step is to include a database that needs to replicated between servers. Since the SRV210 has a database (DB1 which we created earlier), a database copy exists. This needs to be replicated to SRV211.

[PS] Add-MailboxDatabaseCopy DB1 -MailboxServer SRV211
[PS] Get-MailboxDatabaseCopyStatus -Identity DB1

The last command should show you that the database has replicated. Notice the replica is 'healthy' and the original and active version is 'mounted'.

DAG Networks

When we created the DAG, a network for replication was automatically established. This is called a DatabaseAvailabilityGroupNetwork. Because we have two network cards in our servers you should see two networks; DAGNetwork01 and DAGNetwork02. To see this type the following:

[PS] Get-DatabaseAvailabilityGroupNetwork | ft name,identity,replicationenabled,subnets,interfaces –au

This will show you that these networks are used for replication of database information. Considering our servers have two network cards, we can use one of the networks for MAPI traffic. This is traffic from CAS servers.
To set DAGNetwork02 for MAPI traffic, type the following:

[PS] Set-DatabaseAvailabilityGroupNetwork "DAG1\DAGNetwork02" -ReplicationEnabled $False

Manual Seeding Database Replicas

 

There are times when you will be required to force a replication to database copies because they are out of sync with the active original. This is caused by the following situations:

• When a replica is brought back on line after an extended downtime
• Log file corruption
• Database corruption
• Extended WAN outage (assuming the replicas are in different sites)

To reseed a replica database follow these steps

1. Suspend replication
2. Update the replica (reseeding)
3. Start replication

1. To suspend replication use the following cmdlet. This will suspend replication to the database replica on SRV211:

[PS] Suspend-MailboxDatabaseCopy db1\srv211

2. To manually reseed the replica database type the following. Notice that you have to delete any existing files for it to work:

[PS] Update-MailboxDatabaseCopy db1\srv211 -SourceServer srv210 –DeleteExistingFiles $True

3. To resume replication type the following:

[PS] Resume-MailboxDatabaseCopy DB1\SRV211

There are two additional settings that can be used that affect how databases handle logs and failover.

1. ReplayLagTime
2. TruncationLagTime

ReplayLagTime

This is the time that passes before replicated logs are replayed into the passive replicas. This can be useful if you are concerned about replaying a corrupted log into a passive copy.

TruncationLagTime

Is the amount of time that passes before a log file can be deleted on a passive copy database. The following example sets the replaylagtime to a day and the trucationlagtime to a week

[PS] Set-MailboxDatabaseCopy DB01\SRV211 -ReplayLagTime 1.0:0:0 -TruncationLagTime 7.0:0:0

Failovers (When It All Goes Wrong!)
Failover occurs automatically with no administrator intervention. You can manually change your active/passive databases around by the following cmdlet. Obviously the active and passive replicas are still standing. This is called a switchover.

[PS] Move-ActiveMailboxDatabase "DB01" -ActivateOnServer SRV211 -MountDialOverride:None

Exchange 2010 Performing Database Management Pt3

Manage Database Settings

• Configure Exchange Search

• Configure Database Size Limits

Configuring Exchange Search
Exchange Search creates a full text index on mailbox databases allowing users to search their email very quickly. Items are added to the index as they arrive so the index is always up-to date.

This feature can be enabled or disabled on a per database or server manner.

The following disables indexing on a per database basis,

[PS] set-mailboxdatabase DB01 -IndexEnabled $False

The following disables the indexing of all databases on the server,


[PS] stop-service MSExchangeSearch

[PS] set-service MSExchangeSearch -StartupType Disabled
You should remember that although you can disable exchange search its probably not a good idea to. The 'discovery' feature (I will come to this) relies on it being enabled.

You may have to rebuild the index when you are recovering from data loss. A script is included to help out which can be found in the following location:

program files\microsoft\exchange server\scripts\resetsearchindex.ps1

The following will rebuilds the index on a database

cd "c:\program files\microsoft\exchange server\scripts\resetsearchindex.ps1 -Force DB01

Configure Limits on a Database

You can set a size limit on your database and if reached the database is dismounted. Exchange Server standard ed. has a default limit of 50 GB and the enterprise ed. does not have one. However a limt can be established and you can change the 50 GB limit the standard ed. imposes to a higher value. To do this open the registry using regedit and browse to the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\NameOfSever\PrivateDatabaseGUID

The GUID can be found by using the following cmdlet

[PS] Get-MailboxDatabase DB01 | ft name,GUID -au

Look for the registry value 'Database Size Limit in GB'. If it exists change it to a value you require. If not create a new DWORD (32 bit) value by the same name.

Exchange 2010 Performing Database Management Pt2

With the database created in Pt1, we can now perform the following management tasks

1. Configure an Online Maintenance Window
2. Change the Timing for Database Checksumming

1. Configure an Online Maintenance Window

Exchange will perform several tasks to clean up the data in the database. Exchange defragmentation, database compaction and database contiguity maintenance. Because this occurs all the time we no longer need downtime to perform these tasks on a offline database.

Online Maintenance (OLM) of the database occurs every night for 4 hours. By default this begins at 1.00AM but can be changed to suit your requirements. Remember that OLM does not include Online Defragmentation (OLD). This process occurs in the background. In Exchange 2007, OLD was part of the OLM and added alot of time to the OLM process. OLM includes the following processes

• Cleanup (deleted items/mailboxes).Cleanup also happens during OLD.
• Space compaction. The database is compacted and space is reclaimed at run time.
  
• Maintain Contiguity The database is analysed for contiguityand space at run time and defragmented in the background.
• Database Checksum This runs against both active and passive copies of a database. Checksumming can occur within an OLM schedule or as a background process similar to OLD

The schedule or window of maintenace can be set in the following way

[PS] set-mailboxdatabase DB01 -MaintenanceSchedule "sat.1:00 AM-sat.5:00 AM"

This sets maintenance to be switched on at 1:00 am on Saturday and off at 5:00 AM

2. Change the Timing for Database Checksumming

As mentioned this can run within OLM or in the background. The background is the default but this can be changed to the OLM in the following way

[PS] set-mailboxdatabase DB01 -BackgroundDatabaseMaintenance $False