none
Redirect CAS DNS / CAS failover without CAS Array?

    Question

  • I've read some of the similar threads on this topic already. I have two CAS server setup. One of them will have downtime due to it being moved to it's permanent location. How do I avoid clients having problems connecting to their mailboxes/to the CAS server and not noticing the downtime? I know most solutions/best practice say to setup a CAS array and point all clients to that. I've been tasked with finding out if this is possible without the CAS array. I'm almost certain it is. When my admin and I ran testing earlier in the week, we pointed DNS to one of the two CAS servers, but it didn't work. Am I missing something? We made the proper copies of the database active on the CAS server that would remain up. =\
    Thursday, March 15, 2012 4:43 PM

Answers

  • @Brian Day: I saw this post here

    http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8b6f5263-92c9-49cb-8db7-6c83054b8401/

    where the poster is looking to do the same thing as me, and you replied there as well. I'm guessing my post was worded poorly. Just so I understand:

    - Move mailboxes to server that will remain up

    - Update RPCClientAccess Server using 'Set-MailboxDatabase' to existing/working CAS Server

    At this point, do you just wait for Autodiscover to pick up the changes, and/or flush DNS? I guess I understand more than I let on - I figured that's all you had to do, I just wanted to make sure. I'll read your blog posts again, and soon in the future implement a CAS Array as everyone suggests. :)

    • Marked as answer by darksim905 Tuesday, April 03, 2012 8:35 PM
    Tuesday, April 03, 2012 6:21 PM

All replies

  • Hi

    Firstly you should always configure a CAS array as it is rather tricky to add this on after clients have connected to Exchange.  Internal domain joined Outlook clients will use the Service Connection Point in AD to locate their CAS server.  You can view this setting by running:

    Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri

    Steve

    Thursday, March 15, 2012 4:50 PM
  • I would create the RPC CAS array anyway, and point it to one of the current CAS role servers. You do NOT need to have a load balacing solution in place to use an RPC CAS Array and I would have had one in place from the start.

    The only way that might work is to change the DNS entry and to change the RPCClientAccessServer value on the databases to one specific CAS role server. You will need to restart the information store for the change to take effect.

    However the correct answer though is to deploy an RPC CAS ARray and I am puzzled on why you do not want to. It takes five minutes to setup, has zero impact on the clients and will save you a lot of headache later on. The only issue is having to touch the clients to get them to use the new CAS Array host name.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Thursday, March 15, 2012 5:10 PM
  • I know that it's best to configure a CAS Array, and I will do it when the time comes. Say my two servers are MSFTCAS01 and MSFTCAS02. If I point MSFTCAS01's DNS to 02, won't that pick right up and the clients will context, or do things like the Autodiscovery and the SSL certificate prevent it from connecting due to a certificate/hostname mismatch (also, if the certificate is a UC/SAN certificate, does this even matter?) After I've pointed the 01 to 02, if it doesn't work I have to change that internalURI end point, correct? Do the clients pickup automatically, or would they have to Close/Open out of Outlook?
    Thursday, March 15, 2012 5:12 PM
  • Just pointing out what you said so I can come back to it later:

    having to change RPCClientAccessServer value on DAG, and restart information store.

    Regarding the CAS Array and updating the clients and what their Outlook Profiles point to, is there a way to do this automatically, or does each user have to be done manually? =\

    Thursday, March 15, 2012 5:16 PM
  • Just pointing out what you said so I can come back to it later:

    having to change RPCClientAccessServer value on DAG, and restart information store.

    Regarding the CAS Array and updating the clients and what their Outlook Profiles point to, is there a way to do this automatically, or does each user have to be done manually? =\

    Unfortuantely you have to touch the clients, either repair or recreate the Outlook profile. No automatic method is possible without additional tools (And the hit and miss results they bring). That is why it is always best to have the CAS array in place right form the start.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Thursday, March 15, 2012 5:37 PM
  • And if I pointed the DNS to the alternative CAS server I have, and changed the RPC end points on DAG then, in theory this would work without a CAS Array?
    Thursday, March 15, 2012 7:54 PM
  • And if I pointed the DNS to the alternative CAS server I have, and changed the RPC end points on DAG then, in theory this would work without a CAS Array?

    It may do, it isn't something I have done. Why not just create a CAS array as well?

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Thursday, March 15, 2012 10:07 PM
  • Just pointing out what you said so I can come back to it later:

    having to change RPCClientAccessServer value on DAG, and restart information store.

    Regarding the CAS Array and updating the clients and what their Outlook Profiles point to, is there a way to do this automatically, or does each user have to be done manually? =\

    Unfortuantely you have to touch the clients, either repair or recreate the Outlook profile. No automatic method is possible without additional tools (And the hit and miss results they bring). That is why it is always best to have the CAS array in place right form the start.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.


    You can create new mailbox databases, and do an online mailbox move to them.  Users will have to restart but this should avoid any manual profile reconfigurations.


    Mike Crowley | MVP
    My Blog -- Planet Technologies

    Friday, March 16, 2012 2:53 AM
    Moderator
  • Just pointing out what you said so I can come back to it later:

    having to change RPCClientAccessServer value on DAG, and restart information store.

    Regarding the CAS Array and updating the clients and what their Outlook Profiles point to, is there a way to do this automatically, or does each user have to be done manually? =\

    Unfortuantely you have to touch the clients, either repair or recreate the Outlook profile. No automatic method is possible without additional tools (And the hit and miss results they bring). That is why it is always best to have the CAS array in place right form the start.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.


    You can create new mailbox databases, and do an online mailbox move to them.  Users will have to restart but this should avoid any manual profile reconfigurations.


    Mike Crowley | MVP
    My Blog-- Planet Technologies

    In my experience, even moving the mailbox doesn't force Outlook to update, because the address of the server with the CAS role is still valid. Even moving to a new server doesn't force it to update for the same reasons.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Friday, March 16, 2012 10:42 AM
  • Simon, you're right - my mistake.  You need to make the old RpcClientAccessServer  value unaccessable, otherwise, outlook will not use "ecWrongServer" which is what it needs to update the profile.

    More info on this and workarounds here: 

    http://technet.microsoft.com/en-us/magazine/hh528500.aspx (Search for "Return to Center")



    Mike Crowley | MVP
    My Blog -- Planet Technologies

    Monday, March 19, 2012 6:26 PM
    Moderator
  • Simon, you're right - my mistake.  You need to make the old RpcClientAccessServer  value unaccessable, otherwise, outlook will not use "ecWrongServer" which is what it needs to update the profile.

    This is correct, I have a blog article on this topic coming out soon.

    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003
    MCTS: Win Server 2008 AD, Configuration MCTS: Win Server 2008 Network Infrastructure, Configuration
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server

    NOTICE: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, March 20, 2012 2:06 AM
  • Looking forward to it, Brian. When you make that alternative CAS server unavailable, does Autodiscovery kick in as it should? :0
    Tuesday, March 20, 2012 3:25 PM
  • Simon, you're right - my mistake.  You need to make the old RpcClientAccessServer  value unaccessable, otherwise, outlook will not use "ecWrongServer" which is what it needs to update the profile.

    This is correct, I have a blog article on this topic coming out soon.

    Unless your blog article is going to announce that Microsoft have seen the light and decided to do something about this fiasco, it isn't really going to help a great deal.

    After over 10 years of Exchange admins being able to move mailboxes to a new platform and not have to touch all the clients, they are now faced with a situation that really isn't acceptable. You have two main choices

    1. Touch every client to get them to use the CAS array before the migration.

    2. Take the risk and cross your fingers that autodiscover will kick in and direct clients to the new server automatically because the old one has gone away. However for some of my clients who are very risk adverse, that "risk" is too high because they cannot test it and know it will work, so are faced with having to touch clients before a migration can complete so that they "know" it will work. It also means you cannot do a staged migration, which many clients like to do, it is an all or nothing.

    What we need is a way to force the Outlook "ecWrongServer" cycle to take place, perhaps with a PowerShell command, and introduced before the next version of Exchange. At the moment it isn't a huge issue, but at the end of this year the early adopters of Exchange 2010 will be coming to the end of a three year cycle and the level of migrations will start to increase. That doesn't even take in to account the new version of Exchange whenever that turns up.
    Those who haven't created an RPC CAS Array (and I would say about 75% of all Exchange 2010 systems I see do not have them) will find the amount of work required for their migration will increase significantly. It will be much better to get something in place now, rather than have this major issue hit in nine to twelve months time.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Wednesday, March 21, 2012 9:50 AM
  • Simon, you're right - my mistake.  You need to make the old RpcClientAccessServer  value unaccessable, otherwise, outlook will not use "ecWrongServer" which is what it needs to update the profile.

    This is correct, I have a blog article on this topic coming out soon.

    Unless your blog article is going to announce that Microsoft have seen the light and decided to do something about this fiasco, it isn't really going to help a great deal.

    Part 1 of the article is now live. It was too long so I split it into 2 parts, and it will be Part 2 that talks about this item. There isn't a "fix" in there, but it does go into why CAS Arrays should be created no matter what.

    http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx


    Microsoft Premier Field Engineer, Exchange
    MCSA 2000/2003
    MCTS: Win Server 2008 AD, Configuration MCTS: Win Server 2008 Network Infrastructure, Configuration
    MCITP: Enterprise Messaging Administrator 2010
    Former Microsoft MVP, Exchange Server

    NOTICE: My posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Friday, March 23, 2012 9:03 PM
  • Oh man. I just read your articles without noticing it was you because I have that Exchange blog as a tab in IE. :)

    I should read them again to get a thorough understanding. There are some things I also don't get like Autodiscovery. I have my users connect using Outlook Anywhere/Outlook over RPC. What I don't understand is when I setup an e-mail account for someone, the Exchange Server URL should point to my local Exchange Server, but it points to my other site's Exchange server and I don't know why. I would've thought this was a setting or something that can be pulled up in the Exchange Management Shell, but perhpas I am looking in the wrong spot. =\

    Monday, April 02, 2012 4:19 PM
  • If you have the RPC CAS Array configured, then it should use the that for the Exchange server.

    Otherwise it could be that you don't have your AD sites and services configuration correct and the client thinks that both servers are in the same site.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Tuesday, April 03, 2012 8:55 AM
  • Sembee: Is there a precidence or ordering when it comes to both of those servers being in the same site?

    Tuesday, April 03, 2012 2:58 PM
  • @Brian Day: I saw this post here

    http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8b6f5263-92c9-49cb-8db7-6c83054b8401/

    where the poster is looking to do the same thing as me, and you replied there as well. I'm guessing my post was worded poorly. Just so I understand:

    - Move mailboxes to server that will remain up

    - Update RPCClientAccess Server using 'Set-MailboxDatabase' to existing/working CAS Server

    At this point, do you just wait for Autodiscover to pick up the changes, and/or flush DNS? I guess I understand more than I let on - I figured that's all you had to do, I just wanted to make sure. I'll read your blog posts again, and soon in the future implement a CAS Array as everyone suggests. :)

    • Marked as answer by darksim905 Tuesday, April 03, 2012 8:35 PM
    Tuesday, April 03, 2012 6:21 PM
  • Great news!  This has been fixed in Exchange 2010 SP2 UR3:

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



    Mike Crowley | MVP
    My Blog -- Planet Technologies

    I was reading that earlier too and hoping to read the same thing... I am wondering though, is it a complete fix, or just a fix when the mailbox is moved to another site?

    "By default, once you have installed SP2 RU3, when you move mailboxes between AD sites, all versions of Outlook will get prompted to restart and the Outlook profile’s RPC endpoint will be updated."

    Steve


    Steve Goodman
    Check out my Blog for more Exchange info or find me on Twitter

    Wednesday, May 30, 2012 9:01 PM
  • Steve, that's two missteps in one thread.  Not good for my average.  :(

    I deleted the above post.  You're welcome to leave your quotation of it however so that others can read the news about today's update.

    I got some out of band information stating this was fixed with mailbox moves as well, but have since learned that was incorrect.

    My understanding is that: If Outlook has a path to the mailbox via a direct cas server name within the same site (eg. no-cas array), the profile will not update.  If that path goes down or is otherwise obstructed, Outlook will default to autodiscover and then it should get the CASarray value, and then ask the user to restart.

    So no, this was not fixed in today's update.  They do reiterate however that one is wrong to skip the creation of a CASarray even in a single-server environment.  Too bad the product doesn't do this for you, or even expose the feature in the UI.



    Mike Crowley | MVP
    My Blog -- Planet Technologies



    Wednesday, May 30, 2012 11:15 PM
    Moderator