Wednesday, August 29, 2012

The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook

During the implementation of a large Exchange 2010 infrastructure with two DAGs and two CAS  Arrays we had a large number of users that were complaining about receiving the infamous message “The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook”.
This issue started after applying RU3 for Exchange 2010 SP2.

Investigating the problem we found out that all the users that encountered this had open their mailbox stored in one DAG and at least another mailbox stored in the other DAG. This means that they were using one CAS Array to access their mailbox and another CAS Array to open the additional mailbox(s).
Client Team Lead for Messaging discovered this support article from Microsoft It was not fully related to our issue but it contains the way to solve it.

To resolve this issue you need to disable preferred site enforcement (a new feature from Exchange 2010 SP2 RU3)
To do this, create the following DWORD registry value:

Key: HKLM\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value Name: EnablePreferredSiteEnforcement
Data Type: REG_DWORD
Value: 0

After you set the EnablePreferredSiteEnforcement value to 0, a CAS server will accept connection requests from any site and not try to redirect the request to a CAS server from the home site of the mailbox.
To get more details about this new feature and how it can affect your Exchange infrastructure, you can also read this article

Saturday, August 4, 2012

Move mailbox failed when migrating from Exchange 2003 to Exchange 2010

In my last project I had to migrate thousands of mailboxes from Exchange 2003 to Exchange 2010. Almost all of them were migrated successfully but there were some that had errors.
You can find bellow the important part of the error.

Error context: --------
Operation: IDestinationFolder.SetRules
OperationSide: Target
Primary (bd50b428-3943-46cd-8c02-b57f87e7cd94)
Rules: [Rule: Condition: none; Actions: [RuleAction: OOFREPLY TemplateEID:[len=70, data=00000000559C404EBD82D04596AA5A9391BE8A100700868687CBFD049D4089FCFF392D2451CA0000011CC305000000F481963AC3F1428D4E7080D5ECCC710000018A14440000], TemplateGuid:21aadadc-46db-4334-9e1e-1d3cecb4c3d0, Flags:0]; Name ''; Provider: 'MSFT:TDX OOF Rules'; ProviderData: ; ExecutionSequence: 50; Level: 0; StateFlags: 13; UserFlags: 2; IsExtended: False]
Folder: '/Top of Information Store/Deleted Items', entryId [len=46, data=00000000559C404EBD82D04596AA5A9391BE8A100100868687CBFD049D4089FCFF392D2451CA0000011CC3080000], parentId [len=46, data=00000000559C404EBD82D04596AA5A9391BE8A100100868687CBFD049D4089FCFF392D2451CA0000011CC3020000]

I found the following article on Microsoft support web site It’s working perfectly but it’s not mentioning correctly where you should search for the corrupted rule.
To solve the problem make sure that you read the exact folder where the rule is stored (it is marked in red above).