Veröffentlichung des Originalartikels: 20.02.2012

In unserer kürzlichen Ankündigung der Freigabe von Updaterollup 1 für Exchange 2010 Service Pack 2 werden Sie sehen, dass wir eine Menge von Fixes freigegeben haben. Ich möchte hier insbesondere einen davon behandeln und vielleicht ein paar Hintergrundinformationen liefern, wie solche Probleme entstehen und wie wir sie beheben.

Der spezielle Fix wird treffenderweise als 2556113 mit dem Titel Lange Downloadzeit beim Benutzerdownload eines Offlineadressbuchs in einer Exchange Server 2010-Organisation bezeichnet.

Bei diesem Titel denken Sie vielleicht, dass wir eine Möglichkeit gefunden haben, Downloads des Offlineadressbuchs (OAB) „schneller“ zu machen. Sie meinen möglicherweise, wir haben einfach beliebige Benutzer im OAB gelöscht, die Sie nicht kennen, z. B. die Leute in der Buchhaltung im vierten Stock. Oder wir haben versucht, die Details im OAB zu reduzieren, indem wir unnötige Informationen wie Familiennamen, Standort des Büros oder Telefonnummern gelöscht haben. Oder wir haben einfach die Geschwindigkeit des Internet erhöht. Denn das ist wirklich einfach.

Nun, all das haben wir nicht gemacht (obwohl wir immer auf der Suche nach Verbesserungsmöglichkeiten für das Internet sind). Stattdessen haben wir Logik hinzugefügt, die sicherstellt, dass Outlook versucht das OAB vom nächstgelegenen Clientzugriffsserver (CAS) herunterzuladen.

Sie fragen, warum? Nun, das ist eine gute Frage, und ich antworte: „Wie der KB-Artikel besagt, 'Betrachten Sie das folgende Szenario….“

  • Sie verwenden zwei Active Directory-Standorte (AD) in einem langsamen Netzwerk in einer Microsoft Exchange Server 2010-Organisation.
  • Sie verfügen am einen Active Directory-Standort über einen Exchange Server 2010-Clientzugriffsserver und einen Exchange Server 2010-Postfachserver.
  • Sie verfügen am anderen Active Directory-Standort über einen Exchange Server 2010-Clientzugriffsserver und fügen einen Office Outlook-Benutzer hinzu.
  • Der Benutzer, dessen Postfach sich am anderen Active Directory-Standort befindet, versucht das Exchange-Offlineadressbuch (OAB) herunterzuladen.

In diesem Szenario dauert es lange, das OAB herunterzuladen.

Keine Frage, das kann vorkommen. Bei einem großen OAB kann es wirklich sehr, sehr lange dauern. Aber lassen Sie uns das Szenario etwas erweitern, da es etwas gibt, das Sie wissen sollten. Und ein AD-Standort mit nichts anderem als einem CAS scheint für die meisten Benutzer keine besonders kluge Wahl zu sein.

Betrachten Sie daher das folgende detailliertere Szenario:

  • Sie verwenden eine zentralisierte Bereitstellung. Alle Postfächer befinden sich an einem zentralen Standort.
  • Sie haben eine Menge kleiner Standorte, an denen Personen arbeiten.
  • Diese Standorte sind mit dem zentralen Standort über leistungsschwache Netzwerke verbunden: Satellit, ISDN, PSTN, Troposcatter(Ich hatte einmal einen Kunden mit einer solchen Verbindung. Großartig – bis ein Sturm kam...), nasses Stück Schnur usw.
  • Das OAB ist groß. Sehr groß. Nicht gerade klein. Suchen Sie sich die Bezeichnung aus, die Ihnen am besten gefällt. Sagen wir, es ist so groß, dass Sie sich darum Sorgen machen müssen.
  • Der Outlook-Client versucht das OAB herunterzuladen, und es kommt aus dem zentralen Datencenter. Dies gilt auch für den Outlook-Client, der von der Person neben Ihnen und von dem lustigen Typen in der Ecke verwendet wird. Sie alle laden dasselbe OAB herunter. Über dieselbe schlechte Verbindung. Es dauert sehr lange.

Mit etwas Glück bemerken Sie, dass Sie alle um dieselbe Bandbreite konkurrieren, während Sie außerdem arbeiten möchten, und auch wenn die für OAB-Downloads verwendete BITS-Clienttechnologie gut ist, wird sie Ihnen nicht wirklich helfen.

Daher fügen Sie an jedem Remotestandort einen CAS hinzu. So wie es im Diagramm in http://technet.microsoft.com/en-us/library/bb232155.aspx vorgeschlagen wird. Die Idee ist, dass der Clientcomputer das benötigte OAB vom lokalen CAS herunterlädt. Klingt gut – aber so hat Exchange noch nie funktioniert. Vor 2010 SP2 RU1…

Wie hat es dann funktioniert? Und warum erzähle ich Ihnen, dass TechNet falsche Angaben enthält?

Um die erste Frage zu beantworten: Die URL, von der der Client das OAB herunterlädt, wird dem Client vom AutoErmittlungsdienst mitgeteilt. Und im AutoErmittlungscode wird immer eine URL für das OAB ausgewählt, das Sie von dem AD-Standort herunterladen sollen, an dem sich Ihr Postfach befindet, nicht von dem AD-Standort, an dem sich Ihr Clientcomputer befindet.

Um die zweite Frage zu beantworten, müssen Sie zunächst wissen, dass TechNet nie irrt (meine Freunde in UE, wie Scott Schnoll, sind sehr empfindlich, wenn der Inhalt ihrer Artikel angezweifelt wird). Manchmal treffen die Informationen einfach unter einem bestimmten Gesichtspunkt nicht zu. In TechNet ist dies angegeben, weil es Teil der ursprünglichen PM-Spezifikation war, als 2007 entwickelt wurde. Vielleicht hätte ich Ihnen das nicht mitteilen dürfen, aber so war es nun mal. Und es wurde nicht gemacht. Solche Dinge passieren in einem Softwareprodukt mit mehr als 20 Millionen Codezeilen, wenn die Mitarbeiter ständig wechseln. TechNet lügt normalerweise nicht. Jedenfalls nicht sehr.

Zurück zur Funktionsweise. Denken Sie einen Moment darüber nach. Sie haben ein OAB mit 1 GB. Und Sie fügen ein Replikat des OAB auf einem CAS am weit entfernten Remote-AD-Standort hinzu, an dem sich die Benutzer befinden. Aber sie benutzen es nie. (Ok, es sei dann, ihre Postfächer sind ebenfalls am gleichen AD-Standort, aber so ist das Szenario nicht, stimmt's?). So funktioniert es nicht. Doch, höre ich Sie sagen. Es sieht ungefähr wie dieses Diagramm aus.

Bild

Outlook verwendet für die AutoErmittlungsanforderungen des Clients den CAS, der dem Clientcomputer am nächsten ist (das sollte es jedenfalls, und wir kommen gleich darauf zurück), aber die zurückgegebene OAB-URL ist die des CAS an dem AD-Standort, an dem sich das Postfach befindet. Auch wenn wir das OAB an den AD-Standort B replizieren, ruft der Client also das OAB vom AD-Standort A ab.

Ein großer Kunde mit vielen kleinen Standorten und einem riesigen OAB sagt uns, dass das nicht funktionieren wird und Downloads jede verfügbare WAN-Bandbreite auffressen. Was können wir tun? Es gibt ein paar Lösungsmöglichkeiten, und ich muss sagen, dass es eine der lästigen Aufgaben meines Jobs ist, solche Dinge herauszufinden.

  1. Sie könnten die Größe des OAB reduzieren, ihr WAN beschleunigen, die Remotebüros näher zusammenlegen usw. Alles keine schnellen Lösungen. Obwohl wir gefragt haben.
  2. Wir könnten zahlreiche OAB mit demselben Inhalt erstellen. Und für jeden Benutzer oder jede Datenbank angeben, welches OAB der Benutzer herunterladen sollte. Und dann haben wir nur dieses OAB an dem Remotestandort verfügbar. Daher liefert die AutoErmittlung die einzig mögliche URL dafür, nämlich die des Remotestandorts. Das klingt gut, außer wenn Benutzer den Standort wechseln. Ein Download würde dann einen doppelt so langsamen Netzwerkhop bedeuten. Autsch. Streichen Sie das.
  3. Dasselbe gilt für Postfächer – verschieben Sie die Postfächer an die Remotestandorte… nun, Benutzer wechseln oft den Standort, und das würde die Verwaltung und die hohe Verfügbarkeit komplizieren und somit die Kosten erhöhen.
  4. Wir könnten eine Art umgekehrte Zuordnung von IP-Adressen zu AD-Standorten vornehmen. Ich glaube, so sollte das Problem ursprünglich gelöst werden, und es ist ziemlich kompliziert. Denn Sie müssen sicherstellen, dass alle Subnetze, aus denen ein Client stammen könnte, in AD-Standorte und -Dienste vorhanden sind, dann versuchen den AD-Standort des Benutzers zurückzuentwickeln, schließlich die Standortverbindungskosten beachten und …Ich hoffe, Sie verstehen, worauf ich hinaus will. Es ist komplex und scheitert an NAT oder wenn der Admin nicht jedes mögliche Subnetz in AD-Standorte und -Diensteaufgelistet hat.
  5. Wir könnten DNS oder die AutoErmittlungs-XML beeinflussen, sodass der Client meint mit dem zentralen Standort zu kommunizieren, aber tatsächlich mit einer lokalen IIS-Instanz kommuniziert. Auch das ist schwierig, kompliziert zu implementieren und zu unterstützen und einfach hässlich, wenn Sie mich fragen.
  6. Etwas anderes. Ich habe diese Alternative herausgesucht, da die anderen wirklich schwierig erschienen.

Gehen wir gedanklich ein paar Absätze zurück zu dem Satz „Outlook verwendet für die AutoErmittlungsanforderungen des Clients den CAS, der dem Clientcomputer am nächsten ist“ (ich sagte, ich würde darauf zurückkommen). Er ist es wert, darauf zurückzukommen, und zwar wegen einer Sache, die als AutoDiscoverServiceSiteScope bezeichnet wird.

AutoDiscoverServiceSiteScope ist eine CAS-Einstellung, die dem Outlook-Client bei der Zuordnung von AD-Standorten zu CAS hilft, um den dem Client nächstgelegenen CAS für AutoErmittlungsanforderungen zu finden. Hierzu werden Dienstverbindungspunkte (Service Connection Points, SCP) gesucht, die eigentlich Zeiger auf den AutoErmittlungsdienst sind.

Das funktioniert so: Wenn ein Outlook-Client gestartet wird, steuert er auf das Dreieck zu, das manchmal als AD bezeichnet wird, und sucht alle SCP, die vom Exchange-Setup dort eingerichtet wurden. Er findet (hoffentlich) einige, und jeder verfügt über ein Keywords-Attribut, das durch die Verwendung von Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB usw. festgelegt/geändert/manchmal durcheinander gebracht wird. Im Keywords-Attribut wird angegeben, für welche AD-Standorte dieser CAS für AutoErmittlungsanforderungen verantwortlich ist.

Findet der Outlook-Client mehrere SCP, erstellt er eine Liste verwendbarer SCP, indem er den Wert im Keywords-Attribut mit seinem eigenen AD-Standort vergleicht (der vom lokalen Anmeldedienst beim Start oder einer Änderung der IP-Adresse dynamisch aktualisiert wird).

Dann erstellt er eine Liste. Sie umfasst entweder alle SCP, die mit seinem AD-Standort übereinstimmen (mit Keywords-Attribut = AD-Standort des Clients) oder, wenn keine Übereinstimmungen vorhanden sind, werden alle SCP in die Liste aufgenommen. Dies sind die Server, die er für seine AutoErmittlungsanforderungen verwenden kann.

Anschließend beginnt er oben in der Liste (die übrigens immer nach Installationsdatum sortiert ist) und versucht eine Verbindung mit dem URI im ServiceBindingInformation-Attribut herzustellen – dem Standort des AutoErmittlungsdiensts selbst. Dann stellt er XML bereit, erhält eine Antwort usw., und lebt danach für immer glücklich weiter. Weitere Details zum spannenden Thema AutoErmittlung finden Sie hier.

Warum ist dies interessant? Nun, diese AutoDiscoverServiceSiteScope-Einstellung hilft Outlook den dem Clientstandort nächstgelegenen CAS zu finden, vorausgesetzt, der Admin hat die Standortbereiche richtig eingerichtet (und wir teilen ihnen mit, wie man das macht). Daher müssen wir nicht wirklich herausfinden, welcher CAS dem Client am nächsten ist, wenn wir die Anforderung erhalten, da dies bereits geschehen ist, als die Anforderung den CAS erreicht hat.

Wenn die Anforderung den CAS erreicht, ermitteln wir die Einstellungen für die Rückgabe an den Client – aber dann vergessen wir immer eines – dass das vom Benutzer benötigte OAB lokal zum CAS sein könnte, auf dem wir die Anforderung ausführen. Stattdessen gaben wir dem Benutzer immer eine URL von einem weit entfernen CAS zurück. Und das musste korrigiert werden.

Die Lösung ist theoretisch ganz einfach. Wir müssen keine neue Möglichkeit erfinden, um den nächstgelegenen CAS für den Client zu ermitteln, da wir bereits eine haben, die sehr gut funktioniert.

Wenn wir annehmen, dass der Admin AutoDiscoverServiceSiteScope richtig eingerichtet hat, ist der CAS, mit dem der Client für die AutoErmittlung eine Verbindung herstellt, der dem Client am nächsten gelegene CAS. Unter dieser Voraussetzung muss der CAS, wenn er die zurückzugebende AutoErmittlungs-XML bestimmt, nur überprüfen, ob er selbst eine Kopie des OAB besitzt, die der Benutzer verwenden sollte – und wenn ja, stellt er einfach seine eigene OAB-URL bereit. Nicht die für einen CAS am AD-Standort, an dem sich das Postfach des Benutzers befindet. Wenn er über keine Kopie des vom Benutzer benötigten OAB verfügt, sollte natürlich das alte Verhalten gelten, das heißt, der CAS gibt die OAB-URL eines CAS am AD-Standort des Postfachs zurück.

Damit ändert sich das Bild folgendermaßen:

image

Nun, dies ist wesentlich WAN-freundlicher, oder? Eine Kopie wird über das WAN repliziert, und alle Clients an diesem Standort erhalten nun das OAB von ihrem lokalen CAS.

Was müssen Sie tun, um dieses neue Verhalten zu aktivieren? Nur zwei Dinge. Stellen Sie SP2 RU1 auf dem CAS bereit, und stellen Sie sicher, dass die AutoDiscoverServiceSiteScope-Parameter korrekt eingerichtet sind.

Ich hoffe, Sie finden dies nützlich. Möge Ihr WAN für immer eine Long Fat Pipe (Verbindung über große Entfernung mit hoher Bandbreite) sein.

Greg Taylor
Principal Program Manager
Exchange Customer Experience

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter It Takes a Long Time…