Questions et réponses sur la file d’attente Exchange : Trouvez le message qu'il vous faut
Ce mois-ci, notre file Exchange ordinaire & Un éditorialiste est rejoint par un contributeur invité pour résoudre vos problèmes d'échange plus contrariants.
Henrik Walther
Avec le contributeur invité George Hinterhofer
Suivi des messages
Q. Pouvez vous partager un indice ou deux sur comment vous faire message suivi ? Nous trouvons le GUI pour être d'une utilité limitée. Nous sommes à la recherche des conseils sur la façon d'obtenir les renseignements requis des journaux de suivi des messages.
**R :**À l'aide de Windows PowerShell pour le suivi des messages est la méthode préférable. Il vous donne plus de contrôle sur les paramètres de requête et est beaucoup plus rapide. Un code uniligne typique serait :
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
Cela vous obtiendrait tous les enregistrements de suivi des messages de tous les serveurs de transport dans votre environnement qui ont une adresse envoie de test@contoso.com, 18 mars 2012, à partir de 9 h 00 Si vous voulez exporter les résultats vers un de vos utilisateurs ou les clients, de tuyaux les résultats à l'exportation-CSVcmdlet :
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
Vous voulez creuser dans les résultats pour le dépannage ? Ajouter le format-listcmdlet à la commande :
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
Pour la facilité d'utilisation et d'épargner beaucoup de dactylographie, c'est une bonne idée d'écrire votre propre petite fonction de Windows PowerShell. Cela permet la recherche rapide et efficace. Cet exemple recherche des journaux de tous les serveurs de Transport Hub, accepte –sender en tant que paramètre et recherche les dernières 24 heures une valeur de données :
functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }
N'hésitez pas à adapter cette fonction en fonction de vos besoins. Vous pouvez aussi mettre ce morceau de code dans le fichier $ exécution des profil afin qu'il obtient chargé au démarrage. Dès lors, vous devrez seulement de type :
mt –sender test@contoso.com
Utilisez les mises à jour de correctifs cumulatifs
Q. Nous avons entendu que nous pouvons utiliser le dossier Updates sur le support source d'installation de Exchange 2010 pour installer des correctifs cumulatifs lors de l'installation. Est-ce exact ?
**R :**Oui, c'est exact, au moins partiellement. Vous pouvez utiliser le répertoire des mises à jour pour installer un rollup correspondant au cours d'une nouvelle installation d'Exchange 2010 et réduire le temps d'installation requis. Drop juste le fichier .msp dans le répertoire respectif, comme le montre Figure 1.
.jpg)
La figure 1 ajoutant l'extension .msp dans le répertoire de mises à jour vous permet d'installer un rollup correspondant.
N'essayez pas cela pour une installation de mise à niveau, comme sorti de fabrication pour le deuxième service pack, ou le premier service pack pour le deuxième service pack. Cela ne fonctionnera pas et échouera sur l'installation. Mises à jour devraient être effectués de façon séquentielle, et vous ne peut pas combiner de la même manière. Il n'y a plus d'informations sur la page TechNet Library, «installer le dernier correctif cumulatif pour Exchange 2010. »
SP1 ou SP2 ?
Q. Nous avons amélioré nos serveurs Edge d'Exchange 2010 pour le deuxième service pack. L'installation terminée sans erreur. Cependant, en regardant les numéros de build avec Get-ExchangeServer, elles montrent encore que 14.1.xx, aka SP1. Que s'est-il passé ici ?
**R :**C'est un peu trompeur, mais comportement réellement attendu. Une fois un abonnement Edge est en place, Microsoft n'est pas mise à jour des numéros de build dans le cadre du processus EdgeSync régulière. Si jamais vous devez refaire l'abonnement complet (par exemple, si votre certificat utilisé pour EdgeSync expire), vous verrez que les numéros de build seront ainsi mise à jour.
Autorisations des retards
Q. Lorsque j'essaie d'accorder des autorisations de boîte aux lettres pleine à une boîte aux lettres dans Exchange 2010, la liste des boîtes aux lettres prend beaucoup de temps à remplir (allant de plusieurs minutes à heures). Est-ce là tout ce qui peut être fait à ce sujet ?
**R :**Il s'agit d'une question commune. La raison de la fenêtre « Sélectionnez les comptes » remplir lentement est illégitime LDAP interrogation. Vous êtes toutes les boîtes aux lettres de l'extraction et appliquer le filtre par la suite. Si vous étaient à la recherche d'une boîte aux lettres nommée « Fred », par exemple, vous d'abord obtiendrez une liste de toutes les entités de sécurité. Alors vous serait vérifier par la suite pour voir si une de celles-ci est de Fred. Ce processus est douloureusement lent, surtout dans les installations de grand nombre d'utilisateurs.
Heureusement, assez, améliorations de sécurité pour Microsoft Exchange, ou Exchange(SE), a décidé de résoudre ce problème dans le cumulatif plus grand et les plus récent pour Exchange 2010 SP2, à savoir Rollup 1. Le lien direct vers le correctif est ici.
Authentification intégrée
Q. Nous essayons d'activer l'authentification intégrée Windows pour Exchange Outlook Web App (OWA) pour obtenir une single sign-on expérience décente pour nos clients internes, a rejoint le domaine. Les clients ont accès à une URL d'équilibre de charge réseau (NLB) appelée https://mail.contoso.com.
Nous avons désactivé le premier Boot Agent et activé l'authentification intégrée de Windows sur les répertoires virtuels OWA. Toutefois, lorsque vous tentez d'accéder à https://mail.contoso.com/owa, nous sommes toujours invités informations d'identification. Lorsque nous avons accès aux pages de OWA en entrant directement une URL de Service d'accès Client (CAS), comme https://cas1.contoso.com/owa ou https://cas2.contoso.com/owa, nous avons connectés avec aucun invites. Pour le rendre même drôles, si nous saisir l'IP résolue de mail.contoso.com, dans notre cas https://10.1.1.150/owa, nous sommes aussi connectés avec aucune authentification. Avez-vous des conseils ?
R : Après avoir travaillé à ma façon de haut en bas par une trace Netmon et Fiddler, j'ai remarqué que finalement un changement dans les méthodes d'authentification utilisées (vous pouvez le voir dans Fiddler) quand je suis passé de https://10.1.1.150/owa (travail, incitant ne pas) à https://mail.contoso.com/owa (incitant).
Il s'avère que tout en accédant à l'adresse IP résolue, nous utilisions Windows NT LAN Manager pour s'authentifier auprès de OWA. Lors du passage à l'équilibrage de charge réseau entièrement qualifié nom de domaine, nous avons commencé à utiliser Kerberos pour aller à l'encontre de la CAS.
Un peu plus creusage et habile utilisation de setspn.exe – l a révélé que quelqu'un avait ajouté une entrée de nom Principal de Service (SPN) appelée http/mail.contoso.com pour un compte d'ordinateur totalement indépendants. Cette ordinateurs client à son tour fait aller un ticket Kerberos (car une entrée correspondante a été trouvée dans Active Directory) et ensuite présentent le ticket de la zone de CAS. La boîte de CAS avait manifestement aucune idée quoi faire avec un ticket Kerberos délivré à certaines zone complètement différent, donc il a jeté une invite d'authentification répétées.
Une fois l'entrée SPN fausse a été supprimée, l'authentification intégrée de Windows commence à travailler immédiatement contre l'URL NLB et l'invite d'authentification avait disparu.
Avis de non-responsabilité discorde
Q. Nous essayons de créer une règle de transport pour ajouter un avertissement à tous les messages sortants. Au cours des essais, nous avons découvert que les boîtes de Transport semblent ignorer la règle. Il n'a pas ajouter la création souhaitée, même après le redémarrage de toutes les cases de Hub pour s'assurer qu'ils ont chargé en fait la règle. Cependant, la même règle fonctionne comme un charme dans notre environnement de test. Vous avez des idées ?
R : La règle actuelle pour exercer cette fonction ressemble à ce qui est montré dans Figure 2.
.jpg)
La figure 2 cette règle visait à ajouter un avertissement à la fin des messages sortants.
Après avoir vérifié les suspects habituels comme la réplication, le service de transport pas au courant de tout changement et ainsi de suite, tout semblait bon. Puis nous avons vérifié ExTRA de traçage pour capturer un .etl du moteur de règles pendant le traitement d'e-mails sortants.
Le .etl a révélé que le service de transport était parfaitement au courant de la nouvelle règle de transport, mais pour une raison quelconque ne reconnaître les mails sortants comme « sortant ». Pour une raison quelconque, ils étaient traités comme internes.
Autre suivi a révélé le moteur de règles, considéré comme l'entrée « Domaine distant par défaut » dans les domaines distants comme interne. Par conséquent, il n'a pas appliquer la règle de la limitation de responsabilité.
En regardant dans la question, j'ai remarqué qu'il dit IsInternal:$ true pour le domaine distant par défaut. Cela indique à Exchange pour traiter tout le courrier à un espace d'adressage * en interne — et s'applique donc pas la limitation de responsabilité. Nous l'avons changé à la valeur par défaut false. Aujourd'hui, les avertissements sont appliquées avec succès.
.jpg)
.jpg)
Henrik Walther est un Microsoft Certified Master : Exchange 2007 et un MVP Exchange, avec plus de 16 ans d'expérience dans le domaine informatique. Il travaille comme architecte technologique pour un Microsoft Gold Certified Partner au Danemark et comme un rédacteur technique pour Biblioso Corp. (une société américaine spécialisée dans la gestion services de documentation et de localisation). Il est aussi un vendeur sous contrat de travail sur les différentes équipes de produit (y compris les équipes Exchange et Lync) à Microsoft.
Georg Hinterhofer est un maître certifié de Microsoft Exchange 2010. Il travaille comme ingénieur principal champ de premier ministre, en se concentrant sur uniquement sur Microsoft Exchange. Il est basé en Autriche, près de Vienne.