(0) exportieren Drucken
Alle erweitern

Unterstützung für HTTP-Zugriff

 

Letztes Änderungsdatum des Themas: 2007-02-01

Unabhängig davon, ob HTTP-Anfragen von einem Browser oder einem spezialisierten Client erstellt wurden, werden Sie vom Clientcomputer zum Front-End-Server gesendet. Der Front-End-Server verwendet Active Directory, um zu ermitteln, an welchen Back-End-Server die Anfrage über Proxy weitergeleitet werden soll.

Nach Auswahl des richtigen Back-End-Servers leitet der Front-End-Server die Anfrage an den Back-End-Server weiter. Neben den speziellen Headerinformationen, in denen angegeben wird, dass die Anfrage an einen Front-End-Server weitergeleitet wurde, entspricht die Anfrage nahezu der ursprünglichen Anfrage des Clients. Vor allem bleibt der HTTP-Hostheader, der dem Namen des Front-End-Servers entspricht, an den die Anfrage gesendet wurde (d. h. der Hostname oder vollständig qualifizierte Domänenname, den der Benutzer im Browser eingegeben hat), unverändert. Der Front-End-Server kontaktiert den Back-End-Server mit dem Hostnamen des Back-End-Servers (z. B. backend1), aber im HTTP-Header der Anfrage sendet der Front-End-Server den vom Client verwendeten Hostheader, z. B. www.adatum.com. Die Hostheadereinstellungen gewährleisten, dass der richtige virtuelle Exchange-Back-End-Server die Anfrage verarbeitet. Weitere Informationen zum Konfigurieren von virtuellen Servern auf einem Back-End-Server finden Sie unter Konfigurieren eines Back-End-Servers.

Bei HTTP-Anfragen kontaktiert der Front-End-Server den Back-End-Server immer über TCP-Anschluss 80 (HTTP-Standardanschluss), unabhängig davon, ob der Client den Front-End-Server über Anschluss 80 oder 443 (SSL-Anschluss) kontaktiert hat. Dies bedeutet Folgendes:

  • Virtuelle HTTP-Server auf dem Exchange-Front-End-Server stehen nur am Anschluss 80 (HTTP) oder 443 (HTTPS) zur Verfügung.
    noteAnmerkung:
    Außer den Anschlüssen 80 und 443 können keine anderen Anschlüsse für virtuelle HTTP-Server auf Exchange-Front-End-Servern verwendet werden.
  • SSL-Verschlüsselung wird zwischen Front-End- und Back-End-Servern nie eingesetzt, obwohl der Client diese Funktion zur Kommunikation mit dem Front-End-Server verwenden sollte.
  • Virtuelle HTTP-Server, die sich von anderen Server nur durch die Anschlussnummer unterscheiden, werden in einer Front-End- und Back-End-Topologie nicht unterstützt. Wenn ein Back-End-Server über einen virtuellen HTTP-Server verfügt, der Anschluss 8080 überwacht, kann ein Client nur dann auf diesen Back-End-Server zugreifen, wenn er direkt auf diesen Back-End-Server verwiesen wird (Beispiel: http://backend1:8080/data). Ein mit dem Front-End-Server verbundener Client kann auf diese Daten nicht zugreifen.

Der Back-End-Server verarbeitet die HTTP-Anfrage vom Front-End-Server, und die Antwort wird unverändert über den Front-End-Server zurück zum Client gesendet. Der gesamte Vorgang ist für den Client, der nur mit dem Front-End-Server interagiert, nicht sichtbar. Der Client weiß nicht, wie die Anfrage intern verarbeitet wird.

Wenn Sie den Zugriff auf Postfachordern über HTTP ermöglichen möchten, müssen Sie sowohl auf den Exchange-Front-End- als auch auf den Back-End-Servern ein virtuelles Verzeichnis einrichten, dass auf die Postfächer verweist.

noteAnmerkung:
Benutzerpostfächer können nicht auf dem Front-End-Server gespeichert werden.

Beim Installieren von Exchange wird das virtuelle Verzeichnis "Exchange" auf dem virtuellen Standardserver erstellt. Dieses Verzeichnis verweist auf die SMTP-Standarddomäne der Exchange-Organisation. Beim Konfigurieren zusätzlicher virtueller Verzeichnisse auf dem Front-End-Server über den Exchange-System-Mananger können Sie den SMTP-Domänennamen auswählen. In Exchange 2000 Server SP3 und Exchange Server 2003 müssen Benutzer, die eine Verbindung zu diesem virtuellen Server herstellen, über eine E-Mail-Adresse der SMTP-Proxyadressliste ihres Active Directory-Objekts mit derselben Domäne verfügen. In Exchange Server 2003 SP1 können Benutzer die SMTP-Domäne überschreiben, indem sie im URL die SMTP-Adresse angeben (für die explizite Anmeldung) oder sich lediglich implizit anmelden. Weitere Informationen finden Sie unter "Anmelden an Outlook Web Access" weiter unten in diesem Thema.

Im Dialogfeld zur Auswahl der SMTP-Domäne stellt die Domänenliste eine Auflistung der Domänen dar, für die Empfängerrichtlinien gelten. Aus diesem Grund werden möglicherweise doppelte Einträge angezeigt. Dabei ist es unerheblich, welchen der doppelten Einträge Sie auswählen.

Wenn der Front-End-Server eine Anfrage an eine Position im Postfachspeicher erkennt (basierend auf den Einstellungen des virtuellen Servers bzw. virtuellen Verzeichnisses), kontaktiert er einen globalen Active Directory-Katalogserver in der Domäne unter Verwendung von LDAP (Lightweight Directory Access Protocol) und ermittelt, welcher Back-End-Server das Postfach des Benutzers enthält.

Benutzer können sich implizit oder explizit an Outlook Web Access anmelden.

Wenn der Front-End-Server zur Authentifizierung konfiguriert ist, können Benutzer auf ihre Postfächer zugreifen, indem Sie den Benutzernamen in der Anfrage auslassen und über ihren Browser auf das virtuelle Postfachverzeichnis verweisen. Der Standard-URL ist https://<server>/exchange/. Nach der Authentifizierung des Benutzers werden die Authentifizierungsinformationen für die Suche nach dem Postfach verwendet, das mit dem Benutzer in Active Directory und dem Back-End-Server, auf dem sich das Postfach befindet, verknüpft ist. Der URL wird mit dem Benutzernamen aktualisiert und an den richtigen Back-End-Server weitergeleitet. Dieses Verfahren wird als implizite Anmeldung bezeichnet. Die implizite Anmeldung ist bei der Anmeldung an Outlook Web Access hilfreich. Spezialisierte HTTP-Clients verwenden die implizite Anmeldung normalerweise nicht.

Exchange 2000 Server SP3 und Exchange Server 2003

Bei der impliziten Anmeldung wird die im virtuellen HTTP-Verzeichnis angegebene SMTP-Domäne verwendet, um den Benutzer zu identifizieren. Benutzer, die eine Verbindung zu diesem virtuellen Server herstellen, müssen daher in ihrer SMTP-Proxyadressliste im Active Directory-Objekt über eine E-Mail-Adresse mit derselben Domäne verfügen.

Exchange Server 2003 SP1

Die implizite Anmeldung ist nicht mehr ausschließlich von der angegebenen SMTP-Domäne abhängig. Alle Benutzerinformationen können aus der jeweiligen Anmeldung abgeleitet werden. Benutzer können beliebige virtuelle Exchange-Postfachverzeichnis für den Zugriff auf ihre E-Mail-Nachrichten verwenden.

Zum Herstellen eine Verbindung zu Outlook Web Access stehen einige wenige URLs zur Verfügung. Der Standard-URL ist https://<server>/exchange/<benutzername>/. Der Zugriff auf Outlook Web Access mit diesem URL wird als explizite Anmeldung bezeichnet.

Explizite Anmeldung ist erforderlich, wenn der Front-End-Server nicht zur Authentifizierung von Benutzern konfiguriert ist (weitere Informationen zur Authentifizierung finden Sie unter Authentifizierungsmechanismen für HTTP) oder ein Benutzer mit Zugriffsberechtigung auf ein Postfach einer anderen Person zugreift, zum Beispiel bei stellvertretenden Benutzern.

Exchange 2000 Server SP3 und Exchange Server 2003

Wenn ein Front-End-Server eine explizite Anmeldeanforderung vom Client erhält, wird der Benutzername aus dem URL extrahiert und mit dem SMTP-Domänennamen kombiniert, der mit dem virtuellen Verzeichnis oder dem virtuellen Server verknüpft ist, um eine vollständig qualifizierte SMTP-Adresse zu erhalten. Der Front-End-Server sucht diese Adresse in Active Directory und legt fest, welcher Back-End-Server über das mit dieser Adresse verknüpften Postfach verfügt. Anschließend leitet der Front-End-Server die Anfrage an den Back-End-Server weiter, der wiederum die Anfrage über den Front-End-Server an den Client zurückgibt.

Exchange Server 2003 SP1

Der Benutzer kann die im virtuellen Postfachverzeichnis konfigurierte SMTP-Domäne überschreiben, indem er die SMTP-Adresse im URL selbst angibt. Beispiel: https://<server>/exchange/username@domain.com. Wurde keine SMTP-Domäne angegeben, wird die SMTP-Domäne aus dem virtuellen Verzeichnis verwendet.

Sie können den Zugriff auf Outlook Web Access für bestimmte Benutzer verweigern, indem Sie die Verwendung des HTTP-Protokolls durch diese Benutzer nicht erlauben. Wenn Sie die Protokolleinstellungen für Active Directory-Benutzer und -Computer ändern möchten, verwenden Sie die Registerkarte Exchange - Erweitert in den Eigenschaften der Benutzer.

Häufig fragen Benutzer nach einem vereinfachten URL für den Zugriff auf ihre Postfächer. Ausführliche Anweisungen zum Vereinfachen des Outlook Web Access-URLs finden Sie unter Vereinfachen der Outlook Web Access-URL.

Wenn Sie Outlook Web Access verwenden, können Sie das Feature zum Ändern des Kennworts in IIS verwenden, um die folgenden Aktionen auszuführen:

  • Warnen von Benutzern vor dem Ablauf ihrer Kennwörter
  • Benutzern die Verwendung der Schaltfläche Optionen in Outlook Web Access zum Ändern von Kennwörtern ermöglichen.

Beachten Sie, dass Sie bei Verwendung des Features zum Ändern des Kennworts ebenfalls SSL zwischen Clients und dem Front-End-Server verwenden müssen, um das Kennwort während der Übertragung zu sichern. Weiterhin müssen Sie den virtuellen Verzeichnisnamen IISAdmPwd auf den Front-End- und Back-End-Servern erstellen, um die Anfragen zum Ändern des Kennworts zu verarbeiten.

noteAnmerkung:
SSL ist nur dann auf einem Back-End-Server erforderlich, wenn sich die Benutzer direkt mit dem Back-End-Server verbinden sollen. Erinnern Sie sich daran, dass Front-End-Server SSL nicht für Verbindungen zu Back-End-Servern verwendet werden können. Wenn Sie SSL daher auf dem Back-End-Server benötigen, überprüfen Sie, ob Sie SSL für die folgenden Verzeichnisse nicht benötigen und Front-End-Server diese nach wie vor kontaktieren können: Exchange, Public, ExchWeb, Exadmin und alle virtuellen Stammverzeichnisse für Postfächer und Öffentliche Ordner.

Weitere Informationen zum Konfigurieren des Features zur Kennwortänderung finden Sie unter Verwenden des Features "Kennwort ändern" in Outlook Web Access.

Weitere Informationen zum Konfigurieren von SSL finden Sie unter Unterstützung für sichere Kommunikation zwischen Client und Front-End Server.

Die Konfiguration von virtuellen Verzeichnissen für Postfächer entspricht derjenigen von virtuellen Verzeichnissen für alle Öffentliche Ordner-Strukturen, auf die über HTTP vom Front-End-Server aus zugegriffen werden muss.

Bei der Installation von Exchange wird das virtuelle Verzeichnis "public" auf dem virtuellen Exchange-HTTP-Standardserver erstellt, um Zugriff auf die standardmäßige (Zugriff über MAPI) Öffentliche Ordner-Struktur zu erteilen. Beim Erstellen von Öffentliche Ordner-Strukturen (zum Beispiel für Hostanwendungen) müssen Sie ebenfalls virtuelle Verzeichnisse im Exchange-System-Manager erstellen, um diese Strukturen über HTTP anzuzeigen. Auf allen Front-End- und Back-End-Servern, die die Öffentliche Ordner-Struktur hosten, müssen die virtuellen Verzeichnisse identisch sein.

Eine an einen URL in einer Öffentliche Ordner-Struktur gerichtete Anfrage wird beim Zugriff auf die standardmäßige (Zugriff über MAPI) Öffentliche Ordner-Struktur anders verarbeitet, als wenn der Zugriff auf allgemeine Ordner (auch als Anwendungen mit Hierarchien auf der obersten Ebene oder Nicht-Mapi-Hierarchien auf der obersten Ebene bezeichnet) erfolgt.

Der Zugriff auf Öffentliche Ordner hat zwei Ziele:

  • Verfügbarkeit   Wenn sich Daten in einem Öffentlichen Ordner von Exchange 2000 Server oder Exchange Server 2003 an einer beliebigen Stelle innerhalb der Exchange-Organisation befinden und der Zugriff über HTTP erfolgt, sind sie für den Benutzer verfügbar.
  • Konsistenz   So lange der Server verfügbar und der Benutzer authentifiziert ist, übernimmt derselbe Öffentliche Ordner-Server alle Anfragen von diesem Benutzer. Authentifizierten Benutzern werden immer dieselben Daten angezeigt, wenn sie auf die Öffentliche Ordner-Strukturen über den Front-End-Server zugreifen (einschließlich der Statusmeldungen über gelesene oder nicht gelesene Nachrichten, die auf einzelnen Servern gespeichert sind und zwischen den Öffentliche Ordner-Servern nicht repliziert werden). Damit ist sichergestellt, dass authentifizierte Benutzer an denselben Öffentliche Ordner-Server verwiesen werden. Die Tatsache, dass Benutzer immer denselben Bank-End-Server erreichen, ist ebenfalls für serverbasierte Anwendungen von Bedeutung, die den Sitzungsstatus beibehalten, wie zum Beispiel einige Versionen von ASP (Active Server Pages).

In Exchange können Sie die Replikation von Öffentlichen Ordnern auf einer Pro-Ordner-Basis konfigurieren. Die aktuelle Hierarchie für Öffentliche Ordner-Strukturen sind auf allen Öffentliche Ordner-Servern von Exchange in der Organisation enthalten, wogegen der jeweilige Inhalt möglicherweise nicht verfügbar ist. Diese Informationen werden nicht in Active Directory gespeichert, sondern als Ordnereigenschaft im Informationsspeicher für Öffentliche Ordner verwaltet. Eine besondere Vorgehensweise ist daher erforderlich, wenn der vom Front-End-Server ausgewählte Back-End-Server den vom Client angeforderten Inhalt des Ordners nicht enthält.

In der folgenden Abbildung wird die Weiterleitung von Verweisen auf Öffentliche Ordner über einen Front-End-Server dargestellt.

Zugriff auf Öffentliche Ordner
  1. Ein HTTP-Client authentifiziert sich am Front-End-Server und fordert /public/PublicFolder2 an.
  2. Der Front-End-Server authentifiziert den Benutzer bei Active Directory und fordert den Speicherort des standardmäßigen Informationsspeichers für Öffentliche Ordner des Benutzers an.
  3. Active Directory gibt dem Front-End-Server an, dass es sich bei dem standardmäßigen Informationsspeicher für Öffentliche Order des Benutzers um Server1 handelt.
  4. Der Front-End-Server sendet die Clientanfrage an Server1.
  5. Server1 teilt dem Front-End-Server mit, dass er nicht über den Inhalt /public/PublicFolder2 verfügt, verweist jedoch auf Server2 und Server3.
  6. Der Front-End-Server führt einen Hashalgorithmus bei den Servern mit diesem Inhalt aus (in diesem Fall Server2 und Server3). Das Ergebnis dieses Hashalgorithmus ist in diesem Fall Server2, so dass der Front-End-Server die Anfrage an Server2 weiterleitet.
    noteAnmerkung:
    Ein Hashalgorithmus wendet eine vorgegebene Zahlenfolge (in diesem Fall das Sicherheitskürzel des Benutzers) an, um eine Position auf einer Liste zu erzeugen. Sämtliche Eingaben können nun über die so erzeugte Liste verteilt werden.
  7. Server2 gibt den Inhalt /public/PublicFolder2 an den Front-Server weiter, der den Inhalt an den HTTP-Client sendet.

Wenn ein Client auf die Öffentliche Ordner-Standardstruktur in Outlook Web Access zugreift, erfolgt dies, um die Parität der MAPI-Clients, wie zum Beispiel Outlook, beizubehalten. Jeder Postfachspeicher ist mit einem bestimmten Informationsspeicher für Öffentliche Ordner an einer beliebigen Position in der Organisation verknüpft (manchmal auf demselben Server wie der Postfachspeicher, manchmal auf einem dedizierten Server für Öffentliche Ordner). Der mit dem Postfachspeicher des Benutzers verknüpfte Informationsspeicher für Öffentliche Ordner ist der Speicher, der die Öffentliche Ordner-Hierarchie (Struktur) in Outlook darstellt.

Wenn ein Benutzer einen Öffentlichen Ordner in der Öffentliche Ordner-Standardstruktur über HTTP anfordert, authentifiziert der Front-End-Server den Benutzer und sucht ihn in Active Directory, um zu ermitteln, welcher Öffentliche Speicher mit dem Postfachspeicher des Benutzers verknüpft ist. Der Front-End-Server leitet die Anfrage anschließend an den Öffentliche Ordner-Server des Benutzers weiter.

Wenn der Front-End-Server nicht zur Authentifizierung des Benutzers konfiguriert ist, findet bei Anfragen für Öffentliche Ordner kein Lastenausgleich statt.

Standardserver für Öffentliche Ordner-Strukturen sind aufgrund ihres MAPI-Ursprungs mit Postfachspeichern verknüpft. Allgemeine Öffentliche Ordner-Strukturen verfügen nicht über eine derartige Verknüpfung. Anfragen nach Ordnern in allgemeinen Öffentliche Ordner-Strukturen werden daher etwas anders als Anfragen nach Ordnern in der Öffentlichen Ordner-Standardstruktur verarbeitet.

Wenn ein Client eine Anfrage für den Zugriff auf eine allgemeine Öffentliche Ordner-Struktur stellt, kontaktiert der Front-End-Server zunächst Active Directory, um eine Liste aller Server unter Exchange 2000 Server oder Exchange Server 2003 in der Organisation abzurufen, die ein Replikat dieser speziellen allgemeinen Öffentliche Ordner-Struktur haben, auf die der Client zugreift.

noteAnmerkung:
Allgemeine Öffentliche Ordner-Strukturen sind in Exchange Server 5.5 nicht verfügbar.

Der Front-End-Server verwendet anschließend das Authentifizierungstoken in einem Hashalgorithmus für die Serverliste, um sicherzustellen, dass

  • Benutzer auf die verfügbaren Server verteilt werden.
  • einzelne Benutzeranfragen unabhängig vom verwendeten Client immer von demselben Back-End-Server verarbeitet werden.
noteAnmerkung:
Wenn Sie einen Back-End-Server hinzufügen oder löschen, ändert sich das Ergebnis des Hashalgorithmus, und Benutzer werden möglicherweise an einen anderen Server weitergeleitet. Weitere Informationen finden Sie unter "Hinzufügen oder Entfernen eines Back-End-Servers" weiter unten in diesem Thema. Beachten Sie, dass dieses Verfahren nur für MAPI gilt.

In der Front-End- und Back-End-Topologie wird ein besonderes Verfahren angewandt, wenn der Back-End-Server eine Anfrage für einen Öffentlichen Ordner erhält, für den er kein Replikat besitzt. Dieses Verfahren gilt neben Ordnern in den allgemeinen Öffentliche Ordner-Strukturen auch für Ordner im Standardinformationsspeicher für Öffentliche Ordner.

Wenn ein Back-End-Server eine solche Anfrage empfängt, gibt er eine Liste mit Servern zurück, die den Inhalt des angeforderten Ordners enthalten. Der Front-End-Server leitet diese Informationen nicht an den Client zurück, führt jedoch denselben Hashalgorithmus für die neue Serverliste erneut aus, um den Lastenausgleich und konsistente Ansichten sicherzustellen. In Organisationen mit Teilreplikaten von Öffentliche Ordner-Strukturen muss der Front-End-Server möglicherweise zwei HTTP-Anfragen verarbeiten, um eine einzelne Anfrage vom Client zu beantworten. Durch die Verarbeitung der Clientanfrage speichert der Front-End-Server jedoch Informationen darüber, welche Server über den Inhalt verfügen. Front-End-Server können daher zusätzliche Anfragen vermeiden, wenn auf denselben Ordner zukünftig zugegriffen wird.

Die vom Front-End-Server verwalteten Caches vermindern die Anzahl der an Active Directory und Back-End-Server gesendet Anfragen sowohl für öffentliche als auch für private Ordnerzugriffe erheblich. Cacheinformationen laufen nach zehn Minuten ab und werden bei Änderungen in der Serverkonfiguration neu festgelegt.

noteAnmerkung:
Exchange 5.5-Server können nicht ausgewählt werden, da sie die erforderlichen HTTP WebDAV-Erweiterungen nicht unterstützen.

Wenn ein Back-End-Server aufgrund von Wartungsmaßnahmen ausfällt oder der Zugriff über HTTP aus anderen Gründen nicht möglich ist, kann der Front-End-Server keine Verbindung zu ihm herstellen. Der Front-End-Server kennzeichnet den Server für einen Zeitraum von 10 Minuten als "nicht verfügbar" und sendet eine Anfrage an einen anderen Server, falls andere Server verfügbar sind. Die Anfrage schlägt fehl, wenn kein anderer Server vorhanden ist. Während der Back-End-Server nicht verfügbar ist, leitet der Front-End-Server die Anfragen automatisch an andere Server weiter. Wenn ein Back-End-Server wieder betriebsbereit ist, ist der Zugriff über den Front-End-Server möglicherweise für 10 Minuten blockiert, weil der Front-End-Server ihn unter Umständen immer noch als nicht verfügbar gekennzeichnet hat.

Dieser Prozess steigert die Zuverlässigkeit für den Zugriff auf Öffentliche Ordner erheblich. Der Front-End-Server kontaktiert mehrere Back-End-Server in Bezug auf die Daten, wohingegen ein Client mit einer direkten Verbindung zu einem Back-End-Server dies nicht tut.

Ziel des Hashalgorithmus ist der Lastenausgleich. Eine Bedingung dieses Algorithmus ist jedoch, dass die Verteilung von Benutzern auf die Server von der Anzahl der Server abhängt. Wenn der Liste der Server, die den Inhalt für einen Öffentlichen Ordner hostet, Server hinzugefügt oder daraus entfernt werden, wird der Benutzer durch den Hashalgorithmus möglicherweise an einen neuen Server für zukünftige Anfragen geleitet. Bis auf folgende Ausnahme kann der Benutzer während der Verarbeitung einer Anfrage durch den Server keine Mitteilung über eine physikalische Änderung erteilen:

  • Benutzer können feststellen, ob der Status "Lesen" bzw. "Nicht gelesen" von Nachrichten zurückgesetzt wurde.
  • Benutzer von webbasierten Anwendungen (die in allgemeinen Öffentlicher Ordner-Strukturen ausgeführt werden), die den Sitzungsstatus beibehalten, müssen ihre Anwendungssitzung neu starten, wenn sie die Anwendung während der Übergansphase verwenden.

Es wird daher empfohlen, dass Administratoren ihre Benutzer vor dem Hinzufügen von Ordnerinhalt zu Öffentliche Ordner-Servern bzw. vor dem Entfernen von Inhalt informieren.

Auf hohem Niveau wird der Hashalgorithmus wie folgt ausgeführt: Zwei Back-End-Server mit den Nummern 1 und 2, auf denen der Inhalt eines Öffentlichen Ordners gespeichert ist. Wenn unterschiedliche Benutzer (A, B, C, D, E und F) versuchen, auf die Daten in diesem Ordner zuzugreifen, verteilt der Front-End-Server ihre Anfragen wie folgt über die beiden Server:

  • Benutzer A, B und C erhalten ihre Daten von Server 1.
  • Benutzer D, E und F erhalten ihre Daten von Server 2.
noteAnmerkung:
Dieser Lastenausgleich ist transparent, Benutzer wissen nicht, welcher Back-End-Server die Anfrage aktuell verarbeitet.

Dann wird ein weitere Server (Server 3) hinzugefügt, und der Inhalt wird ebenfalls auf diesen Server repliziert. Die Benutzer werden anschließend wie folgt verteilt:

  • Benutzer A und B erhalten die Daten von Server 1.
  • Benutzer C un D erhalten die Daten von Server 2.
  • Benutzer E und F erhalten die Daten von Server 3.

In diesem Beispiel haben Benutzer C, E und F die Server gewechselt, Benutzer A, B und D hingegen nicht.

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft