Exchange Queue & A Taille de pièce jointe mysterious augmente, réplication de dossiers publics, etc.

Henrik Walther

Questions-réponses sur infrastructure de messagerie de notre organisation est basé sur Exchange Server 2007. Nous avons une limite de taille de messages relativement stricte de 12 Mo défini dans l'organisation.

Nous a observé un comportement étrange qui semble être lié à la taille des fichiers joints à un message. Lorsque vous envoyez un message électronique à un utilisateur externe, nous allons par exemple, pièce jointe 11MB, le message est remis au destinataire comme prévu. Mais si ce message (y compris la pièce jointe) est transmis à l'expéditeur sur le réseau interne, l'expéditeur reçoit un rapport de non-remise (NDR), indiquant que le message est supérieur à la limite système en cours ou que boîte aux lettres du destinataire est pleine.

Après avoir reçu un oeil fermer le problème, nous pouvons voir que à un moment donné une fois le message quitte l'organisation, la taille de la pièce jointe augmente à environ 30 %. La question est : pourquoi ne jointe taille augmenter tout en envoyer et recevoir des messages électroniques via Internet ? Et plus important, ce comportement est normal ?

A la réponse brève est Oui. Cela est souvent comportement attendu, non seulement pour Exchange Server 2007, mais également pour les versions antérieures d'Exchange Server, ainsi que tout autre système de messagerie qui prend en charge MIME (Multipurpose Internet Mail Extensions) et utilise le codage base64 pour coder les pièces jointes. Lorsqu'un utilisateur Exchange interne envoie un message à un destinataire de l'organisation Exchange, le message ne nécessite pas de conversion de contenu. Cela signifie que vous ne voyez le message ou les pièces jointes augmentation taille lorsqu'ils sont remis. Messages envoyés aux destinataires externes, d'autre part, peuvent nécessiter conversion de contenu.

Un message SMTP standard (également connu sous le nom, un message texte brut) se compose d'une enveloppe de message et le contenu du message, l'en-tête de message et le corps du message. Ces éléments sont basés sur simple texte de US-ASCII 7 bits. Lorsqu'un message contient des éléments qui ne sont pas simple texte US-ASCII, les éléments doivent être codées. Lorsque vous traitez des tel contenu non textuels, y compris les pièces jointes, MIME est utilisé pour codage. À la fois Exchange 2007 et des versions antérieures d'Exchange Server à utilisent l'algorithme en base64 pour coder les pièces jointes. Et l'inconvénient de codage Base64 est qu'il bloats les pièces jointes par 33 %.

Dans Exchange 2007, sauf lorsque Outlook Web Access est utilisée, en plus de transport liés conversion de contenu est effectuée sur le serveur de transport Hub. Pour une explication détaillée, voir la rubrique « conversion de contenu présentation » à technet.microsoft.com/library/bb232174.

q: nous sont en milieu d'une transition à partir de Microsoft Exchange 2003 vers Exchange 2007. Nous a déplacée toutes les boîtes aux lettres utilisateur vers les serveurs de boîtes aux lettres Exchange 2007, qui ont été configurés à l'aide de continue réplication des clusters (CCR). Nous avons actuellement répliquez tous les dossiers publics à partir de notre serveur de dossiers publics Exchange 2003 hérité vers un serveur de boîtes aux lettres en fonction de CCR. Cependant, nous avons découvert au cours des tests que lorsqu'un basculement avec perte se produit sur le cluster CCR, la base de données de dossiers publics n'est pas mis en ligne sur l'autre nœud. Nous avons également ne peut pas monter manuellement après le basculement.

Nous avons un environnement de laboratoire qui reflète notre infrastructure Exchange 2007 dans l'environnement de production et de test indique que ce problème se produit ici ainsi. Nous ne pas voir ce problème avec des bases de données des boîte aux lettres sur des clusters CCR sur lequel un basculement avec perte se produit, donc il semble à relier strictement aux bases de données de dossiers publics sur clusters CCR. Puisque nous souhaitons atteindre redondance cette propriété a la valeur true pour toutes les bases de données, y compris la base de données de dossiers publics, vous avez tout vision que serait provoquer ce problème ?

A les méthodes de réplication utilisé par le CCR et par la réplication de dossiers publics dans Exchange 2007 sont deux choses très différentes. De ce fait, il n'est pas recommandé que vous combinez plusieurs bases de données dossiers publics dans une organisation Exchange avec serveurs de boîtes aux lettres en fonction de CCR, si une des dossiers publics bases de données est hébergée sur un serveur de boîtes aux lettres en fonction de CCR. En fait cela pendant une transition, et le groupe de produits Exchange prend en charge avoir une base de données de dossiers publics hébergé sur un serveur de boîtes aux lettres en fonction de CCR et, par exemple, un serveur Exchange 2003 hérité. Mais il est vivement recommandé que vous supprimez la base de données dossiers publics sur le serveur non CCR en fonction de boîte aux lettres après tout public dossier données a été répliqué.

Ce que vous rencontrez dans votre environnement de messagerie Exchange est normal. Lorsque vous avez plusieurs bases de données dossier public et qu'un d'entre eux est hébergé sur un serveur de boîtes aux lettres en fonction de CCR, la base de données dossiers publics sur le serveur en fonction de CCR boîte aux lettres ne pas être mise en ligne pendant un basculement avec perte (c'est-à-dire, une panne non planifiée).

En fait, la base de données de dossiers publics ne peut pas être mis en ligne avant le nœud actif précédemment s'affiche à nouveau. En outre, tous les fichiers de journaux transaction pour le groupe de stockage dans lequel la base de données de dossiers publics est hébergé doivent être disponibles.

Si ce n'est pas une option, la première ligne de défense doit être pour restaurer la banque de dossiers publics à partir de la dernière sauvegarde bonne, lu les journaux disponibles et puis reseed l'autre nœud à partir de la base de données restaurée. Sinon, la banque de dossiers publics a pu être créée à partir de zéro. Dans ce cas, le nœud actif d'origine doit être récupéré et une nouvelle base de données dossier public doit être créée et ont données de dossiers publics répliqués à partir un autre serveur de dossiers publics de l'organisation Exchange.

Ce qui peut sembler étrange est que lorsqu'une panne (planifiée) sans perte est effectuée, la base de données de dossiers publics est mis en ligne. Ce comportement est normal. Pour plus plus d'informations voir « cluster continue réplication et publics bases de dossier données » sur le « Planification de réplication continue en cluster."

Questions-réponses sur tous les serveurs de boîtes aux lettres au sein de notre infrastructure de messagerie Exchange 2007 sont configurés à l'aide de CCR. Nous sommes très satisfaits de la CCR fonctionne, mais vous avez une question nous espérons que vous pouvez répondre.

Lorsque la maintenance en ligne est exécutée chaque nuit, une des tâches est la défragmentation en ligne. Comment nous assurer que les bases de données sur le nœud passif dans un cluster CCR obtenir défragmentés au cours de maintenance en ligne ?

A la défragmentation en ligne tâche, qui supprime les éléments marqués pour suppression et puis active l'espace utilisé par ces éléments dans espace blanc, génère des nouveaux fichiers journaux des transactions au cours du processus. Les fichiers journaux de transactions générés sur le nœud actif CCR seront répliqués vers le noeud passif, débouche les modifications en cours d'exécution aux bases de données sur le nœud passif.

Par conséquent, assurez-vous que vous planifiez la fenêtre de maintenance en ligne afin que qu'il n'est pas en conflit avec votre fenêtre de sauvegarde, comme cela force la défragmentation en ligne pour s'arrêter. Non, que la défragmentation doit nécessairement compléter tous les jours, toutes les semaines ou même toutes les deux semaines d'ailleurs. Dans le passé, conseils du groupe produit Exchange spécifié ayant la défragmentation en ligne effectuer au moins chaque semaine deuxième. Mais qui est modifié dans Exchange Server 2007 SP1 comme environnement de chaque organisation est différent. Pour des détails plus sur ces nouvelles instructions, voir la rubrique la publication sur le Blog de l'équipe Microsoft Exchange.

q: nous vous intention d'utiliser CCR Exchange 2007 afin d'atteindre redondance cette propriété a la valeur true pour nos serveurs de boîtes aux lettres. Actuellement, nous vous recherchez dans comment le transport benne est utilisée conjointement avec le CCR afin de garantir qu'aucun message n'est perdues pendant un basculement avec perte à partir du nœud CCR actif vers le noeud passif. Savez-vous de n'importe quel transport benne problèmes nous devez être conscient des ?

A le transport benne garantit que vous avez une perte de données minimales pendant un basculement avec perte d'un nœud à un autre sur un serveur de boîtes aux lettres Exchange 2007 qui utilise CCR. Pour cela en redelivering messages qui ont été récemment envoyées au serveur boîte aux lettres. Un basculement avec perte, il est probable réel vous perdez certaines transactions fichiers journaux et, en raison de cette, données réelles ainsi. Comme indiqué, le transport benne redelivers les messages qui ont été récemment envoyées au serveur boîte aux lettres et ce qui garantit que les données perdues lors de l'échec avec perte sont restaurées. Toutefois, car il est Seuls les messages qui sont livrés par le serveur de transport Hub sur laquelle le transport benne réside, données tels que Calendrier des tâches et éléments créés sur le basculement avec perte seront perdues.

q: nous actuellement envisagez une migration à partir d'une organisation Exchange 2003 cross-forest à une organisation Exchange 2007 dans une nouvelle forêt Active Directory. Nous ont largement étudié la documentation de migration cross-forest » Comment accéder à partir de la forêt unique à entre les forêts», qui indique que vous devez créer une approbation de forêt et pas une approbation externe entre les forêts. Pourquoi est-ce qu'une approbation externe ne peut pas être utilisée ?

un même si la documentation Exchange 2007 sur TechNet indique que vous devez utiliser une approbation de forêt plutôt qu'une approbation externe, cela ne signifie que vous ne pouvez pas utiliser une approbation externe. En fait, une approbation externe fonctionne parfaitement pour une migration de Exchange cross-forest, mais il existe un inconvénient. Vous devez spécifier un compte avec les autorisations appropriées d'accéder un contrôleur de domaine dans la forêt fiable lors de la création d'une boîte aux lettres liée (voir figure 1 ), car vous ne pouvez pas utiliser les informations d'identification de journalisé, sur utilisateur, quel que les autorisations ont été affectées à.

Figure 1 spécification d'un compte sur la page compte principal lorsque vous créez une boîte aux lettres liée

Questions-réponses sur notre organisation uniquement transférée vers Exchange 2007, et jusqu'à présent nous sont très heureux avec la nouvelle version, avec une exception possible. Retour lorsque nous ont été utilisez Exchange 2003 SP2, nous avons pas configurer notre environnement de sorte que le nom affiché simple d'une boîte aux lettres utilisateur a été indiqué comme expéditeur de message sortant. À notre dismay, nous n'ont pas été en mesure de trouver une fonctionnalité similaire dans Exchange 2007. Veuillez ne signifie nous qu'elle est manquant dans Exchange 2007 !

A Cette fonctionnalité était, en fait, manquant dans Exchange 2007 RTM, droite jusqu'à Exchange 2007 SP1 report mise à jour 4 (RU4) a été publiée en octobre 2008. Avec Service Pack 1 RU4, vous pouvez là encore, comme avec Exchange 2003 SP2, configurer Exchange pour afficher le nom affiché simple dans les messages sortants. Cette tâche peut être réalisée à l'aide de la cmdlet Windows PowerShell Set-RemoteDomain avec le paramètre –Use­SimpleDisplayName. Par exemple, pour activer l'affichage simple des noms de messages sortants qui sont envoyés vers le domaine contoso.com, utilisez la commande illustrée figure 2 .

La figure 2 Affichage simple à l'aide de noms pour les messages sortants

q: quel est la meilleure pratique pour défragmenter les copies de la base de données sur le nœud passif sur un serveur de boîte aux lettres Exchange 2007-CCR-base ? Exchange va devenir confondu si les bases de données sur un des nœuds dans le CCR sont défragmentés, mais ce sur les autres nœuds ne sont pas ?

A si une défragmentation hors connexion est requise, elle doit toujours être effectuée sur le nœud actif dans le cluster CCR, jamais sur le nœud passif. N'oubliez pas également que si vous effectuez une défragmentation hors connexion d'une ou plusieurs bases de données sur le nœud actif, un réamorçage complet des bases de données particuliers vers le noeud passif est requis.

Cela signifie, par exemple, que si vous disposez d'une base de données 200GB (lorsque vous utilisez le CCR, la taille de base de données recommandé est 200GB lors de la réplication sur un réseau de 1 Go), il va prendre plusieurs heures pour défragmenter elle (une règle couramment adoptée est 2 à 4 Go par heure). Mais une fois le processus de défragmentation est terminée, vous devrez également répliquer 200GB de données vers le nœud passif. Si l'envoi de fichiers journaux se produit sur le réseau public, ce peut influer sur les les performances réseau globale rencontrés par vos utilisateurs finaux.

Dans la plupart des cas, le motif d'effectuant une défragmentation off­line consiste à supprimer tout espace blanc dans la base de données pour réduire la taille de la base de données. Mais c'est rarement nécessaire puisque l'espace blanc sera réutilisée avant une base de données augmente plu. Et peu très si vous disposez de l'espace disponible dans la base de données ou sur le disque lui-même, ne ?

Vous avez plusieurs gigaoctets d'espace blanc dans une base de données et que vous souhaitez supprimer, une bien meilleure approche doit déplacer toutes les boîtes aux lettres de la base de données et dans un autre.

Henrik Walther est un Microsoft Certified Master : Exchange 2007 et MVP Exchange ayant des plus de 14 années d'expérience dans l'entreprise informatique. Il travaille comme architecte technologique pour Interprise conseil (un partenaire Microsoft Gold basé dans Danemark) et comme un rédacteur technique pour Biblioso Corporation (une société en fonction d'américain spécialisée dans les services gérés documentation et de localisation).