SOLVED

Setup up autoDiscover In On-Perm DNS to integrate with O365

Copper Contributor

Hello

I'm am moving all mailboxes to O365 using cutover method .

but my main concern is the way that On-perm outlook clients will connect to O365.

I am aware that outlook uses autodiscover , SRV Record and CNAme record to perform auto discover to O365 . currently On Perm Exchange XML files are located at Mail.MyDomain.com and there is DNS entry record on my internal DNS which points to a local IP address .

 

would it be enough to change the Local IP address for DNS entry mail.MyDomain.com to O365 IP address instead? and if the answer is yes , do I need to add SRV and CNAMe to my internal DNS as well as External DNS to point to O365? and if I do that do I need to crate autodiscover.xml file O365 manually?

 

Do I need to redirect mail.Mydomain.com to autodiscover.MyDomain.com ?

 

Your Help is much appreciated

 

13 Replies

@hntaurus 

 

What you would need to do when your mailboxes are in Exchange Online is to change the serviceBindingInformation parameter of the service connection point in either ADSI Edit or AD Sites and Services.  The link below shows how to do that.

 

https://social.technet.microsoft.com/Forums/ie/en-US/5b0ab7b5-fb73-41f8-a0fa-5753308cf195/steps-to-r...

 

The SCP can be set to 

https://autodiscover.outlook.com/autodiscover/autodiscover.xml and this should take care of autodiscover for any Outlook clients inside your network.

 

@PeterRising 

Thanks a lot for your prompt reply

 

Do I need to create SRV and CNAME for that auto discover on my Internal DNS as well?

 

@hntaurus please use Exchange Management Shell to change it, not ADSIEDIT ;)

 

Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.outlook.com

 

Disable-OutlookAnywhere –Server <ServerName>

 

You only have to change/add the CNAME record in your external DNS after migration.

@Dominik Hoefling 

 

Good call I agree, I would avoid using ADSIEdit unless you absolutely have no choice.  The Exchange Shell method is absolutely the way to go.  

@Dominik Hoefling 

Thanks a lot for your time

 

I see you mentioned a command about Outlook Anyehre

DO I need to disable that one as well?

@PeterRising 

Sure, I'll do it from exchange

and I guess by doing that I should not be worried about outloook clients finding the right path to connect to O365 ?

@hntaurus 

 

Yes that should do the trick for you with internal autodiscover.  Any of the mentioned methods to alter the service connection point will work,  but it was correct to point out that ADSIEdit is the least desirable way to do it, as you can very easily mess things up in there if you don't know your way around.

best response confirmed by hntaurus (Copper Contributor)
Solution

@hntaurus Yes, you should do that as well to avoid your clients connecting to the old namespace after migration. In fact, you don't need this anymore and after your cutover, you can decommission Exchange as well.

Much appreciated , Thank you
Hi Dominik,

I have fully hybrid env with exch2010, and I just run AutoDiscoverServiceInternalUri $Null
So how do I retrieve old value?

TA

@aussupport what do you want to achieve? The old value is often your Autodiscover URL e. g. https://autodiscover.domain.tld/Autodiscover/Autodiscover.xml

@Dominik Hoefling 

 

It is not setup like that and just need to know the way of identifying the old value? We have different regions and load balancers so DNS got auotdiscover-Nz, autodisocover-aus,and autodiscover-us etc etc..

 

As

@aussupport  IMHO there is no option/cmdlet to revert the value back to the old one. It would be good for a complex environment like yours to have a look at your documentation. I don't know what you mean with different sites but maybe this helps: https://docs.microsoft.com/en-us/powershell/module/exchange/set-clientaccessserver?view=exchange-ps

 

Don't mix up the value with AutoDiscoverSiteScope you mentionend in your post.

1 best response

Accepted Solutions
best response confirmed by hntaurus (Copper Contributor)
Solution

@hntaurus Yes, you should do that as well to avoid your clients connecting to the old namespace after migration. In fact, you don't need this anymore and after your cutover, you can decommission Exchange as well.

View solution in original post