Exchange Fragen & Antworten: Erhalten Sie die passende Meldung
In diesem Monat unsere regelmäßige Exchange Queue & Kolumnist ist durch ein Gast Beitrag zu Ihren am meisten ärgerlich Exchange-Problemen verbunden.
Henrik Walther
Mit Gast-Le George Hinterhofer
Nachrichtenverfolgung
F: Können Sie gemeinsam einen Hinweis oder zwei auf wie Sie Verfolgung dieser Meldung zu tun? Wir finden die GUI von begrenztem Nutzen sein. Wir suchen Ratschläge, wie man die erforderliche Informationen aus der Nachrichtenverfolgung Protokolle.
**Antwort:**Mithilfe von Windows PowerShell für die Nachrichtenverfolgung ist der vorzuziehen Ansatz. Es gibt Ihnen mehr Kontrolle über den Abfrageparametern und ist viel schneller. Ein typischer Einzeiler wäre:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
Dies würde Sie alle Nachrichtentracking Datensätze aus allen Transport-Servern in Ihrer Umgebung erhalten, die eine sendende Adresse des test@contoso.com, ab 18. März 2012, 9 Uhr Wenn Sie einem Benutzer oder Kunden die Ergebnisse exportieren möchten, leiten Sie die Ergebnisse in die Export-CSVcmdlet:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
Möchten Sie in die Ergebnisse für die Problembehandlung zu graben? Fügen Sie den Befehl Format-Listcmdlet:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
Zu erleichtern und eine Menge Tipparbeit zu ersparen ist es eine gute Idee, eine eigene kleine Windows PowerShell-Funktion zu schreiben. Dies ermöglicht schnelle und effektive Suche. In diesem Beispiel wird suchen Protokolle von allen Hub-Transport-Servern, –sender als Parameter akzeptieren und suchen die letzten 24 Stunden im Wert von Daten:
functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }
Fühlen Sie sich frei, diese Funktion an Ihre Bedürfnisse anzupassen. Sie können auch dieses Stück Code in der $ PS1 Profildatei setzen, so dass es beim Start geladen wird. Dann müssten Sie nur geben:
mt –sender test@contoso.com
Updates für Rollups verwenden
F: Wir haben gehört, dass wir Ordner Updates auf dem Quellmedium Exchange 2010 Installation zum Installieren von Rollups während der Installation verwenden können. Ist dieser genau?
**A.**Ja, das stimmt – zumindest teilweise. Im Updates-Verzeichnis können Sie einen passenden Rollup während einer Neuinstallation von Exchange 2010 installieren, und reduzieren die erforderliche Installationszeit. Werfen Sie einfach die MSP-Datei in das entsprechende Verzeichnis, wie in Abbildung 1.
.jpg)
Abbildung 1 die MSP in das Updates-Verzeichnis hinzufügen, können Sie einen passenden Rollup installieren.
Versuchen Sie nicht dieses für eine Upgrade-Installation, z. B. für das verarbeitende Gewerbe, das zweite Servicepack oder das erste Servicepack, das zweite Servicepack veröffentlicht. Dies wird nicht funktionieren und auf Installation fehl. Aktualisierungen müssen nacheinander ausgeführt werden, und Sie können sie nicht auf diese Weise kombinieren. Gibt es weitere Informationen auf der TechNet-Bibliothek-Seite, "Installieren Sie das aktuellste Updaterollup für Exchange 2010."
SP1 oder SP2?
F: Wir haben unsere Exchange 2010 Edge Server auf das zweite Servicepack aktualisiert. Die Installation ohne Fehler abgeschlossen. Allerdings zeigen bei der Betrachtung der Build-Nummern mit Get-ExchangeServer sie noch als 14.1.xx, aka SP1. Was ist hier schief gelaufen?
**A.**Dies ist ein wenig irreführend, aber eigentlich erwartet. Nachdem ein Edge-Abonnement vorhanden ist, aktualisiert nicht Microsoft Build-Nummern als Teil des regulären EdgeSync-Prozesses. Wenn Sie jemals brauchen werden, um das gesamte Abonnement (z. B., wenn Ihr für EdgeSync verwendete Zertifikat abläuft) zu wiederholen, sehen Sie, dass die Build-Nummern ebenfalls aktualisiert werden.
Berechtigungen Verzögerungen
F: Wenn ich versuche zu gewähren vollständige Postfachberechtigungen für ein Postfach in Exchange 2010, die Liste der Postfächer dauert eine lange Zeit zu füllen (überall von einigen Minuten bis Stunden). Gibt es etwas, das über das getan werden kann?
**A.**Dies ist eine häufig gestellte Frage. Der Grund für das "Konten wählen" Fenster so langsam fehlerhafte LDAP Abfragen ist auffüllen. Sie alle Postfächer abrufen, und danach der Filter angewendet. Wenn Sie ein Postfach mit dem Namen "Fred" gesucht wurden, beispielsweise erhalten zuerst eine Liste der alle Sicherheitsprinzipale Sie. Dann würde Sie danach überprüfen, ob einer von denen ist Freds. Dieser Prozess ist schmerzlich langsam, vor allem in großen Anzahl Benutzer-Installationen.
Zum Glück hat genug, Security Enhancements für Microsoft Exchange, oder Exchange(SE), zur Behebung dieses Problems in der spätesten und größten Rollup für Exchange 2010 SP2, nämlich Rollup 1. Der direkte Link zur ansetzen ist hier.
Integrierte Authentifizierung
F: Wir versuchen zu aktivieren Sie integrierte Windows-Authentifizierung für Exchange Outlook Web App (OWA), eine anständige einzige anmelden Erfahrung für unsere internen, Domäne Kunden erhalten. Kunden greifen genannt https://mail.contoso.com URL ausgeglichen (Network Load Balancing, NLB).
Wir ersten Boot-Agent deaktiviert und integrierte Windows-Authentifizierung für das virtuelle OWA-Verzeichnisse aktiviert. Jedoch sind beim Zugriffsversuch auf https://mail.contoso.com/owa, wir noch zur Eingabe von Anmeldeinformationen aufgefordert bekommen. Wenn wir die OWA-Seiten zugreifen, indem Sie direkt eine Client Access Service (CAS) URL, wie z. B. https://cas1.contoso.com/owa oder https://cas2.contoso.com/owa, sind wir keine Aufforderungen angemeldet. Um zu machen, noch seltsamer, wenn wir die aufgelöste IP "Mail.contoso.com", geben Sie in unserem Fall https://10.1.1.150/owa, sind wir auch ohne Authentifizierung angemeldet. Können Sie weiterhelfen?
A. Nach der Arbeit meinen Weg rauf und runter durch Netmon und Fiddler Spuren, bemerkte ich schließlich eine Änderung der verwendeten Authentifizierungsmethoden (sehen Sie diese in Fiddler) wenn ich wechselte von https://10.1.1.150/owa (arbeiten, nicht Aufforderung) zu https://mail.contoso.com/owa (Aufforderung).
Es stellt sich heraus, dass beim Zugriff auf die IP-Adresse aufgelöste, wir Windows NT LAN-Manager zur Authentifizierung gegenüber OWA. Beim Wechsel zu den NLB Fully Qualified Domain Name, begannen wir, die Kerberos verwenden, gehen gegen die CAS.
Ein wenig mehr graben und clevere Nutzung von setspn.exe l ergab, dass jemand einen (Service Principal Name, SPN) Eintrag mit der Bezeichnung http/mail.contoso.com zu einem völlig unabhängigen Computerkonto hinzugefügt hatte. Diese wiederum aus Clientcomputer gehen für ein Kerberos-Ticket (da ein entsprechender Eintrag in Active Directory gefunden wurde) und dann das Ticket für die CAS-Box präsentieren. Die CAS-Box hatte offensichtlich keine Ahnung, was zu tun, um etwas ganz anderes Feld ausgestellt, es warf eine Anmeldeaufforderung für die wiederholte Authentifizierung Kerberos-Ticket.
Einmal der falsche SPN-Eintrag entfernt wurde, integrierte Windows-Authentifizierung begann sofort gegen den NLB-URL zu arbeiten und die Anmeldeaufforderung für die Authentifizierung war verschwunden.
Haftungsausschluss Zwietracht
F: Wir versuchen, erstellen eine Transportregel auf alle ausgehenden Nachrichten eine Verzichtserklärung hinzufügen. Während der Tests, entdeckten wir, dass die Transportkisten scheinen die Regel zu ignorieren. Es hinzufügen nicht die gewünschte Haftungsausschlüsse, sogar nach dem Neustart alle Hub-Kästen, stellen Sie sicher, dass sie tatsächlich die Regel geladen. Jedoch ist die gleiche Regel wie ein Charme in unserer Testumgebung arbeiten. Haben Sie irgendwelche Ideen?
A. Die eigentliche Regel zum Ausführen dieser Funktion sieht aus wie in Abbildung 2.
.jpg)
Abbildung 2 dieser Regel soll am Ende von ausgehenden Nachrichten eine Verzichtserklärung hinzufügen.
Nach Überprüfung der üblichen Verdächtigen wie Replikation, Transportdienst Änderungen nicht bewusst und so weiter, sah alles richtige. Dann haben wir geprüft ExTRA Ablaufverfolgung, ein ETL das Regelmodul während der Verarbeitung ausgehenden E-mails zu erfassen.
Die ETL ergab, dass der Transportdienst die neue Transportregel bewusst war, aber aus irgendeinem Grund nicht erkennen ausgehende Mails als "ausgehende". Aus irgendeinem Grund waren sie als intern behandelt.
Weitere Ablaufverfolgung offenbart das Regelmodul als den "Standard" Remotedomäneneintrag in remote-Domänen als interne. Daher anzuwenden nicht es die Verzichtserklärung Regel.
Beim Blick auf die Frage, ich bemerkte es sagt IsInternal:$ True für die Standard-Remotedomäne. Dies weist Exchange zu behandeln, alle e-Mails zu einem Adressraum von * als intern — und gelten daher nicht den Haftungsausschluss. Wir haben es wieder auf den Standardwert false. Die Haftungsausschlüsse sind nun erfolgreich angewendet.
.jpg)
.jpg)
Henrik Walther ist Microsoft Certified Master: Exchange 2007 und Exchange MVP mit über 16 Jahren Erfahrung in der IT-Branche. Er arbeitet als Technologiearchitekt für Microsoft Gold Certified Partner in Dänemark und als Autor technischer Artikel für Biblioso Corp. (ein US-amerikanischen Unternehmen, das spezialisiert auf verwaltete Dokumentations- und Lokalisierungsdienste). Er ist auch ein vertraglich Anbieter arbeiten an verschiedenen Produktteams (einschließlich Exchange und Lync Teams) bei Microsoft.
Georg Hinterhofer ist Microsoft Certified Master für Exchange 2010. Er arbeitet als senior premier Field Engineer, Schwerpunkt ausschließlich auf Microsoft Exchange. Er hat seinen Sitz in Österreich, nahe Wien.