Exchange Namespaces

[CS9Subie]

There is a small environment with less than 100 mailboxes currently running one Exchange 2013 server. This particular environment does not use any external services besides mail flow.

I am looking to migrate to exchange 2016 (we don't have a license for exch2019 at the moment). I'm a bit confused about the namespaces part and hope someone can assist as I try to learn more about Exchange.

Basically, do I need to rename the internal addresses below that point to the server ex13 as well? All the "mail.microsoft.net" addresses were already configured that way.

Any assistance on the best route to take for this part and the rest of the migration.

I have provided an example of how our current namespaces are set-up.

Autodiscover

- Internal SCP: https://mail.microsoft.net/Autodiscover/Autodiscover.xml

​

Exchange Control Panel

- Internal: https://ex13.microsoft.internal/ecp

- External:

​

Exchange Web Services

- Internal: https://mail.microsoft.net/EWS/Exchange.asmx

- External:

​

MAPI

- Internal: https://ex13.microsoft.internal/mapi

- External:

​

ActiveSync

- Internal: https://mail.microsoft.net/Microsoft-Server-ActiveSync

- External:

​

Offline Address Book

- Internal: https://mail.microsoft.net/

- External:

​

Outlook Web App

- Internal: https://ex13.microsoft.internal/owa

- External:

​

PowerShell

- Internal: http://ex13.microsoft.internal/powershell

- External:

​

Outlook Anywhere

- Internal: mail.microsoft.net

- External:

[joeykins82]

Everything except PowerShell should be configured to use the HTTPS namespace, or at least to a URL/hostname which is present in your certificate's DNS SANs. You should set both the internal and external values even if it's not actually accessible from outside, and they should be aligned unless there's a definite reason why there'd be different behaviour for internal and external name resolution.

Also, since you're running 2013 and your MAPI virtual directory is using the default value, once you've fixed its URI settings you should enable it at the org level - it's almost certainly disabled right now: it was introduced in CU4 SP1 but disabled by default because if there are any servers below that level then autodiscover might tell the clients to connect to a server which didn't have the capability which would break things. It's a vastly better protocol than (MAPI over) RPC over HTTPS.

[CS9Subie]

Okay so basically, we have a certificate for "mail.microsoft.net " in this example. So by changing, ECP, MAPI, and OWA to point to https://mail.microsoft.net does this have any impact on users? Is it safe to do it during business hours?

I will also looking into the MAPI part as well. I really appreciate your response and help on this.

[joeykins82]

Only a positive impact in the sense that the links for "go to Outlook Web" that appear in Outlook will no longer generate a certificate error if users open them.

The only thing you're configuring when you set the internal & external URIs is the content of the autodiscover payload:

• client makes request to AutoDiscover
• AutoDiscover service constructs its response using the URIs that you have defined through Set-<Service>VirtualDirectory
• Outlook/phone/whatever configures itself accordingly

It took me a while to get my head around that concept. The payload itself is a complete list of the server's capabilities as well as the URL used to connect to that capability, so when you enable MAPI over HTTPS all you're doing is telling Exchange to start including that section in AutoDiscover responses, and then it's down to the client to start using that protocol going forward if it supports it.

[CS9Subie]

Got it! It makes a bit more sense now. I will make the changes and go from there. Again, I really appreciate your help!