O365 with onprem hybrid server need autodiscovery at DR location that would have no hybrid server?
We're creating a DR location and i have a question about email. We currently use O365 along with a hybrid on-prem Exch 2013 mail server where we create onprem users/mbxs and then migrate to O365 cloud. We use onprem ADFS to auth. This setup is current and will not change at current production site. (wasn't involved in design but it will remain)
In the event of DR scenario, i will redirect external STS DNS A record to now point to DR location (as well as create an internal STS for DR site) to work with DR onprem ADFS server (we will use DR location ADFS, not Azure in cloud) to authenticate users. This part i believe is correct.
My question is the external and internal autodiscovery DNS A record. I know this is used for initial user Outlook setup, but i don't plan to be ready to make new users in the event of DR scenario. Only planning for short duration at DR location before moving back. (perhaps optimistic :) but this is the plan)
I will not have a hybrid server at the DR location. So - I don't need the autodiscovery DNS A external and internal record as it will have nothing to point to, and is not then needed for this temporary time, correct? Am i wrong? and if so - what's the autodiscovery purpose at a temp DR location and what would it point to without a hybrid server at DR?
Any link to confirming information would also be appreciated. Thanks guys/girls!
In the event of DR scenario, i will redirect external STS DNS A record to now point to DR location (as well as create an internal STS for DR site) to work with DR onprem ADFS server (we will use DR location ADFS, not Azure in cloud) to authenticate users. This part i believe is correct.
My question is the external and internal autodiscovery DNS A record. I know this is used for initial user Outlook setup, but i don't plan to be ready to make new users in the event of DR scenario. Only planning for short duration at DR location before moving back. (perhaps optimistic :) but this is the plan)
I will not have a hybrid server at the DR location. So - I don't need the autodiscovery DNS A external and internal record as it will have nothing to point to, and is not then needed for this temporary time, correct? Am i wrong? and if so - what's the autodiscovery purpose at a temp DR location and what would it point to without a hybrid server at DR?
Any link to confirming information would also be appreciated. Thanks guys/girls!
ASKER
Thanks for the informed response. We've discussed removing the hybrid with MS multiple times. While we know it's possible, MS stated the resulting status would not be fully supported, so mgmt has decided firmly not to remove the hybrid server. Understood that it's not preferred, but if the end result is not fully supported, they won't allow me to do it. Not happening, unfortunately.
We've also explored with MS moving auth fully to Azure in the cloud as well, that has also be denied. We run a dirsync server onprem every 30min with Azure AD connect to sync AD with the cloud.
Knowing our prod site will remain this way - (correct me if i'm wrong from this point on) i would need to install an ADFS server at DR and configure it so i can point STS and autodiscover internally and externally to it in the event of a DR scenario.
As i will only be needing auth ability for usesrs in the cloud leveraging onprem ADFS for current O365 users, would i still need a CAS/mailbox role server in the DR site? It may be pie in the sky to assume this, but we are planning for a DR site transfer to be temporary and do not plan to create any users during that time until the prod site is back up. So unless there's something else needed by that CAS server, do we need it at DR site as well?
Please let me know, and thanks!
We've also explored with MS moving auth fully to Azure in the cloud as well, that has also be denied. We run a dirsync server onprem every 30min with Azure AD connect to sync AD with the cloud.
Knowing our prod site will remain this way - (correct me if i'm wrong from this point on) i would need to install an ADFS server at DR and configure it so i can point STS and autodiscover internally and externally to it in the event of a DR scenario.
As i will only be needing auth ability for usesrs in the cloud leveraging onprem ADFS for current O365 users, would i still need a CAS/mailbox role server in the DR site? It may be pie in the sky to assume this, but we are planning for a DR site transfer to be temporary and do not plan to create any users during that time until the prod site is back up. So unless there's something else needed by that CAS server, do we need it at DR site as well?
Please let me know, and thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
understood. so:
1. i need to create an ADFS server in DR and (in event of DR scenario) point sts.mydomainname.com to DR ADFS server internally and externally.
2. (in event of DR scenario) point autodiscover.mydomainname.
i thought STS did the auth piece back to ADFS/AD and autodiscover does initial Outlook wizard setup? i can't find a good example of what each does that the other don't online.
what specifically does each do/needed for? if you would, please state it for me - as websites i've checked don't do the definition justice.
1. i need to create an ADFS server in DR and (in event of DR scenario) point sts.mydomainname.com to DR ADFS server internally and externally.
2. (in event of DR scenario) point autodiscover.mydomainname.
i thought STS did the auth piece back to ADFS/AD and autodiscover does initial Outlook wizard setup? i can't find a good example of what each does that the other don't online.
what specifically does each do/needed for? if you would, please state it for me - as websites i've checked don't do the definition justice.
2. (in event of DR scenario) point autodiscover.mydomainname.com to autodiscover.outlook.com.
If you reread my last comment again, you need autodiscover.domain.com alias pointing to autodiscover.outlook.com in production and DR site both
Yes, STS does authentication piece back to back with ADFS/AD
However autodiscover is required to locate and configure O365 mailbox initially and to connect to exchange web services (EWS) every time you start outlook
As long as you have DC\DNS in DR STS authentication will work and autodiscover record would be there as part of DNS zone
ASKER
ok, i don't want to mess with current production, so:
1. right now create ADFS instance in DR in prep for future DR scenario
2. in event of DR -
- point sts.mydomainname.com to DR ADFS internally and externally
- create autodiscover.mydomainname.
* i don't want to introduce the autodiscover for DR as if we have ANY kind of blip in email without a DR happening, mgmt would not be happy. They would prefer it 90% ready and introduce the alias for DR later. Unless i absolutely need to put an alias in DNS for the DR site, mgmt would prefer to wait til it's needed. not driving that train :)
does this sound comprehensive enough considering my mgmt's request?
1. right now create ADFS instance in DR in prep for future DR scenario
2. in event of DR -
- point sts.mydomainname.com to DR ADFS internally and externally
- create autodiscover.mydomainname.
* i don't want to introduce the autodiscover for DR as if we have ANY kind of blip in email without a DR happening, mgmt would not be happy. They would prefer it 90% ready and introduce the alias for DR later. Unless i absolutely need to put an alias in DNS for the DR site, mgmt would prefer to wait til it's needed. not driving that train :)
does this sound comprehensive enough considering my mgmt's request?
- create autodiscover.mydomainname.com alias in DR pointing to autodiscover.outlook.com
check your production dns server, you still be having autodiscover record pointing to autodiscover.outlook.com ? don't you?
its not matter of DNS record creation, it must be already there in production and DR DNS server
ASKER
ahhh. sorry, my mistake. you're correct. not sure what i was thinking.
so just need to create ADFS at DR, and in the event of DR scenario, point STS internally and externally towards DR ADFS, correct?
so just need to create ADFS at DR, and in the event of DR scenario, point STS internally and externally towards DR ADFS, correct?
Yes, that's right...
you do need domain controller at DR...as well
ASKER
Understood, we have 2 DCs there already, so there's no need to worry bout that one.
thank you, you've be great.
thank you, you've be great.
ASKER
great answer.
keeping hybrid environment with DR means increasing management overheads / overall costing and defeat the purpose of migrating to O365
Better you migrate all your mailboxes to O365, remove hybrid config and keep only one Exchange server for user management, that is also Microsoft don't officially support user management without exchange software. Now you don't need autodiscover pointing to onpremise exchange servers since you don't have any mailboxes onpremsie
Point your autodiscover record to autodiscover.outlook.com (CNAME) and you don't need mail.domain.com record anymore, outlook will find O365 mailbox with DNS autodiscover method
For ADFS you can either use SQL as database and add one more server in adfs farm at DR in addition to ADFS servers in production, in the event of failure, you can point STS to DR ADFS server internally and externally
OR
Use password sync as well with Azure AD connect. This will ensure that You can change O365 domain authentication from federated to managed and it will allow users to authenticate with their AD passwords as cloud only authentication when ADFS at production site fails and ADFS DR instance is not deployed
This way only ADFS would be dependant on DR scenario and you will get benefited from moving email system to cloud
Note that hybrid mode is innovated by Microsoft specially fro large scale migration where co-existence will remain for longer period until all mailboxes get migrated and meantime sharing / freebusy calender etc should work, its not intended to keep onpremsie exchange infrastructure for ever (you can, its different story) , else its defeating purpose of moving to cloud