Modifications de la connectivité intersites pour l’accès au client RPC

Article d’origine publié le mercredi 30 mai 2012

Il y a environ deux ans, j’ai présenté une session intitulée Éléments à prendre en compte pour une conception hautement disponible à la conférence TechEd North America 2010. J’y ai décrit les modifications que nous apportions à la connectivité MAPI lorsqu’elle intervient après des événements de déplacements de boîtes aux lettres et *over de bases de données intersites. Malheureusement, juste après cette présentation nous avons dû stopper la fonctionnalité en raison de la complexité des modifications à introduire et le peu de temps à notre disposition pour effectuer les tests avant la sortie du Service Pack 1. Et malgré tous mes efforts pour en faire une priorité, nous n’avons pas pu intégrer ces modifications dans le Service Pack 2 non plus.

Malheureusement, tous les retraits de fonctionnalités ne se font pas avec une précision chirurgicale et une partie du code modifié est restée dans le SP1. Par exemple, vous avez pu remarquer que l’applet de commande Set-DatabaseAvailabilityGroup contient une propriété AllowCrossSiteRPCClientAccess. Vous pouvez essayer d’activer cette propriété booléenne autant que vous voulez, elle n’aura strictement aucun effet sur le comportement du produit (je sais... c’est la raison pour laquelle je pense que cette image est curieusement pleine de sens) :

Comportement de la connectivité d’accès au client RPC intersites (RTM, SP1, SP2 jusqu’à SP2-RU2)

Mais je m’emporte. Tout d'abord, voyons quelques principes de base.

Avec Exchange 2010, la modification principale porte sur la façon dont les clients se connectent et accèdent aux données de boîte aux lettres. Contrairement aux versions précédentes, les clients ne se connectent plus directement à la banque d'informations sur le rôle serveur de boîtes aux lettres pour accéder aux données de boîtes aux lettres. Les clients se connectent désormais à un ensemble de services sur le rôle et les services serveur d’accès au client (CAS) au sein des données de boîte aux lettres d’accès au rôle CAS à l’aide de MAPI/RPC depuis le serveur de boîtes aux lettres pour le compte de l’utilisateur. Imaginez ça comme une couche d’abstraction.

Fondamentalement, une seule modification a été apportée pour faire en sorte que toute la connectivité MAPI des boîtes aux lettres passe par le service d’accès au client RPC sur le rôle serveur d’accès au client. Pour favoriser cette couche d’abstraction, les objets de base de données ne sont plus des objets enfants des serveurs de boîtes aux lettres. Une nouvelle propriété a été ajoutée à la base de données de boîtes aux lettres, RPCClientAccessServer, qui définit le legacyExchangeDN à utiliser pour accéder à la base de données spécifique. Cette propriété a la valeur d’un FQDN. Pour garantir une haute disponibilité et une tolérance de panne dans le cas d’un CAS défectueux, cette valeur doit être le FQDN d’un groupe CAS à équilibrage de charge. Ce FQDN à équilibrage de charge est appelé groupe de serveurs d’accès au client RPC.

Pour plus d’informations, voir les billets de Brian Day sur la démystification de l’objet de groupe CAS, Partie 1 et Partie 2.

Expérience Outlook caractéristique

Toutes les versions d’Outlook se comportent de la même manière dans le scénario d’un seul centre de données (ou d’un seul site Active Directory). Le point de terminaison RPC du profil Outlook est le groupe de serveurs d’accès au client RPC (ou un CAS spécifique si pour une raison ou une autre vous n’avez pas créé de groupe, ce que vous auriez dû faire, et si vous ne savez pas pourquoi, je me répète : lisez les billets de Brian). Si une panne se produit dans le DAG (base de données défectueuse, serveur défectueux, etc.), le point de terminaison RPC ne change pas, donc Outlook continue à se connecter au même groupe de serveurs d’accès au client RPC. Si une panne se produit au niveau du groupe CAS (CAS défectueux, équilibreur de charge défectueux, etc.), le point de terminaison RPC ne change pas, donc Outlook continuera à essayer de se connecter au groupe de serveurs d’accès au client RPC.

Toutes les versions d’Outlook se comportent aussi de la même manière dans un scénario de basculement de centres de données, en supposant que vous avez suivi nos conseils. Pour quelle raison ? Eh bien, parce que dans un basculement de centres de données, vous changez l’adresse IP principale du groupe de serveurs d’accès au client RPC du centre de données pour qu'il pointe désormais vers le groupe de serveurs d’accès au client RPC du centre de données de secours. La découverte automatique continue à distribuer le groupe de serveurs d’accès au client RPC du centre de données principal en tant que point de terminaison RPC. Les clients Outlook existants ne nécessitent aucune reconfiguration. Une fois que le cache DNS du client est mis à jour, il n’a plus qu’à se connecter au point de terminaison qui se trouve désormais dans le centre de données de secours. Cela fonctionne car ni le client ni le CAS ne se préoccupe du site dans lequel se trouve le CAS, ils peuvent se connecter et le CAS auquel le client est connecté peut fournir un accès à la boîte aux lettres et c’est tout ce qui leur importe.

Comportement de la base de données *over intersites

Pour comprendre ce scénario, il faut savoir que quand vous configurez un DAG multisite, la propriété RPCClientAccessServer d’une base de donnée spécifique est généralement associée au groupe de serveurs d’accès au client RPC qui se trouve dans le même site AD que la copie de la base de données de boîte aux lettres avec le plus petit numéro de préférence d’activation. Par exemple :

Figure 1 : Groupe de disponibilité de base de données étendu entre deux sites Active Directory

Si une copie de la base de données est activée dans le centre de données de secours, les utilisateurs continueront à exploiter le groupe de serveurs d’accès au client RPC depuis le site AD où se trouve la base de données de boîtes aux lettres avec la plus petite valeur de préférence d’activation comme point de terminaison de la connectivité.

Figure 2 : La base de données MDB1 a été activée dans le site Active Directory de secours

Si vous examinez les journaux d’accès au client RPC sur le groupe de serveurs d’accès au client RPC source, vous verrez ceci :

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

Si le groupe de serveurs d’accès au client RPC du site AD où se trouve la base de données de boîtes aux lettres avec la plus petite valeur de préférence d’activation devient inaccessible aux utilisateurs, les clients Outlook seront dans l’incapacité de se connecter à leur boîte aux lettres se trouvant dans l’autre centre de données. En d’autres termes, un événement de panne du centre de données se produit et le processus de basculement des centres de données doit être exécuté.

Autrement dit, Outlook se connecte toujours au point de terminaison RPC configuré (s’il est joignable) quelle que soit la valeur de la propriété RPCClientAccessServer de la base de données.

Le système peut-il changer la valeur de la propriété RPCClientAccessServer automatiquement ?

Le système change la valeur de la propriété RPCClientAccessServer sur la base de données uniquement quand l’administrateur change le numéro ActivationPreference sur la copie de la base de données activée pour lui attribuer la plus petite valeur (elle devient donc la copie préférée), comme illustré dans la Figure 3.

Figure 3 : La base de données MDB1 a été activée dans le site Active Directory de secours et la propriété RPCClientAccessServer a changé

Toutefois, les clients Outlook dotés d’un profil Outlook existant continueront à utiliser l’ancien point de terminaison RPC plutôt que le nouveau (même si la découverte automatique a détecté le changement), car l’ancien point de terminaison RPC ne renvoie pas de réponse ecWrongServer au client. Le point de terminaison RPC accepte la connexion. Outlook ignore donc la réponse de découverte automatique car il dispose d’une connexion active. Si l’ancien point de terminaison RPC devient inaccessible, Outlook 2007/2010 met alors à jour ses paramètres (Outlook 2003, en revanche, ne le fait pas car il n’exploite pas la découverte automatique). Vous pouvez obliger Outlook à utiliser le nouveau point de terminaison RPC à tout moment en imposant la réparation du profil.

Que se passe-t-il si l’administrateur met à jour manuellement la valeur RPCClientAccessServer après un événement de base de données *over intersites ?

À la Figure 2, si l’administrateur met à jour manuellement la valeur RPCClientAccessServer pour pointer vers cas-sec.contoso.com pour MDB1 une fois la copie de la base de données de boîtes aux lettres activée sur MBX-C (dont la valeur ActivationPreference est supérieure à 1), alors les clients Outlook dotés d’un profil existant continueront à utiliser l’ancien point de terminaison RPC plutôt que le nouveau à condition que l’ancien point de terminaison RPC reste disponible (les réparations du profil corrigeront le problème). Les profils Outlook créés après la modification de la valeur RPCClientAccessServer utiliseront le nouveau point de terminaison RPC.

Déplacement de boîtes aux lettres entre les sites Active Directory

Avant Exchange 2010, quand vous déplaciez des boîtes aux lettres entre les serveurs, le point de terminaison RPC d’Outlook se mettait à jour pour pointer vers le serveur de boîtes aux lettres (ou une instance de serveur de boîtes aux lettres en clusters) hébergeant la base de données où se trouve la boîte aux lettres. Après le déplacement de la boîte aux lettres, l’utilisateur du client Outlook était invité à redémarrer Outlook par la boîte de dialogue « L’administrateur d’Exchange a effectué une modification qui nécessite de quitter et redémarrer Outlook ». Après le redémarrage d’Outlook, le client était connecté au nouveau point de terminaison RPC.

Avec Exchange 2010, vous avez peut-être remarqué qu’après avoir déplacé des boîtes aux lettres entre les sites AD, cette boîte de dialogue n’est pas présentée à l’utilisateur. Par ailleurs, le point de terminaison RPC des utilisateurs n’est pas mis à jour pour refléter le groupe de serveurs d’accès au client RPC associé à la base de données de boîtes aux lettres du site AD où se trouve désormais la boîte aux lettres. En effet, l’ancien point de terminaison RPC ne renvoie pas de réponse ecWrongServer au client. Le point de terminaison RPC accepte la connexion, et Outlook ignore donc la réponse de la découverte automatique car il dispose d’une connexion active. Si le point de terminaison RPC devient inaccessible, Outlook met alors à jour ses paramètres (Outlook 2003, en revanche, ne le fait pas car il n’exploite pas la découverte automatique). Vous pouvez obliger Outlook à utiliser le nouveau point de terminaison RPC à tout moment en imposant la réparation du profil.

Désormais, je suis sûr que vous comprenez l’image humoristique du chaton !

L’avenir... SP2 RU3 et après

Je n’ai jamais perdu l’espoir de venir à bout de ces problèmes. Certains d’entre nous ont souffert, mais l’équipe de développement d’accès au client RPC, l’équipe de maintenance d’Exchange et moi-même avons travaillé sans relâche pour insérer les deux modifications nécessaires dans le produit. La première étant la correction du profil Outlook lorsqu’une boîte aux lettres est simplement déplacée entre des bases de données de différents sites AD, et la deuxième lorsqu’une base de données *over intersites provoque l’utilisation par Outlook d’un CAS qui n'est pas le meilleur choix pour l’emplacement de la base de données actuellement activée.

Déplacements de boîtes aux lettres

Par défaut, une fois que vous avez installé SP2 RU3, quand vous déplacez des boîtes aux lettres entre des sites AD, toutes les versions d’Outlook doivent être redémarrées et le point de terminaison RPC du profil Outlook est mis à jour.

Si vous examinez les journaux d’accès au client RPC dans le groupe d’accès au client RPC, vous verrez ceci :

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Notez que l’opération RPC (ROP) est WrongServer (équivalent d'ecWrongServer). Cela oblige le client Outlook à effectuer une découverte de profil et à mettre à jour le profil selon les nouvelles informations trouvées dans le répertoire. Le profil est mis à jour et après le redémarrage du client, ce dernier établit ses connexions au nouveau point de terminaison RPC.

Et (parce que la question sera inévitablement posée), quelles sont les autres conditions qui entraînent l’affichage de « L’administrateur d’Exchange a apporté une modification qui nécessite de quitter et redémarrer Outlook » ?

1. Quand vous spécifiez la propriété DoNotPreserveMailboxSignature à New-MoveRequest.
2. Quand les bases de données de boîtes aux lettres source et cible utilisent un magasin de hiérarchie de dossier public différent.
3. Quand vous déplacez votre boîte aux lettres d’une version existante d’Exchange vers Exchange 2010.

Événements de base de données *over intersites

Le comportement des événements de base de données *over intersites dépendra de la valeur de la propriété DAG AllowCrossSiteRPCClientAccess. Si vous définissez la valeur de la propriété AllowCrossSiteRPCClientAccess à $true, le comportement que j’ai décrit dans la section précédente sera alors le comportement par défaut. Dans le cas où la base de données est activée dans le centre de données de secours, les utilisateurs continueront à exploiter le groupe d’accès au client RPC du site AD où se trouve la base de données de boîtes aux lettres avec la plus petite valeur de préférence d’activation comme point de terminaison de leur connectivité.

Si vous définissez la valeur de la propriété AllowCrossSiteRPCClientAccess à $false (la valeur par défaut de la propriété est $false), le point de terminaison RPC du profil Outlook sera alors mis à jour en tant que groupe de serveurs d’accès au client RPC se trouvant dans le même site AD où la base de données est active et montée. Notez que la propriété RPCClientAccessServer n’est pas mise à jour, car elle définit le site préféré.

Figure 4 : La base de données MDB1 a été activée sur le site Active Directory de secours et le profil Outlook a été automatiquement mis à jour

Si vous examinez les journaux d’accès au client RPC du groupe de serveurs d’accès au client RPC source, vous verrez ceci :

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Tout comme dans le scénario de déplacement de la boîte aux lettres, le ROP WrongServer oblige le client Outlook à effectuer une découverte et à mettre à jour le profil d’après les nouvelles informations trouvées dans le répertoire. Le profil est mis à jour et après le redémarrage du client, ce dernier établit ses connexions au nouveau point de terminaison RPC.

Conclusion

Voilà, avec SP2 RU3 (ou versions ultérieures) vous pouvez garantir que le profil des boîtes aux lettres déplacées entre des sites AD sera mis à jour correctement. Par ailleurs, dans le scénario de la base de données *over intersites, vous pouvez décider d’autoriser la connectivité RPC intersites ou obliger le client Outlook à utiliser le groupe de serveurs d’accès au client RPC se trouvant dans le même site AD que la base de données activée et montée (le comportement par défaut). Je pense qu’il serait opportun de terminer par ceci :

Ross Smith IV
Responsable principal du programme
Exchange Customer Experience

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page RPC Client Access Cross-Site Connectivity Changes