When you create an RPC Client Access Array AFTER you have created Exchange 2010 databases, you need to go back to those existing databases and stamp them with the RPC Client Access Array FQDN. That way, clients will use that RPC Client Access Array. Otherwise, they won’t. On the other hand, if you create the RPC Client Access Array FQDN before you create your Exchange 2010 databases, nothing else is needed on your part.
There’s a bug with Outlook 2007 and Outlook 2010 that prevent the RPC Endpoint from updating. This is similar to the bug in which Outlook 2007 will not update its Outlook Anywhere Endpoint which was fixed in Outlook 2010 Beta 2. Because of this bug, it is very important that you get the RPCClientAccessServer database parameter configured correctly prior to moving users to Exchange 2010. If you make this mistake and have the RPCClientAccessServer Database Parameter incorrectly and Outlook users are already hosted on Exchange 2010, once you modify the RPCClientAccessServer parameter for those clients, those clients can do an Outlook Profile Repair to get the updated change. I will update this article in the future when this issue gets fixed.
So before you move users to Exchange 2010, please make sure that you either:
- Create the RPC Client Access Array before creating your databases OR
- Go back on the databases and stamp those databases by running the following command:
The reason why #1 works making #2 not necessary is the way Exchange assigns the RPC Client Access Array property to a database. It does this in 3 different ways:
- If there is no RPC Client Access Array and you create the database on a server that hosts the MBX and CAS role, it will choose itself, always.
- If there is no RPC Client Access Array and you create the database on a server where the CAS and MBX are not collocated on the same server, it will randomly pick a CAS in the same site to set as the RPCClientAccessServer.
- If there is an RPC Client Access Array in that site, it will automatically set the FQDN of the CAS Array for the RPCClientAccessServer.
Autodiscover will see the database the user lives on and will assign the user’s Exchange Server (RPC Endpoint) to what the RPCClientAccessServer parameter is. That is why it’s important to make sure this setting is right before a user is moved to Exchange 2010.