Exchange 2013 internal and external hostnames

[Yarisken]

Hallo,

Ik ben een boek aan het lezen over exchange 2013. Daar wordt beschreven dat je best voor je intern en externe hostname een aparte neemt. Wij hebben een aparte dns bij een isp en een interne bij ons. Kunnen wij niet gewoon dan dezelfde naam gebruiken voor intern en externe hostnames ?

External names for Outlook Anywhere
Choosing an external name for Outlook Anywhere is slightly trickier. The name you choose has to be externally resolvable; for that reason, the consensus seems to be that you should choose a name different from the internal hostname. A common design pattern is to use “outlook” as the internal hostname and “mail” as the external hostname, so you’d see something like this when performing a Get-OutlookAnywhere:
Get-OutlookAnywhere | select identity, *hostname
In Exchange 2010, if the internal and external hostnames are both externally resolvable, but the internal hostname isn’t actually reachable from the Internet, Outlook clients can try to connect to the internal hostname first. They’ll fail, of course, but this adds an unwanted startup delay. Exchange 2013 doesn’t have that problem, but many still consider it a best practice to have the internal hostname both unreachable and unresolvable from the external world. However, you cannot do this if you’re using a single namespace with split DNS as described in the “Using a single namespace” section earlier in this chapter.

[Wim-Bart]

Zelf werk ik gewoon met een interne en externe hostname welke identiek zijn in een split-dns configuratie. Gewoon webmail.<mijndomein>.nl. Lekker simpel en maar 1 (wildcard) certificaat nodig voor webmail en autodiscover.

[Jazzy]

Yarisken schreef op vrijdag 28 februari 2014 @ 11:56:
Exchange 2013 doesn’t have that problem, but many still consider it a best practice to have the internal hostname both unreachable and unresolvable from the external world. However, you cannot do this if you’re using a single namespace with split DNS as described in the “Using a single namespace” section earlier in this chapter.[/i]

Ik herken me niet in die best practice. Sterker nog, het advies is om altijd zo min mogelijk namespaces te gebruiken. Dat maakt de boel eenvoudiger en is goedkoper. Ik mis in bovenstaand stukje dan ook de argumentatie voor deze 'best practice'.

Microsoft zegt iets anders:
http://blogs.technet.com/...ing-in-exchange-2013.aspx

Internal vs. External Namespaces

Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces. A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.

This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of Client Access server virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.

Welk boek is dit eigenlijk?

Edit:

However, you cannot do this if you’re using a single namespace with split DNS as described in the “Using a single namespace” section earlier in this chapter

Dit klopt ook niet. Met Exchange 2013 kun je prima een andere externe namespace gebruiken voor Outlook Anywhere dan intern. Zie hetzelfde artikel:

In the event that you do not deploy a spit-brain DNS infrastructure, Exchange 2013 has introduced one improvement in this area – Outlook Anywhere now supports separate internal and external namespaces.

[ Voor 13% gewijzigd door Jazzy op 12-03-2014 15:50 ]

[Linke Loe]

De laatste regel wil volgens mij alleen maar zeggen, dat je geen "internal only" namespace kan gebruiken, als je een single namespace hanteert. Externe clients kunnen dan namelijk geen verbinding maken met je Exchange omgeving.

Ook ik hanteer overigens gewoon een single namespace 'domain.com' voor onze Exchange omgeving. Wij gebruiken echter deze omgeving voor meerdere landen. Om autodiscover in zo'n geval goed te laten werken, kun je in de externe DNS SRV-records opnemen voor '_autodiscover,_tcp.domein.nl' die verwijst naar 'autodiscover.domain.com' op poort 443. Zo kun je gewoon een wildcard certificaat voor *.domain.com installeren.

[Jazzy]

Linke Loe schreef op woensdag 12 maart 2014 @ 16:31:
De laatste regel wil volgens mij alleen maar zeggen, dat je geen "internal only" namespace kan gebruiken, als je een single namespace hanteert. Externe clients kunnen dan namelijk geen verbinding maken met je Exchange omgeving.

Volgens mij juist wel. Of je nu wel of geen ExternalURL ingevuld hebt zal Outlook toch eerst proberen te connecten naar de InternalURL waarde. Bij split-DNS en een enkele namespace kan hij die ook extern resolven en alsnog verbinding maken.

Dat andere wat je schrijft gaat over Autodiscover, dat heeft hier eigenlijk niets mee te maken.

[Yarisken]

Jazzy, ik heb het uit dit boek :

Microsoft Exchange Server 2013 Inside Out_ Mailbox and High Availability

Edit:
Dit doet me wat denken aan de .local dat MS vroeger adviseerde voor een domain op te zetten en waar ze nu ook van terug aan het komen zijn.

[ Voor 40% gewijzigd door Yarisken op 13-03-2014 12:58 ]

[ro3lie]

Staat deels los van de discussie, maar .local zou ik niet meer gebruiken.

Door de wijziging in regelgeving van certificaten zijn zulke extensies niet meer ondersteunt voor certificaten.

Zie ook: http://www.digicert.com/internal-names.htm

Ik heb in en extern juist gelijk gehouden.

[Wim-Bart]

ro3lie schreef op dinsdag 18 maart 2014 @ 21:42:
Staat deels los van de discussie, maar .local zou ik niet meer gebruiken.

Door de wijziging in regelgeving van certificaten zijn zulke extensies niet meer ondersteunt voor certificaten.

Zie ook: http://www.digicert.com/internal-names.htm

Ik heb in en extern juist gelijk gehouden.

Ik denk dat als je de kans hebt om een nieuw forrest in te richten dat het gewoonweg handig is om de publieke naam te nemen. Zo iets als kantoor.<bedrijf>.nl als AD domein en je exchange benaderbaar te maken als webmail.<bedrijf>.nl/autodiscover.<bedrijf>.nl et cetera. Dan voorkom je de november 2015 hell.

Daarnaast kan je als je ook je eigen cert service draaien als je 1 niveau hoger gaat zitten zonder last te hebben van private en publieke certificaten in 1 namespace.

[Yarisken]

ro3lie schreef op dinsdag 18 maart 2014 @ 21:42:
Staat deels los van de discussie, maar .local zou ik niet meer gebruiken.

Door de wijziging in regelgeving van certificaten zijn zulke extensies niet meer ondersteunt voor certificaten.

Zie ook: http://www.digicert.com/internal-names.htm

Ik heb in en extern juist gelijk gehouden.

Idd ik heb dat ook gedaan. Nu neem je zowel voor intern als extern hetzelfde domein.