File d'attente d'Exchange & A: Exchange est en constante évolution
Si la modification de jours de calendrier par défaut, les points de terminaison de centre de données ou de la redirection des serveurs, vous devez toujours être prêt à apporter des modifications à Exchange.
Henrik Walther
Le Blues lundi
Q. Nous sommes une grande organisation européenne et que vous venez de migrer à partir d'IBM Lotus Domino vers Microsoft Exchange 2010. La plupart de nos utilisateurs utilisent Outlook Web App 2010 comme leur client de messagerie par défaut. Plusieurs utilisateurs ont observé « Dimanche » est la valeur par défaut premier jour de la semaine défini sous Paramètres | Calendrier dans le panneau de configuration Exchange (voir Figure 1).
.jpg)
Figure 1 la valeur par défaut le premier jour de la semaine pour une boîte aux lettres Exchange 2010.
Étant donné que lundi est considéré comme le premier jour de la semaine de travail dans la région, nous voulons modifier ce paramètre pour tous les utilisateurs Exchange 2010 dans l'organisation. Pouvons-nous nous utilisons le console de gestion Exchange (EMC) ou Exchange Management Shell (EMS) pour ce faire de manière centralisée à tous nos utilisateurs ? Nous avons présenté sur la page de propriétés des boîtes aux lettres EMC et même via EMS en utilisant le cmdlet Get-Mailbox, mais nous ne pouvons pas voir tous les attributs relatifs au premier jour de la semaine. Avez-vous des conseils ?
**R :**Lundi étant le premier jour de la semaine de travail dans la plupart des pays européens, je comprends votre frustration. Heureusement, il est relativement facile de modifier ce paramètre pour tous vos utilisateurs. Vous ne pouvez rien faire à l'aide d'EMC, mais vous pouvez certainement faire avec Exchange Management Shell (EMS). La plupart serait pense que vous devez utiliser la cmdlet Set-Mailbox pour modifier ce paramètre. En fait, vous devez utiliser la cmdlet Set-MailboxCalendarConfiguration.
Exécutez la commande suivante, et vous verrez tous les paramètres de calendrier spécifiques vous pouvez manipuler pour une boîte aux lettres (voir Figure 2) :
Get-MailboxCalendarConfiguration –Identity <user> | fl
.jpg)
Figure 2 Modifier la valeur par défaut le premier jour de la semaine via le Shell de gestion Exchange.
Si vous souhaitez modifier le « WeekStartDay » pour le lundi pour tous les utilisateurs dans l'organisation Exchange 2010 qui avait « Contoso » dans l'attribut de la société (par exemple), utilisez la commande suivante :
Get-User –Filter "Company –eq 'Contoso'" | Set-MaiboxCalendarConfiguration –WeekStartDay “Monday”
Retour au centre
Q. Nous avons exécutant Exchange 2010 pour environ un an maintenant. Nous sommes une grande organisation, et jusqu'à présent, nous avons eu un unique centre de données qui héberge notre solution de messagerie de Exchange 2010. Nous avons créé un centre de données supplémentaire afin que nous pouvons atteindre la résilience de boîte aux lettres au niveau du site. Il y aura actives utilisateurs se connectant à deux centres de données, afin que nous avons créé un tableau de serveur d'accès Client (tableau d'autorités de certification) de l'autre centre de données.
Nous avons déjà déplacé les 100 premiers utilisateurs au nouveau centre de données pour vérifier les choses fonctionnent comme prévu. Nous ne sommes pas tout à fait il. Nous voyons les problèmes liés à la présence de terminaison client MAPI Outlook modifié de « outlook-1.contoso.com"(autorités de certification tableau objet nom de domaine complet dans le premier centre de données) à « outlook-2.contoso.com » (nouvel autorités de certification tableau objet nom de domaine complet du nouveau centre de données).
Les clients Outlook MAPI est simplement continuent à utiliser le point de terminaison ancienne, ce qui signifie que les clients Outlook créer des sessions RPC dans le tableau des autorités de certification dans le premier centre de données et de la baie d'autorités de certification communique ensuite avec RPC avec les serveurs de boîtes aux lettres dans le nouveau centre de données. Toute idée si cela est intentionnel ? Si ce n'est pas le cas, avez-vous une idée de comment nous pouvons corriger ?
**R :**Certaines files d'attente Exchange & Un lecteurs seront souviendra que j'ai touché ce sujet avant. Lorsque vous déplacez des boîtes aux lettres à partir d'un centre de données avec un tableau d'autorités de certification sur un autre centre de données avec un autre tableau de CAS, vous ne voulez pas que rendre l'ancien point de terminaison insolubles/indisponible. Cela aura un impact sur tous les utilisateurs qui sont actives dans le premier centre de données.
La solution de contournement — bien qu'il n'est pas joli — est mise à jour le profil MAPI Outlook pour les utilisateurs qui disposaient de leur boîte aux lettres déplacée vers le nouveau centre de données (à l'aide de l'option « Réparer profil » dans Outlook. par exemple).
Certains d'entre vous demanderez peut-être pourquoi Exchange 2010 se comporte de cette manière. Cela fonctionne parfaitement avec les versions antérieures d'Exchange. Les clients MAPI Outlook maintenant se connectent au service d'accès Client RPC (service d'autorité de certification RPC) sur le rôle de serveur d'accès Client, pas directement à la banque sur le rôle de serveur de boîtes aux lettres.
Dans Exchange 2007 et versions antérieures, lorsque vous avez déplacé une boîte aux lettres à partir de la base de données d'une boîte aux lettres vers un autre, il en résulterait dans la base de données de boîte aux lettres source envoie un « ecWrongserver » pour le client Outlook. Qui a forcé à localiser la boîte aux lettres dans la base de données dans lequel la boîte aux lettres est désormais stockée.
Le service RPC CA ne peut pas répondre avec un « ecWrongServer » lorsqu'un * sur (commutateur de base de données ou de basculement) se produit entre deux centres de données (et le service d'autorité de certification RPC est disponible). De même, il ne peut pas répondre si vous déplacez une boîte aux lettres à partir d'une base de données de boîtes aux lettres dans un centre de données sur une base de données de boîtes aux lettres dans un autre, où l'attribut RpcClientAccessServer de la base de données cible contient une autre entièrement qualifié nom de domaine (FQDN).
Pendant le développement de Exchange 2010 SP1, il y avait plans visant à introduire une option « Autoriser Cross Site RPC Accès Client » dite que vous configureriez pour un groupe de disponibilité de base de données (DAG). Cette option a été jugée excessivement complexe, et a été coupé droite avant livraison Exchange 2010 SP1.
Nous pouvons coexister ?
Q. Nous avons déployé Exchange 2010 dans notre organisation Exchange 2003. Nous planifions actuellement au point de l'espace de noms que nous utilisons pour accéder à une boîte aux lettres dans Exchange 2003 dans le tableau des autorités de certification Exchange 2010. Nous avons déjà ajouté un FQDN hérité (legacy.contoso.com) pour le certificat de SAN/communications unifiées et nous avons configuré l'URL héritée sur le répertoire virtuel OWA 2010.
Nous avons délestage SSL sur la solution d'équilibreur de charge qui distribue le trafic client sur les autorités de certification. Nous avons également suivi les étapes de cette l'article TechNet Wiki pour configurer le déchargement SSL sur les serveurs Exchange 2010 CA. Le déchargement SSL n'est pas activé sur les serveurs frontaux (FE) Exchange 2003.
Nous ne savons d'indique si le déchargement SSL fonctionne dans un scénario de coexistence, où les clients se connectent aux serveurs Exchange 2010 CA et sont redirigés vers les serveurs Exchange 2003 FE. Savez-vous si ce scénario fonctionnera ?
**R :**Oui, les utilisateurs OWA 2003 accèdent à leurs boîtes aux lettres en authentifiant contre les serveurs Exchange 2010 CA qui redirigent la session à des serveurs Exchange 2003 FE. Cela fonctionne même avec SSL est activé sur la solution d'équilibrage de charge et les serveurs Exchange 2010 CA.
Certains d'entre vous pourraient s'attendre à une autre réponse. Exchange 2003 URL configurée sur le répertoire virtuel OWA 2010 doit être sous forme de « https://legacy.contoso.com/exchange » et non « http://legacy.contoso.com/exchange ». Sinon, vous obtiendrez un 91 d'ID d'événement dans le journal d'Application (voir Figure 3).
.jpg)
Figure 3 erreur dans le journal des applications héritée URL est configuré avec HTTP, au lieu de HTTPS.
L'héritage URL doit commencer par HTTPS et non HTTP. Dans la mesure où les serveurs Exchange 2010 CA redirigent simplement la session du client à un serveur Exchange 2003 FE, il fonctionnera correctement lorsque vous utilisez HTTPS pour l'URL hérité de OWA.
File d'attente de copie
Q. Lorsque je travaille avec divers scénarios Exchange 2010 Diacylglycérol (généralement dans des environnements de laboratoire), je vois parfois une longueur de file d'attente de copie extrêmement élevé (voir Figure 4).
.jpg)
Figure 4 une file d'attente de copie extrêmement élevée est toujours une possibilité.
La première fois que j'ai remarqué qu'elle je pensais, « ce que la? » Une étude plus approfondie, je peux voir qu'il est le même nombre exact de chaque fois qu'elle ne survienne. Savez-vous s'il s'agit d'un bogue ou quelque chose ?
**R :**Le nombre que vous voyez est la valeur plus élevée, vous pouvez définir pour la longueur de file d'attente de copie. Copie du journal n'est pas lieu et les mises à jour de base de données de cluster ne sont pas effectuée. Une perte de connectivité réseau entre les nœuds de Diacylglycérol généralement provoque quelque chose comme ceci.
Dans un environnement de laboratoire lente, cela peut se produire à l'occasion. Vous ne devrait pas l'afficher dans un environnement de production, cependant. Si vous le faites, je vous recommande de tenter de trouver la cause de perdre la connectivité réseau entre les nœuds de Diacylglycérol...
.jpg)
**Henrik Walther**est un objet Microsoft Certified Master : Exchange 2007 et MVP Exchange, avec plus de 16 années d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour un partenaire Microsoft Gold Certified au Danemark et comme rédacteur technique pour Biblioso Corp. (société américaine qui se spécialise dans managed services documentation et de localisation). Il est également un fournisseur sous contrat travaillant sur les diverses équipes de produit (y compris les équipes Exchange et Lync) chez Microsoft.