none
High Availibility Namespace

    Întrebare

  • Current High Level Design Plan:

    Site A

    DAG1 MEMBERS - MAILBOX SERVER 1, MAILBOX SERVER 2

    CAS ARRAY (outlook.domain.com)  MEMBERS - HT/CAS1,HT/CAS2

    NETSCALER PAIR - Used for GSLB - OWA, ActiveSync, Autodiscover

    Site B

    DAG1 MEMBERS - MAILBOX SERVER 3, MAILBOX SERVER 4

    CAS ARRAY (outlookdr.domain.com) MEMBERS - HT/CAS3, HT/CAS4

    NETSCALER PAIR - Used for GSLB - OWA, ActiveSync, Autodiscover

    Site A is Primary and all user mailboxes have preference of servers in that AD site.  Site B will be used for failover in the event of various failures.

    Site A and Site B are connected via MPLS

    ****************

    My first test was to failover DB1 on MAILBOX SERVER 1 to MAILBOX SERVER 3 (in Site B)

    Currently I have the internal and external url for Site A set to service.domain.com and Site B set to servicedr.domain.com.

    My outlook client is still connected to the CAS server Array in Site A, and everything seems to be working as expected.  My OWA and Activesync fail tests fail.

    My question is how do I design the namespace for OWA, ActiveSync, and Autodiscover?  Externally I would like to use the same namespace and leverage GSLB to connect in various failure events.

    8 martie 2012 17:16

Răspunsuri

  • Jennifer - were you given a link to change the RPCClientAccessServer attribute?  Trying to understand the rational behind the recommendation you received.

    Click my profile, and there is a link on my blog to email me directly if you prefer that. 

    You do not need to change the RPCClientAccess attribute on a site failover, simply change the internal DNS entry for CASArraySite1 -> the IP of your CASArraySite2 (which should be a VIP on your netscalar). That way the outlook client will resolve the name to the IP in the second site and get access to mail. 

    Details here

    http://technet.microsoft.com/en-us/library/dd351049.aspx 


    Clients connect to service endpoints (for example Outlook Web App, Autodiscover, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4, and the RPC Client Access array) to access Exchange services and data. Therefore, activating Client Access servers involves changing the mapping of the DNS records for these service endpoints from IP addresses in the primary datacenter to the IP addresses in the second datacenter that are configured as the new service endpoints. Depending on your DNS configuration, the DNS records that need to be modified may or may not be in the same DNS zone.

    Clients will then automatically connect to the new service endpoints in one of two ways:

    • Clients will continue to try to connect, and should automatically connect after the TTL has expired for the original DNS entry, and after the entry is expired from the client's DNS cache. Users can also run the ipconfig /flushdns command from a command prompt to manually clear their DNS cache.
    • Clients starting or restarting will perform a DNS lookup on startup and will get the new IP address for the service endpoint, which will be a Client Access server or array in the second datacenter.

    Assuming that all appropriate configuration changes have been completed to define and configure the services in the second datacenter to function as they were in the primary datacenter, and assuming that the established DNS configuration is correct, no further changes should be needed to activate Client Access servers.


    Cheers, Rhoderick


    10 martie 2012 15:55
  • Hello Suk

    Even for a site failure or failover, it is not required nor is it recomended to change the rpcclientaccess attribute value on the databases.


    Bulls on Parade

    • Propus ca răspuns de Sukh828 11 martie 2012 16:03
    • Marcat ca răspuns de Frank.Wang 15 martie 2012 01:59
    11 martie 2012 14:49

Toate mesajele

  • Do you have external DNS records for servicedr.domain.com, you need to. Is servicedr.domain.com listed as one of the names in your cert? what is the cert's principal name or common name? I'm assuming its service.domain.com?

    Bulls on Parade

    9 martie 2012 15:34
  • Yes, I have external DNS records for servicedr.domain.com and the names are listed on my SAN cert.  It turns out I had the same ip address for service.domain.com and servicedr.domain.com externally (I am still testing and have a temporary solution in place for my netscalers).  Once I changed the servicedr external record IP it worked as expected (redirection).  I was also told by Microsoft to manually update the database that I failed to the other site, with the CAS array (for Site B) for the rpcclientaccess server parameter.  Once I did this it broke my outlook rpc clients.  I was told this was due to there not being a public folder database in Site B.  I am in the middle of creating a public folder databse in site B and will failover for testing.  I will update this thread with my results.  Thank you Skipster for your help.

    Jennifer

       
    9 martie 2012 19:52
  • Hello Jennifer,

    I think Microsoft told you wrong. You should not have to change the rpcclientaccess name for any databases after a database failover or a site failover. The rpcclientaccess name stays with the database. If you change this you create connection problems for your users. Regarding Public folders, thats a new one, I have never heard public folders were required for Exchange 2010. Public folders are only required if you have Outlook 2003 clients in your environment


    Bulls on Parade

    • Propus ca răspuns de Sukh828 11 martie 2012 16:04
    9 martie 2012 22:18
  • If you have a complete site failure, site A is down, then you have to change the RPCClientAccess attribute on the DR site to you that sites CAS Array.  If it's not down then you dont have to.

    You dont need an PF DB in a pure Exch 2010 Org with Outlook 2007/2010, it's optional.  MBX use Availability service and can use web based distribution for OAB.

    Sukh


    • Editat de Sukh828 10 martie 2012 02:31
    10 martie 2012 02:29
  • Hi Skipster and Sukh

    Thank you both for your responses.  When my CAS Array is down I manually changed the RPCClientAccess attibute to the other CAS Array however when I change it back, the client does not recongine that it changed back.  Is there something I have to do to update the client?  As for the public folder, I have Exchange 2003 still in my environment so I have a copy of that public folder in both sites.  I assume I could get rid of these and just point the databases to the 2003 Public folder to get free busy for 2003 mailboxes?

    Thanks again for your response.

    10 martie 2012 07:48
  • If you have changed this, then you have to either repair the Outlook profile or create a new one.

    As for the PF, do you mean get rid of 2003 and point the DB to the PF on the local 2010 server?


    Sukh

    10 martie 2012 14:02
  • Jennifer - were you given a link to change the RPCClientAccessServer attribute?  Trying to understand the rational behind the recommendation you received.

    Click my profile, and there is a link on my blog to email me directly if you prefer that. 

    You do not need to change the RPCClientAccess attribute on a site failover, simply change the internal DNS entry for CASArraySite1 -> the IP of your CASArraySite2 (which should be a VIP on your netscalar). That way the outlook client will resolve the name to the IP in the second site and get access to mail. 

    Details here

    http://technet.microsoft.com/en-us/library/dd351049.aspx 


    Clients connect to service endpoints (for example Outlook Web App, Autodiscover, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4, and the RPC Client Access array) to access Exchange services and data. Therefore, activating Client Access servers involves changing the mapping of the DNS records for these service endpoints from IP addresses in the primary datacenter to the IP addresses in the second datacenter that are configured as the new service endpoints. Depending on your DNS configuration, the DNS records that need to be modified may or may not be in the same DNS zone.

    Clients will then automatically connect to the new service endpoints in one of two ways:

    • Clients will continue to try to connect, and should automatically connect after the TTL has expired for the original DNS entry, and after the entry is expired from the client's DNS cache. Users can also run the ipconfig /flushdns command from a command prompt to manually clear their DNS cache.
    • Clients starting or restarting will perform a DNS lookup on startup and will get the new IP address for the service endpoint, which will be a Client Access server or array in the second datacenter.

    Assuming that all appropriate configuration changes have been completed to define and configure the services in the second datacenter to function as they were in the primary datacenter, and assuming that the established DNS configuration is correct, no further changes should be needed to activate Client Access servers.


    Cheers, Rhoderick


    10 martie 2012 15:55
  • If you have a complete site failure, site A is down, then you have to change the RPCClientAccess attribute on the DR site to you that sites CAS Array.  If it's not down then you dont have to.

    You dont need an PF DB in a pure Exch 2010 Org with Outlook 2007/2010, it's optional.  MBX use Availability service and can use web based distribution for OAB.

    Sukh


    Its not required to change the RPCClientAccessServer paramater on site failover, please see my post below. 

    If you do that, it leads to a pile of pain in updating profiles etc.  Outlook 2003 especially.


    Cheers, Rhoderick

    • Propus ca răspuns de Sukh828 11 martie 2012 16:03
    10 martie 2012 15:58
  • If you have a complete site failure, site A is down, then you have to change the RPCClientAccess attribute on the DR site to you that sites CAS Array.  If it's not down then you dont have to.

    You dont need an PF DB in a pure Exch 2010 Org with Outlook 2007/2010, it's optional.  MBX use Availability service and can use web based distribution for OAB.

    Sukh


    Its not required to change the RPCClientAccessServer paramater on site failover, please see my post below. 

    If you do that, it leads to a pile of pain in updating profiles etc.  Outlook 2003 especially.


    Cheers, Rhoderick


    Not even for a site failure?  Wouldn't you need to update the value then it they have been activated at the DR site which is supposed to use the DR CAS Array?

    Sukh

    10 martie 2012 16:05
  • Hello Suk

    Even for a site failure or failover, it is not required nor is it recomended to change the rpcclientaccess attribute value on the databases.


    Bulls on Parade

    • Propus ca răspuns de Sukh828 11 martie 2012 16:03
    • Marcat ca răspuns de Frank.Wang 15 martie 2012 01:59
    11 martie 2012 14:49
  • Hi Skipster

    You are correct and so is Rhoderick, I was thinking something completly different, thanks for pointing out.


    Sukh

    11 martie 2012 16:03
  • No worries.  Its just about getting the client to a functional RPCA endpoint.

    Jennifer - does that help you out here?  Also can fill in the details as to why you were recommended to change the RPCClientAccess attribute?  Curious as public folders don't even use that - they go straight to the MBX role. 


    Cheers, Rhoderick

    12 martie 2012 02:07
  • Hi Jennifer,

    Please also read Henrik's exciting article:

    Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/planning-deploying-testing-exchange-2010-site-resilient-solution-sized-medium-organization-part1.html


    Frank Wang

    TechNet Community Support

    12 martie 2012 05:53
  • Hi
    Rhoderick, yes, your response helps solidify my thoughts. Changing the
    rpcclientaccess attribute as I was told to do by Microsoft support caused the
    outlook client issues that you describe. When I initially called support my
    issue was that webmail was not silently redirecting. In troubleshooting this
    issue Microsoft Support told me that I had to manually change the
    rpcclientaccess attribute when failing a database over to another AD site. Doing
    this caused the outlook client to stop working. Their answer to why it stopped
    working was I needed a public folder in site B. As I suspected, creating the
    public folder database in Site B did not resolve the outlook client issue after
    changing the rpcclientaccess attribute. Basically one problem created after
    another - due to bad advice at each turn.

    Here is where I am today. When I fail just the database over to Site B, I leave
    everything as is and outlook clients are working (as they should since the CAS
    servers in Site A are up). When the CAS servers in site A fail I have internal
    DNS for the CAS Array pointing to the two netscaler pairs (one in each site).
    The DNS entry is the VIP for the GSLB VServer for the rpc client access array.
    This will allow us to sustain a double netscaler failure in Site A, and/or a
    CAS array failure in Site A and still leave the outlook clients unaffected. As
    for my initial problem; webmail not redirecting when I failed the DB to Site B;
    the issue was that I was in a testing phase on the Netscaler environment (basically
    I was unable to make changes to our netscalers in Site B) so I had created Site
    B's VIPs on site A's netscalers. The problem was I was using the same IP for
    both sites. Once I was able to change the IP of the temp Site B VIPs, all was
    well :)



    Please let me know if there is any caveats to the setup I described. My end goal is to
    survive any combination of failures without the client knowing. Additionally I
    am using Kerberos authentication and my outlook 2010 clients are pointing to
    the netscaler VIPs for rpc connectivity to the CAS array. I started down the
    path of setting out outlook anywhere and attempting to use that as a backup but
    realized that my client prompted me for credentials when I attempted a CAS
    array/Site A netscaler failure.



    Thanks
    again for all of your help Rhoderick.



    15 martie 2012 03:27
  • Hi Jennifer,

    If I'm understanding you correctly the main issue is the non-silent cross-site redirection.  Is that the case?

    Cross site OWA redirection is not silent until you install Exchange 2010 SP2, then when you hit a CAS in siteA and the mailbox is in SiteB then the user will get a silent redirection if the authentication matches.

    If possible use the steps to contact me above, and I can take your feedback and send it on internally. 


    Cheers, Rhoderick

    15 martie 2012 19:55
  • Hi Rhoderick (and everyone else)!

    This is really good stuff!  I seem to have a problem with a point in your last reply, Rhoderick: You said that in Exch 2010 SP2 the OWA, and hopefully EAS, redirection is silent and it doesn't seem to be so for me.  A little background on my environment: I have a VM which is my CAS and all Outlook 2010 clients connect to is as do EAS devices and OWA users.  I have two physical maibox servers in a DAG, one lives in my production site which is where the CAS lives, and the other is at our DR location.  All is well while the CAS is connected to the primary mbox server but OWA and EAS fails when the databases failover.  The CAS's app log shows event 1044:

    The Client Access server doesn't have the InternalURL value set for the Microsoft-Server-ActiveSync virtual directory. This prevents Exchange ServiceDiscovery from finding the MobileSyncService information for user MBOXDR.DOMAIN.LOCAL. At least one Client Access server in the user's mailbox Active Directory site must have the InternalURL value set. The format for the InternalURL value is https://hostname/Microsoft-Server-ActiveSync.

    If I run Get-ActiveSyncVirtualDirectory from ANY of my Exchange servers, I get:

    Name                                    Server                                  InternalUrl
    ----                                    ------                                  -----------
    Microsoft-Server-ActiveSync (Default... CAS                                   https://cas.domain.local/Microsof...

    What am I missing?

    Many thanks to all for your help!

    Alex

    28 martie 2012 13:59
  • Just to check, you do have CAS installed in the other AD site?


    Cheers, Rhoderick

    28 martie 2012 18:53
  • Hi Rhoderick,

    Excellent question!  The plan is a bit more comlicated than that: The CAS that I have running in my prod site is a VM that replicates using vRanger to our DR site.  If the prod site goes down completely then I power up the replica VM which talks to the MB server.  The failover that I'm talking about here is strictly for the DBs.

    Thanks!

    Alex

    29 martie 2012 02:56
  • Hi Alex,

    Even though the DBs are moved to the second site, the issue is still around CAS.

    You must have a CAS server running in that secondary site so that the CAS server in the primary site can either proxy or redirect the connection to it.  Some details are here:http://technet.microsoft.com/en-us/library/bb310763.aspx

    Basically the way you have this right now, there is no way that CAS in the primary site can get the user's request over to the secondary site. 

    I'd also like to ask you how you are planning to update CAS so that it now know it is running in the secondary site?  This is written into AD when CAS role is installed, and you need to modify it if moving to a new location.  Its possible to change this, but it is added complexity.  Also is this software taking snapshots of the Exchange VM?  Make sure that all of the system requirements are met http://technet.microsoft.com/en-us/library/bb310763.aspx 

    Is there a reason that you cannot have a second CAS server in that secondary site up and running at all times? 

    The content I posted above in the thread for silent redirection assumes that you have deployed a supported design, ie CAS and HUB in all sites that have MBX role.   One other thing to consider, what will happen when the mailbox server in that second AD site wants to send an email - is there a HUB transport server in that AD site?   If not then it will never be able to send or receive email.  MBX role only communicates to HUB servers in the same AD site. 


    Cheers, Rhoderick

    29 martie 2012 04:10
  • Hi Rhoderick,

    First of all, I'd like to thank you for your continued responses and for sticking with me on this issue.  To answer your questions, I did not add a CAS to the DR site purely for licensing reasons.  If, on the other hand, you tell me that it is not possible to do it this way then we will install a a second CAS and create a CAS array.  Related question: Would it be possible for me to maintain the MAPI server name for the array since it is currently the computer name for the current CAS?

    I wasn't aware that I'd have to do any updates to the CAS so that it knew it was now running in DR besides fire it up.  The replication application basically keeps the vmdks between the two VMs in sync and in the event of failure it just starts it up because the DR vm is a cold site.

    Lastly, both of my MBX servers have HUB roles installed on them as does the CAS which may actually be redundant.

    Thanks!

    Alex

    29 martie 2012 12:49
  • Rhoderick,

    One more question: Isn't CAS able to talk to two different MBOX servers regardless of the site they're in?  I guess what I'm not understanding is why the one CAS that I have can't address whichever MBOX server that has the DBs mounted on it.  It has to be doing it in some way since MAPI clients work fine but OWA and EAS breaks.

    Thanks again,

    Alex


    Thanks! Alex

    29 martie 2012 15:58
  • Rhoderick,

    One more question: Isn't CAS able to talk to two different MBOX servers regardless of the site they're in?  I guess what I'm not understanding is why the one CAS that I have can't address whichever MBOX server that has the DBs mounted on it.  It has to be doing it in some way since MAPI clients work fine but OWA and EAS breaks.

    Thanks again,

    Alex


    Thanks! Alex

    Yes it can, but it is a proxy or redirect to the CAS in the second site.  This is in the proxy & redirection document that I mentioned above.  You need to have CAS and HUB in every site that you have MBX role installed - there is no getting away from that.

    Why not just add CAS role to the MBX/HUB server that you have in the second site?  Why mess with that VM failover - it is not giving you anything.

    MAPI access is done via RPC Client access which is a separate discussion from the above, hence it is operating differently. 

    Does that make sense?


    Cheers, Rhoderick

    29 martie 2012 18:14
  • Rhoderick,

    One more question: Isn't CAS able to talk to two different MBOX servers regardless of the site they're in?  I guess what I'm not understanding is why the one CAS that I have can't address whichever MBOX server that has the DBs mounted on it.  It has to be doing it in some way since MAPI clients work fine but OWA and EAS breaks.

    Thanks again,

    Alex


    Thanks! Alex

    Yes it can, but it is a proxy or redirect to the CAS in the second site.  This is in the proxy & redirection document that I mentioned above.  You need to have CAS and HUB in every site that you have MBX role installed - there is no getting away from that.

    Why not just add CAS role to the MBX/HUB server that you have in the second site?  Why mess with that VM failover - it is not giving you anything.

    MAPI access is done via RPC Client access which is a separate discussion from the above, hence it is operating differently. 

    Does that make sense?


    Cheers, Rhoderick


    Ah, understood.  I failed to catch the requirement of a CAS in every site that has HUB and MBX in it.  Right, sounds like I should just build a CAS in my DR site and forget the replication business.  Would you still recommend that I keep the CAS role separate from the others or go back to multi role as I did before?  Can one build a CAS array even if the Exchange boxes are multi-role with CAS, HUB and MBX on each?

    Thanks! Alex

    29 martie 2012 18:46
  • Yes - the recommendation is to create the logical CASArray object even if you have one server. 

    Now, CASArray itself does not provide load balancing.  You need something else to do that load balancing for you, if you have multirole servers then that means an external LB device/appliance. 


    please take a peek here at parts 1 and 2 of this excellent article:  http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx


    Cheers, Rhoderick

    • Propus ca răspuns de AlexZ438858 2 aprilie 2012 14:25
    29 martie 2012 18:58
  • Yes - the recommendation is to create the logical CASArray object even if you have one server. 

    Now, CASArray itself does not provide load balancing.  You need something else to do that load balancing for you, if you have multirole servers then that means an external LB device/appliance. 


    please take a peek here at parts 1 and 2 of this excellent article:  http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx


    Cheers, Rhoderick


    Thanks again, Rhoderick!  I don't plan on using the CAS array for load balancing, just DR/BCP.  So, if I have a separate CAS VM in DR and in prod, they're both in an array and then I have the two physical servers that are HUB and MBX, each in prod and DR, then if a CAS or an MBX server fail everything will still keep ticking (Outlook clients, OAW and EAS)?

    Thanks! Alex

    29 martie 2012 19:24
  • Yes - the recommendation is to create the logical CASArray object even if you have one server. 

    Now, CASArray itself does not provide load balancing.  You need something else to do that load balancing for you, if you have multirole servers then that means an external LB device/appliance. 


    please take a peek here at parts 1 and 2 of this excellent article:  http://blogs.technet.com/b/exchange/archive/2012/03/23/demystifying-the-cas-array-object-part-1.aspx


    Cheers, Rhoderick


    Thanks again, Rhoderick!  I don't plan on using the CAS array for load balancing, just DR/BCP.  So, if I have a separate CAS VM in DR and in prod, they're both in an array and then I have the two physical servers that are HUB and MBX, each in prod and DR, then if a CAS or an MBX server fail everything will still keep ticking (Outlook clients, OAW and EAS)?

    Thanks! Alex

    Hi Rhoderick,

    You might have expected this but I thought I'd relay it anyway: Failing over my CAS VM to DR and letting it talk to the DR MBX server was a total flop for OWA and EAS while Outlook worked fine.  Guess I'll be building a 2nd CAS box as you suggested.

    Thanks for all of your help!


    Thanks! Alex

    2 aprilie 2012 14:25
  • Hi Alex

    Erm, yes :)  

    Thanks for closing the loop on this!


    Cheers, Rhoderick

    5 aprilie 2012 15:23