Freigeben über


Outlook, RPC end point and PF : The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook

The dialog “The Exchange administrator has made a change that requires you quit and restart Outlook” can be seen due to various reasons which includes mailbox moves in Exchange 2010 when the RPCClientAccessServer property changes between the source and target database.

 

 When RPC endpoint Changes:-

For Exchange 2010 before SP2 RU 3 - The Outlook clients with an existing Outlook profile would continue to use the old RPC endpoint rather than the new RPC endpoint (even though Autodiscover detected the change). This is because the old RPC endpoint does not return an ecWrongServer response to the client. The RPC endpoint accepts the connection; therefore, Outlook ignores the Autodiscover response because it has a working connection.

In the event that the old RPC endpoint becomes inaccessible, Outlook 2007/2010 would update its settings (Outlook 2003, on the other hand, would not as it does not leverage Autodiscover). If you want to update it before that, at any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

With 2010 SP2 RU 3 and later, RPC operation (ROP) is WrongServer (also known as ecWrongServer) issued by the RPC End point forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory. The profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

All versions of Outlook will get prompted to restart and the Outlook profile’s RPC endpoint will be updated.

 

If you face situations where the cas array name is changed we need to update the name of the RPC client access server on the databases.

Also after exchange 2010 SP2 RU3 all versions of Outlook will get prompted to restart and the Outlook profile’s RPC endpoint will be updated.

https://blogs.technet.com/b/exchange/archive/2012/05/30/rpc-client-access-cross-site-connectivity-changes.aspx

 

The changes made in Exchange 2010 SP2 RU3 and later for move mailboxes between AD sites for changes in the RPC end point the RPC client access would forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory.

For Exchange 2010 SP2 RU3 and later, when you move mailboxes between AD sites, all versions of Outlook will get prompted to restart and the profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

To add further on the cas array, the Outlook clients with an existing Outlook profile would continue to use the old RPC endpoint rather than the new RPC endpoint (even though Autodiscover detected the change). This is because the old RPC endpoint does not return an ecWrongServer response to the client. The RPC endpoint accepts the connection; therefore, Outlook ignores the Autodiscover response because it has a working connection.

In the event that the old RPC endpoint becomes inaccessible, Outlook 2007/2010 would update its settings (Outlook 2003, on the other hand, would not as it does not leverage Autodiscover). If you want to update it before that, at any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

 

Outlook 2003:

Outlook 2003 can’t change the endpoint automatically and doesn’t include a profile repair feature.

https://support.microsoft.com/kb/873214

Creating a PRF (Outlook Profile) configuration file to automatically update Outlook to point to the new server. You will need to script this out to ensure it automatically runs on all workstations. Group policy can be used to push it on clients.

https://technet.microsoft.com/en-us/library/cc179062.aspx

As for the profile repair for outlook 2003 using options like GPO or similar we engaged the outlook team on this case to provide their suggestions on this.

If a change to existing Outlook 2003 profiles is required to update Exchange account information, the only solution is to create and apply a PRF file.

PRF files can be created for Outlook 2003 using the Custom Installation Wizard:

Custom Installation Wizard:

https://office.microsoft.com/en-us/office-2003-resource-kit/custom-installation-wizard-HA001140170.aspx

Steps to create a PRF and methods to apply a PRF are detailed in this Office 2003 article:

Customizing Outlook Profiles by Using PRF Files:

https://office.microsoft.com/en-us/office-2003-resource-kit/customizing-outlook-profiles-by-using-prf-files-HA001140258.aspx

 

Same AD site with just one CAS Array:-

 

What if  you receive the dialog "The Microsoft Exchange Administrator has made a change that requires you quit and restart Outlook" received in outlook even when no changes were made to user’s mailbox and all exchange servers are in same AD site with just one CAS Array.

That would make one wonder.

 

The RPC Client access logs might shows entry like below:

yyyy-mm-ddT01:01:201.053Z,440018,4,/o=Domain/ou=Name of Administrative Group/cn=Recipients/cn=firstname.lastname,,OUTLOOK.EXE,14.0.xxxx.1000,Cached,,,ncacn_ip_tcp,,PublicLogon,1144 (rop::WrongServer),00:00:00,"Logon: Public,  in database xxxxxx-xxxx-xxxx-xxxx-xxxxxxx last mounted on servername.domain.local at mm/dd/yyy 1:01:01 AM, currently Mounted; Redirected: not a user's home public server, suggested new server: /o=Domain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=servername",RopHandler: Logon:

 

The issue occurs due to the PF being present on just one of the CAS and having CAS Array configured with other members in the CAS array which do not hold the PF.

Check the CAS Array members and check if some of them have PF present on it.

 

This issue occurs because the IP address of the Client Access Array is being returned to the client instead of the server that is hosting the Public Folders. Observed when Public Folders are mounted on a multirole Exchange 2010 server that is a member of a Client Access Array. 

The Problem exists when an Outlook client connects into a CAS array initial if it 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 to Outlook.d30.intra (the CAS array name) When the Clients IP address changes (e.g. they change from Wired to wireless networks, docked to undocked or transition across wireless access points where their IP addresses Change) or any other cause that may cause it to re-connect, if it gets connected to a CAS array member that does not have the PF server, then we get an ECwrong server Response from Exchange, Outlook in its reconnect logic Cannot follow the Redirection Result that contains the correct PF server name, and displays the Error "the Admin has made a change that requires you restart Outlook"

 

Move the PF on a server which does not have CAS role since you have CAS Array configured in your environment.

For Exchange 2010 Move Public Folders to a server that is not a member of the Client Access Array. 

 

Exchange 2013:-

The issue does not occur in Exchange 2013.

Outlook clients no longer connect to a server FQDN as they have done in all previous versions of Exchange. Outlook uses Autodiscover to create a new connection point comprised of mailbox GUID, @ symbol, and the domain portion of the user’s primary SMTP address. This simple change results in a near elimination of the unwelcome message of “Your administrator has made a change to your mailbox. Please restart.” Only Outlook 2007 and higher versions are supported with Exchange 2013

https://technet.microsoft.com/en-us/library/jj150540%28v=exchg.150%29.aspx#BKMK_Arch

Comments

  • Anonymous
    November 26, 2013
    great i am using MailEnable for my business their best feature is the outlook collabration (www.mailenable.com/outlook-collaboration.asp). nice feature of working with Outlook and other major platform.

  • Anonymous
    March 25, 2014
    Does the issue happen on the users migrated from Exchange 2010 to Exchange 2013?

  • Anonymous
    April 09, 2014
    This does happen in Exchange 2013. Notably after a migration from Exchange 2007.

  • Anonymous
    April 14, 2014
    We have installed RU5 for Exchange 2010 SP3 but still getting the same prompt on some user profile.

  • Anonymous
    May 01, 2014
    http://somnathghosh.wordpress.com/2013/03/22/exchange-2010-users-randomly-prompted-with-the-microsoft-exchange-administrator-has-made-a-change-that-requires-you-quit-and-restart-outlook/


    I used the first step on this and it seemed to fix the issue for me. We are using Exchange 2013 and Outlook 2013 while recieving that error.

    All I did was uncheck the email account setting that Encrypts data between the Exchange Server and Outlook Client.

  • Anonymous
    May 01, 2014
    This definitely still happens when migrating to Exchange 2013 from 2007... just did it today, and all my users who are using Outlook 2010 received this message 2-3x and then it went away finally... haven' had time to look yet but watch out for some feedback if you are in my shoes. No interruption of service, just caused confusion among the first batch of users we migrated... which were the IT staff just in case something like this happened.

  • Anonymous
    June 19, 2014
    The comment has been removed

  • Anonymous
    July 20, 2014
    Had the same issue and found the following fix:

    The resolution in this case was to drill down to the properties of the Mailbox Database in ADSIEDIT & set the value of “msExchHomePublicMDB” to be blank. Afterwards, a restart of the Information Store Service resolved the issue.

    It happens to all users migrated from Exchange 2007 or Exchange 2010 to Exchange 2013.

  • Anonymous
    December 18, 2014
    I had users get this message when their database went over the 250gb cap. It showed disconnected in Outlook because the database was dismounted, but all of them also got this "has made a change...Restart Outlook" prompt, which didn't make any sense. This was a single Exchange 2007 server environment that had been stable for years. So hopefully this helps others who get this confusing and misleading error when their database is offline due to the size cap.