We are running Exchange 2010 SP2 on a single domain single site with four servers
mail1 - CAS,HT,Mbox ()DAG member)
mail2 - CAS,HT
mail3 - CAS,HT,Mbox (DAG member)
mail4 - mbox (DAG member)
We do not have a CAS array and intend to use mail.domain.com namespace this time when we upgrade to 2013.
Our three 2010 servers mail1,mail2 and mail3 are published on public DNS and are accessible externally over different ISP links and our clients have their outlook 2011 Mac and few other IMAP accounts configured using mail1.domain.com, mail2.domain.com or mail3.domain.com
We are planning transition to Exchange 2013 with another four servers as :
Ex13CAS1 - CAS
Ex13CAS2 - CAS
Ex13Mbox1 - Mbox in DAG
Ex13Mbox2 - Mbox in DAG
we also will have a hardware load balancer before the CAS servers and will use mail.domain.com
Question:
Our concern is for Mac clients / IMAP accounts that are configured manually which will have impact once we move the namespace. We want to check the possibility if both setup can coexist independently for a period while we help all such users to conveniently move to exchange 2013.
Since users are at different geographical locations with manual account configuration it would be big overhead in reconfiguring each user account who all will lose connectivity as we move the namespace. Is there a way we setup Exchange 2013 with the new name space but keep these client using their existing configuration with existing namespace and gradually move them in batches causing minimum impact. ie same domain two name space.
In other words, Is it possible that users keep using mail1,mail2 or mail3 as per their present configuration while we move the users gradually to the new single name space mail.domain.com i.e. can both exchange setup be functional over different ISP links independently. if we transit to a single namespace, users that are moved get their 2013 mailbox but the users still on 2010 continue to use their mail accounts with mail1\mail2 or mail3.domain.com instead of getting proxied from 2013 CAS. Please suggest a correct approach in this situation.
mail1 - CAS,HT,Mbox ()DAG member)
mail2 - CAS,HT
mail3 - CAS,HT,Mbox (DAG member)
mail4 - mbox (DAG member)
We do not have a CAS array and intend to use mail.domain.com namespace this time when we upgrade to 2013.
Our three 2010 servers mail1,mail2 and mail3 are published on public DNS and are accessible externally over different ISP links and our clients have their outlook 2011 Mac and few other IMAP accounts configured using mail1.domain.com, mail2.domain.com or mail3.domain.com
We are planning transition to Exchange 2013 with another four servers as :
Ex13CAS1 - CAS
Ex13CAS2 - CAS
Ex13Mbox1 - Mbox in DAG
Ex13Mbox2 - Mbox in DAG
we also will have a hardware load balancer before the CAS servers and will use mail.domain.com
Question:
Our concern is for Mac clients / IMAP accounts that are configured manually which will have impact once we move the namespace. We want to check the possibility if both setup can coexist independently for a period while we help all such users to conveniently move to exchange 2013.
Since users are at different geographical locations with manual account configuration it would be big overhead in reconfiguring each user account who all will lose connectivity as we move the namespace. Is there a way we setup Exchange 2013 with the new name space but keep these client using their existing configuration with existing namespace and gradually move them in batches causing minimum impact. ie same domain two name space.
In other words, Is it possible that users keep using mail1,mail2 or mail3 as per their present configuration while we move the users gradually to the new single name space mail.domain.com i.e. can both exchange setup be functional over different ISP links independently. if we transit to a single namespace, users that are moved get their 2013 mailbox but the users still on 2010 continue to use their mail accounts with mail1\mail2 or mail3.domain.com instead of getting proxied from 2013 CAS. Please suggest a correct approach in this situation.