Recently, I was at a customer who had end users experiencing the much familiar ” Your Administrator has made a change. Please restart your outlook” prompt. There could be various reasons why this could happen but what intrigued me in this particular instant was that the customer was seeing this outlook prompt whenever they failed their DAG members over.
After some quizzing, here is what I understood about the environment.
- All their Exchange servers were multirole servers with MBX-CAS-HT roles installed on them.
- Since these servers had CAS role installed on them, these servers were part of the CAS Array as well.
- One of the servers in each site also had a public folder replica homed on it.
- Clients were mostly using Outlook 2010.
Okay, looks like a pretty clean environment to me… what is causing the problem?
Good question! Turns out that hosting a public folder replica on one of the CAS servers that’s a part of the CAS Array is what is causing the problem.
Here’s the explanation:
” This behavior is expected when a public folder exists on a multirole server that is part of the Exchange Server 2010 CAS array.This issue occurs because the
VIP of the CAS array is being returned to the client instead of the hosting server.
The problem arises when an Outlook client connects to the CAS array. Initially, if outlook connects to the CAS array member that contains the PF role, then Outlook converges all
connections and displays both the Public and Private logons as one single connection (the CAS array name). When the Client re-connects and gets connected to a CAS array member
that does not have the PF server, then it gives a wrong server response from Exchange, Outlook in its reconnect logic cannot follow the redirection to the correct PF server name and has to reconfigure itself through a profile refresh. Hence the users get prompted with a ” Restart your Outlook” message. “
So what can we do about it if we are currently encountering this issue in our environment? Presently to work around this problem and avoid the prompt, the suggested approach is to move your public folder replicas to a server that is not part of the CAS Array.
Also something to try is replicating your public folders to all the CAS servers that are part of the CAS Array. I am yet to try this approach so please test it first before implementing in production.