Autodiscover - Sonderfälle

Solange Sich ihr Client in ihrem Forest befindet und Exchange On-Premise genutzt ist, ist Autodiscover ziemlich einfach. Wie sieht AutoD aber in einem Ressource Forest-Szenario, mit Office 365 oder Hybrid-Umgebungen aus? Auch eine Migration "Cross-Forest" ist eine Herausforderung für Autodiscover-Implementationen.

Autodiscover und Shared Mailboxen / Exchange Archive

Wenn Benutzer Outlook starten, dann möchten Sie nicht nur ihre primäre Mailbox eingebunden bekommen, sondern ebenfalls ein eventuell vorhandenes Exchange Archiv und die Postfächer, auf die Sie als Stellvertreter zugreifen können.

Auch hier hilft Autodiscover, weil der Exchange Server auch diese Informationen per XML-Datei an den Client liefern kann.

Solche Konstruktionen sind manchmal aber auch Ursache, dass Autodiscover nicht funktioniert, wenn nämlich diese Einträge auf ungültige Objekte verweisen:

Autodiscover und TargetAddress

Autodiscover spielt auch eine Rolle, wenn zwei Exchange Organisationen in zwei Forests arbeiten. Per Default kann natürlich die Auflösung von "autodiscover.andere.domain" die Arbeit erledigen. Interessanter wird es aber, wenn Sie Benutzer von einer Organisation in die andere Organisation migrieren und es zwischen den Forests einen Trust gibt dann kann man nämlich in dem lokalen Forest für Outlook einen Hinweis hinterlegen, wie es die CAS-Server der anderen Organisation erreicht. Dies ist der Fall, wenn z.B. Tochterfirmen einer Holding zwar eigene Forests und Exchange Systeme betreiben aber nach Außen mit einer "Konzernadresse" auftreten sollen. Diese Konstellation finden Sie aber auch mit BPOS, wenn sie einen Teil ihrer Postfächer noch selbst betreiben und einen anderen Teil bei einem Hoster "auslagern". Und natürlich bei Migrationen in andere Forests hinein.

In beiden Fällen kann es aber nur einen Autodiscover-Eintrag geben, der auf eine "Master-" Exchange Organisation verweist. Aber auch hier gibt es von Microsoft Exchange dann den Trick, dass es in dieser Master Organisation natürlich einen Benutzer geben muss, dessen Mails aber anhand der TargetAddress in die anderen Organisation geleitet werden. Genau diese "Weiterleitungsadresse" hilft nun auch bei Autodiscover, da der CAS-Server den Client an diese Domäne verweist.

Und auch hier gibt es einmal den DNS-Weg, d.h. die Weiterleitung auf eine andere Domain, für die ebenfalls "Autodiscover" korrekt eingerichtet ist. Speziell bei Migrationen innerhalb einer Firma oder zwischen vertrauten Domains, gibt es aber auch noch den Weg, im Active Directory einen Hinweis zu hinterlegen.

Ein so genannter "ServiceConnectionPoint" an oberster Ebene in der Configuration Partition kann den Client als auch die CAS-Server auf dir richtige Spur bringen.

dn: CN=msxfaq.de,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=netatwork,DC=de
changetype: add
objectClass: top
objectClass: leaf
objectClass: connectionPoint
objectClass: serviceConnectionPoint
cn: msxfaq.de
distinguishedName: CN=msxfaq.de,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=netatwork,DC=de
name: msxfaq.de
keywords: 67661D7F-8FC4-4fa7-BFAC-E1D7794C1F68
serviceBindingInformation: LDAP://msxfaq.de
objectCategory: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=netatwork,DC=de

dn: CN=lyncme.de,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=netatwork,DC=de
changetype: add
objectClass: top
objectClass: leaf
objectClass: connectionPoint
objectClass: serviceConnectionPoint
cn: lyncme.de
distinguishedName: CN=lyncme.de,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=netatwork,DC=de
name: lyncme.de
keywords: 77378F46-2C66-4aa9-A6A6-3E7A48B19596
serviceBindingInformation: https://cas.lyncme.de
objectCategory: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=netatwork,DC=de

Natürlich müssen Sie diese Einträge nicht von Hand anlegen. Ein Exchange 2010 PowerShell-Commandlet kopiert ihnen die Einträge aus einer Quelle direkt in das Ziel.

$cred= Get-Credential

Export-AutoDiscoverConfig
-DomainController dc1.source.tld 
-TargetForestDomainController dc2.target.tld
-TargetForestCredential $cred 
-MultipleExchangeDeployments $true
-verbose

Dieser Befehl legt im Ziel dann einen Service Connection Point an. Wie sie im obigen Bild sehen können, ist der Eintrag für "Microsoft Exchange Online" in jeder Exchange 2010 Installation sogar schon vordefiniert. Per Default überträgt der Befehl aber den Namen des Forests. Stimmt die primäre SMTP-Domain des Mitarbeiters aber nicht mit dem AD-Forestnamen überein, dann müssen Sie zusätzlich den "PreferredSourceFqdn" mit angeben.

Wenn sie zudem noch die Option "MultipleExchangeDeployments" verwenden, dann überträgt das Commandlet auch noch alle autoritativen Domains der Quelle und legt diese im Ziel im Feld "Keyword" mit an. Da eine Domain immer nur in einer Organisation "Autoritativ" sein sollte, wird damit eine durchgängige Auflösung erreicht.

Präferenz
Interessant ist, dass eine Anfrage eines Clients nach seiner Mailadresse von Outlook per LDAP immer erst der passende SCP heran gezogen wird, d.h. ein LDAP-Eintrag für einen anderen Forest, der zu einer Mailadresse passt, bringt Outlook dazu direkt den anderen Forest zu fragen und nicht erst die lokalen Autodiscover-Dienste zu kontaktieren, die dann z.B. per "TargetAddress" eine Umleitung zurückgeben könnten. Es sollte also nur ein Forest "Autoritativ" für eine Domain sein, damit notfalls der remote Forest die user wieder zurück senden kann, wenn das Postfach doch noch lokal wäre.

When you make a query für free or für busy information in a multiple forest scenario, the Autodiscover URL from the external forest entry is used instead of the Autodiscover URL from the local forest entry
Quelle: 973404 Description of the Outlook 2007 hotfix package (Outlook-x-none.msp): August 25, 2009

Dies ist auch interessant, wenn Sie Benutzer und Postfächer migrieren und über das Feld TargetAddress die Mails von einem Forest in den anderen umleiten. Der Inhalt dieses Feldes hat auch Auswirkungen auf die Funktion von Autodiscover für dieses Postfach. Fragt ein Benutzer nämlich seinen CAS-Server im Forest an, dann prüft dieser im AD nicht nur, wo sein HomeServer und CAS-Zugang ist, sondern auch, ob das Feld TargetAddress gefüllt ist. Ist dieses Feld gefüllt, dann schaut der CAS nämlich in diesen Autodiscover-Verweisen nach und lenkt den Client zur anderen Organisation.

Hinweis:
Die Funktion von Autodiscover wurde auch mit nachfolgenden Servicepacks und besonders auch Hotfixes immer weiter verbessert. Bei Problemen ist ein Update daher erst einmal zu prüfen

Autodiscover mit vielen Domains bzw. Cloud Szenarien

Wer nur eine Maildomäne betreibt, der kann in sein Zertifikat auch einfach noch "autodiscover.<maildomain>" hinterlegen und den "einfachen" Weg nutzen. Aber wer als internationale Firma mehrere SMTP-Domains betreibt, muss sich was anderes überlegen. Es ist nicht ganz einfach (und billig) in einem SAN-Namen für jede Domain einen Autodiscover-Eintrag zu addieren. Die Liste kann nicht endlos lang sein.

Auch Provider wie z.B. Office 365 haben ein Problem mit einer solchen Konfiguration, da Sie ja für jeden neuen Kunden .bzw. neue SMTP-Domain ihre Zertifikate austauschen müssen. Hier sind also andere Lösungen gefragt. Sie sollten mittlerweile ja die verschiedenen Möglichkeiten am Anfang dieses Artikels gelesen und verstanden haben, dass Sie den passenden Weg für sich einrichten können. Nicht alle Clients benötigen auch zwingend Autodiscover, speziell wenn Sie keine EWS/OAB-Dienste nutzen, z.B. OWA, ActiveSync.

Anbieter Clients Option Beschreibung

Hoster

Standalone PCs

Lokale XML

Für Hoster ist dies der eleganteste Weg über eine kleine Softwarelösung auf den Client des Kunden die erforderliche XML-Datei und Registry-Keys zu hinterlegen, dass der Kunde beim Zugriff auf seine Domain den Servernamen in den Zertifikaten des Hosters vertraut. So verteilt z.B. Microsoft über den Office 365 Client Assistent, den Sie auf jedem PC einmal aufrufen

Hoster

Andere Clients

Manuell

Manuelle Konfiguration ohne Autodiscover
Anleitung auf dem "Mobile Phone Setup wizard"
http://go.microsoft.com/fwlink/?linkid=235512
http://help.outlook.com/en-us/140/dd936215.aspx

Firma

Standalone Clients

HTTP redirect
XML verteilen

Wenn Sie als Firma den Zugriff von "nicht domain joined" Systemen zulassen wollen, dann müssen die Anwender entweder per HTTP-Redirect einmal die Warnung bestätigen oder Sie verteilen ein Tool wie bei Office365,welches lokal ein paar Einstellungen vornimmt. Der Einsatz von GPOs scheidet leider aus.
Generell sollten Sie aber genau prüfen, ob sie fremden Client einen Zugriff per Outlook erlauben wollen. Sie haben keine Kontrolle über Virenschutz, Kennwortrichtlinien , Verschlüsselung und eine lokale ungeschützte OST-Datei ist ein gefundenes Fressen für Datenspione. Es soll schon Fälle gegeben haben, bei denen in der Wohnung von Führungskräften nur der private Notebook geklaut wurde.
OWA ist hier vielleicht die bessere, weil sicherere, Lösung.

Firma

Domain Clients

GPO Konfiguration mit XML-Datei

Wenn die Client hingegen Mitglied der Domäne sind, dann ist es für den Administrator relativ einfach, die erforderlichen Einstellungen per Gruppenrichtlinie zu verteilen, um eine Anmeldung der Client mit einem einfachen Zertifikat zu erreichen. Man addiert einfach die Domänen mit den passenden ServerURLs, die sich dann natürlich selten ändern sollten, auf dem Client.

Firma

Domain Clients

Direct Access / VPN

Wenn Sie den Zugriff mit Outlook zum Abgleich über Direct Access oder andere VPNs erlauben, dann können Sie diese als intern ansehen und nutzen die Abfrage des Service Connection Point per LDAP

Weitere Links