Exchange 2010: A Few More Migration Tips
Here are a few more notes from the field to consider when you are planning your Exchange 2010 deployment and migration. Some of these items are good to know even after you have completed your migration and may help with overall system stability.
Make Appropriate AV Exclusions
If you are using a third party anti-virus solution you will want to ensure that the appropriate directories are excluded from scans. Otherwise you could end up with less than optimal performance. The official article on such exclusions can be found at Microsoft’s site.
Here is a quick summary of some recommended exclusions for some of the more popular Exchange 2010 roles.
Exchange 2010 directories for AV exclusion
Tweak Your DAG
There are a number of things you can do to increase the resiliency of your DAG. I’ve only ever worked with DAGs spread across desperate physical locations but it wouldn’t hurt to consider these tweaks even in a same site configuration as well.
Change Cluster Thresholds
Microsoft’s article on this process is documented on their web-site. The gist of the matter is that the cluster thresholds used by default are rather paltry. To help prevent unneeded database failovers you can manually change the threshold on each DAG member. To boost the thresholds to their maximum value run the following:
To verify the settings run the following:
Disable Advanced NIC Settings
Receive Side Scaling (RSS), Chimney, and TCP Offload Engine (TOE) sound like cool technology to have enabled on your network interfaces but they tend to make exchange servers crabby. When theya re crabby they tend to have intermittent connectivity issues which makes your DAG do seemingly random fail-over issues. If you look in the failover cluster manager you will likely see errors about connectivity to the witness server. This can be exasperated in a multiple site DAG configuration as advanced nic features like RSS require end-to-end support to be used effectively.
To disable these features it is recommended to physically go into the advanced nic properties and manually disable each related setting as well as disable the setting at the OS level. I’ve only needed to do the OS level disabling by using the following commands at each DAG server AND on each witness server.
Mailboxes Migrate Into Exchange 2010 as Linked Mailboxes
I saw this for a few clients, thought it was weird, so I’m posting it here 🙂
Basically there were extra attributes from some prior migration that was confusing Exchange 2010 during the migration. If you are certain that you are not using linked mailboxes then you can convert all linked mailboxes to user mailboxes in one line.
A Microsoft technician explained a bit more on what causes this to happen. He noted that the affected accounts have msExchMasterAccountSID populated prior to mailbox migration. This attribute should only be populated on disabled accounts that have an associated external account assigned permissions to the mailbox in Exchange 2003. Apparently you can fix this from happening by running NoMAS in fix mode.
You Get “This error is not retriable” When Migrating A Mailbox
So you are all ramped up and ready to start migrating your mailboxes to the environment you erected with much hard work, sweat, and tears. Everything is great until you see that several users refuse to migrate with an error like this:
What the heck does that mean? Well the Insufficient Access Rights portion of the error says it all. What you may find out is that user mailboxes which exhibit this error tend to not be inheriting permissions in active directory. Even if they are, it doesn’t hurt to reset the inheritance setting for the account and try again. You can do this in Active directory users and computers by making sure that the “Advanced” option is set in the view menu. Then select the account in question, go to the permissions tab, select advanced, and look for the permission inherited checkbox. Either uncheck, apply, recheck, apply or check the box and apply (depending if it is already selected or not). Try to migrate again and you should be golden.
Or if you are using the handy-dandy quest powershell cmdlts you can update the account with a single line:
If you are looking for all the possible trouble accounts run the following for a quick report on those who are not inheriting their OU permissions:
Arbitration Mailboxes May Not Always Be Setup Properly
This one is a bit of a nuisance, but it is not a show stopper. You may not even notice that there is an issue with arbitration mailboxes until you want to use a feature which requires them to be 100% functional. For me it was finding out that I could not run admin audit logs but other symptoms of an issue might be that you cannot moderate distribution lists or perform discovery. If you find this to be the case then you may be running into an arbitration mailbox issue. I cannot help you if you accidentally deleted these essential mailboxes (ok, I can help you, just reprep your forest/domain, they will likely be recreated with no fanfare). If you find that you are unable to use these mailboxes you may just need to fix them. There are three arbitration mailboxes which get stored at your forest root:
- Discovery– SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}
- Message Approval – SystemMailbox{1f05a927-xxxx-xxxx-xxxx-xxxxxxxxxxxx} (where x is a random number)
- Federated E-mail – FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042
Firstly you might experience issues even seeing these mailboxes. If you are in an environment which follows best AD practices then your forest root is nearly empty and the production domain with all of your users and mailboxes is in a sub-domain of the forest root. You then do most of your work with a domain admin account in that sub-domain. In order to see the arbitration mailboxes you need to change the scope of your default view to include the entire forest in EMC. You will know that you need to do this if you run get-mailbox -arbitration and get an empty result with no errors. To get around this change your scope in EMC
Unless you foolishly deleted your initial default mailbox or did something else wrong you should see your three federation mailboxes without any errors. If you do get errors they may look something like this:
I was confused when I first saw this error. When I looked up these accounts in adsiedit I found that their homeMDB attribute was totally blank. This was not my install so I’m not certain what was done to mash up the arbitration mailboxes so badly. To fix this is pretty simple though, find the correct homeMDB attribute value and assign it to the accounts. Then make sure that the account is enabled. What I did was looked at the homeMTA attribute and extrapolated what the homeMDB value was supposed to be.
You can get to the correct area in adsiedit by selecting the default naming context and making sure that your root domain name is used. Then, by default, these accounts will be located in the Users system object (or I can inaccurately say the Users OU, which it is not).
I happened to be lucky. The homeMTA pointed to a server which was in production and all the databases were sequentially numbered. I guessed that the first database was the initial install database… and it was!
homeMTA looked like this:
My guess as to why this happened is that between the forest/domain preparations not enough time elapsed before continuing the server role installations in the sub-domain. That is purely a guess though as I wasn’t around when this particular install occurred and the person doing the install is no longer around. Should you need to recreate the arbitration mailboxes all together here is a good site covering how to do so.
Not All Issues Are Exchange Related
I think I’ve had to deal with just about every Outlook client related issue under the sun when doing Exchange 2010 mailbox migrations. People assume that every issue stems from Exchange and that is simply not the case. Outlook 2003/2007/2010 all behave differently and have their own unique issues to deal with. Here are some basic tips for fixing Outlook 2007/20100 issues (I’ve been lucky enough not to have to deal with Outlook 2003 as much).
Repair Numerous Issues in Outlook 2007
This has fixed more unexplainable issues in outlook 2007 than I can even remember. It requires that your end user be out of outlook, any other office application, and office communicator while it runs. You may want to suggest starting this before lunch.
- Go to Help and select “Office Diagnostics…”
Clean/Fix OST/PST files in Outlook 2007
- Close both Outlook and Office Communicator
- Run C:\Program Files\Microsoft Office\Office12\SCANPST.EXE
- Browse for OST/PST files in “%userprofile%\Application Data\Microsoft\Outlook” and run scanpst.exe against each of them.
Clean/Fix OST/PST files in Outlook 2010
This is highly recommended if the user has just upgraded to Outlook 2010 from a prior version. No matter how good the SCCM package is that gets pushed to your end users Outlook will still have random and weird issues after being upgraded.
On 64-bit computer
C:\Program Files (x86)\Microsoft Office\Office14\SCANPST.EXE
On 32-bit computer
C:\Program Files\Microsoft Office\Office14\SCANPST.EXE
Repair Outlook 2007 profile
- In Outlook 2007, from the Tools menu, click Account Settings.
- In the Account Settings dialog box, on the E-mail tab, select your account, and then click Repair. Follow any prompts from the repair wizard.
- When the repair is done, restart Outlook 2007.
Repair Outlook 2010 profile
- In Outlook 2010, on the File tab, click the arrow next to Account Settings, and then click Account Settings.
- In the Account Settings dialog box, on the E-mail tab, select your account, and then click Repair. Follow any prompts from the repair wizard.
- When the repair is done, restart Outlook 2010.
Recreate Outlook Profile Snag (if you are forced to go as far as to recreate the profile)
- After removing the default profile in outlook you will need to rename/move/delete “%userprofile%\Local Settings\Application Data\Microsoft\Outlook” for the user
Default location for outlook.exe 2010
On 64-bit computer
C:\Program Files (x86)\Microsoft Office\Office14\outlook.exe
On 32-bit computer
C:\Program Files\Microsoft Office\Office14\outlook.exe
Default location for outlook.exe 2007
On 64-bit computer
C:\Program Files (x86)\Microsoft Office\Office12\outlook.exe
On 32-bit computer
C:\Program Files\Microsoft Office\Office12\outlook.exe
Open Outlook With A Custom Flag
From a run dialog box:
Switches You Can Use With Outlook.exe (the /Clean switches can be particularly useful)*
Here is a link to a reference table for Outlook 2007/2010 command-line switches.