Hallo Leutz,
fuer die November 2016 Ausgabe der Print Ausgabe des IT Administrator (www.it-administrator.de) habe ich einen Artikel zum Thema “Sichere Exchange Server 2016 Veroeffentlichung mit dem Microsoft Web Application Gateway (WAP)” geschrieben.
Weitere Informationen findet man hier: http://www.it-administrator.de
Gruss Marc
Hallo Leutz,
bei einem Kunden bin ich seit einigen Tagen in einem Workshop zum Thema Exchange Migration von 2010 ueber 2013 zu 2016. Einer der (Azubi)Admins hat eine entsprechende Test-Umgebung eingerichtet und nach der Migration auf Exchange Server 2013 und spaeter Exchange Server 2016 stellten wir fest, dass Mails in OWA und Outlook intern nicht zugestellt werden konnten.
Im Routing Log Viewer erschien die Meldung: 554 5.4.4 SMTPSEND.DNS.NonExistentDomain
Ein Telnet ExchangeServer 25 ergab beim Submit: 451 4.7.0 temporary server error. please try again later. PRX2
Nach einigen Tests fanden wir bei beiden Exchange Servern eine Gemeinsamkeit. Der (Azubi)Admin hatte in der Testumgebung nur einen DC installiert und auf jedem Client und Server als primaeren DNS Eintrag den DC, als sekundaeren DNS Eintrag einen Google Nameserver eingetragen.
Sobald man den zweiten DNS Eintrag des Google Nameserver auf den Exchange Servern entfernt hatte, wurden die Mails SOFORT zugestellt und Telnet ExchangeServer 25 funktionierte auch SOFORT wieder.
Somit haben wir folgende Feststellung fuer Exchange Server 2013 und 2016 gemacht:
Sekundaeren DNS Server auf Internet Nameserver = Fehler
Sekundaeren DNS Server auf nicht erreichbare IP = OK
Sekundaeren DNS Server auf einen Rechner mit erreichbarer IP, welcher aber kein DNS Server ist = OK
Sekundaeren DNS Server auf einen DNS Server im LAN ohne lokale FLZ mit Weiterleitung ueber Root Hints = Fehler
Erkenntnis: In Exchange 2013 / 2016 Umgebungen mit nur einem DC/DNS sollte auch (zumindest auf den Exchange Servern) nur ein DNS Server eingetragen werden, damit die Mailzustellung funktioniert).
Gruss Marc
Hallo Leutz,
fuer die Maerz 2016 Ausgabe der Print Ausgabe des IT Administrator habe ich einen Artikel zum Thema Data Loss Prevention in Exchange Server 2016 geschrieben.
Weitere Informationen findet man hier: http://www.it-administrator.de
Gruss Marc
Hallo Leutz,
im Rahmen der “IT Jogging Veranstaltungen” der Fa. Netz-Weise (http://www.netz-weise.de) darf ich am 02.02.2016 in der Zeit von 18:30 – 21:00 Uhr einen Workshop zum Thema “Exchange Server 2016 Neuerungen” halten.
Abstrakt:
In diesem Vortrag werden die wichtigsten Aenderungen in Exchange Server 2016 theoretisch und praktisch vorgefuehrt, sowie die Integration und Migration mit aelteren Exchange Versionen erlaeutert.
Agenda:
– Was ist neu in Exchange Server 2016
– Integration in bestehende Exchange Umgebungen
– Integration mit Outlook
– Migration von aelteren Exchange Versionen auf Exchange Server 2016
Anmeldung hier: (http://www.netz-weise.de)
Die Praesentation kann hier herunter geladen werden: (http://www.it-training-grote.de/download/Exchange-2016.pdf)
Gruss Marc
Hallo Leutz,
ich bin gerade bei einem Kunden, welcher in der Migrationsphase von Exchange 2010 auf 2013 steckt. Man hat festgestellt, dass einige migrierte Benutzer auf Exchange Server 2013 nicht auf FreeBusy Informationen von anderen Benutzern zugreifen koennen (Weder ueber OWA noch ueber Outlook). Wenn das Postfach der Benutzer wieder auf Exchange 2010 verschoben wird, funktionieren die FreeBusy Zugriffe wieder. Also kann ein Outlook Client Problem ausgeschlossen werden (trotzdem testeten wir Autodisocver, EWS, OOF, OAB, CALcheck, TestExchangeConnectivity).
Spannend war hier, dass der Zugriff auf OOF funktioniert, sprich Proxy-Einstellungen konnten nicht dir Ursache fuer das nicht funktionierende FreebBusy sein.
Wir vermuteten also ein Active Directory Problem, kopierten die betroffenen Benutzer und erstellten fuer diese ein neues Postfach. Gleiches Verhalten. Dann fiel uns auf, dass die User Mitglieder in hunderten von active-Directory Gruppen waren und der Kunde schon mal ein Problem mit der Kerberos MaxTokenSize hatte.
Die Kombination der MaxTokenSize und der maximalen HTTP EWS Request Laenge fuehrte hier dazu, dass die Benutzer keine Berechtigungen zur Abfrage von FreeBusy-Informationen hatten. Abhilfe schafft die Vergroesserung der MaxTokenSize und Aenderung der MaxReceivedMessageSize und MaxBufferSize auf den 2013 CAS Servern in der Registry und Web.Config:
Zum KB Artikel
Gruss Marc
Hallo Leutz,
bei einem Kunden habe ich gestern Abend ein DPM 2012 R2 – Exchange Server 2013 Problemmit inkonsistenten Exchange Replicas geloest. Saemtliche Exchange DB Sicherungen in den entsprechenden Protection Groups zeigten nach der Replikat-Erstellung der Exchange DBs den Zustand “Replica Inconsistent” an. Nach einigen Recherchen sind wir auf ein nicht installiertes Visual C++ Redistributable for Visual Studio 2012 auf dem Exchange Server gestossen. Nach der Installation waren die Replikate auf dem DPM Server konsistent. Um das Problem reproduzieren zu koennen, habe ich das Szenario heute Morgen auf meinem Exchange Server 2013 nachgestellt und es war reproduzierbar. Dabei ist folgendes Bilderbuch entstanden:
http://www.it-training-grote.de/download/DPM2012R2-Exchange2013-ReplicaInconsistent.pdf
Gruss Marc
Hallo Leutz,
fuer die Mai 2014 Ausgabe der Print Ausgabe des IT Administrator habe ich einen Artikel zum Thema Administrative Sicherheit und Ueberwachungsfunktionen in Exchange Server 2013 geschrieben.
Weitere Informationen findet man hier: http://www.it-administrator.de
Gruss Marc
Hallo Leutz,
bei einem Kunden bin ich gerade in der finalen Phase der Migration der Exchange Server 2010 auf Exchange Server 2013. In der letzten Phase muss dass Offline Adressbuch fuer die neuen Exchange 2013 Server zugewiesen werden (bis zu diesem Zeitpunkt wurden die OAB von Exchange 2010 verwendet) und die alten OAB vor der Exchange Server 2010 Dekommissonierung geloescht werden. Da die OAB nicht von Exchange 2010 zu Exchange Server 2013 verschoben werden koennen, muessen neue OAB erstellt werden.
Bei der Erstellung der neuen OAB per Exchange Management Shell (GUI ist nicht mehr moeglich), kam die Fehlermeldung ManagementObjectNotFoundException. Die neuen OAB wurden jedoch in der Active Directory Konfigurations Partition erstellt. Die Anzeige der OAB mit der Exchange Management Shell zeigte nur die Exchange 2010 OAB an. Nach einiger Recherche habe ich festgestellt, dass die Berechtigungen fuer die Exchange Sichereitsgruppen im Container CN=Offline Adress Lists der Active Directory Konfigurations Partition nicht korrekt waren, bzw. die Vererbung der Berechtigungen auf dieser Ebene deaktiviert war. Nach Bereinigung der Berechtigungen liessen sich neue OAB mit der Exchange Management Shell anlegen und den neuen Exchange 2013 Datenbanken zuweisen.
Ein weiteres Problem bestand noch darin, dass das von Exchange Server 2013 angelegte OAB Standard-Offlineadressbuch (Ex2013) ein Problem hatte, weil es noch fuer OABGEN 2 und 4 eingerichtet war. Das Problem konnte geloest werden, indem mit ADSIEDIT in den Eigenschaften des OAB der Wert des Attributs doOABVersion von 6 auf 4 gesetzt wurde.
Weitere Details, Fehlermeldungen und Loesungsansaetze stehen in diesem Bilderbuch:
http://www.it-training-grote.de/download/Mig-2010-2013-OAB-Probleme.pdf
Gruss Marc
Hallo Leutz,
im Rahmen einer Exchange 2007 zu 2013 Migration mussten wir den Forefront TMG Server anpassen, dass Outlook Web Access Benutzer sowohl auf Exchange 2007 als auch Exchange 2013 Mailboxen zugreifen koennen.
Dazu wurden in der Exchange Server Umgebung die entsprechenden internen/externen URL / SCP angepasst.
Nach der Anpassung hatten OWA User aus dem Internet aber das Problem, dass ein Exchange 2007 User nicht korrekt ueber die Legacy URL redirected wurde und sich in einer Endlosschleife befand. Im Forefront TMG kam die Meldung “302 Moved Temporarily”.
Wie man das Problem loesen kann, steht in diesem Bilderbuch:
http://www.it-training-grote.de/download/EX2013-Migration-LegacyURL-TMG.pdf
Gruss Marc
Hallo Leutz,
bei einem Kunden wurden fuer die Exchange Server Zertifikate von Entrust verwendet. Seit einigen Tagen haeufen sich bei diversen Clients die Fehlermeldungen, dass die Outlook Web App Seite nicht mehr per HTTPS erreicht werden kann. Es erscheint die Meldung “Die Webseite kann nicht angezeigt werden”, welche auf den ersten Blick vermuten laesst, der IIS stellt kein Socket mehr auf Port 443 zur Verfuegung, was aber nicht der Fall ist, da das Problem nur an vereinzelten Clients auftaucht. Nach einiger Recherchen habe ich festgestellt, dass Entrust (Comodo) die Ausstellung von RSA Schluesseln kleiner als 2.048 Bit fuer eigene Zertifizierungsstellen (Root und Intermediate) gesperrt hat. Wie man die Ursache des Problems ermitteln und eine Loesung schaffen kann, steht in folgendem Bilderbuch:
http://www.it-training-grote.de/download/Entrust-RootCA.pdf
Gruss Marc