Now that Exchange 2013 SP1 (15.00.0847.032) has been released, those that work as consultants will start to see a spike in billable hours. The reason being is that our enterprise customers will now seek to begin migration projects. While the validity of that best practice has fallen by the wayside many years ago, I still experience many customers standing their ground about not executing a large-scale migration project until SP1 of the product has been released. Certain habits are difficult to break no matter how hard we challenge that line of reasoning during the pre sales process. Just to highlight the diligence around patching a messaging infrastructure, I’m sure all those that have installed 2013 SP1 have also installed the required post SP1 fixes.
Humor aside, this is a good time to review several salient reminders that were pointed out during the Microsoft Exchange Conference concerning mailbox migrations to 2013.
- Exchange 2013 has changed the methodology in which a user’s actual mailbox size is reported. Now, a more precise calculation is used which reports back all properties of a user’s mailbox and not a partial set of properties like in the legacy versions. According to Microsoft, the net effect of this change is that legacy Exchange users that are migrated into 2013 will see the “reported” size of their mailbox increase around 30%. It is important to note that the physical size on disk has not increased; rather the logical reporting size of the mailbox has increased. This means that legacy users close to their quota (~75%) will require additional attention prior to migration. Users that are close to their quota within the legacy environment and then are moved to 2013 most likely will exceed their enforced quota. An unanticipated effect may be that the user cannot send or receive new mail after migration. This is of course dependent on what the configured quota restrictions in place are. A simple fix is to increase the quotas by 30% at the database level (or mailbox) on the legacy Exchange system prior to migration. Remember to check the following limits on your legacy Exchange databases: Issue warning at (GB), Prohibit send at (GB), and Prohibit send and receive at (GB). You can verify your configured database limits prior to migration by using the following PowerShell command: Get-MailboxDatabase <database name> | fl *quota*.
- During migration projects for larger enterprise customers, any production impacting changes will need to be coordinated through a change review board. These changes are then approved through a committee vote and scheduled for a precise start and end time. During an approved change, a conference bridge is setup (with a cast of thousands) where you will need to announce when you are making a change, when the change is completed, and when the change has been tested. Don’t be the consultant that requests the DNS team to make a change to an A record for a namespace cutover only to realize the TTL is set to 86400 seconds (24 hours) while on the bridge. I guarantee that you will never forget that mistake. As part of your steps during a namespace cutover, make sure to verify and document the TTL of all relevant DNS records. If the TTL is set to a longer than desired time, then change the TTL of these DNS records 24 hours prior to the actual scheduled namespace cutover.
- It is important to review how the Offline Address Book (OAB) within your legacy Exchange environment is configured. Many mailbox databases have a setting of $null for their default OAB. This configuration simply means that the default OAB is used. However, when the first Exchange 2013 Mailbox server is introduced into the environment a new ‘default’ OAB is created. This means the Exchange 2013 will now be responsible for generating and distributing the OAB. This becomes problematic if your environment has a large OAB (some are 100 MB+) with thousands of Outlook clients distributed over many types of networks with varying degrees of available bandwidth. Yes – think about how popular you will be with the network team on Monday morning when 10,000 users open up Outlook and initiate a full OAB download at the same time. Brutal. The easy work around is to configure all legacy Exchange databases with the legacy OAB prior to install Exchange 2013. The following PowerShell command can help: Set-MailboxDatabase –Identity <database name> -OfflineAddressBook “<default OAB Name>.” For a more detailed explanation of this situation read the article written by fellow Microsoft Certified Master (and MVP) Andrew Higginbotham.
- The timing of when to swing the SMTP endpoint from the legacy Exchange infrastructure to 2013 is often discussed. The best practice for larger migrations is to make this change once 50% of users have been move to 2013.
- Some scenarios can benefit from installing newly built Exchange 2013 servers into an empty Active Directory Site. This will allow you to configure the 2013 environment fully, while providing a logical separation from internal domain joined clients AutoDiscover SCP requests. The 2013 servers can be moved to the production Active Directory site once you have completed all necessary configuration steps.
- Don’t forget all the great tools that Microsoft provides us with to help with migrations! We have the:
Hopefully, some of these reminders can help you to avoid being the consultant that has to request an emergency extension to a change control window because you forgot something!
Now where is my Exchange 2013 post SP1 project plan…