Hi San,
Thank you for your question.
Did those uses come from the same database?
We could rebuild the profile to check if the issue persist.
Any user with a pre-existing Outlook profile configured to point to a CAS name and not the CAS array object will continue to connect to the CAS name and it will not update itself to utilize the CAS array object FQDN.
The profile will not update itself because the client will not receive an ecWrongServer response from CAS. It will not receive this response because any CAS is a valid connection point for any mailbox database via RPC (over TCP) so clients can survive datacenter
switchover/failover events without being reconfigured and all an admin has to do is flip the CAS array object DNS record to point to a surviving pool of CAS. Currently the only way to fix mailbox profiles would be a manual profile repair within Outlook, by
publishing an Office PRF file via GPO (not going to work for non-domain joined machines), or by decommissioning the CAS server named in the users profiles so the endpoint is no longer available. This last option should (test test test!!) trigger a full profile
repair by Autodiscover in Outlook 2007 or Outlook 2010. Outlook 2003 is only repairable with a profile repair or a PRF file. Autodiscover will not as of this articles writing update a profile to a new server name as part of the normal Autodiscover process
which updates the Outlook Anywhere configuration and discovers EWS URLs for other features such as OOF Management, Free/Busy, and Inbox Rules management.
We could refer to the following link:
http://blogs.technet.com/b/exchange/archive/2012/03/28/demystifying-the-cas-array-object-part-2.aspx
If there are any questions regarding this issue, please be free to let me know.
Best Regard,
Jim