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.
We did a migration from 2010 to a new 2010 server back at the beginning of the year. I was one of those people who did not create a CAS array until AFTER I moved my users. Once I found out – I did create a CAS array and set the property on all my Mailbox DBs. But I had to manually update 100+ user's mail profiles by hand.
The old server has been shut down now for 6+ months, but I'm still getting random logon prompts from certain users even though they have even had new machines installed (with new user and Outlook profiles).
Cold this be related to the CAS array issue? Or is it something else?
This looks like a different issue. New profile always works…
Does anyone have an update on this? Does SP1 correct this issue?
It is not fixed and it is unknown when it will be fixed.
Thanks Elan. I am going to try the method of creating a new DB and moving the mailboxes. Do you know if this will work for Outlook 2003 clients? Also do you know if it's possible to create a one server CAS array? We don't have the resources for 2 servers right now….but at least if I can configure this using a 1 server "array", I shouldn't encounter this same problem again in the future.
Thanks.
I always create a CAS Array even if it's 1 CAS. Therefore, even if you end up adding more CAS Servers down the road, no worries and you won't have to worry about the update issue. Outlook 2003 clients should also have an issue as it's an issue with the RPC Client Access Service, not the clients.
I'm also looking to migrate from a single CAS / HT server to a CAS array. This is concerning if all users need to manually run a repair. Are there any options to automate this?
Easiest way I can think about is create new databases that are stamped with CAS Array and move them to the new databases. Their profiles "should" get updated after the mailbox move. Give it a shot with a mailbox or two.
I'm in the same boat. Did Elan's suggestion work?
Hello,
Has there been any update to this? Are there any possible solutions to updated clients automatically to use the RPCCAS array fqdn automatically?
Thank you.
Hi all,
I have the same issue with Outlook 2007 and Outlook 2010 not updating the RPC Endpoint after changing RPCClientAccessServer on mailbox database to cas array fqdn. I have 2 HUB-CAS-MBX boxes in a DAG.
When I do a profile repair the profile gets updated with the cas array fqdn but the profile is in offline mode. I have to disable that too. Someone told me this has to do with CAS and MBX role residing on one box.
Is there still no fix for this bug? These issues are preventing me for changing the RPCClientAccessServer parameter on my mailbox databases
I haven't seen a fix. These types of issues have existed since Outlook 2007 and Exchange 2007 with Outlook not being able to update Outlook Anywhere FQDN if it can still contact its old Outlook Anywhere endpoint. Not sure when Microsoft will ever fix these issues, if ever.
Hi elan.
ı'm migrating exchange 2003 environment to the exchange 2010.
On pilot phase, i move a exchange 2003 user to the exchange 2010.client is outlook 2007.
But unless i click repair account, this user is not recognizecas array fqnd automatically.it stays on disconnected state.
If i manually configure user account with cas array fqdn instead of exchange 2003 server, it checks name correctly.
My cas array fqdn is pointing nlb vip.
I think my autodiscover service is not publishing cas array fqdn to the clients.What can be the problem?
all my internal and external names are configured and including in wildcard cert.
So there should really be two things happening:
1. Client contacts old server and gets redirected to new server and client gets updated
2. If that fails, Autodiscover should still be taking care of the Outlook profile.
Seems like both things are failing for you. I'd give PSS a call to see what's going on with your Exchange environment.
Elan thanks for the headsup and sharing , Great info as always,
ocd
Elan, great post and definitely something to watch out for. I also wanted to point out that you define the CAS array using the powershell command new-ClientAccessArray.
Reference:http://technet.microsoft.com/en-us/library/dd3511…
Elan, great post and definitely something to watch out for. I also wanted to point out that you define the CAS array using the powershell command new-ClientAccessArray.
Reference:http://technet.microsoft.com/en-us/library/dd3511…
Elan, great post and definitely something to watch out for. I also wanted to point out that you define the CAS array using the powershell command new-ClientAccessArray.
Reference:http://technet.microsoft.com/en-us/library/dd3511…
One of the most dissapointing thisngs about Outlook 2010 is the fact there is no method for it to see freebusy information in public folders, whereas with 2007 you could use the UseLegacyFB registry change.
Didn't know that Outlook 2010 doesn't have UseLegacyFB anymore. Good to know though. Thanks.
Hi, great post! According to Henrik Walther Outlook 2010 behaves like Outlook 2007, that it wont update the profile. However if you make the old RPC endpoint unavailable it will refresh the users profile on Oulook 2007 and 2010. You can also perform a profile repair to update the profile. If the user use Outlook 2003 you need to update the profile by applying a new PRF file. Check out what Henrik Walther said here:http://technet.microsoft.com/en-us/magazine/ff626…
Are you sure that Outlook 2010 will update automatically?
So here's the thing with that. The Outlook Anywhere FQDN update was fixed with Outlook 2010 which should have fixed the RPC Endpoint issue as well but I have not confirmed that. I did talk with Ross Smith about this several months ago in the Exchange 2010 RTM TAP. Let me make an update in the SP1 TAP list and see what Ross or someone else comes back with and I will update this accordingly.
Not working with Outlook 2010 RC1. Tested myself and verified with others.
Thanks Henrik and Ståle for bringing this to my attention. I have updated the article accordingly.