Autodiscover Outlook 2007 Client Issues
During the migration of mailboxes from a Windows 2000 Forest / Exchange 2000 Org we had an issue where migrated users with non-migrated mailboxes were recieving the following error on loading their Outlook 2007 client:
“Your mailbox has been temporarily moved on Microsoft Exchange Server. A temporary mailbox exists, but might not have all of your data. You can connect to the temporary mailbox or work offline with all of your old data. If you choose to work with your old data, you cannot send or receive e-mail messages.”
For some reaosn the client had detected the users stub-mailbox in the target environment and automatically configured the users MAPI profile to connect to it. The main issue with this being that this mailbox was incable of recieving email due to the redirect setup back to the source environment. Thus, the only way to resolve this for the user was to rebuild their MAPI profile, until they load Outlook agin and the same thing happens!
First lets look at why this was happenin:
- Exchange 2007 was running in the target domain.
- The users were logging in to the target domain, accessing a mailbox in the source using the Associated External Account (AEA)setting on the source mailbox.
- Affected clients were running Outlook 2007
- There were a small number of migrated mailbox users connecting to the new Exchange Org.
Outlook 2007 supports Autodsover, which was available for the users that were loggin in to the target domain. Using OWA and locating a user in the GAL or a Free/Busy lookup in the Outlook ‘thick’ client would trigger the stub-mailbox to become ‘active’ – it would suddenly have itemCount and totalItemSize attributes. On load Outlook 2007 performs autodiscovery, it would then detect the users new mailbox and display the above message.
The biggest problem here is that nothing is actually going wrong. Exchange is designed to create a mailbox on Free/Busy lookup via OWA or the full Outlook client. So the question was how to break Autodiscover for non-migrated users only.
Initially I configured the AutodiscoverServiceInternalUri to an invalid URL and the problem affecting non-migrated users went away. With this came a wealth of further issues affecting migrated users:
- The Offline Address Book failed to download for Cached Exchange Mode users.
- The scheduling features would fail to work with ‘Item could not be found’ error
- The Out of Office Assistant would fail to load.
All of these side-effects were caused by Autodiscover being unavailable to Outlook 2007 clients connecting to the new Exchange 2007 Org.
Next we configured the IIS Virtual Directory on the Client Access Servers to Deny Connection to users that had not been migrated. This meant compiling and maintaining a Active Directory Security Group containing all mailbox migrated users. Whilst this stopped the clients detecting the mailbox on the new server it meant that non-migrated users were plagued with Authentication requests to connect to the Client Access Servers asthe Outlook Clients had still detected the Autodiscover Configuration via the SCP record in the Active Directory.
This then led to the final, and successful, solution. Using the group containing all migrated mailbox users we configured the SCP record on each CA server in the Active Directory, via ADSIedit, so that ‘Authenticated Users’ has no defined read permissions and the new security group containing all migrated usershad defined read permissions. This meant that clients running under a non-migrated user account could not find the autodiscover settings using the SCP record as they were unable to read this in the Active Directory. The images below detail this process:
The Default Permissions were configured as follows:
The newly configured permissoins for Authenticated Users during the migration:
And the newly configured permissions for the group containing all migrated mailbox users:
