20 Jahre Exchange Server !!

Wussten Sie, dass seit dem Release von Exchange Server 4.0 bereits 20 Jahre (!) vergangen sind?

Ja, am 14. März 1996 erschien Exchange auf der Bildfläche und nur wenige Tage später habe ich mich damit beschäftigt? Warum? Keine Ahnung, weil es mich einfach schon immer gereizt hat, Neues auszuprobieren. Viele Jahre hatte ich mit Lotus Notes zu tun und hatte – wie viele andere auch – immer was auszusetzen daran.

Exchange hat sich nun in mehr als 20 Jahren stets entwickelt, seinen Vorsprung und die Marktpräsenz ausgebaut. Dies kann ja nicht von ungefähr kommen 🙂

Die bescheidenen Anfänge,  z.B. das SMTP-Protokoll über einen Internet-Mail-Connector hinzufügen, sowie den Web-Zugriff in Exchange Server 5.0 im Jahre 1997 bis hin zu Exchange Server 2016 und Exchange Online – wir haben viele eine Transformation durchlaufen.

Es bleibt stets spannend, harren wir mal der Dinge, die da in Zukunft hoffentlich noch kommen.

Ihr Robert Lindermeier

Exchange 2013 im BackEnd nicht verfügbar – Event-ID 15021 (httpevent)

Als Fehlerbild auf dem Exchange 2013 zeigt sich, dass die ECP und EMS nicht mehr verfügbar sind. Outlook-Clients konnten können sich nicht mehr mit Exchange verbinden. Das betrifft auch OWA und EAS. Im Eventlog des Servers finden sich im Bereich System Fehler mit der Fehler-ID 15021 

01.Protokollname: System 
02.Quelle: Microsoft-Windows-HttpEvent 
03.Datum: tt.mm.jjjj hh:mm:ss 
04.Ereignis-ID: 15021 
05.Aufgabenkategorie:Keine 
06.Ebene: Fehler 
07.Schlüsselwörter:Klassisch 
08.Benutzer: Nicht zutreffend 
09.Computer: server.domain.local 
10.Beschreibung: 
11.Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:444 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten. 
12.Ereignis-XML: 
13.<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event;>” 
14. <System> 
15. <Provider Name=”Microsoft-Windows-HttpEvent” Guid=”{7b6bc78c-898b-4170-bbf8-1a469ea43fc5}” EventSourceName=”HTTP” /> 
16. <EventID Qualifiers=”49152″>15021</EventID> 
17. <Version>0</Version> 
18. <Level>2</Level> 
19. <Task>0</Task> 
20. <Opcode>0</Opcode> 
21. <Keywords>0x80000000000000</Keywords> 
22. <TimeCreated SystemTime=”jjjj-mm-ttThh:mm:ss.ssss” /> 
23. <EventRecordID>34616</EventRecordID> 
24. <Correlation /> 
25. <Execution ProcessID=”4″ ThreadID=”76″ /> 
26. <Channel>System</Channel> 
27. <Computer>server.domain.local</Computer> 
28. <Security /> 
29. </System> 
30. <EventData> 
31. <Data Name=”DeviceObject”>\Device\Http\ReqQueue</Data> 
32. <Data Name=”Endpoint”>0.0.0.0:444</Data> 
33. <Binary>000004000200300000000000AD3A00C00000000000000000000000000000000000000000000000005F0000C0</Binary> 
34. </EventData> 
35.</Event> 

Als Ursache für das Problem kann genannt werden, dass im IIS für den Port 444 das SSL-Zertifikat des Exchange Servers nicht ausgewählt ist. Wenn man das Zertifikat wieder dem Port 444 zuweise und über iisreset /force die IIS-Dienste neu startet, dann ist nach kurzer Zeit der Exchange Server wieder erreichbar. 

Guide To Successful Microsoft Exchange Reporting & Analysis

Alle Unternehmen und Organisationen stützen und verlassen sich auf Ihre E-Mailumgebung und investieren enorme Mittel in zuverlässige Systeme. Um eine zuverlässige und effiziente Kommunikation zu gewährleisten wird tagtäglich die Umgebung überwacht. Traditionelle Monitoring-Systeme liefern jedoch nur Daten über die Verfügbarkeit der Serversysteme und keine Daten in Bezug auf den E-Mailverkehr.

Hier setzt Sirana AppAnalyzer an!! Lesen Sie hierzu das folgende Whitepaper

Business-Focused-Exchange-Reporting

Exchange 2010 E-Mail-Header-Firewall aktivieren

Jeder Administrator von E-Mail-Systemen arbeitet nahezu täglich mit den Nachrichtenkopfzeilen einer E-Mail. Auch im Helpdesk bzw. an der Hotline größerer Unternehmen werden mit Hilfe des Headers die Fragen nach Laufzeiten, Herkunft und Gründen für Verzögerungen in der Nachrichtenzustellung einer E-Mail beantwortet.

Darin finden sich auch eine Menge Informationen, die normalerweise nicht unbedingt für diese Tätigkeiten benötigt werden. Insbesondere detaillierte Angaben wie IP-Adressen zu den internen Servern sind damit öffentlich.

Der Exchange Server 2010 bietet dazu nun eine einfache Möglichkeit, beim Versand ins Internet den „Versand“ dieser internen Informationen zu unterbinden. Sehen wir uns dazu mal einen Auszug aus einem E-Mail-Header an, der alle Infos preisgibt:

it-Administrator-01-2013-#1

Mit einem einzigen Kommando lässt sich nun der „rot“ markierte Bereich in einer ausgehenden E-Mail unterdrücken und somit vor der Öffentlichkeit verbergen:

it-Administrator-01-2013-#2

Um diese Einstellung nun wirksam werden zu lassen, starten wir die Exchange Verwaltungs-Shell und geben folgendes Kommando ein um die aktuellen Einstellungen anzusehen. Der Name des Sende-Connectors (hier: SMTP-Versand) muss natürlich an Ihre Umgebung angepasst werden:

Get-SendConnector “SMTP-Versand”   | Get-ADPermission | Where-Object { $_.extendedrights -like   “*routing*”} | fl user, *rights

Für die Ausgabe bzw. Übermittlung der Header-Informationen ist eine spezielle Berechtigung auf dem Sendeconnector verantwortlich. Jeder Benutzer welcher das erweiterte Recht ms-Exch-Send-Headers-Routing auf dem Sendeconnector hat,  hat Zugriff auf die serverspezifischen Headerinformationen. In diesem Fall ist nun prüfen wir, wer dieses Recht auf dem Connector besitzt.

In der nachfolgenden Ausgabe des Kommandos ist insbesondere die Zeile mit “Anonymous“ interessant, ist diese doch dafür verantwortlich, dass bei ausgehenden E-Mails über diesen Connector die ausführlichen Header-Informationen mitgesandt werden.

User                    : NT-AUTORITÄT\ANONYMOUS-ANMELDUNG
  AccessRights      : {ExtendedRight}
  ExtendedRights : {ms-Exch-Send-Headers-Routing}

User                    : YOUR-ADMIN\Exchange Servers
  AccessRights   : {ExtendedRight}

Im Regelfall verfügt der Anonymous – über dieses Recht und damit ist die Header-Firewall ausgeschaltet. Um die Header-Firewall zu aktivieren nehmen wir mit nachfolgendem Kommando für Anonymous die Berechtigungen weg:

Get-SendConnector “SMTP-Versand”   | Remove-ADPermission -User “Nt-Autorität\ Anonymous-Anmeldung”   -ExtendedRights “ms-Exch-Send-Headers-Routing”

Bestätigung
  Möchten Sie diese Aktion wirklich ausführen?
  Die Active Directory-Berechtigung ‘SMTP-Versand’ für den Benutzer   ‘Nt-Autorität\ Anonymous-Anmeldung’ mit ‘AccessRights’    ”ms-Exch-Send-Headers-Routing” wird entfernt.

Diese Berechtigung kann auch über den ADSI-Edit geprüft bzw. verwaltet werden. Hier sehen Sie das aktuelle Beispiel:

it-Administrator-01-2013-#3

Für die Auswertung von E-Mail-Headern gibt es eine interessante Webseite, bei der nur der Header einkopiert werden muss, und schon erhält man eine übersichtliche Ausgabe, die sicherlich einfacher zu lesen ist, als der Header selbst.

–> http://www.mxtoolbox.com/EmailHeaders.aspx

 

System-Meldungen unter Exchange 2010 anpassen

Exchange generiert für die unterschiedlichen Ursachen, entsprechende Meldungen, welche an den Absender einer E-Mail zurückgegeben werden, sofern die Zustellung an die angegebenen Empfänger gescheitert ist. Hierbei handelt es sich um die sogenannten DSN-Meldungen. (Delivery Status Notification)

Diese DSN-Meldungen lassen sich unter Exchange 2010 anpassen. In diesem Workshop wollen wir dies an 2 Beispielen aufzeigen. Das erste Beispiel behandelt den Return-Code 5.3.2 (Timeout), sowohl für interne als auch für externe Absender, und die tägliche Warnmeldung, die an ein Postfach zugestellt wird, sobald die Warning-Quota gerissen wird.

Die Originalnachricht bei Ereignis 5.3.2 lautet:

Vom E-Mail-System des Empfängers werden derzeit keine Nachrichten angenommen. Versuchen Sie, die Nachricht zu einem späteren Zeitpunkt erneut zu senden, oder wenden Sie sich direkt an den Empfänger.

Anpassen einer vorbelegten Systemnachricht für interne Absender

Wir möchten nun die Kontaktdaten unseres lokalen Helpdesk einfügen, um unseren Benutzern die Kontaktaufnahme zu erleichtern. Hierzu erzeugen wir eine benutzerdefinierte Systemmeldung mit dem cmdlet new-systemmessage.

new-systemmessage -DsnCode 5.3.2 -Language de -Internal $True -Text “Vom E-Mail-System des Empfängers werden derzeit keine Nachrichten angenommen. Versuchen Sie, die Nachricht zu einem späteren Zeitpunkt erneut zu senden, oder wenden Sie sich an unseren Helpdesk unter 0123/45 67 89. Ihr E-Mail-Administrator.”

Über das cmdlet „Get-SystemMessage de\Internal\5.3.2 | fl“ lassen wir uns die Änderung zur Kontrolle nochmals anzeigen. Die nachfolgende Meldung wird Ihnen ab sofort nach der Anpassung in Outlook angezeigt.

Ex-2010-Systemmessage

Anpassen einer vorbelegten Systemnachricht für externe Absender

Nun passen wir auch die für externe Absender angezeigte Nachricht entsprechend an, indem wir den Parameter –Internal verändern.

new-systemmessage -DsnCode 5.3.2 -Language de -Internal $False -TextVom E-Mail-System des Empfängers werden derzeit keine Nachrichten angenommen. Versuchen Sie, die Nachricht zu einem späteren Zeitpunkt erneut zu senden, oder wenden Sie sich an unseren Helpdesk unter 0123/45 67 89. Ihr E-Mail-Administrator.”

Anpassen einer bereits gesetzten Systemnachricht

Wenn wir uns nun die Nachricht für 5.3.2 an externe Absender ansehen, macht es wohl wenig Sinn, wenn externe Absender dieselbe Nachricht mit einer Telefonnummer erhalten, wie interne Sender. Daher sollten wir diese Meldung für „extern“ nochmals anpassen. Hierzu benutzen wir nun das Cmdlet „set-systemmessage“ wie folgt. Hier bitte beachten, dass die Parameter sich zum new-systemmessage etwas unterscheiden.

set-systemmessage De\External\5.3.2 -TextVom E-Mail-System des Empfängers werden derzeit keine Nachrichten angenommen. Versuchen Sie, die Nachricht zu einem späteren Zeitpunkt erneut zu senden, oder wenden Sie sich an Ihren lokalen Helpdesk”

Anpassen einer Quota-Warnung

Die Warnmeldung, die ein Benutzer erhält, wenn die Größe seines Postfaches über ein bestimmtes Limit steigt, wird wiederum geringfügig anders behandelt. Nachfolgend ein Beispiel um die Warning-Quota-Meldung anzupassen und die Änderungen anschließend anzuzeigen.

new-systemmessage -QuotaMessageType WarningMailbox -Language de -Text “Sie liegen über der Warn-Grenze Ihres Postfaches. Um zu vermeiden, dass Sie in Kürze nicht mehr Senden dürfen, sollten Sie Ihr Postfach umgehend bereinigen!”

Get-SystemMessage de\WarningMailbox | fl

Reporting, Analyse und Monitoring für Microsoft® Office 365

Unser Partner Sirana Software stellt in Kürze eine Lösung für ein ausführliches Reporting, eingehende Analysen und ein Monitoring der Office 365 Mail-Konten vor. Wer interessiert daran ist, bereits im Beta-Stadium sich kostenlos damit auseinander zu setzen, der erstellt sich schlicht einen Account unter der nachfolgende Webseite:

–> www.appanalyzer.com