When planning a mailbox migration to Exchange Server 2007 you should consider the amount of transaction logging that will be generated by the move. In low risk environments circular logging can be used to avoid disk space problems caused by the volume of transaction logs generated during bulk mailbox moves.
You can query the current state of circular logging on your storage groups with the Get-StorageGroup cmdlet.
[PS] C:\>Get-StorageGroup | fl name, circularloggingenabled
Name : SG1 Staff A-L
CircularLoggingEnabled : False
Name : SG2 Staff M-Z
CircularLoggingEnabled : False
Name : SG4 Public Folders
CircularLoggingEnabled : False
Name : SG3 Service Accounts
CircularLoggingEnabled : False
To enable circular logging use the Set-StorageGroup cmdlet. You can enable circular logging on all storage groups together by piping a Get-StorageGroup command to Set-StorageGroup.
Get-StorageGroup | Set-StorageGroup -CircularLoggingEnabled $true
Get-StorageGroup will now reflect the change.
[PS] C:\>Get-StorageGroup | fl name, circularloggingenabled
Name : SG1 Staff A-L
CircularLoggingEnabled : True
Name : SG2 Staff M-Z
CircularLoggingEnabled : True
Name : SG4 Public Folders
CircularLoggingEnabled : True
Name : SG3 Service Accounts
CircularLoggingEnabled : True
Use Set-StorageGroup again to disable circular logging after your migration is complete.
Get-StorageGroup | Set-StorageGroup -CircularLoggingEnabled $false
Project Coconut entries:
Now that the Exchange server is installed and configured it is time to migrate the mailboxes. You can take a look at the existing mailboxes in the Exchange organisation using the Exchange Management Console or using the Get-Mailbox cmdlet in the Exchange Management Shell.
[PS] C:\>Get-Mailbox
Name Alias ServerName ProhibitSendQuo
ta
—- —– ———- —————
Administrator Administrator labex1 unlimited
User1 User1 labex1 unlimited
User2 User2 labex1 unlimited
User3 User3 labex1 unlimited
User4 User4 labex1 unlimited
John Adams johnadams labex1 unlimited
Paul Anderson paulanderson labex1 unlimited
Gary Billups garybillups labex1 unlimited
Frank Curtin frankcurtin labex1 unlimited
Harry Kindle harrykindle labex1 unlimited
Carl Munro carl munro labex1 unlimited
WARNING: Object lab.internal/Lab Corp/Users/Carl Munro has been corrupted and
it is in an inconsistent state. The following validation errors have occurred:
WARNING: “carl munro” is not valid for Alias. Valid values are: Strings formed
with characters from a to z (uppercase or lowercase), digits from 0 to 9, !, #,
$, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may
be embedded in an alias, but each one of them should be preceded and followed
by at least one of the other characters. Unicode characters from U+00A1 to
U+00FF are also valid in an alias, but they will be mapped to a best-fit
US-ASCII string in the email address which is generated from such an alias.
The first thing you might notice is the warning about an invalid alias on one of the mailbox users. The EMC and EMS will warn you of any such problems with mailboxes and you should take steps to fix them before you attempt the mailbox migration. With just one invalid alias it is easy to fix, but if you have dozens or even hundreds of them you’ll need some scripting assistance. Fortunately the Microsoft Exchange Team has come up with a script to make this easy.
Consider Transaction Logging
Bulk mailbox migrations generate a lot of transaction logging on the target server, as each mailbox item moved is a line in a log file. This can cause disk space problems on even very large capacity volumes, which is a problem you definitely want to avoid as running out of disk space will cause the databases in that storage group to dismount.
There are two approaches you can take to work around this:
- use circular logging during the mailbox migrations (not recommended)
- migrate the mailboxes in smaller batches and use backups to truncate the resulting log files (recommended)
I generally recommend the second approach as circular logging carries some risks. By migrating the mailboxes in smaller batches you allow your support staff to better handle any unforeseen problems that arise because they will only affect smaller numbers of users. It also makes the migrations easier to schedule in limited non-business hours. And finally it encourages a post-migration backup of the database which is just a plain good idea. In real life I tend to aim for a 2-3 hour window for mailbox moves in the evening and then launch a backup and go to sleep.
How to Migrate in Batches
The Exchange Management Console makes it very simple to migrate users in batches by simply using filters to limit your view of mailboxes to just those you wish to migrate. For example, if I planned on migrating all users with surnames starting with “A” I could apply such a filter easily.
Similarly I could plan to move users according to which Mailbox Database they are on, and filter on that criteria.
You can also use the Exchange Management Shell to move users who match certain criteria. To move all users with surnames starting with “A” using the Exchange Management Shell I can pipe a Get-User query into the Move-Mailbox cmdlet.
[PS] C:\>Get-User | where {$_.RecipientType -eq “UserMailbox” -and $_.LastName -
like “A*”} | Move-Mailbox -TargetDatabase “Mailbox Database” -Confirm:$false
Using -Confirm:$false ensures that I am not prompted for each mailbox move.
In the next part of Project Coconut I’ll discuss some of the post-migration issues you may encounter, and go through the process of removing the legacy Exchange servers from the organisation.
Exchange Server 2007 has some very useful replication features such as Local Continuous Replication (in RTM and SP1) and Standby Continuous Replication (in SP1 only). These features can provide nice and simple disaster recovery options by replicating your storage group logs and databases to another location, be it another disk/LUN with LCR or another mailbox server with SCR.
However, if you choose to implement LCR or SCR you should be aware of the implications for your backups. A normal Exchange backup will truncate the transaction logs for your storage group, however when LCR or SCR are deployed this truncation may not work as you first expect.
One example of this is when using SCR to replicate your storage group to another mailbox server. The source mailbox server ships each transaction log to the SCR target where it is replayed into a replica of the database. In this scenario there are two queues created - the copy queue and the replay queue.
[PS] C:>Get-StorageGroupCopyStatus -StandbyMachine SERVER2
Name SummaryCopySt CopyQueueLeng ReplayQueueL LastInspecte
atus th ength dLogTime
—- ————- ————- ———— ————
First Storage Group Healthy 2 3232 25/04/200…Â
The copy queue length is the number of transaction log files yet to be shipped to the standby server. The replay queue length is the number of transaction log files yet to be replayed into the replica database (in this case the default 24 hour replay delay has been used).
Now that the source server knows it is shipping logs to a standby server it will be sure not to remove any transaction logs that are yet to be shipped. This would mean that if replication is suspended or fails for any particular reason, and the copy queue length begins to grow quite long, that the source server will not truncate the logs during a normal backup.
However, even when SCR appears healthy and has a zero length copy queue there may be problems with the RPC calls between the servers to notify of log truncation events. If the source and target cannot verify with each other that the logs have shipped and replayed then the source server will not truncate the logs during a normal backup.
To monitor for these types of scenarios it is wise to check for MSExchangeRepl warnings and errors on the target server. For example:
Event Type:Â Â Â Warning
Event Source:Â Â Â MSExchangeRepl
Event Category:Â Â Â Service
Event ID:Â Â Â 2137
Date:Â Â Â Â Â Â Â 19/02/2008
Time:Â Â Â Â Â Â Â 6:31:25 AM
User:Â Â Â Â Â Â Â N/A
Computer:Â Â Â SERVER2
Description:
Log truncation request to the Information Store using RPC has failed for storage group ‘SERVER1\First Storage Group’. Error code: 4294966264.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
When such SCR issues are interfering with backup operations one of the simplest ways to resolve the issue is to reseed the SCR target.
[PS] C:\>Suspend-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2
[PS] C:\>Update-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2 -DeleteExistingFiles
[PS] C:\>Resume-StorageGroupCopy “SERVER1\First Storage Group” -StandbyMachine
SERVER2
In the near future I’d like to nail down some more specific scenarios, causes and remedies, but for now I’ll just summarise by saying if you are having backup problems in an environment where LCR or SCR are deployed, look to your event logs for MSExchangeRepl errors and consider reseeding your replicas to get your backups behaving normally again.
Project Coconut entries:
Deploying the first Exchange Server 2007 server
In this post I’ll explain some of the tasks around deploying the first Exchange Server 2007 server into the existing Exchange organisation at the Project Coconut customer site.
Read the rest of this article…
In earlier versions of Exchange Server the Message Tracking log settings were configured through the GUI interface. Now with Exchange Server 2007 you can set the Message Tracking log path in the GUI, but you need to hit the Exchange Management Shell for other settings such as the log retention period.
To view the retention period on all of your Hub Transport servers you can use the Get-TransportServer cmdlet.
[PS] C:\>Get-TransportServer | fl name, messagetrackinglogmaxage, messagetrackin
glogpath
Name : SERVER1
MessageTrackingLogMaxAge : 30.00:00:00
MessageTrackingLogPath : C:\Program Files\Microsoft\Exchange Server\Transport
Roles\Logs\MessageTracking
Name : SERVER2
MessageTrackingLogMaxAge : 30.00:00:00
MessageTrackingLogPath : C:\Program Files\Microsoft\Exchange Server\Transport
Roles\Logs\MessageTracking
The MessageTrackingLogMaxAge attribute is in the format dd.hh:mm:ss (d = days, h = hours, m = minutes, s = seconds). To modify all of your Hub Transport servers to retain Message Tracking logs for 60 days you can pipe the Get-TransportServer cmdlet to the Set-TransportServer cmdlet.
[PS] C:\>Get-TransportServer | Set-TransportServer -MessageTrackingLogMaxAge 60.00:
00:00
Get-TransportServer will now reflect the new setting.
[PS] C:\>Get-TransportServer | fl name, messagetrackinglogmaxage, messagetrackin
glogpath
Name : SERVER1
MessageTrackingLogMaxAge : 60.00:00:00
MessageTrackingLogPath : C:\Program Files\Microsoft\Exchange Server\Transport
Roles\Logs\MessageTracking
Name : SERVER2
MessageTrackingLogMaxAge : 60.00:00:00
MessageTrackingLogPath : C:\Program Files\Microsoft\Exchange Server\Transport
Roles\Logs\MessageTracking
