Share via


Questions et réponses sur la file d’attente Exchange : Migrations et transitions

Un grand nombre d’entreprises semblent continuer à utiliser Exchange 2003, ce qui peut s’avérer assez rentable, mais au risque d’entraîner certains problèmes de compatibilité.

Henrik Walther

Calendriers partagés

Q : Nous venons de migrer d’Exchange 2003 vers Exchange 2010 SP1. Nous avons un mélange de clients Outlook 2003 et Outlook 2007 dans toute l’entreprise. Nous avons reçu des plaintes de la part de certains utilisateurs qui ont ouvert de nombreux calendriers partagés dans Outlook 2003 (ouvrir plus de 15 calendriers à la fois n’est pas inhabituel). Un message d’erreur apparaît parfois lors de l’ouverture d’un calendrier (voir Figure 1).

The error message you’ll see when opening more than 15 shared calendars from Outlook 2003

Figure 1 Message d’erreur qui apparaît à l’ouverture de plus de 15 calendriers partagés dans Outlook 2003

Est-il possible de résoudre ce problème sans passer à la version Outlook 2007 ? Nous ne pouvons faire la mise à niveau de ces clients avant le deuxième semestre 2011.

R : Ce problème est souvent la conséquence des nouvelles stratégies de limitation des appels de procédure distante (RPC) qui font partie d’Exchange 2010, en particulier le paramètre de stratégie de limitation « RCAMaxConcurrency ». Si des utilisateurs veulent ouvrir plus de 15 calendriers partagés ou des boîtes de réception supplémentaires dans Outlook 2003, vous pouvez ajuster les paramètres de stratégie de limitation du RPC en utilisant l’applet de commande Set-ThrottlingPolicy. Augmentez la valeur de RCAMaxConcurrency, qui est définie à 20 par défaut. Le paramètre RCAMaxConcurrency indique combien l’utilisateur d’un service d’accès au client RPC a de connexions concurrentes par rapport à un serveur qui exécute Exchange 2010 à un moment précis.

Pour augmenter la valeur de RCAMaxConcurrency et paramétrer la stratégie de limitation par défaut de 20 à 30, ouvrez Exchange Management Shell et exécutez la commande suivante pour d’abord créer une variable pour la stratégie :

$a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

Envoyez ensuite la variable à l’applet de commande Set-ThrottlingPolicy :

$a | Set-ThrottlingPolicy -RCAMaxConcurrency 30

Pour appliquer ces modifications, redémarrez le service « Microsoft Exchange Throttling » sur chaque Client Access Server (CAS). Vous allez être maintenant en mesure d’ouvrir beaucoup plus de calendriers partagés ou de boîtes de réception supplémentaires qu’avec les paramètres par défaut (voir Figure 2).

Figure 2 >Opening 15 calendars using Outlook 2003 after changing the default setting for RCAMaxConcurrency

Figure 2 Ouverture de 15 calendriers dans Outlook 2003 après la modification des paramètres par défaut de RCAMaxConcurrency

Vous trouverez des informations supplémentaires sur les stratégies de limitation Exchange 2010 SP1dans la documentation sur Exchange 2010 de Microsoft Technet.

Support de Windows Phone

Q : Notre entreprise envisage d’offrir des appareils Windows Phone 7 à nos utilisateurs. Avant cela, nous voulons savoir si les appareils Windows Phone 7 prennent en charge les mêmes stratégies Exchange ActiveSync (EAS) que les appareils Windows Mobile 6.x.

R : Bien que Microsoft ait développé Windows Phone 7 en pensant principalement aux besoins des particuliers, l’équipe Windows Phone a inclus des fonctionnalités d’entreprise dans son système d’exploitation, car la plupart des utilisateurs ont recours à leur téléphone pour des besoins personnels et professionnels. Le système d’exploitation de Windows Phone 7 prend en charge un sous-ensemble des stratégies EAS fournies avec Exchange 2010 SP1, y compris les stratégies suivantes :

  • Mot de passe requis
  • Longueur minimale des mots de passe
  • Valeur pour la fréquence pour le délai d’inactivité
  • Seuil de réinitialisation
  • Mots de passe simples
  • Expiration du mot de passe
  • Historique du mot de passe
  • Désactivation du stockage amovible
  • Désactivation IrDA
  • Désactivation Desktop Sync
  • Blocage du Bureau à distance
  • Blocage du partage sur Internet

Si vous souhaitez utiliser d’autres stratégies EAS, vous avez les options suivantes :

  • créer une stratégie dédiée EAS Windows Phone 7 et l’associer aux boîtes de réception des utilisateurs qui utilisent des appareils Windows Phone 7 ;
  • définir la propriété AllowNonProvisionableDevices pour mettre en place la stratégie EAS par défaut déjà configurée ;
  • reconfigurer la stratégie EAS par défaut à travers l’organisation Exchange, de sorte qu’elle n’ait que les stratégies configurées indiquées précédemment ;
  • déployer un client EAS tiers sur les appareils Windows Phone 7.

Coexistence avec Exchange

Q : Nous sommes une petite entreprise et nous envisageons actuellement de faire la transition d’Exchange 2003 vers Exchange 2010 SP1. Nous avons seulement un serveur Exchange 2003. L’une des tâches décrites dans la section « Mise à niveau de l’accès au client d’Exchange 2003 » de la bibliothèque TechNet Exchange 2010 consiste à associer un nom d’hôte hérité (legacy domain.com) à l’infrastructure Exchange 2003. Vous devrez ensuite configurer une URL Exchange 2003 sur le CAS Exchange 2010 pointant vers un serveur frontal Exchange 2003 avec la commande suivante :

Set-OWAVirtualDirectory <CAS2010>\OWA* -Exchange2003URL https://legacy.contoso.com/exchange

Cela va permettre à nos utilisateurs d’accéder à leurs boîtes de réception par un système d’authentification unique pendant la période de coexistence dont nous avons besoin, car nous n’avons qu’un serveur Exchange 2003 dans notre entreprise. La documentation TechNet précise que l’URL d’Exchange 2003 doit pointer vers un serveur frontal Exchange 2003. Cela veut-il dire que nous ne pouvons pas utiliser cette fonctionnalité de coexistence à moins d’introduire un serveur frontal Exchange 2003 ?

R : Un serveur frontal Exchange 2003 dédié n’est pas absolument nécessairement. Lorsque vous n’avez qu’un seul serveur Exchange 2003, vous pouvez faire pointer directement l’URL Exchange 2003 du CAS Exchange 2010 vers un serveur frontal Exchange 2003. Gardez à l’esprit que pour avoir une authentification unique, il faut activer une authentification basée sur des formulaires pour le CAS Exchange 2010 et pour le serveur principal d’Exchange 2003 (voir Figure 3).

Figure 3 Enabling forms-based authentication in Exchange 2003

Figure 3 Activation d’une authentification basée sur des formulaires dans Exchange 2003

N’oubliez pas que vous devrez installer un certificat SSL qui comporte le nom d’hôte hérité (legacy.domain.com) sur le serveur Exchange 2003. Il n’est pas nécessaire que ce soit le nom commun sur le certificat. Si vous pouvez utiliser le certificat UC/SAN sur votre serveur Exchange 2010, vous pouvez ajouter le nom d’hôte hérité à la liste SAN et utiliser ce certificat sur le serveur Exchange 2003.

Spécification de passerelles multiples

Q : Nous déployons actuellement Exchange 2010 SP1. Nous avons deux centres de données et envisageons d’utiliser les groupes de disponibilité de bases de données (DAG) entre chacun d’eux. Nous aurons deux membres DAG dans un centre de données et deux dans l’autre. Chaque serveur DAG membre aura deux interfaces réseau (une pour l’accès MAPI et une pour la réplication) et différents sous-réseaux pour chaque centre de données.

Nous avons défini une passerelle par défaut pour le réseau MAPI sur chaque serveur et les membres DAG dans un centre de données. Ils peuvent atteindre les membres DAG dans l’autre centre de données et vice-versa via l’adresse IP du réseau MAPI configuré. Néanmoins, les serveurs ne peuvent être en contact l’un avec l’autre via le réseau de réplication, ce qui constitue un problème. Nous pensons que cela est dû au fait que nous avons également besoin de définir une passerelle par défaut sur les réseaux de réplication. Lorsque nous le faisons via la page de propriétés TCP/IPv4 sur l’interface de réplication, nous voyons le message d’avertissement indiqué à la Figure 4.

Figure 4 Warning message when configuring multiple default gateways

Figure 4 Message d’avertissement en cas de configuration de plusieurs passerelles par défaut

Avant de continuer avec la configuration de l’interface de réplication, nous voudrions savoir quelle est la méthode appropriée en ce qui concerne la spécification de plusieurs passerelles sur un serveur DAG membre ?

R : Je suis heureux que vous ayez demandé avant de décider de configurer plusieurs passerelles en utilisant le GUI. Cela n’est pas pris en charge et aurait créé des problèmes de routage entre les centres de données. Il vous faudra spécifier une passerelle par défaut pour l’interface réseau de réplication.

Auparavant, avec Exchange 2007, vous avez utilisé la commande « Route Add » pour configurer des passerelles par défaut en déployant des clusters multisites Cluster Continuous Replication (CCR) ou des clusters Single Copy Cluster avec des nœuds sur différents sous-réseaux. Avec Windows Server 2008 et Windows Server 2008 R2, les instructions ont un peu changé. Au lieu d’utiliser « Route Add », Microsoft a recommandé aux clients d’utiliser « Netsh » pour configurer la passerelle par défaut.

Avec les serveurs Exchange 2010 membres DAG situés dans des sous-réseaux séparés, vous devriez toujours utiliser Netsh. Vous aurez besoin de créer un itinéraire statique pour le sous-réseau de réplication dans l’autre centre de données avec Netsh. Pour créer un itinéraire statique persistant du sous-réseau 10.10.10.0/24 vers 10.10.11.0/24 en utilisant « Route Add », utilisez la commande suivante :

Route add 10.10.11.0 mask 255.255.255.0 10.10.10.203 –p

Ceci enverra tout le trafic destiné à 10.10.11.0/24 vers la passerelle 10.10.10.203. Cela va ensuite l’acheminer vers les serveurs respectifs sur le sous-réseau 10.10.11.0/24. Pour créer le même itinéraire statique en utilisant Netsh, utilisez la commande suivante :

Netsh interface ipv4 add route 10.10.11.0/24 "REPLICATION" 10.10.10.203

Le nom de l’interface réseau de réplication est « REPLICATION et la passerelle par défaut est 10.10.10.203. Notez qu’avec Netsh, « Route Add » sera créé comme un itinéraire persistant.

Déplacement parallèle des boîtes de réception

Q : Nous venons juste de mettre à niveau nos serveurs Exchange 2010 vers Exchange 2010 SP1. Nous avons constaté que cela déplaçait seulement deux boîtes aux lettres en parallèle par base de données cible. Avec Exchange 2010 RTM, nous avons vu cinq boîtes aux lettres déplacées en parallèle.

Deux questions viennent à l’esprit : Pourquoi le nombre de transferts de boîtes aux lettres en parallèle a-t-il changé avec Exchange 2010 SP1 et pouvons-nous changer cette valeur ?

R : Vous avez raison, les transferts actifs maximum par base de données de boîte aux lettres cible est passé de cinq à deux avec Exchange 2010 SP1. Le nombre maximum de transferts actifs par serveur cible est toujours fixé à cinq. Cela veut dire que si vous déplacez des utilisateurs vers de plusieurs bases de données de boîtes aux lettres cible, vous serez toujours en mesure de déplacer cinq boîtes aux lettres en parallèle par serveur de boîtes aux lettres cible.

Un test interne du groupe de produits Exchange a montré que la possibilité de faire jusqu’à cinq transferts en parallèle par base de données de boîte aux lettres cible pesait beaucoup sur le niveau de disponibilité. Ceci est particulièrement vrai des boîtes aux lettres volumineuses sont déplacées vers un serveur de boîtes aux lettres cible qui est aussi membre d’un DAG.

Vous pouvez modifier la valeur de ce paramètre en fonction de vos besoins et de votre environnement spécifique. Il est conseillé de le maintenir à cinq si vous déplacez de grandes boîtes aux lettres et que vous utilisez un DAG. Toutefois, si vous avez de petites boîtes aux lettres ou si vous utilisez des serveurs de boîtes aux lettres autonomes Exchange 2010, vous pouvez augmenter la valeur à 10 par base de données de boîtes aux lettres cible et 40 par serveur de boîtes aux lettres cible.

Pour changer cette valeur, connectez-vous au CAS Exchange 2010 et ouvrez le fichier MSExchangeMailboxReplication.exe.config dans Notepad (voir Figure 5).

Figure 5 Opening the MSExchangeMailboxReplication.exe.config file in Notepad

Figure 5 Ouverture du fichier MSExchangeMailboxReplication.exe.config dans Notepad

Une fois le fichier ouvert, modifiez les valeurs MaxActiveMovesPerTargetMDB et MacActiveMovesPerTargetServer (voir Figure 6).

Figure 6 Default MaxActiveMovesPerTargetMDB and MaxActiveMovesPerTargetServer values in Exchange 2010 SP1

Figure 6 Valeurs MaxActiveMovesPerTargetMDB et MaxActiveMovesPerTargetServer par défaut dans Exchange 2010 SP1

Une fois les valeurs modifiées, redémarrez le service Microsoft Exchange Mailbox Replication pour qu’elles s’appliquent. Si vous avez plusieurs serveurs CAS Exchange 2010 dans l’entreprise, vous devez bien entendu réaliser les étapes ci-dessus pour chacun d’eux.

Email Henrik Walther

_***Henrik Walther***est un Microsoft Certified Master : MVP Exchange 2007 et Exchange avec plus de 15 ans d’expérience dans le domaine informatique. Il travaille comme architecte technologique pour Timengo Consulting (Microsoft Gold Certified Partner basé au Danemark) et comme rédacteur technique pour Biblioso Corporation (société basée aux États-Unis et spécialisée dans les services de documentation et de localisation gérés). Vous pouvez contacter Walther par courrier électronique à l’adresse v-henwal@microsoft.com. _

Contenu associé