Verwalten von Affinität zwischen einer Gruppe von Abonnements und dem Postfachserver in Exchange
Erfahren Sie mehr über die Aufrechterhaltung der Affinität zwischen einer Gruppe von Abonnements und dem Postfachserver.
Affinität ist die Zuordnung einer Sequenz von Anforderungs- und Antwortnachrichten zu einem bestimmten Postfachserver. Für die meisten Funktionen in Exchange wird die Affinität vom Server verarbeitet. Benachrichtigungen sind jedoch eine Ausnahme. Der Client ist für die Aufrechterhaltung der Affinität zum Postfachserver für Benachrichtigungsabonnements verantwortlich. Diese Affinität ermöglicht es dem Lastenausgleich und den Clientzugriffsservern zwischen dem Client und dem Server, Benachrichtigungsabonnements und zugehörige Anforderungen an den Postfachserver weiterzuleiten, der das Abonnement verwaltet. Ohne Affinität wird die Anforderung möglicherweise an einen anderen Postfachserver weitergeleitet, der nicht die Abonnements des Clients enthält, was dazu führen kann, dass ein ErrorSubscriptionNotFound-Fehler zurückgegeben wird.
Wie wird die Affinität aufrechterhalten?
Affinität in Exchange basiert auf Cookies. Der Client löst die Erstellung des Cookies aus, indem er bestimmte Header in die Abonnementanforderung einschließt, und dann enthält die Abonnementantwort das Cookie. Der Client sendet dieses Cookie dann in nachfolgenden Anforderungen, um sicherzustellen, dass die Anforderung an den richtigen Postfachserver weitergeleitet wird.
Genauer gesagt wird die Affinität in Exchange wie folgt behandelt:
X-AnchorMailbox : Ein HTTP-Header, der in der anfänglichen Abonnementanforderung enthalten ist. Es identifiziert das erste Postfach in einer Gruppe von Postfächern, die die Affinität mit demselben Postfachserver teilen.
X-PreferServerAffinity – Ein HTTP-Header, der in der anfänglichen Abonnementanforderung mit dem X-AnchorMailbox-Header enthalten ist und auf true festgelegt ist, um anzugeben, dass der Client die Beibehaltung der Affinität mit dem Postfachserver anfordert.
X-BackEndOverrideCookie : Ein Cookie, das in der ursprünglichen Abonnementantwort enthalten ist und ein Cookie enthält, das der Lastenausgleich und der Clientzugriffsserver verwenden, um nachfolgende Anforderungen an denselben Postfachserver weiterzuleiten.
Gewusst wie die Affinität mithilfe der verwalteten EWS-API oder EWS aufrechterhalten?
Sie können dieselben Schritte ausführen, um die Affinität für mehrere Postfachabonnements und deren Postfachserver aufrechtzuerhalten, unabhängig davon, ob Sie Streaming-, Pull- oder Pushbenachrichtigungen verwenden, und unabhängig davon, ob Sie einen lokalen Exchange-Server oder Exchange Online als Ziel verwenden.
Rufen Sie für jedes Postfach AutoErmittlung auf, und rufen Sie die Benutzereinstellungen GroupingInformation und ExternalEwsUrl ab. Für SOAP AutoErmittlung verwenden Sie das Setting-Element und für POX AutoErmittlung das GroupingInformation-Element .
Mithilfe der Einstellungen GroupingInformation und ExternalEwsUrl aus den AutoErmittlungsantworten platzieren Sie Postfächer mit demselben verketteten ExternalEwsUrl- und GroupingInformation-Wert in derselben Gruppe. Wenn Gruppen über mehr als 200 Postfächer verfügen, teilen Sie die Gruppen weiter auf, sodass jede Gruppe nicht mehr als 200 Postfächer hat.
Erstellen Sie ein ExchangeService-Objekt , und verwenden Sie es für den Rest der Prozedur. Wenn Sie dasselbe ExchangeService-Objekt verwenden, werden Cookies und Header (wenn sie festgelegt sind) automatisch verwaltet. Beachten Sie, dass Sie ein anderes ExchangeService-Objekt für jeden Benutzer erstellen können, wenn Sie nicht beabsichtigen, Streamingabonnements in einer einzigen Verbindung zu gruppieren.
Senden Sie eine Abonnementanforderung für den Benutzer, dessen Benutzername zuerst angezeigt wird, wenn alle Benutzer in der Gruppe alphabetisch sortiert sind (wir bezeichnen diesen Benutzer als Ankerpostfachbenutzer). Gehen Sie wie folgt vor:
Fügen Sie den X-AnchorMailbox-Header mit einem Wert ein, der auf die SMTP-Adresse des Ankerpostfachbenutzers festgelegt ist.
Schließen Sie den X-PreferServerAffinity-Header mit einem wert ein, der auf true festgelegt ist.
Verwenden Sie die ApplicationImpersonation-Rolle (den ExchangeImpersonation-Typ ).
Rufen Sie in der Abonnementantwort den X-BackEndOverrideCookie-Wert ab. Fügen Sie diesen Wert in jede der nachfolgenden Abonnementanforderungen für Benutzer in dieser Gruppe ein.
Senden Sie für jeden zusätzlichen Benutzer in der Gruppe eine Abonnementanforderung, und führen Sie die folgenden Schritte aus:
Fügen Sie den X-AnchorMailbox-Header mit einem Wert ein, der auf die SMTP-Adresse des Ankerpostfachbenutzers für die Gruppe festgelegt ist.
Schließen Sie den X-PreferServerAffinity-Header mit einem wert ein, der auf true festgelegt ist.
Schließen Sie das X-BackEndOverrideCookie ein, das in der Abonnementantwort des Ankerpostfachbenutzers zurückgegeben wurde.
Verwenden Sie die ApplicationImpersonation-Rolle (den ExchangeImpersonation-Typ ).
Beachten Sie, dass der Server die Werte X-PreferServerAffinity und X-BackendOverrideCookie zusammen verwendet, um das Routing an den Postfachserver durchzuführen. Der X-AnchorMailbox-Header ist ebenfalls erforderlich, wird aber vom Server ignoriert, wenn die anderen beiden Werte gültig sind. Wenn sich X-AnchorMailbox und X-PreferServerAffinity in einer Anforderung befinden und X-BackendOverrideCookie nicht enthalten ist, wird der X-AnchorMailbox-Wert verwendet, um die Anforderungen weiterzuleiten.
Da die Werte "X-PreferServerAffinity" und "X-BackendOverrideCookie" das Routing ausführen, ändert sich die Logik nicht, da X-BackendOverrideCookie die Anforderung an den richtigen Server für die Gruppe weiterleite.
- Senden Sie eine einzelne GetStreamingEvents - oder GetEvents-Anforderung für die Gruppe, und führen Sie die folgenden Schritte aus:
Schließen Sie die SubscriptionId-Werte ein, die in den einzelnen Abonnementantworten für Postfächer in der Gruppe zurückgegeben werden.
Wenn mehr als 200 Abonnements für die Gruppe vorhanden sind, erstellen Sie mehrere Anforderungen. Die maximale Anzahl von SubscriptionId-Werten , die in eine Anforderung eingeschlossen werden sollen, beträgt 200.
Wenn Sie mehr Verbindungen benötigen, als für das Zielpostfach verfügbar sind, verwenden Sie das Dienstkonto, um die Identität des Ankerpostfachs für die Gruppe anzugeben. verwenden Sie andernfalls keinen Identitätswechsel. Im Idealfall möchten Sie per GetStreamingEvents - oder GetEvents-Anforderung die Identität eines eindeutigen Postfachs annehmen, damit sie nie auf Drosselungsgrenzwerte stoßen.
Verwenden Sie ApplicationImpersonation, wenn Sie mehr Verbindungen benötigen, als für das Zielpostfach verfügbar sind. verwenden Sie andernfalls applicationImpersonation nicht.
Schließen Sie den X-PreferServerAffinity-Header ein, und legen Sie ihn auf true fest. Dieser Wert wird automatisch eingeschlossen, wenn Sie das ExchangeService-Objekt verwenden, das Sie in Schritt 2 erstellt haben.
Schließen Sie das X-BackEndOverrideCookie für die Gruppe ein (das X-BackEndOverrideCookie, das in der Abonnementantwort des Ankerpostfachbenutzers zurückgegeben wurde). Dieser Wert wird automatisch eingeschlossen, wenn Sie das ExchangeService-Objekt verwenden, das Sie in Schritt 2 erstellt haben.
- Übergeben Sie die zurückgegebenen Ereignisse zur Verarbeitung an einen separaten Thread.
Welche Drosselungswerte muss ich berücksichtigen?
Beim Planen der Benachrichtigungsimplementierung sollten Sie zwei Werte berücksichtigen: die Anzahl der Verbindungen und die Anzahl der Abonnements. In der folgenden Tabelle sind die Standardwerte für jede Einschränkungseinstellung und die Verwendung der Einstellungen aufgeführt. Für jeden Wert wird das Budget dem Zielpostfach zugeordnet. Aus diesem Grund ist der Identitätswechsel zum Herstellen zusätzlicher Verbindungen in vielen Szenarien ein erforderlicher Schritt.
Tabelle 1. Standardeinschränkungswerte
| Betrachtungsgebiet | Einschränkungseinstellung | Standardwert | Beschreibung |
|---|---|---|---|
| Streamingverbindungen |
Standardgrenzwert für hängende Verbindungen |
10 für Exchange Online 3 für Exchange 2013 |
Die maximale Anzahl gleichzeitiger Streamingverbindungen, die ein Konto gleichzeitig auf dem Server geöffnet haben kann. Um innerhalb dieses Grenzwerts zu arbeiten, verwenden Sie ein Dienstkonto mit der ApplicationImpersonation-Rolle, die für die Zielpostfächer zugewiesen ist, und geben Sie beim Abrufen gestreamter Ereignisse die Identität des ersten Benutzers in jeder Abonnement-ID-Gruppe an. |
| Pull- oder Pushverbindungen |
EWSMaxConcurrency |
27 |
Die maximale Anzahl gleichzeitiger Pull- oder Pushverbindungen (Anforderungen, die empfangen, aber noch nicht beantwortet wurden), die ein Konto gleichzeitig auf dem Server geöffnet haben kann. |
| Abonnements |
EWSMaxSubscriptions |
20 für Exchange Online 5000 für Exchange 2013 |
Die maximale Anzahl nicht abgelaufener Abonnements, die ein Konto gleichzeitig haben kann. Dieser Wert wird verringert, wenn das Abonnement auf dem Server erstellt wird. |
Das folgende Beispiel zeigt, wie Budgets zwischen jedem Zielpostfach und dem Dienstkonto behandelt werden, dem die ApplicationImpersonation-Rolle für die Zielpostfächer zugewiesen ist.
ServiceAccount1 (sa1) imitiert die Identität vieler Benutzer (m1, m2, m3 usw.) und erstellt Abonnements für jedes Postfach. Beachten Sie, dass beim Erstellen der Abonnements der Abonnementbesitzer sa1 ist. Wenn sa1 also eine Verbindung mit den Abonnements öffnet, erzwingt EWS, dass die Abonnements im Besitz von sa1 sind.
Sa1 kann die Verbindung wie folgt öffnen:
Ohne Identitätswechsel, sodass die Verbindung gegen sa1 berechnet wird.
Indem Sie die Identität eines Benutzers annehmen – z. B. m1 –, sodass die Verbindung mit einer Kopie des Budgets von m1 belastet wird. (M1 selbst kann zehn Verbindungen mithilfe von Exchange Online öffnen, und alle Dienstkonten, die die Identität von m1 annehmen, können mithilfe des kopierten Budgets zehn Verbindungen öffnen.)
Wenn das Verbindungslimit erreicht wird, stehen die folgenden Problemumgehungen zur Verfügung:
Wenn Option 1 verwendet wird, kann der Administrator mehrere Dienstkonten erstellen, um die Identität zusätzlicher Benutzer zu annehmen.
Wenn Option 2 verwendet wird, kann der Code die Identität eines anderen Benutzers annehmen , z. B. m2.
Beispiel: Beibehalten der Affinität zwischen einer Gruppe von Abonnements und dem Postfachserver
Okay, sehen wir uns es in Aktion an. Im folgenden Codebeispiel wird gezeigt, wie Sie Benutzer gruppieren und die Header X-AnchorMailbox und X-PreferServerAffinity sowie das X-BackendOverrideCookie-Cookie verwenden, um die Affinität mit dem Postfachserver aufrechtzuerhalten. Da die Header und das Cookie in der Affinitätsgeschichte von primärer Bedeutung sind, konzentriert sich dieses Beispiel auf die EWS-XML-Anforderungen und -Antworten. Informationen zur Verwendung der verwalteten EWS-API zum Erstellen des Texts der Abonnementanforderungen und -antworten finden Sie unter Streamen von Benachrichtigungen zu Postfachereignissen mithilfe von EWS in Exchange und Pullbenachrichtigungen zu Postfachereignissen mithilfe von EWS in Exchange. Dieser Abschnitt enthält zusätzliche Schritte, die insbesondere für die Aufrechterhaltung der Affinität und das Hinzufügen der Header zu Ihren Anforderungen erforderlich sind.
In diesem Beispiel sind vier Benutzer vorhanden: alfred@contoso.com, alisa@contoso.com, ronnie@contoso.comund sadie@contoso.com. Die folgende Abbildung zeigt die AutoErmittlungseinstellungen GroupingInformation und ExternalEwsUrl für die Benutzer.
Abbildung 1: AutoErmittlungseinstellungen zum Gruppieren von Postfächern
Mithilfe der Einstellungen aus den AutoErmittlungsantworten werden die Postfächer nach dem verketteten Wert der Einstellungen GroupingInformation und ExternalEwsUrl gruppiert. In diesem Beispiel haben Alfred und Sadie die gleichen Werte, sodass sie sich in einer Gruppe befinden, und Alisa und Ronnie teilen sich die gleichen Werte, sodass sie sich in einer anderen Gruppe befinden.
Abbildung 2: Erstellen von Postfachgruppen
In diesem Beispiel konzentrieren wir uns auf Gruppe A. Wir würden die gleichen Schritte für Gruppe B verwenden, aber einen anderen X-AnchorMailbox-Wert für diese Gruppe verwenden.
Erstellen Sie mithilfe von ApplicationImpersonation die Abonnementanforderung für das Ankerpostfach (alfred@contoso.com), wobei der X-AnchorMailbox-Header auf die E-Mail-Adresse und den X-PreferServerAffinity-Headerwert true festgelegt ist. Das Festlegen dieser beiden Headerwerte löst den Server aus, ein X-BackEndOverrideCookie für die Antwort zu erstellen.
Wenn Sie die verwaltete EWS-API verwenden, verwenden Sie die HttpHeadersAdd-Methode , um ihrer Abonnementanforderung die beiden Header wie gezeigt hinzuzufügen.
service.HttpHeaders.Add("X-AnchorMailbox", Mailbox.SMTPAddress);
service.HttpHeaders.Add("X-PreferServerAffinity", "true");
Alfreds Abonnementanforderung sieht also wie folgt aus.
POST https://outlook.office365.com/EWS/Exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0516.014
X-AnchorMailbox: alfred@contoso.com
X-PreferServerAffinity: true
Host: outlook.office365.com
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<t:RequestServerVersion Version="Exchange2013" />
<t:ExchangeImpersonation>
<t:ConnectingSID>
<t:SmtpAddress>alfred@contoso.com</t:SmtpAddress>
</t:ConnectingSID>
</t:ExchangeImpersonation>
</soap:Header>
<soap:Body>
<m:Subscribe>
<m:StreamingSubscriptionRequest>
<t:FolderIds>
<t:DistinguishedFolderId Id="inbox" />
</t:FolderIds>
<t:EventTypes>
<t:EventType>NewMailEvent</t:EventType>
</t:EventTypes>
</m:StreamingSubscriptionRequest>
</m:Subscribe>
</soap:Body>
</soap:Envelope>
Die folgende XML-Nachricht ist die Antwort auf Alfreds Abonnementanforderung und enthält X-BackEndOverrideCookie. Senden Sie dieses Cookie für alle nachfolgenden Anforderungen an Benutzer in dieser Gruppe erneut. Beachten Sie, dass die Antwort auch zusätzliche Cookies enthält, z. B. das exchangecookie-Cookie, das von Exchange 2010 verwendet wird. Exchange Online, Exchange Online als Teil von Office 365 und Versionen von Exchange ab Exchange 2013, ignorieren exchangecookie, wenn es in nachfolgenden Abonnementanforderungen enthalten ist.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Set-Cookie: exchangecookie=ddb8c383aef34c7694132aa679744feb; expires=Thu, 25-Sep-2014 18:42:45 GMT; path=/;
HttpOnly
Set-Cookie: X-BackEndOverrideCookie=CO1PR06MB222.namprd06.prod.outlook.com~1941996295; path=/; secure; HttpOnly
Set-Cookie: X-BackEndCookie=alfred@contoso.com=Ox8XKzcXLxg==;
expires=Wed, 25-Sep-2013 18:52:49 GMT; path=/EWS; secure; HttpOnly
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15"
MinorVersion="0"
MajorBuildNumber="775"
MinorBuildNumber="7"
Version="V2_4"
xmlns:h="https://schemas.microsoft.com/exchange/services/2006/types"
xmlns="https://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<m:SubscribeResponse xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:SubscribeResponseMessage ResponseClass="Success">
<m:ResponseCode>NoError</m:ResponseCode>
<m:SubscriptionId>JgBjbzFwcjA2bWIyMjIubmFtcHJkMDYucHJvZC5vdXRsb29rLmNvbRAAAAAUeGk+7JFdSaFM8/NI/gQQpVdgZX6H0Ag=</m:SubscriptionId>
</m:SubscribeResponseMessage>
</m:ResponseMessages>
</m:SubscribeResponse>
</s:Body>
</s:Envelope>
Mithilfe von X-BackEndOverrideCookie aus Alfreds Antwort und dem X-AnchorMailbox-Header wird die Abonnementanforderung für Sadie erstellt, das andere Mitglied von Gruppe A. Sadies Abonnementanforderung sieht wie folgt aus.
POST https://outlook.office365.com/EWS/Exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0516.014
X-AnchorMailbox: alfred@contoso.com
X-PreferServerAffinity: true
Host: outlook.office365.com
Cookie: X-BackEndOverrideCookie=CO1PR06MB222.namprd06.prod.outlook.com~1941996295
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<t:RequestServerVersion Version="Exchange2013" />
<t:ExchangeImpersonation>
<t:ConnectingSID>
<t:SmtpAddress>sadie@contoso.com </t:SmtpAddress>
</t:ConnectingSID>
</t:ExchangeImpersonation>
</soap:Header>
<soap:Body>
<m:Subscribe>
<m:StreamingSubscriptionRequest>
<t:FolderIds>
<t:DistinguishedFolderId Id="inbox" />
</t:FolderIds>
<t:EventTypes>
<t:EventType>NewMailEvent</t:EventType>
</t:EventTypes>
</m:StreamingSubscriptionRequest>
</m:Subscribe>
</soap:Body>
</soap:Envelope>
Sadies Abonnementantwort sieht wie folgt aus. Beachten Sie, dass X-BackEndOverrideCookie nicht enthalten ist. Der Client ist für das Zwischenspeichern dieses Werts für zukünftige Anforderungen verantwortlich.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Set-Cookie: exchangecookie=640ea858f69d47ff8cce8b44c337f6d9; path=/
Set-Cookie: X-BackEndCookie=alfred@contoso.com=Ox8XKzcXLxg==;
expires= Wed, 25-Sep-2013 18:53:06 GMT; path=/EWS; secure; HttpOnly
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:ServerVersionInfo MajorVersion="15"
MinorVersion="0"
MajorBuildNumber="775"
MinorBuildNumber="7"
Version="V2_4"
xmlns:h="https://schemas.microsoft.com/exchange/services/2006/types"
xmlns="https://schemas.microsoft.com/exchange/services/2006/types"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<m:SubscribeResponse xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages"
xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types">
<m:ResponseMessages>
<m:SubscribeResponseMessage ResponseClass="Success">
<m:ResponseCode>NoError</m:ResponseCode>
<m:SubscriptionId>JgBjbzFwcjA2bWIyMjIubmFtcHJkMDYucHJvZC5vdXRsb29rLmNvbRAAAAB4EQOy2pfrQJfM3hzs/nZJIZssan6H0Ag=</m:SubscriptionId>
</m:SubscribeResponseMessage>
</m:ResponseMessages>
</m:SubscribeResponse>
</s:Body>
</s:Envelope>
Mithilfe der SubscriptionId-Werte aus den Abonnementantworten wurde eine GetStreamingEvents-Vorgangsanforderung für alle Abonnements in der Gruppe erstellt. Da in dieser Gruppe weniger als 200 Abonnements vorhanden sind, werden sie alle in einer Anforderung gesendet. Der X-PreferServerAffinity-Header ist auf true festgelegt, und das X-BackEndOverrideCookie ist enthalten.
POST https://outlook.office365.com/EWS/Exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0516.014
X-AnchorMailbox: alfred@contoso.com
X-PreferServerAffinity: true
Host: outlook.office365.com
Cookie: X-BackEndOverrideCookie=CO1PR06MB222.namprd06.prod.outlook.com~1941996295
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="https://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="https://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<t:RequestServerVersion Version="Exchange2013" />
<t:ExchangeImpersonation>
<t:ConnectingSID>
<t:SmtpAddress>sadie@contoso.com</t:SmtpAddress>
</t:ConnectingSID>
</t:ExchangeImpersonation>
</soap:Header>
<soap:Body>
<m:GetStreamingEvents>
<m:SubscriptionIds>
<t:SubscriptionId>JgBjbzFwcjA2bWIyMjIubmFtcHJkMDYucHJvZC5vdXRsb29rLmNvbRAAAAB4EQOy2pfrQJfM3hzs/nZJIZssan6H0Ag=</t:SubscriptionId>
<t:SubscriptionId>JgBjbzFwcjA2bWIyMjIubmFtcHJkMDYucHJvZC5vdXRsb29rLmNvbRAAAAAUeGk+7JFdSaFM8/NI/gQQpVdgZX6H0Ag=</t:SubscriptionId>
</m:SubscriptionIds>
<m:ConnectionTimeout>10</m:ConnectionTimeout>
</m:GetStreamingEvents>
</soap:Body>
</soap:Envelope>
Die zurückgegebenen Ereignisse werden dann zur Verarbeitung an einen separaten Thread übergeben.
Wie hat sich die Affinität geändert?
In Exchange 2010 werden Abonnements auf dem Clientzugriffsserver verwaltet, wie in Abbildung 3 dargestellt. Ab Exchange 2010 werden Abonnements auf dem Postfachserver verwaltet, wie in Abbildung 4 dargestellt.
Abbildung 3: Prozess zur Aufrechterhaltung der Affinität in Exchange 2010
Abbildung 4: Prozess zur Aufrechterhaltung der Affinität in Exchange Online und Exchange 2013
In Exchange 2010 kennt der Client nur die Adresse des Lastenausgleichs, und das vom Server zurückgegebene exchangecookie stellt sicher, dass die Anforderung an den richtigen Clientzugriffsserver weitergeleitet wird. In späteren Versionen müssen jedoch die Lastenausgleichs- und Clientzugriffsserverrollen die Anforderungen entsprechend weiterleiten, bevor sie an den Postfachserver gelangen. Dazu sind zusätzliche Informationen erforderlich, weshalb die neuen Header und Cookies eingeführt wurden. Im Artikel Benachrichtigungsabonnements, Postfachereignisse und EWS in Exchange wird erläutert, wie Abonnements in Exchange 2013 verwaltet werden.
Möglicherweise stellen Sie fest, dass das exchangecookie, das Exchange 2010 verwendet, immer noch von späteren Versionen zurückgegeben wird. Es ist nicht schade, dieses Cookie in Anforderungen einzufügen, aber in späteren Versionen von Exchange wird es ignoriert.
Siehe auch
- Benachrichtigungsabonnements, Postfachereignisse und EWS in Exchange
- Streambenachrichtigungen zu Postfachereignissen mithilfe von EWS in Exchange
- Pullbenachrichtigungen zu Postfachereignissen mithilfe von EWS in Exchange
- Umgang von Fehlern im Zusammenhang mit Benachrichtigungen in EWS in Exchange
- Änderungen in Verwalten der Affinität für EWS-Abonnements...
- EWS-Einschränkung in Exchange
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für