Conserver l’affinité entre un groupe d'abonnements et le serveur de boîtes aux lettres dans Exchange
Découvrez comment conserver l’affinité entre un groupe d’abonnements et le serveur de boîtes aux lettres.
L’affinité est l’association d’une séquence de messages de demande et de réponse à un serveur de boîtes aux lettres particulier. Pour la plupart des fonctionnalités dans Exchange, l’affinité est gérée par le serveur. Toutefois, les notifications constituent une exception. Le client est chargé de maintenir l’affinité avec le serveur de boîtes aux lettres pour les abonnements de notification. Cette affinité permet à l’équilibreur de charge et aux serveurs d’accès au client entre le client et le serveur d’acheminer les abonnements de notification et les demandes associées vers le serveur de boîtes aux lettres qui gère l’abonnement. Sans affinité, la demande peut être routée vers un autre serveur de boîtes aux lettres qui n’inclut pas les abonnements du client, ce qui peut entraîner le renvoi d’une erreur ErrorSubscriptionNotFound .
Comment l’affinité est-elle conservée ?
L’affinité dans Exchange est basée sur les cookies. Le client déclenche la création du cookie en incluant des en-têtes spécifiques dans la demande d’abonnement, puis la réponse de l’abonnement contient le cookie. Le client envoie ensuite ce cookie dans les requêtes suivantes pour s’assurer que la requête est routée vers le serveur de boîtes aux lettres approprié.
Plus précisément, l’affinité dans Exchange est gérée par les éléments suivants :
X-AnchorMailbox : en-tête HTTP inclus dans la demande d’abonnement initiale. Il identifie la première boîte aux lettres d’un groupe de boîtes aux lettres qui partagent l’affinité avec le même serveur de boîtes aux lettres.
X-PreferServerAffinity : en-tête HTTP inclus dans la demande d’abonnement initiale avec l’en-tête X-AnchorMailbox et défini sur true pour indiquer que le client demande que l’affinité soit conservée avec le serveur de boîtes aux lettres.
X-BackEndOverrideCookie : cookie inclus dans la réponse d’abonnement initiale et contenant un cookie que l’équilibreur de charge et le serveur d’accès au client utilisent pour acheminer les requêtes suivantes vers le même serveur de boîtes aux lettres.
Comment faire conserver l’affinité à l’aide de l’API managée EWS ou EWS ?
Vous pouvez utiliser les mêmes étapes pour maintenir l’affinité pour plusieurs abonnements aux boîtes aux lettres et leurs serveurs de boîtes aux lettres, que vous utilisiez des notifications de diffusion en continu, d’extraction ou de push, et que vous ciblez un serveur exchange local ou un Exchange Online.
Pour chaque boîte aux lettres, appelez autodiscover et obtenez les paramètres utilisateur GroupingInformation et ExternalEwsUrl. Pour la découverte automatique SOAP, vous utilisez l’élément Setting , et pour la découverte automatique POX, vous utilisez l’élément GroupingInformation .
À l’aide des paramètres GroupingInformation et ExternalEwsUrl des réponses de découverte automatique, placez les boîtes aux lettres avec les mêmes valeurs concaténées ExternalEwsUrl et GroupingInformation dans le même groupe. Si des groupes ont plus de 200 boîtes aux lettres, divisez les groupes de façon à ce que chaque groupe n’ait pas plus de 200 boîtes aux lettres.
Créez et utilisez un objet ExchangeService pour le reste de la procédure. Lorsque vous utilisez le même objet ExchangeService , les cookies et les en-têtes (lorsqu’ils sont définis) sont automatiquement conservés. Notez que si vous n’avez pas l’intention de regrouper les abonnements de diffusion en continu dans une seule connexion, vous êtes libre de créer un objet ExchangeService différent pour chaque utilisateur emprunt d’identité.
Envoyez une demande d’abonnement pour l’utilisateur dont le nom d’utilisateur apparaît en premier lorsque tous les utilisateurs du groupe sont triés par ordre alphabétique (nous désignerons cet utilisateur comme utilisateur de boîte aux lettres d’ancre). Procédez comme suit :
Incluez l’en-tête X-AnchorMailbox avec une valeur définie sur l’adresse SMTP de l’utilisateur de la boîte aux lettres d’ancre.
Incluez l’en-tête X-PreferServerAffinity avec une valeur définie sur true.
Utilisez le rôle ApplicationImpersonation (type ExchangeImpersonation ).
Dans la réponse de l’abonnement, obtenez la valeur X-BackEndOverrideCookie. Incluez cette valeur dans chacune des demandes d’abonnement suivantes pour les utilisateurs de ce groupe.
Pour chaque utilisateur supplémentaire du groupe, envoyez une demande d’abonnement et procédez comme suit :
Incluez l’en-tête X-AnchorMailbox avec une valeur définie sur l’adresse SMTP de l’utilisateur de boîte aux lettres d’ancre pour le groupe.
Incluez l’en-tête X-PreferServerAffinity avec une valeur définie sur true.
Incluez la X-BackEndOverrideCookie qui a été retournée dans la réponse d’abonnement de l’utilisateur de la boîte aux lettres d’ancrage.
Utilisez le rôle ApplicationImpersonation (type ExchangeImpersonation ).
Notez que le serveur utilise les valeurs X-PreferServerAffinity et X-BackendOverrideCookie ensemble pour effectuer le routage vers le serveur de boîtes aux lettres. L’en-tête X-AnchorMailbox est également obligatoire, mais il est ignoré par le serveur si les deux autres valeurs sont valides. Si X-AnchorMailbox et X-PreferServerAffinity se trouvent dans une requête et que X-BackendOverrideCookie n’est pas inclus, la valeur X-AnchorMailbox est utilisée pour router les requêtes.
Étant donné que les valeurs X-PreferServerAffinity et X-BackendOverrideCookie effectuent le routage, si la boîte aux lettres d’ancre se déplace vers un autre groupe ou serveur, la logique ne change pas, car X-BackendOverrideCookie route la requête vers le serveur approprié pour le groupe.
- Envoyez une seule requête GetStreamingEvents ou GetEvents pour le groupe, puis procédez comme suit :
Incluez les valeurs SubscriptionId retournées dans chacune des réponses d’abonnement individuelles pour les boîtes aux lettres du groupe.
S’il existe plus de 200 abonnements pour le groupe, créez plusieurs demandes. Le nombre maximal de valeurs SubscriptionId à inclure dans une requête est de 200.
Si vous avez besoin de plus de connexions que la boîte aux lettres cible, utilisez le compte de service pour emprunter l’identité de la boîte aux lettres d’ancrage pour le groupe . sinon, n’utilisez pas l’emprunt d’identité. Dans l’idéal, vous souhaitez emprunter l’identité d’une boîte aux lettres unique par requête GetStreamingEvents ou GetEvents afin de ne jamais rencontrer de limites de limitation.
Utilisez ApplicationImpersonation si vous avez besoin de plus de connexions que celles disponibles pour la boîte aux lettres cible ; sinon, n’utilisez pas ApplicationImpersonation.
Incluez l’en-tête X-PreferServerAffinity et définissez-le sur true. Cette valeur est automatiquement incluse si vous utilisez l’objet ExchangeService que vous avez créé à l’étape 2.
Incluez la X-BackEndOverrideCookie pour le groupe (la X-BackEndOverrideCookie qui a été retournée dans la réponse d’abonnement de l’utilisateur de la boîte aux lettres d’ancrage). Cette valeur est automatiquement incluse si vous utilisez l’objet ExchangeService que vous avez créé à l’étape 2.
- Passez les événements retournés à un thread distinct pour traitement.
Quelles valeurs de limitation dois-je prendre en compte ?
Lorsque vous planifiez votre implémentation de notification, vous devez prendre en compte deux valeurs : le nombre de connexions et le nombre d’abonnements. Le tableau suivant répertorie les valeurs par défaut pour chaque paramètre de limitation et la façon dont les paramètres sont utilisés. Pour chaque valeur, le budget est alloué à la boîte aux lettres cible. Pour cette raison, l’utilisation de l’emprunt d’identité pour obtenir des connexions supplémentaires est une étape requise dans de nombreux scénarios.
Tableau 1. Valeurs de limitation par défaut
| Domaine à prendre en considération | Paramètre de limitation | Valeur par défaut | Description |
|---|---|---|---|
| Connexions de streaming |
Limite de connexion bloquée par défaut |
10 pour Exchange Online 3 pour Exchange 2013 |
Nombre maximal de connexions de streaming simultanées qu’un compte peut ouvrir simultanément sur le serveur. Pour respecter cette limite, utilisez un compte de service avec le rôle ApplicationImpersonation attribué pour les boîtes aux lettres cibles et empruntez l’identité du premier utilisateur de chaque groupe d’ID d’abonnement lors de l’obtention d’événements diffusés en continu. |
| Connexions par extraction ou envoi (push) |
EWSMaxConcurrency |
27 |
Nombre maximal de connexions pull ou push simultanées (demandes qui ont été reçues mais auxquelles elles n’ont pas encore répondu) qu’un compte peut avoir ouverte sur le serveur en même temps. |
| Abonnements |
EWSMaxSubscriptions |
20 pour Exchange Online 5000 pour Exchange 2013 |
Nombre maximal d’abonnements non expirés qu’un compte peut avoir à la fois. Cette valeur est décrémentée lorsque l’abonnement est créé sur le serveur. |
L’exemple suivant montre comment les budgets sont gérés entre n’importe quelle boîte aux lettres cible et le compte de service auquel le rôle ApplicationImpersonation est attribué pour les boîtes aux lettres cibles.
ServiceAccount1 (sa1) emprunte l’identité de nombreux utilisateurs (m1, m2, m3, etc.) et crée des abonnements pour chaque boîte aux lettres. Notez que lorsque les abonnements sont créés, le propriétaire de l’abonnement est sa1. Par conséquent, lorsque sa1 ouvre une connexion avec les abonnements, EWS impose que les abonnements appartiennent à sa1.
Sa1 peut ouvrir la connexion des manières suivantes :
Sans emprunt d’identité, la connexion est donc facturée sur sa1.
En empruntant l’identité de l’un des utilisateurs ( m1 par exemple) afin que la connexion soit facturée sur une copie du budget de m1. (M1 lui-même peut ouvrir dix connexions à l’aide de Exchange Online, et tous les comptes de service qui empruntent l’identité de m1 peuvent ouvrir dix connexions à l’aide du budget copié.)
Si la limite de connexion est atteinte, les solutions de contournement suivantes sont disponibles :
Si l’option 1 est utilisée, l’administrateur peut créer plusieurs comptes de service pour emprunter l’identité d’utilisateurs supplémentaires.
Si l’option 2 est utilisée, le code peut emprunter l’identité d’un autre utilisateur, par exemple m2.
Exemple : Maintien de l’affinité entre un groupe d’abonnements et le serveur de boîtes aux lettres
Voyons-le en action. L’exemple de code suivant montre comment regrouper des utilisateurs et utiliser les en-têtes X-AnchorMailbox et X-PreferServerAffinity et le cookie X-BackendOverrideCookie pour conserver l’affinité avec le serveur de boîtes aux lettres. Étant donné que les en-têtes et le cookie sont de première importance dans l’article d’affinité, cet exemple se concentre sur les requêtes et réponses XML EWS. Pour utiliser l’API managée EWS afin de créer le corps des demandes d’abonnement et des réponses, consultez Diffuser des notifications sur les événements de boîte aux lettres à l’aide d’EWS dans Exchange et Notifications d’extraction sur les événements de boîte aux lettres à l’aide d’EWS dans Exchange. Cette section inclut des étapes supplémentaires en particulier pour maintenir l’affinité et ajouter les en-têtes à vos demandes.
Cet exemple a quatre utilisateurs : alfred@contoso.com, alisa@contoso.com, ronnie@contoso.comet sadie@contoso.com. La figure suivante montre les paramètres de découverte automatique GroupingInformation et ExternalEwsUrl pour les utilisateurs.
Figure 1. Paramètres de découverte automatique utilisés pour regrouper les boîtes aux lettres
À l’aide des paramètres des réponses de découverte automatique, les boîtes aux lettres sont regroupées par la valeur concaténée des paramètres GroupingInformation et ExternalEwsUrl. Dans cet exemple, Alfred et Sadie ont les mêmes valeurs, donc ils sont dans un groupe, et Alisa et Ronnie partagent les mêmes valeurs, donc ils se trouvent dans un autre groupe.
Figure 2. Création de groupes de boîtes aux lettres
Pour les besoins de cet exemple, nous allons nous concentrer sur le groupe A. Nous utilisons les mêmes étapes pour le groupe B, mais nous utilisons une autre valeur X-AnchorMailbox pour ce groupe.
À l’aide d’ApplicationImpersonation, créez la demande d’abonnement pour la boîte aux lettres d’ancre (alfred@contoso.com), avec l’en-tête X-AnchorMailbox défini sur leur adresse e-mail et une valeur d’en-tête X-PreferServerAffinity true. La définition de ces deux valeurs d’en-tête déclenche la création d’un X-BackEndOverrideCookie pour la réponse.
Si vous utilisez l’API managée EWS, utilisez la méthode HttpHeadersAdd pour ajouter les deux en-têtes à votre demande d’abonnement, comme indiqué.
service.HttpHeaders.Add("X-AnchorMailbox", Mailbox.SMTPAddress);
service.HttpHeaders.Add("X-PreferServerAffinity", "true");
La demande d’abonnement d’Alfred ressemble donc à ceci.
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>
Le message XML suivant est la réponse à la demande d’abonnement d’Alfred et inclut la X-BackEndOverrideCookie. Renvoyez ce cookie pour toutes les demandes suivantes pour les utilisateurs de ce groupe. Notez que la réponse contient également des cookies supplémentaires, tels que le cookie exchangecookie utilisé par Exchange 2010. Exchange Online, Exchange Online dans le cadre de Office 365 et les versions d’Exchange à compter d’Exchange 2013, ignorez exchangecookie s’il est inclus dans les demandes d’abonnement suivantes.
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>
À l’aide de la X-BackEndOverrideCookie de la réponse d’Alfred et de l’en-tête X-AnchorMailbox, la demande d’abonnement est créée pour Sadie, l’autre membre du groupe A. La demande d’abonnement de Sadie ressemble à ceci.
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>
La réponse d’abonnement de Sadie ressemble à ceci. Notez qu’il n’inclut pas la X-BackEndOverrideCookie. Le client est responsable de la mise en cache de cette valeur pour les demandes futures.
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>
À l’aide des valeurs SubscriptionId des réponses d’abonnement, une demande d’opération GetStreamingEvents a été créée pour tous les abonnements du groupe. Étant donné qu’il y a moins de 200 abonnements dans ce groupe, ils sont tous envoyés dans une seule requête. L’en-tête X-PreferServerAffinity est défini sur true et X-BackEndOverrideCookie est inclus.
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>
Les événements retournés sont ensuite passés à un thread distinct pour traitement.
Comment l’affinité a-t-elle changé ?
Dans Exchange 2010, les abonnements sont conservés sur le serveur d’accès au client, comme illustré dans la figure 3. Dans les versions d’Exchange ultérieures à Exchange 2010, les abonnements sont conservés sur le serveur de boîtes aux lettres, comme illustré dans la figure 4.
Figure 3. Processus de gestion de l’affinité dans Exchange 2010
Figure 4. Processus de maintenance de l’affinité dans Exchange Online et Exchange 2013
Dans Exchange 2010, le client connaît uniquement l’adresse de l’équilibreur de charge, et l’exchangecookie retournée par le serveur garantit que la requête est acheminée vers le serveur d’accès au client approprié. Toutefois, dans les versions ultérieures, l’équilibreur de charge et les rôles serveur d’accès au client doivent tous deux router les requêtes de manière appropriée avant qu’elles ne soient envoyées au serveur de boîtes aux lettres. Pour ce faire, des informations supplémentaires sont nécessaires, c’est pourquoi les nouveaux en-têtes et cookies ont été introduits. L’article Abonnements aux notifications , événements de boîte aux lettres et EWS dans Exchange explique comment les abonnements sont gérés dans Exchange 2013.
Vous remarquerez peut-être que l’exchangecookie utilisé par Exchange 2010 est toujours retourné par les versions ultérieures. L’inclusion de ce cookie dans les requêtes n’entraîne aucun préjudice, mais les versions ultérieures d’Exchange l’ignorent.
Voir aussi
- Abonnements à des notifications, événements de boîte aux lettres et EWS dans Exchange
- Notifications de flux concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange
- Notifications de type pull concernant les événements de boîte aux lettres à l'aide de EWS dans Exchange
- Gestion des erreurs liées à la notification dans EWS dans Exchange
- Modifications apportées à la gestion de l’affinité pour les abonnements EWS...
- Limitation EWS dans Exchange
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour