Seit Exchange 2013 ist auch ein Virenscanner enthalten. Wie bei den meisten anderen Virenscanner auch, müssen auch hier die Signaturen aktualisiert werden. Bei der Aktualisierung der Signaturen kann es zu Problemen kommen, insbesondere wenn Exchange nicht auf Laufwerk C: installiert wurde.

Der folgende Eintrag findet sich dann im Eventlog:

Quelle: FIPFS

Ereignis-ID: 6027

MS Filtering Engine Update process was unsuccessful to download the engine update for Microsoft from Primary Update Path.
Update Path:http://forefrontdl.microsoft.com/server/scanengineupdate
UpdateVersion:0
Reason:“There was a catastrophic error while attempting to update the engine. Error: DownloadEngine failed and there are no further update paths available.Engine Id: 1 Engine Name: Microsoft“

Ganz so drastisch wie die Fehlermeldung, ist das Problem aber nicht:

There was a catastrophic error while attempting to update the engine.

Um den „katastrophalen“ Fehler zu beheben, sollte zunächst geprüft werden, ob die Update URL aus der Fehlermeldung erreichbar ist:

http://forefrontdl.microsoft.com/server/scanengineupdate

Die Webseite liefert den HTTP Code 403 „Access denied“ wieder, wenn eine Verbindung hergestellt werden konnte. Bei HTTP 403 handelt es sich hier also um kein Problem. Bei HTTP 404 wäre die Seite nicht erreichbar, in diesem Fall könnte eine Firewall Schuld sein.

In diesem Fall ist also alles in Ordnung:

Wie bereits eingangs erwähnt, tritt das Problem häufig auf, wenn Exchange Server auf einem anderen Laufwerk als C: installiert wurde. In diesem Beispiel ist Exchange auf Laufwerk E: installiert und die UAC eingeschaltet. In diesem Fall greift der Schutz für bestimmte Verzeichnisse von Exchange Server. Leider wird dadurch auch die Aktualisierung der Signaturen verhindert und es kommt zu den oben gezeigten Fehler.

Um den Fehler zu beheben reicht es die Meldung „Sie verfügen momentan nicht über die Berechtigung des Zugriffs auf diesen Ordner“ mit „Fortsetzen“ zu bestätigen:

Die Meldung muss für alle Ordner in dem folgenden Pfad bestätigt werden:

E:\Exchange Server\FIP-FS\Data\Engines\amd64 (wobei E:\Exchange Server das entsprechende Installationsverzeichnis ist)

Weiterhin kann auch gleich kontrolliert werden, ob der Benutzer „Netzwerkdienst“ Vollzugriff auf entsprechende Verzeichnis hat:

Exchange lädt in der Standardeinstellung alle 30 Minuten Signaturen runter. In meinem Fall war nach den oben genannten Schritten das Update erfolgreich und es wurde das Event 6036 angezeigt:

Falls die Schritte nicht reichen sollten, gibt es noch das Tool „FPSDiag“ im Ordner FIP-FS\Bin. Das Diagnosetool generiert einen Satz Logfiles die ggf. bei der Analyse weiterhelfen können:

In den meisten Fällen ist aber eine der folgenden Ursachen für das Problem verantwortlich:

• Firewall blockiert Update Seite
• „Netzwerkdienst“ hat keinen Zugriff auf das Verzeichnis
• Verzeichnisschutz aktiv

Hinweis: Bei einer größeren Anzahl Exchange Server im Unternehmen, muss nicht jeder Exchange Server die Signaturen aus dem Internet runterladen. Es gibt die Möglichkeit ein zentrales Repository für die Exchange Server zu konfigurieren.Ein entsprechender Artikel dazu folgt noch.

Der Beitrag Exchange 2016: FIPFS Event ID 6027 Filter Updates werden nicht runtergeladen erschien zuerst auf Franky's Web.

Dank Autodiscover ist es einfach Outlook Profile für Exchange Server einzurichten. Die Benutzer müssen nur ein paar Mal auf „Weiter“ klicken und schon ist das entsprechende Profil erstellt. Die folgenden Dialoge dürften daher den meisten bekannt sein:

Da hier im Falle von Exchange Server und einer korrekten Autodiscover Konfiguration allerdings keine Benutzerinteraktion nötig ist und der Benutzer sowieso nur ein auf „Weiter“ klicken muss, kann man sich diese Dialoge auch sparen.

Genau für diesen Zweck gibt es ZeroConfigExchange, dabei handelt es sich um einen Registry Schlüssel, der direkt das Outlook Profil anlegt, ohne das der Benutzer den Assistenten durchklicken muss. Das folgende kurze Video verdeutlicht den Unterschied:

Die Registry Datei die im Video zur Windows Regitry hinzugefügt wird, enthält nur die folgenden Zeilen für Outlook 2016:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ZeroConfigExchange"=dword:00000001

Es muss also nur ein DWORD-Wert zur Registry hinzugefügt werden, um den Einrichtungsassistenten abzuschalten. Wie im Video zu sehen ist, wird nach dem Setzen des DWORDs der Assistent nicht mehr angezeigt und ein Profil wird direkt erzeugt. Die Abfrage des Produktschlüssels erscheint natürlich auch nicht, wenn entsprechende Lizenzen mit einem KMS-Server verwaltet werden.

Die Registry Dateien können hier für Outlook 2007, 2010, 2013 und 2016 runtergeladen werden:

ZeroConfigExchange 1.49 KB

Download

Natürlich kann der Registry Wert auch per Gruppenrichtlinie gesetzte werden. Dazu kann eine neue Gruppenrichtlinie erstellt werden:

Unter dem Punkt „Benutzerkonfiguration –> Einstellungen –> Windows Einstellungen –> Registrierung“ kann ein neues Registrierungselement hinzugefügt werden:

Die Eigenschaften des Registrierungselements sehen dann für Outlook 2016 wie folgt aus:

• Struktur: HKEY_Current_USER
• Schlüsselpfad: SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover
• Name: ZeroConfigExchange
• Werttyp: REG_DWORD
• Wertdaten: 1 (Dezimal)

Für ältere Outlook Versionen ändert sich nur der Schlüsselpfad wie folgt:

• Outlook 2013: SOFTWARE\Microsoft\Office\15.0\Outlook\AutoDiscover
• Outlook 2010: SOFTWARE\Microsoft\Office\14.0\Outlook\AutoDiscover
• Outlook 2007: SOFTWARE\Microsoft\Office\12.0\Outlook\AutoDiscover

Kleiner Hinweis: Wenn es schon ein Outlook Profil für den Benutzer auf dem Rechner gibt, wird es nicht neu erstellt, sondern das vorhandene Profil wird weiterhin genutzt. Wenn das Standard Profil gelöscht wurde, wird Outlook auch bei ZeroConfigExchange nach einen neuen Profilnamen fragen:

Die restliche Einrichtung geschieht dann wieder automatisch.

Der Beitrag Outlook: Exchange Profile ohne Benutzerinteraktion konfigurieren (ZeroConfigExchange) erschien zuerst auf Franky's Web.

Mittlerweile erreichen mich täglich Mails mit Fragen zu Zertifikaten und/oder Outlook Anywhere. Wobei auch die Fragen zu Outlook Anywhere meistens ebenfalls auf die Zertifikate zurückzuführen sind. In den meisten Fällen enden die Mails einem Satz ähnlich wie diesem:

Zertifikate sind für mich ein rotes Tuch!

Der Satz stammt aus einer Mail die ich heute erhalten habe. Da wie schon erwähnt diese Mails langsam überhand nehmen, versuche ich mal ein bisschen Licht ins Dunkel zu bringen. Dazu soll dieser Artikel dienen. Dieser Artikel ist bewusst möglichst ausführlich und einfach gehalten und richtet sich an Einsteiger in diesem Thema. Ich hoffe es hilft einigen Leuten.

Noch eine Bitte vorab: Wenn etwas unklar ist, bitte einen Kommentar hinterlassen, damit ich den Artikel entsprechend aktualisieren kann.

Hintergrund: Wie funktionieren Zertifikate

Keine Angst, ich will gar nicht tief ins Detail gehen, sondern nur ganz oberflächlich erklären wie ein Zertifikat funktioniert. Als Beispiel nehmen wir mal einen Personalausweis. Ein Personalausweis enthält Daten zu meiner Person um diese zu identifizieren, also beispielsweise den Namen, ein Foto und eine Unterschrift. Ebenfalls wird ein Personalausweis von einem Land (oder einer Behörde) ausgestellt.

Beispiel Ausweis

Wenn ich die Identität von jemanden mit dem ich gerade rede feststellen möchte, kann ich mir also seinen Personalausweis zeigen lassen und kann die Daten auf dem Ausweis (Foto und Unterschrift) mit meinem Gesprächspartner vergleichen. Stimmen die Merkmale überein, handelt es sich wahrscheinlich um die entsprechende Person. Allerdings muss ich dazu jemandem Vertrauen. Erstens muss ich meinem Gesprächspartner vertrauen, das er den Ausweis nicht gefälscht hat und ich muss dem Staat oder der Behörde vertrauen, dass die Identität meines Gesprächspartners auch wirklich geprüft wurde und somit der Ausweis an sich vertrauenswürdig ist. Mein Gesprächspartner könnte mich ja schließlich auch einen Zettel mit Foto und Unterschrift zeigen, den er eben selbst gemalt hat. Als Ausweis akzeptiere ich das natürlich nicht.

Beispiel Zertifikate

Angenommen ich bin nun keine Person mehr, sondern ein PC der mit einem Server sprechen möchte. Ich als PC bekomme vom Server den Ausweis (Zertifikat) gezeigt. Die Daten auf dem Zertifikat kann ich nun prüfen:

• Welcher Name steht auf dem Zertifikat?
• Wer hat es ausgestellt?
• Sehe ich das Zertifikat als gültig an?

Etwas genauer gesagt: Eine Zertifizierungsstelle (Behörde/Land) stellt ein Zertifikat aus, dieser Zertifizierungsstelle muss ich vertrauen, dass Sie ihre Arbeit gewissenhaft erledigt und die Identität entsprechend geprüft hat. Ein selbst ausgestelltes Zertifikat ähnelt dem selbst gemalten Ausweis. Wenn ich mir als PC in einem der Punkte nicht sicher bin, gebe ich eine entsprechende Warnung aus. Auf die Folgen kommen wir später zu sprechen.

Das soll es auch schon zum Hintergrund gewesen sein. Natürlich ist das Thema Zertifikate etwas komplexer, aber für diesen Artikel soll es erst einmal reichen. Verschlüsselung, Sperrlisten, Algorithmen  und was es noch alles gibt, interessiert hier erst einmal nicht weiter.

Hintergrund: Exchange 2016 und Zertifikate

Ein Exchange Server bietet mehrere Dienste an, die mit Zertifikaten konfiguriert werden können/müssen. Ein Dienst stellt dabei, um beim Beispiel zu bleiben, einen Gesprächspartner dar. Im wesentlichen sind es die folgenden Dienste, die ein Zertifikat (Stichwort Ausweis) benötigen:

• IIS
• SMTP
• IMAP
• POP

UC lassen wir an dieser Stelle mal außen vor. Jeder dieser Dienste (Gesprächspartner) KANN ein eigenes Zertifikat (Ausweis) erhalten, MUSS aber nicht. Ein Zertifikat kann mehreren Diensten zugeordnet sein, ähnlich wie eine Gesprächspartner der mehrere Sprachen spricht, aber nur einen Ausweis hat.

Eine Besonderheit ist allerdings, dass ein Exchange Server mehrere Namen hat, die auf dem Zertifikat vorhanden sein müssen. Dies ist vergleichbar mit einem zweiten Vornamen auf dem Ausweis.

Beispielumgebung

Um die Sache mit den Ausweisen, äh… Zertifikaten etwas deutlicher zu machen, habe ich eine Beispielumgebung installiert.

Allgemeine Beschreibung

Im wesentlichen besteht die Umgebung aus drei Abschnitten:

• Einem Benutzer im Home Office (blau)
• Das Internet mit einem Hoster für das Unternehmen (rot)
• Das Unternehmen welches den Exchange Server bereitstellt (grün)

Der Benutzer im Home Office hat nur einen normalen Internetanschluss, kein VPN oder sonstiges, nur einen PC mit Outlook.

Das Unternehmen stellt die Exchange Infrastruktur bereit, verfügt also über einen Domain Controller und einen Exchange Server. Ob das Unternehmen nun Domain Controller und Exchange Server auf einer VM oder physikalisch betreibt oder ob es ein Server/VM oder getrennte Server sind, spielt in diesem Beispiel keine Rolle. Das Unternehmen hat ebenfalls Benutzer die auf Exchange zugreifen innerhalb des eigenen LANs.

Das Unternehmen hat einen Hoster im Internet damit beauftragt, eine Domain für das Unternehmen zu hosten.

Die Details zum Unternehmen

Der Name dieses fiktiven Unternehmens ist „FrankysWeb“. FrankysWeb hat einen Internetanschluss mit fester IP-Adresse und ein Active Directory welches auf den Namen „frankysweb.local“ hört. Die E-Mail Adressen des Unternehmen enden auf frankysweb.de. Intern sieht das Netzwerk also in etwa so aus:

• Name des Active Directory: frankysweb.local
• Name des Domain Controllers: dc1.frankysweb.local
• Name des Exchange Servers: EX1.frankysweb.local
• E-Mail Adresse des internen Benutzers: frank@frankysweb.de
• Benutzername: frank@frankysweb.local
• Feste externe IP-Adresse: 81.169.145.159

Der Benutzer Frank nutzt ein Notebook und ist sowohl intern im Unternehmen als auch im Home Office tätig.

Die Details zum Hoster im Internet

Das fiktive Unternehmen FrankysWeb hat den Hoster Strato damit beauftragt die Domain frankysweb.de zu hosten.

Strato hostet ebenfalls die Website des Unternehmens und betreibt die DNS-Server für frankysweb.de

Die Details zum Home Office

Das Home Office wird gern vom Benutzer Frank genutzt, hier ist nur ein normaler Internetanschluss, ohne feste IP, oder sonstige Konfiguration. Es wird kein VPN genutzt, aber Mails sollen im Home Office bearbeitet werden können.

Frank möchte dazu Outlook Anywhere vom PC aus benutzen und ActiveSync vom Smartphone. Wenn es schnell gehen muss, nutzt er auch Outlook Web Access. Frank möchte auf keinen Fall einen dieser Fehler sehen:

Und auch die folgenden Fehler möchte Frank nicht zu Gesicht bekommen:

Vorkonfiguration der Beispielumgebung

Bisher sind nur der Domain Controller für die Domain frankysweb.local und der Exchange 2016 Server installiert. Auf dem Exchange Server gibt es nur eine akzeptierte Domain, sowie das Postfach für Frank und eine Adressrichtlinie, die dem Postfach für Frank die E-Mail Adresse frank@frankysweb.de zuweist. Mehr ist bisher nicht konfiguriert worden. Der Vollständigkeit halber hier einmal die Screenshots:

Die Beispielumgebung ist also mehr oder weniger eine grüne Wiese. So oder so ähnlich werden aber die meisten Umgebungen in den Mails geschildert, in denen es immer wieder Probleme mit Zertifikaten gibt:

• Active Directory Domain Name endet auf .local oder ähnlichem
• Es gibt einen Domain Controller und einen Exchange Server bzw. Exchange und Domain Controller laufen auf einem Server (ungünstig, aber für diesen Artikel nicht von Bedeutung)
• Ein Internet Anschluss mit fester IP ist vorhanden
• Ein Hoster (Strato, 1und1 HostEurope, etc) hosten die Mail Domain

Die Anforderungen sind dann schnell definiert:

• Outlook Anywhere soll/muss funktionieren
• Keine Zertifikatswarnungen mehr

Dieser Artikel soll dabei helfen diese Anforderungen umzusetzen, und gilt für Exchange 2013 und Exchange 2016 und entsprechend unterstützten Outlook Versionen.

Exchange in der Standardkonfiguration

Während der Exchange Installation wird bereits ein Zertifikat installiert und den Exchange Diensten zugewiesen. Dabei handelt es sich um ein Selbstsigniertes Zertifikat, wie diesem aus der Beispielumgebung:

Das Standard Zertifikat der Beispielumgebung, welches bei der Installation geniert wird, schaut im Browser dann wie folgt:

Der Exchange Server hört auf den Namen EX1 und hat sich daher ein Zertifikat mit dem Namen EX1 selbst ausgestellt, dies wird im Screenshot oben deutlich (Ausgestellt für EX1, Ausgestellt von EX1). Um bei dem Ausweisbeispiel zu bleiben: Dies ist der handgemalte Ausweis, kein offizielles Dokument einer Behörde, sondern eher vergleichbar mit einer Visitenkarte. Auf Visitenkarten kann jeglicher Unsinn stehen, niemand kann es prüfen, ob es auch stimmt.

Eine kleiner Besonderheit wird in diesem Screenshot sichtbar:

Das Standard Zertifikat enthält bereits zwei Namen (DNS-Name), einmal den Shortname (UNC-Name) und einmal den FQDN. Bei den Standard Zertifikat handelt es sich somit schon um ein SAN-Zertifikat (Subject Alternate Name). SAN hat in diesem Fall nichts mit Storage Netzwerken zu tun, sondern bezeichnet einen Zertifikatstyp. Hier werden mehrere Namen auf einem Zertifikat hinterlegt. Im Screenshot oben sind das die Namen EX1 und EX1.frankysweb.local. Wieder zurück zu den Ausweisen: Hier wurde Vorname und zweiter Vorname angegeben, oder Vor- und Zuname, aber das ist Haarspalterei.

Ein Client, der sich mit diesem Exchange Server verbindet wird die folgende Fehlermeldung im Browser bekommen:

Ob Internet Explorer, Edge, Chrome, Firefox ist erst einmal egal, die Fehlermeldung sieht überall ähnlich aus:

Warum der Fehler auftritt ist schnell erklärt: Der selbstgemalte Ausweis ist Schuld, zwar steht auf dem Ausweis ein Name, aber niemand hat überprüft und verifiziert, dass dieser Name auch wirklich stimmt. Vereinfacht erklärt: Bei unserer Ausweiskontrolle versucht sich hier jemand gerade mit einer Visitenkarte auszuweisen.

Jetzt stellt sich natürlich die Frage, wer denn überhaupt berechtigt ist, gültige Zertifikate (Ausweise) auszustellen?

Die Zertifizierungsstelle (Beispiel: Behörde/Land)

Damit ein Zertifikat als gültig angesehen wird, muss also nicht nur der Name auf dem Zertifikat stimmen, sondern es muss auch von einer vertrauenswürdigen Stelle ausgestellt worden sein. Eine Visitenkarte reicht also nicht, ein Personalausweis, der von einem Land oder entsprechender Behörde ausgestellt wurde, ist viel vertrauenswürdiger. Die Zertifizierungsstellen übernehmend das Ausstellen der Zertifikate und sind in diesem Beispiel vergleichbar mit einem Land oder Behörde. Im folgenden Beispiel hat die Zertifizierungsstelle (CA) Wosign (Roter Kasten) ein Zertifikat für mail.frankysweb.de (Blauer Kasten) ausgestellt:

In den Screenshot oben ist auch zu sehen, dass Zertifizierungsstellen häufig mehrstufig aufgebaut sind. Die Stammzertifizierungsstelle (Root-CA, im Beispiel das Land) hat eine Zwischenzertifizierungsstelle (Sub-CA, im Beispiel Behörde) signiert, damit die Zwischenzertifizierungsstelle für den Server mail.frankysweb.de (im Beispiel die Person) ein Zertifikat ausstellen kann. Da sich das Zertifikat der Stammzertifizierungsstelle im Windows Zertifikatsspeicher befindet, werden entsprechende Zertifikat als vertrauenswürdig anerkannt, sofern der Name stimmt und das Zertifikat nicht abgelaufen ist.

Wie schon erwähnt befinden sich die Stammzertifizierungsstellenzertifikate im Windows Zertifikatsspeicher, in diesem Speicher befinden sich eine ganze Reihe offizieller Zertifizierungsstellen, die alle ein Prüfungsverfahren durchlaufen haben, um sicherzustellen, dass nur berechtigte Inhaber ein Zertifikat ausgestellt bekommen. Im folgenden Beispiel findet sich das Zertifikat für WoSign:

Die meisten Windows Programme greifen auf den Windows Zertifikatsspeicher zurück um Zertifikate zu prüfen. Eine bekannte Ausnahme bildet hier der Browser Firefox. Firefox bringt seine eigene Zertifikatsverwaltung mit.

Überlegungen zur Exchange Konfiguration

Wie bereits oben beschrieben, reicht das Zertifikat der Standard Exchange Konfiguration nicht aus und muss ausgetauscht werden. Da auf einem Zertifikat aber DNS-Namen (wie Namen auf einem Ausweis) angegeben werden müssen, muss zunächst einmal überlegt werden, über welche DNS-Namen und Protokolle die verschiedenen Programme und Geräte auf den Exchange Server zugreifen werden. In kleinen Umgebungen ist diese Planung recht schnell erledigt, da sich nahezu alles über einen einzelnen DNS-Namen realisieren lässt, Autodiscover bildet allerdings eine Ausnahme: Die folgende Tabelle stellt einmal die Standardkonfiguration dar:

In der Standardkonfiguration enthalten also alle Zugriffspunkte den internen Servernamen und die externen sind leer. Mit internen Servernamen kann der Benutzer im Home Office natürlich nichts anfangen, wenn er keine VPN Verbindung hat. Weiterhin gilt für Exchange Server 2013 und Exchange Server 2016 die Best Practise interne und externe Zugriffsnamen gleich zu halten.

Wenn es also nur einen Exchange Server im Unternehmen gibt, dann wird dieser Server von internen Benutzern, sowie von externen Benutzern angesprochen werden.

Da wir in diesem Fall ja glücklicher Besitzer einer öffentlichen Domain bei einem Hoster sind, können wir mittels Subdomain einen öffentlichen Namen definieren. Für die Domain frankysweb.de könnte der Exchange Zugriff also über die folgende Subdomain erfolgen: mail.frankysweb.de (Alternativ irgendein anderen Namen den sich die Benutzer gut merken können).

Eine kleine Ausnahme bildet Autodiscover, der Autodiscover Eintrag sollte immer unter autodiscover.domain.tld veröffentlicht werden, die Veröffentlichung von autodiscover unter dem entsprechenden Namen verhindert eine Warnung die einmalig von Outlook angezeigt wird. Für die Domain frankysweb.de wäre der Autodiscover Eintrag also autodiscover.frankysweb.de.

Darauf würde sich unter der Berücksichtigung der Best Practise (interne und externe Namen gleich, keine internen Namen auf öffentlichen Zertifikaten, Autodiscover mit separaten Namen) die folgende Konfiguration ergeben:

Aus dieser Konfiguration ergibt nun das Zertifikat.

Überlegungen für das Zertifikat

Aus der Konfiguration oben ergeben sich schon die Anforderungen für das Zertifikat. Auf einem Zertifikat werden nur die FQDNs (DNS-Namen) angegeben, keine URLs! Daher wird auch ntur ein Zertifikat mit genau zwei Namen benötigt:

• mail.frankysweb.de
• autodiscover.frankysweb.de

In diesem Fall wird also ein SAN-Zertifikat (Subject Alternate Name) benötigt, welches die oben angegebenen Namen enthält. Mehr nicht.

Das Zertifikat muss aber von einer Zertifizierungsstelle ausgestellt werden, wenn es als gültig anerkannt werden soll. Es besteht die Möglichkeit selbst eine Zertifizierungsstelle zu betreiben, allerdings lohnt meist der Aufwand in kleinen Umgebungen nicht, denn ein entsprechendes Zertifikat gibt es kostenlos oder auch gegen geringe Gebühr. Hinzu kommt: Eine eigne Zertifizierungsstelle die auf einem Windows Server installiert wird, ist erst einmal nur innerhalb des Active Directory vertrauenswürdig. Ein Smartphone oder ein Client der nicht Mitglied des Active Directory ist, wird das Zertifikat nicht als vertrauenswürdig ansehen und wieder mit den bekannten Fehlern reagieren.

Meine Empfehlung daher: Entsprechendes Zertifikat von einer offiziellen Zertifizierungsstelle beziehen.

Konfiguration Exchange Server

Da dieser Artikel schon recht lang geworden ist, wird die Konfiguration im nächsten Artikel behandelt. Sobald der Artikel online ist, werde ich ihn hier verlinken.

Der Beitrag Exchange 2016: Zertifikate konfigurieren (Teil 1) erschien zuerst auf Franky's Web.

Dies ist der zweite Teil der Artikelserie. Wie schon im ersten Teil angekündigt, befasst sich dieser Artikel mit der Konfiguration.

Wichtig: Vorher unbedingt den ersten Teil lesen, da dieser Artikel direkt darauf aufbaut.

Konfiguration Exchange 2016

Der erste Teil endete mit den Überlegungen für die URLs mit denen auf Exchange zugegriffen werden soll. Der Einfachheit halber hier noch einmal die Tabelle mit den URLs:

Die Konfiguration der URLs ist für Autodiscover wichtig. Diese URLs werden durch Autodiscover an Outlook verteilt, somit findet Outlook den entsprechenden Exchange Server. Werden die virtuellen Verzeichnisse nicht mit entsprechenden URLs konfiguriert, kommt es später wieder zu Zertifikatsfehlern. Es ist also genau darauf zu achten, dass für jedes virtuelle Verzeichnis eine entsprechende interne und externe URL gesetzt wird. Autodiscover verteilt sonst falsche URLs an die Clients.

Die URLs können per Exchange Administrative Center eingestellt werden, hier für OWA:

hier für ECP:

Auf diese Weise werden alle virtuellen Verzeichnisse konfiguriert, mit Ausnahme von “Powershell” und “Autodiscover”. “PowerShell” und “Autodiscover” werden _NICHT_ verändert und erhalten keine neuen URLs:

Es werden also nur die folgenden virtuellen Verzeichnisse mit den URLs aus der Tabelle gefüllt:

• owa
• OAB
• Microsoft-Server-ActiveSync
• mapi
• EWS
• ecp

Nachdem die virtuellen Verzeichnisse konfiguriert wurden, kann auch der Hostname für Outlook Anywhere vergeben werden, auch dies ist wieder per Exchange Administrative Center möglich:

Eine kleine Ausnahme bildet die Autodiscover URL für den CAS-Dienst, diese kann nur per Exchange Management Shell gesetzt werden. In der Standardeinstellung ist auch hier der interne Servername eingetragen:

Mit dem folgenden Befehl wird die URL entsprechend geändert:

Set-ClientAccessService EX1 -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"

Nachdem diese Schritte durchgeführt wurden, kann der IIS Server mittels “iisreset” neu gestartet werden:

Die Exchange Konfiguration ist soweit fertig, weiter geht es mit den erforderlichen DNS Einträgen.

DNS Konfiguration

Exchange hört nach den oben durchgeführten Schritte nur noch auf mail.frankysweb.de und Autodiscover auf autodiscover.frankysweb.de. Damit diese beiden FQDNs nun auch im internen Netzwerk, sowie auch aus dem Internet (HomeOffice) auflösbar sind, müssen entsprechende DNS Einträge konfiguriert werden.

Noch einmal kurz der Ablauf der Kommunikation (vereinfacht)

Ein interner Rechner hat als DNS Server üblicherweise den Domain Controller konfiguriert. Outlook auf dem internen Rechner wird zunächst autodiscover.frankysweb.de anfragen um den Exchange Server zu finden. Der DNS Server auf dem Domain Controller antwortet auf die Anfrage des Clients mit der internen IP Adresse des Exchange Servers. Der Client ruft die Konfiguration ab und fragt dann wiederum den internen DNS Server nach mail.frankysweb.de. Das Bild stellt die DNS Anfragen und Antworten vereinfacht dar (grüne und roter Pfeile):

Ähnliches gilt für Clients im HomeOffice. Auf den meisten Routern wird ein DNS-Forwarder laufen. Dieser DNS Forwarder auf dem Router reicht die DNS Anfragen des Clients aus dem HomeOffice an entsprechende DNS-Server im Internet weiter. Hier gibt es zwar noch mehrere beteiligte DNS-Server, aber schlussendlich wird der DNS-Server des Hosters auf die Autodiscover reagieren müssen. Die Anfragen zu autodiscover.frankysweb.de und mail.frankysweb.de, sollen nun mit der externen IP-Adresse des Internetanschlusses des Unternehmens beantwortet werden. Die Outlook Verbindung wird also diesen Weg gehen (blaue Pfeile)

Intern wird sich Outlook mit mail.frankysweb.de verbinden welches auf die interne IP-Adresse des Exchange Servers zeigt. Extern wird es ebenso mail.frankysweb.de sein, nur mit dem Unterschied, dass jetzt die externe IP aufgelöst wird.

Dazu müssen die DNS Server entsprechend konfiguriert werden:

Internen DNS Server konfigurieren

Da Autodiscover nach erfolgter Konfiguration nun die URLs wie oben angegeben verteilen wird, müssen die URLs nun auch verfügbar sein. Auf dem Domain Controller werden die DNS-Zonen etwa wie folgt aussehen:

Da das ActiveDirectory in diesem Fall auf den Namen frankysweb.local hört, gibt es dazu zwei entsprechende interne Zonen und normalerweise auch eine Reverse Lookup Zone mit den entsprechenden Subnetzen.

Intern muss Exchange nun aber über den Namen mail.frankysweb.de und autodiscover.frankysweb.de erreichbar sein, denn diese Namen wurden entsprechend konfiguriert. Daher wird zunächst eine neue DNS Zone erstellt:

Als Zonentyp wird “Primäre Zone” belassen:

Auch die Zonenreplikation kann so belassen werden:

Als Zonenname wird “mail.frankysweb.de” eingetragen:

Dynamische Updates können abgeschaltet werden:

Innerhalb der neuen Zone wird nun ein neuer HOST-A Eintrag angelegt:

Für den HOST-A Eintrag wird _KEIN_ Name konfiguriert. Im Feld IP-Adresse wird die interne IP des Exchange Servers angegeben und das Häkchen bei “Verknüpften PTR-Eintrag erstellen” entfernt:

Somit sollte es nun wie folgt aussehen:

Die Schritte werden entsprechend für Autodiscover wiederholt. Eine weitere Neue Zone mit dem Namen “Autodiscover.frankysweb.de” wird angelegt:

Und auch in der Zone autodiscover.frankysweb.de wird ein HOST-A Eintrag mit der internen IP des Exchange Servers angelegt:

Mittels nslookup können nun die beiden Zonen überprüft werden.

Autodiscover.frankysweb.de und mail.frankysweb.de müssen von einem internen Client/Rechner/Server auf die interne IP des Exchange Servers verweisen:

Konfiguration externer DNS (Hoster)

Damit der Exchange Server nun auch aus dem Internet (HomeOffice) unter dem Namen mail.frankysweb.de erreichbar ist, müssen entsprechende DNS Einträge beim Hoster der Domain gesetzt werden. Je nach Hoster (Strato, 1und1, HostEurope etc.) verläuft die Konfiguration hier etwas unterschiedlich. In diesem Beispiel ist es Strato:

Zuerst werden zwei neue Subdomains angelegt:

Einmal die Subdomain mit dem Namen “mail”, woraus sich “mail.frankysweb.de” ergibt:

Gleiches für die Subdomain mit dem Namen “autodiscover”, woraus sich autodiscover.frankysweb.de ergibt.

Für beide Subdomains wird jetzt ein A-Record definiert:

Als IP-Adresse wird die externe IP-Adresse des Internetanschlusses des Unternehmens angegeben:

Hinweis: Hier handelt es sich um die WAN-IP des Routers / Firewalls des Unternehmens.

Die WAN-IP wird für autodiscover und mail eingegeben. Die Übersicht der Domain sollte nun in etwa so aus sehen:

Autodiscover.frankysweb.de und mail.frankysweb.de verfügen über je einen A-Record mit der externen IP Adresse des Unternehmens.

Die DNS Auflösung mittels nslookup sollte jetzt die externe IP für autodiscover.frankysweb.de und mail.frankysweb.de zurückliefern:

Es fehlt jetzt noch die Portweiterleitung am Router des Unternehmens damit der Exchange Server auch unter Port 443 erreichbar ist.

Konfiguration Portweiterleitung am Router / Firewall

Die END-Einträge wurden nun konfiguriert, allerdings fehlt noch eine Portweiterleitung am Router des Unternehmens, damit der Exchange Server auch via Port 443 aus dem Internet erreichbar ist. Auch hier ist die Einrichtung wieder abhängig vom eingesetzten Router oder Firewall. Auch der Name variiert hier von Hersteller zu Hersteller, NAT-Regel, Portforward, DNAT, Portweiterleitung oder Portfreigaben sind hier gängige Begriffe.

Die Logik dahinter ist folgende:

Eine Verbindung, die an der externen IP Adresse des Routers auf einem bestimmten Port ankommt, wird weitergeleitet an eine interne IP-Adresse und Port.

Hinweis: Die Einrichtung einer Portweiterleitung macht den Exchange Server aus dem Internet via Port 443 erreichbar. Besser wäre der Einsatz einer entsprechenden Firewall bzw. Proxys (hier ein Beispiel) zwischen Internet und Exchange Server. Die Einrichtung ist aber nicht Gegenstand dieses Artikels.

Falls das Unternehmen über eine Fritzbox verfügt, funktioniert die Einrichtung einer Portfreigabe wie folgt:

Wie im Screenshot zu erkennen ist, wird nur der Port 443 (TCP) an die interne IP des Exchange Servers auf Port 443 weitergeleitet.

Das rote Tuch (Exchange Zertifikat)

Zum Schluss ist das “rote Tuch” besser bekannt als Zertifikat an der Reihe. Wenn die Vorbereitungen allerdings alle abgeschlossen wurden, ist es jetzt kein Problem mehr.

Noch einmal kurz zum Hintergrund:

In der voran gegangene Konfiguration wurden die virtuellen Verzeichnisse und die Outlook Anywhere Konfiguration soweit angepasst, das diese auf mail.frankysweb.de hören, aus diesem FQDN ergeben sich dann die entsprechenden URLs mit denen die Verzeichnisse (interne und externe URLs) entsprechend konfiguriert wurden. Internes und Externes DNS wurden ebenfalls so konfiguriert, dass der Exchange Server unter diesen URLs erreichbar ist. Somit sind für das Zertifikat nur die folgenden FQDNs von Bedeutung:

• mail.frankysweb.de
• autodiscover.frankysweb.de

Mehr muss nicht auf dem Zertifikat stehen. Nur diese beiden Namen. Falls sich jetzt schon jemand fragen sollte: Was ist denn wenn ich mehrere Domains habe und auch E-Mail Adressen mit beispielsweise “@frankysweb.com”? Weiterlesen, kommt noch…

Um die Zertifikatsanforderung zu speichern, sollte vorab ein Ordner angelegt werden. Am besten auf dem Exchange Server selbst unter C:\. In diesem Fall ist es C:\Zertifikat:

Jetzt kann die Zertifikatsanforderung erstellt werden.

Zertifikatsanforderung erstellen

Damit eine Zertifizierungsstelle ein Zertifikat ausstellen kann, wird eine Zertifikatsanforderung benötigt. Die Zertifikatsanforderung teilt der Zertifizierungsstelle die Eigenschaften für das Zertifikat mit. Um bei den Ausweisbeispiel zu bleiben: Die Zertifikatsanforderung ist der Antrag auf einen Ausweis, wobei der Antrag den Namen, Adresse usw. enthält. Der Antrag (Zertifikatsanforderung) muss jetzt von von einer Behörde/Land (Zertifizierungsstelle) ausgestellt werden.

Eine Zertifikatsanforderung kann via Exchange Admin Center erstellt werden:

Als Anzeigename wird “mail.frankysweb.de” eingetragen:

Der nächste Dialog kann so belassen werden, hier muss nichts ausgewählt werden:

Gespeichert wird das Zertifikat auf EX1 dem Exchange Server:

Im darauf folgenden Dialog werden alle URLs noch einmal angezeigt:

Wer die Liste durchscrollt, wird feststellen, das hier noch interne Servernamen und URLs angezeigt werden. Auch diese können so belassen werden:

Im nächsten Dialog lassen sich die Einträge für das Zertifikat bearbeiten, hier wird jetzt alles gelöscht, sodass nur noch “mail.frankysweb.de” und “autodiscover.frankysweb.de” überbleibt.

Vorher:

Nachher:

Jetzt müssen noch ein paar Angaben vervollständigt werden. Organisationsname entspricht dabei den Firmenname, der Abteilungsname kann frei gewählt werden, Ort, Bundesland und Land sollte klar sein:

Zum Schluss wird der Speicherort für die Zertifikatsanforderung angegeben. Im Vorfeld wurde dazu der Ordner c:\Zertifikat auf dem Exchange Server angelegt. Dieser Ordner kann nun per Administrativer Freigabe angesprochen werden:

Die Anforderung wurde erstellt im Admin Center ist nun eine ausstehende Anforderung zu sehen:

Ausstehende Anforderung bedeutet in diesem Fall soviel wie: Antrag ausgefüllt, aber noch kein Ausweis ausgestellt.

Unter C:\Zertifikat findet sich nun eine Datei mit dem Namen “Anforderung.txt”. Diese Datei enthält den Antrag für die Zertifizierungsstelle, auch “Certificate Signing Request” (CSR) genannt:

Der Antrag (CSR) muss nun bei einer Zertifizierungsstelle eingereicht werden.

Zertifikat von einer offiziellen Zertifizierungsstelle anfordern

Die zuvor generierte Anforderung muss nun bei einer Zertifizierungsstelle eingereicht werden. Die Zertifizierungsstelle stellt dann ein entsprechendes Zertifikat aus.

Wie schon mehrfach erwähnt müssen zwei Namen auf dem Zertifikat (SAN Zertifikat) vorhanden sein (autodiscover.frankysweb.de und mail.frankysweb.de). So steht es auch in der generierten Anforderung. Bei dem Reseller PSW gibt es recht günstig ein entsprechendes Zertifikat:

https://www.psw-group.de/ssl-zertifikate/detail/c44-geotrust-quickssl-premium/

3 Jahre Gültigkeit kosten 99 EUR. Verschiedene andere CAs bieten Zertifikate auch kostenlos an, wobei als wohl bekanntester Vertreter StartSSL Probleme mit Mozilla bekommen hat (StartSSL und auch WooSign haben es nicht ganz so genau mit der eigenen Sicherheit genommen).

Der Prozess wie eine Anforderung eingereicht werden muss, ist aber bei den meisten Zertifizierungsstellen ähnlich:

1. Anmelden
2. Zertifikatsanforderung einreichen
3. Valdierung durchlaufen (das Verfahren kann unterschiedlich sein, meistens eine Mail an webmaster@domain.tld oder hostmaster@domain.tld)
4. Zertifikat erhalten
5. Bezahlen (ggf. auch kostenlos)

Trotz der Probleme bei StartSSL lassen sich weiterhin Zertifikate beantragen, da wie schon der Prozess bei den meisten Zertifizierungsstellen relativ ähnlich ist, folgt hier das Beispiel mit StartSSL. Die Anmeldung wurde bereits abgeschlossen:

Bei StartSSL müssen dann die beiden DNS-Namen angegeben und der Inhalt der Datei Anforderung.txt hochgeladen werden:

Nach entsprechender Validierung durch die Zertifizierungsstelle erhält man das Zertifikat. Für Testumgebungen lässt sich StartSSL weiterhin wunderbar verwenden, ich nehme an das die Probleme mit Mozilla in absehbarer Zeit geklärt werden.

Für produktive Umgebung würde ich empfehlen ein Zertifikat zu kaufen, der Preis aus dem oben genannten Beispiel ist sicherlich nicht zu hoch und bei 3 Jahren Laufzeit durchaus erschwinglich.

Sobald man das Zertifikat von der Zertifizierungsstelle erhalten hat (meistens per Download oder per Mail), kann es auf dem Exchange Server unter C:\Zertifikat abgespeichert werden.

Die meisten Zertifizierungsstellen stellen das Zertifikat in verschiedenen Formaten aus. Exchange Server kann mit .CER und .CRT Dateien umgehen. In diesem Beispiel ist es eine .CRT Datei:

Zertifikatsanforderung abschließen und Dienste zuweisen

Sobald das Zertifikat im Ordner C:\Zertifikat abgespeichert wurde, kann die Austehende Anforderung abgeschlossen werden. Dieser Vorgang kann wieder mittels Exchange Admin Center erfolgen:

Im Dialog wird dann wieder die Administrative Freigabe und der Name des Zertifikats angegeben:

Sobald die Anforderung abgeschlossen wurde, wird das Zertifikat mit “Gültig” gekennzeichnet:

Jetzt ist zwar ein gültiges Zertifikat vorhanden, aber dieses Zertifikat wurde noch nicht den Exchange Diensten zugeordnet.

Damit Exchange dieses Zertifikat auch künftig verwendet, muss es an die relevanten Dienste gebunden werden, dazu werden die Eigenschaften des Zertifikats per Doppelklick geöffnet und die folgenden Dienste zugewiesen:

• SMTP
• IMAP
• POP
• IIS

Die Warnung muss bestätigt werden, dann wird das Zertifikat ausgetauscht:

Ab jetzt benutzt Exchange das neue Zertifikat.

Überprüfung

Zur Überprüfung können nun mehrere Tests durchgeführt werden.

Zunächst kann die DNS Auflösung von internen sowie externen Rechnern getestet werden:

Intern muss die interne IP des Exchange Servers aufgelöst werden, extern die entsprechende IP des Routers mit der Portweiterleitung.

Dann kann Outlook Web Access von internen sowie externen Rechnern aufgerufen werden, jeweils unter den Namen mail.frankysweb.de. Beim Aufruf darf nun keine Zertifikatswarnung mehr auftreten:

In den Details des Zertifikat unter dem Punkt “Alternativer Antragsstellername” müssen beide Namen hinterlegt sein:

Outlook zeigt im Verbindungsstatus nur mail.frankysweb.de als Servernamen an, interne Namen dürfen hier nicht mehr vorkommen:

Der Outlook Modus “E-Mail Autokonfiguration testen” liefert nur noch URLs mit https://mail.frankysweb.de/… zurück

Exchange Remote Connectivity Analyzer lässt für den Autodiscover Test sauber durch:

Bei der URL “https://frankysweb.de:443/Autodiscover” darf es zu einem Fehler kommen, da Exchange nicht unter dieser URL erreichbar ist, für die URL https://autodiscover.frankysweb.de:443/autodisover” muss es sauber durchlaufen (Ohne Zertifikatswarnung)

Nachtrag

Dies war die grundlegende Konfiguration mit einer E-Mail Domain und einem offiziellen Zertifikat. Nun gibt es natürlich noch weitere Fälle mit einer internen Zertifizierungsstelle oder mehreren E-Mail Domänen. Das wird dann ein Fall für Teil 3 (bereits in Arbeit, wird verlinkt wenn fertig).

Der Beitrag Exchange 2016: Zertifikate konfigurieren (Teil 2) erschien zuerst auf Franky's Web.

Dies ist der letzte Teil der Beitragsserie “Zertifikate konfigurieren” für Exchange Server 2013 und Exchange 2016. Die vorherigen Teile finden sich hier:

• Zertifikate konfigurieren Teil 1
• Zertifikate konfigurieren Teil 2

Hinweis: Auch dieser Teil baut auf Teil 1 und Teil 2 auf, also bitte unbedingt vorher die ersten beiden Teile lesen.

In diesem Teil geht es um zwei Themen, zum einen die Anbindung weiterer E-Mails Domänen und zum anderen die Punkte die zu beachten sind , wenn eine interne Zertifizierungsstelle anstatt öffentlicher Zertifikate genutzt wird.

Anbindung weiterer E-Mail Domänen

Um es direkt vorweg zu nehmen: Für das Anbinden weiterer E-Mail Domänen, muss das Zertifikat nicht geändert werden.

In Teil 2 wurde das folgende Zertifikat für Exchange Server ausgestellt und nutzbar gemacht:

Als Namen wurden mail.frankysweb.de für die Exchange Benutzerschnittstellen (OWA, ActiveSync, EWS, MAPI) eingetragen und für Autodiscover der Name autodiscover.frankysweb.de. Als E-Mail Domain wird entsprechend @frankysweb.de verwendet.

Nehmen wir mal an, dass neben frankysweb.de und auch firma.de als E-Mail Domain genutzt werden soll. Wie hier zu sehen, gibt es jetzt einen Benutzer mit der E-Mail Adresse hans@firma.de:

firma.de ist dann natürlich auch als akzeptierte Domain angelegt:

Um die Domain firma.de entsprechend auch per Autodiscover erreichbar zu machen sind nur Änderungen am DNS des Hosters und am internen DNS nötig.

Anpassung interner DNS Server

Am internen DNS Server, also normalerweise auf dem Domain Controller, wird eine weitere DNS Zone erstellt:

Als Typ wird wieder “Primäre Zone” ausgewählt:

Die Zone wird auf allen DNS Server ausgeführt:

Als Zonenname wird “firma.de” angegeben:

Dynamische Updates können deaktiviert werden:

Nachdem der Assistent abgeschlossen wurde, gibt es nun eine DNS-Zone mit dem Namen “firma.de”:

Achtung: Hierbei handelt es sich jetzt um eine DNS-Split Brain Konfiguration. Das heißt konkret, der DNS Server ist jetzt für interne Rechner, die den internen DNS Server nutzen für die Zone firma.de authorativ. Versuchen jetzt interne Clients beispielsweise www.firma.de aufzurufen, wird der interne DNS Server mit NXDOMAIN (non existent Domain, gibts nicht) antworten. Der Hintergrund ist einfach: Der Domain Controller geht davon aus, das er der Chef für firma.de ist, da die Zone firma.de wie oben zu sehen keine Einträge enthält (Beispielsweise www) antwortet er mit “Gibt’s nicht”:

Wenn es sich bei www.firma.de nun um einen Webserver beim Hoster handelt der die Firmenwebsite hostet, dann muss dieser Server entsprechend intern bekannt gemacht werden. Nehmen wir an, der Webserver des Hosters hat die IP 12.34.12.34, dann wird nun ein HOST-A Eintrag in der Zone firma.de angelegt:

Nachdem der Eintrag angelegt wurde, ist auch www.firma.de zu erreichen:

Auf diese Weise müssen nun alle externen Server eingetragen werden, beispielsweise shop.firma.de, portal.firma.de oder was es sonst noch geben mag.

Wenn alle externen Ressourcen eingetragen wurden, kann ein Autodiscover Eintrag angelegt werden. Bei dem Autodiscover Eintrag handelt es sich um einen SRV-Record, dieser kann über “Weitere neue Einträge” angelegt werden:

Im Assistenten muss “Dienstidentifizierung (SRV)” ausgewählt werden:

Für den SRV-Record gelten folgende Werte:

• Dienst: _autodiscover
• Protokoll: _tcp
• Portnummer: 443
• Host: autodiscover.FRANKYSWEB.de

Hinweis: Die Unterstriche müssen mit eingegeben werden!

So sieht es nach dem Anlegen des Eintrags aus:

Vereinfacht gesagt haben wir jetzt einen Verweis angelegt, der Outlook mitteilt, dass Autodiscover für firma.de unter autodiscover.frankysweb.de zu erreichen ist. Da autodiscover.frankysweb.de auf dem Zertifikat vorhanden ist, wird Outlook das Zertifikat als gültig akzeptieren.

Auf diese Art und Weise lassen sich beliebige Domains anbinden. Das Zertifikat muss nicht mehr angefasst werden.

Anpassung externer DNS (Hoster)

Die Änderung, wie oben beschrieben, ist für das interne LAN. Damit auch Outlook Anywhere funktioniert, muss ebenfalls ein SRV-Record beim Hoster angelegt werden. Da sich hier die Einrichtung wieder von Hoster zu Hoster unterscheidet, gibt es hier nur ein Beispiel für Strato. Als Beispiel dient hier die Domain “exchange-tools.de” (Denken wir uns einfach exchange-tools.de ist firma.de):

Wenn vorhanden, muss zunächst die Hoster eigene Autodiscover Funktion abgeschaltet werden:

Danach kann in den DNS Einstellungen ein SRV-Record angelegt werden:

Für den SRV-Record sind die gleichen Einstellungen wie für den internen DNS vorzunehmen:

• Service: _autodiscover
• Protokoll: _tcp
• Port: 443
• Ziel: autodiscover.FRANKYSWEB.de

Das war schon alles. Jetzt können Tests folgen.

Outlook Anywhere (Client nicht Mitglied im Active Directory)

Wie eingangs erwähnt, habe ich einen Benutzer “Hans” mit der E-Mail Adresse hans@firma.de angelegt. Wenn Hans nun Outlook auf einem PC nutzen möchte, der NICHT Mitglied des Active Directory ist, dann läuft die Einrichtung wie folgt ab:

Hans startet Outlook beispielsweise im Home Office:

Hans möchte ein E-Mail Konto einrichten:

Hans trägt seinen Namen, E-Mail Adresse und sein Passwort des ActiveDirectory Benutzerkontos ein:

Bei der Konfiguration wird Hans jetzt nach seinem Benutzernamen und Kennwort gefragt, in dem Fall ist es normal:

• Der Benutzername ist nicht hans@firma.de sondern hans@frankysweb.local, Nur die E-Mail Adresse ist hans@firma.de:
• Outlook kann keine Anmeldeinformationen durchreichen, denn der PC befindet sich nicht im ActiveDirectory und Hans ist ein lokaler Benutzer
• Hans muss also seine Anmeldedaten angeben und wird daher gefragt:

Hans muss seine Active Directory Daten angeben:

Hans ist glücklich, ohne Zertifikatswarnungen:

Die Outlook Verbindung läuft nun wie für alle anderen Benutzer gegen den Server mail.frankysweb.de:

Da ein SRV Record gefunden wurde, funktioniert auch Autodiscover problemlos:

Outlook innerhalb des Active Directory

Zum Vergleich hier noch einmal die Einrichtung von Outlook wenn Hans einen PC nutzt der Mitglied des Active Directory ist und Hans sich mit seinem Benutzerkonto angemeldet hat:

Name und E-Mail Adresse wird automatisch ausgefüllt, das Passwort Feld existiert nicht:

Direkte Anmeldung an Exchange, ohne Abfrage von Benutzername und Kennwort und selbstverständlich ohne Zertifikatsfehler:

Auch hier laufen die Verbindungen gegen mail.frankysweb.de

Autodiscover funktioniert ebenfalls ohne Probleme:

Nutzung einer internen Zertifizierungsstelle

Die Einrichtung einer eigenen Zertifizierungsstelle habe ich hier bereits detailliert beschrieben und das HowTo ist ebenfalls für Exchange 2016 gültig, daher spare ich mir an dieser Stelle noch einmal die Konfiguration zu beschreiben:

https://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/

Es gibt allerdings ein paar Punkte zu beachten:

Im oben angegebenen Artikel wird eine interne Zertifizierungsstelle eingerichtet, diese Zertifizierungsstelle generiert sich das Zertifikat selbst. Die Zertifizierungsstelle verfügt also über ein selbst ausgestelltes Zertifikat. Hier ist wieder der Vergleich mit dem Ausweis und der Behörde: Die Zertifizierungsstelle behauptet sie wäre ein Staat/Behörde und stellt entsprechende Ausweise (Zertifikate) aus. Die Frage ist nun wer akzeptiert die Ausweise und die Behörde? Innerhalb des Aktive Directory wird das Zertifikat der Zertifizierungsstelle per Gruppenrichtlinie automatisch verteilt, somit sehen alle Active Directory Mitglieder die Zertifizierungsstelle als vertrauensvolle Behörde an. Alle Clients die nicht Mitglied es Active Directory sind (Smartphones, ggf. HomeOffice, etc) kennen die Behörde nicht und sehen sie daher auch als nicht vertrauenswürdig an, die Ausweise sind damit ebenfalls nicht vertrauenswürdig: Zertifikatsfehler.

Entweder man sorgt nun dafür, dass das Zertifikat der Zertifizierungsstelle auf allen Clients installiert wird, was bei Clients ausserhalb des Active Directory (PCs im HomeOffice, Smartphones, Notebooks, etc) ziemlich viel Arbeit machen kann, oder man investiert direkt ein bisschen Geld in ein entsprechendes Zertifikat einer öffentlichen Zertifizierungsstelle. Ich würde zum öffentlichen Zertifikat raten.

Wer die interne Zertifizierungsstelle auch auf Clients vertrauenswürdig machen möchte, muss das Stammzertifizierungsstellenzertifikat seiner eignen Zertifizierungsstelle auf den Clients installieren.

Installation des Stammzertifizierungsstellenzertifikats unter Windows

Das Stammzertifizierungsstellenzertifikat befindet sich auf der Zertifizierungsstelle im folgenden Ordner:

C:\Windows\System32\CertSrv\CertEnroll

Dieses Zertifikat muss nun auf allen Clients installiert werden:

Das Zertifikat sollte im Speicher für den Computer installiert werden, damit es nicht für jeden Benutzer einzeln installiert werden muss:

Das Zertifikat wird im Zertifikatsspeicher “Vertrauenswürdige Stammzertifizierungsstellen” installiert.

Hinweis: Das Zertifikat des Exchange Servers welches von dieser Zertifizierungsstelle ausgestellt wurde, muss NICHT installiert werden. Alle Zertifikate die von der installierten Zertifizierungsstelle ausgestellt werden, werden akzeptiert. Sofern natürlich die Namen und das Ablaufdatum stimmen.

Übrigens: Firefox bringt seinen eignen Zertifikatsspeicher mit und greift nicht auf den Windows Zertifikatsspeicher zu. Hier muss das Zertifikat gesondert importiert werden.

Der Beitrag Exchange 2016: Zertifikate konfigurieren (Teil 3) erschien zuerst auf Franky's Web.

Heute stellte sich ein Windows 2012 Server gelinde gesagt etwas zickig an, als Updates installiert werden sollten. Es musste ein Windows Update installiert werden, damit Windows Server 2012 mit der KMS Rolle Windows Server 2016 aktivieren kann.

Damit Server 2012 KMS Windows Server 2016 aktivieren kann, sind diese beiden Updates nötig:

Windows Server 2012:

• KB3058168
• KB3172615

Windows Server 2012 R2:

• KB3058168
• KB3172614

Mein Windows 2012 Server wollte das Update KB3172615 allerdings nicht einspielen. Nach dem Neustart hing der Server 15 Minuten lang mit folgender Meldung fest:

Windows Updates werden konfiguriert

67 % abgeschlossen

Nach 15 Minuten entschied sich der Server dazu, die Änderungen rückgängig zu machen, was wieder ca. 20 Minuten in Anspruch nahm.

Beim ersten Mal denkt man ja noch: “Gut, installier ich nochmal, dann klappt’s bestimmt”… nach weiteren 45 Minuten war ich schlauer: Klappt nicht!

Also ist Troubleshooting angesagt und um es vor weg zu nehmen: Ja, ich hab die Prozedur noch ein paar mal gesehen…

Das Eventlog war sauber, Speicher war auch genug frei. Den einzigen Hinweis fand ich in dieser Datei:

• C:\Windows\SoftwareDistribution\ReportingEvents.log

Dort fanden sich die folgenden beiden Fehlermeldungen (gekürzt):

[AGENT_INSTALLING_FAILED]       101     {BC8ED8B9-FA16-4281-B953-B3678FA9355F}    501         800f0920       wusa   Failure Content Install         Installation Failure: Windows failed to install the following update with error 0x800f0920: Update für Windows (KB3172615).

[AGENT_DETECTION_FAILED]        101     {D67661EB-2423-451D-BF5D-13199E37DF28}   1         80244022      SelfUpdate    Failure Software Synchronization    Windows Update Client failed to detect with error 0x80244022.

Die Fehlercodes deuteten darauf hin, dass der Trusted Installer in einen Timeout läuft. Der TimeOut Wert lässt sich via Registry anpassen, was bei mir zur Behebung des Problems geführt hat.

Unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TrustedInstaller gibt es den DWORD “BlockTimeIncrement” welcher per Default auf 900 Sekunden steht. Ich habe diesen Wert auf 10800 Sekunden erhöht:

Nachdem der Wert auf 10800 geändert wurde, habe ich das Update erneut installiert. Der Windows Server hing nun länger bei den 67 Prozent fest. Nach 25 Minuten war dann allerdings das Update erfolgreich installiert. Hier schien also das 15 Minuten TimeOut (900 Sekunden) die Ursache gewesen zu sein. Da Windows Server 2012 R2 den gleichen TimeOut besitzt könnte es auch hier helfen.

Der Beitrag Windows Update hängt bei 67 Prozent – Änderungen werden rückgängig gemacht erschien zuerst auf Franky's Web.

Wahrscheinlich sind schon einige darauf aufmerksam geworden, es gibt eine neue Unterseite mit dem Namen Projekte. Auf dieser Seite veröffentliche ich Tools, die entweder Spielerei waren oder aus dem Fokus verschwunden sind.

Derzeit gibt es dort zwei Tools, die mehr oder weniger erfolgreich waren: Die Raumanzeige und den Header Analyzer.

Die Raumanzeige war mal als digitale Frei/Belegt Anzeige für Besprechungsräume gedacht:

Der Header Analyzer war dazu gedacht, die Mail Header besser lesbar darzustellen :

In der nächsten Zeit werde ich noch weitere Tools oder Bastelanleitungen veröffentlichen. Allerdings sei an dieser Stelle noch gesagt: Manches ist über ein Bastelprojekt nicht hinaus gekommen, entweder weil ich die Lust daran verloren habe oder weil der vorgesehene Einsatzzweck nicht mehr gegeben war.

Die Projekte auf dieser Seite sind also alles kleine private Bastelgeschichten, die ich irgendwann einmal ausprobiert habe. Manche Dinge wurden mittlerweile weiterentwickelt, manches wurde schnell wieder beerdigt. Ein gutes Beispiel für ein erfolgreiches Projekt ist der „Exchange Reporter“, dieser wird mittlerweile von einigen namhaften Organisationen eingesetzt, die mitunter sehr große Exchange Umgebungen besitzen.

Aber auch die Fehlversuche könnten ja durch aus mal interessant sein. Vielleicht findet sich ja auch jemand der es weiterentwickelt, wenn nicht fristen die Projekte eben nun auf ihrer eigenen Seite dahin. Immer noch besser als auf der lokalen Festplatte in der Versenkung zu landen und irgendwann der großen Aufräumaktion zum Opfer zu fallen. Ich müsste wirklich dringend mal aufräumen.

Der Beitrag Neue Unterseite: Projekte erschien zuerst auf Franky's Web.

Auf dem Exchange Team Blog ist eine Warnung zu Exchange Server 2016 auf Windows Server 2016 zu erschienen. Auf Windows Server 2016 kann es zum abstürzen des IIS (konkret w3wp.exe) kommen. Ein Fix für Windows Server 2016 ist in Arbeit. Bis zum Erscheinen des Updates wird davon abgeraten Exchange 2016 auf Windows Server 2016 zu installieren.

Auch in den Windows Server 2016 Release Notes ist ein entsprechender Hinweis zu finden:

If you attempt to run Microsoft Exchange 2016 CU3 on Windows Server 2016, you will experience errors in the IIS host process W3WP.exe. There is no workaround at this time. You should postpone deployment of Exchange 2016 CU3 on Windows Server 2016 until a supported fix is available.

Das Problem scheint Exchange Server zu betreffen die Mitglied einer DAG sind. Der W3WP Prozess stürzt hier scheinbar ab und im Anwendungseventlog finden sich die folgenden Event IDs: 4999, 5011 und 1003. Standalone Server scheinen von dem Problem nicht betroffen zu sein, auch meine Exchange Standalone Installation (also ohne DAG) läuft bisher sauber auf Windows Server 2016.

Das Problem ist allerdings schwerwiegend, da der IIS nahezu die komplette Kommunikation des Exchange Servers abwickelt (MAPI, ActiveSync, EWS, EAC, etc).

Produktive Installationen sollten allerdings trotzdem derzeit nicht auf Windows Server 2016 installiert werden.

Wann das Update für Windows Server 2016 erscheinen wird ist derzeit noch offen. Sobald es Neuigkeiten zu dem Problem gibt, werde ich den Artikel aktualisieren.

Der Beitrag Achtung: Windows Server 2016 mit Exchange 2016 macht Probleme erschien zuerst auf Franky's Web.

Gerade habe ich die neue Version der Message Tracking GUI für Exchange Server 2013 und Exchange 2016 hochgeladen.

Hier ein Screenshot der neuen GUI:

Folgende Funktionen sind derzeit verfügbar:

• Wenn kein Server angegeben wird, werden die Mail auf allen Exchange Servern gesucht
• Die Anzahl der Ergebnisse lässt sich einschränken (oder alle Ergebnisse anzeigen)
• Es können alle Werte einer Mail angezeigt werden (ausgenommen Inhalt)
• Ein reduzierter Bericht für Benutzer ist verfügbar (für Helpdesk)
• Die Resultate lassen sich in einer CSV-Datei speichern
• Die Health Check Nachrichten werden zur besseren Übersicht nicht angezeigt, lassen sich aber bei Bedarf anzeigen
• Die GUI ist in 3 Sprachen verfügbar (Deutsch, Englisch, Französisch)

Gegenüber der ersten Version sind einige Verbesserungen eingeflossen:

• Das Feld Betreff filtert auf ähnliche Angaben, anstatt den exakten Betreff zu suchen
• Die Sprache lässt sich direkt umstellen, es sind keine unterschiedlichen Versionen nötig
• Als Anwendung (statt Script) paketiert, somit direkt per Doppelklick aufrufbar
• Falls die Exchange Management Tools nicht verfügbar sind, wird eine Fehlermeldung angezeigt

Aber es gibt auch noch Verbesserungspotenzial, folgende Features stehen noch auf der ToDo Liste:

• Wildcard Suche für alle Felder
• Remote Shell nutzen um die Abhängigkeit zu den Exchange Management Tools zu beheben
• Bessere Filterung der EventIDs
• Bessere Fehlerbehandlung

Hier geht es direkt zur neuen Seite und zum Download:

Exchange Server Message Tracking GUI

Falls Probleme auftreten oder es Verbesserungsvorschläge gibt, findet sich dort auch ein Kontaktformular.

Update: Jetzt auch ohne Rechtschreibfehler in der Überschrift ;-)

Der Beitrag Neue Version der Message Tracking GUI verfügbar erschien zuerst auf Franky's Web.

Frei nach dem Motto der Exchange User Group Berlin:

We all get better when we share

Die Exchange User Group Berlin und die Exchange User Group OWL sind ab sofort Partner Communities. Beide Offline Communities stehen noch ganz am Anfang, haben aber das gleiche Ziel:

• Wir wollen den direkten Austausch zwischen den Administratoren, Consultants und Interessierten in geselliger Runde fördern.

Das erste Treffen der Exchange User Group Berlin findet nach derzeitiger Planung am 15.12.2016 in den Räumen der ppedv in Berlin statt. Für Interessierte aus dem Raum Berlin bietet die Exchange User Group Berlin eine Plattform, sich mit Gleichgesinnten über aktuelle Themen auszutauschen. Hier gibt es nähere Informationen und die Möglichkeit sich anzumelden:

http://exusg.de/

Auch die Planungen für das nächste Treffen der EUGO nehmen Gestalt an. Wir streben einen vierteljährlichen Zyklus an, den wir aber aufgrund diverser Termine nicht ganz halten können. Nach derzeitiger Planung findet das nächste Treffen der EUGO im Februar 2017 statt. Natürlich folgen noch weitere Details.

Ich kann leider nicht beim ersten Treffen der Berliner Usergroup dabei sein, habe mir aber fest vorgenommen beim zweiten Treffen dabei zu sein.

Ich hoffe das beide Communities in Zukunft einen festen Standpunkt erreichen und allen Teilnehmern einen Mehrwert bieten können. Den “Blick über den Tellerrand” und die Möglichkeit direkt zu fragen “Hey, wie macht ihr das?” bietet eben nur eine Community mit direkten Austausch… und einem kühlen Bier…

Übrigens: Der Initiator der Exchange User Group in Berlin dürfte nicht ganz unbekannt sein. Meiner Meinung nach also beste Voraussetzungen.

Der Beitrag Exchange User Group Berlin (EXUSG) und Exchange User Group OWL (EUGO) erschien zuerst auf Franky's Web.

Die Sophos UTM Email Protection enthält einen Bug bei dem die Empfängerverifizierung einfach übersprungen wird. Im Falle der Empfänger Prüfung mittels Active Directory und der Abfrage via SSL findet keine Verifizierung der Empfänger statt. Hier einmal die problematischen Einstellungen:

• Empfängerverifizierung mittels Active Direcory

• Abfrage des Active Directory mit SSL

Im Live Log der Email Protection führt es dann zu folgenden Logeinträgen:

2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 [127.0.0.1] F= R= Verifying recipient address in Active Directory 
2016:11:16-20:45:43 utm exim-in[25000]: 2016-11-16 20:45:43 H=mx.frankysweb.com [127.0.0.17]:46804 Warning: ACL "warn" statement skipped: condition test deferred: failed to bind the LDAP connection to server 127.0.0.2:636 - ldap_bind() returned -1 

Das Abfragen des Domain Controller schlägt fehl, und die Empfängerverifizierung wird übersprungen.

Empfängerprüfung via Serveranfrage (CallOut)?

Das Verhalten ist insbesondere mit Exchange 2013 und Exchange 2016 unschön, denn eine Empfängerprüfung via CallOut (Mit Serveranfrage) ist ohne Edge Transport Server nur schwer umzusetzen.

Da Recipient Validation erst am Hub Transport Connector stattfindet, aber nicht am FrontEnd. Exchange wird in diesem Fall also immer mit “250 Recipient OK” antworten. Die fehlende Empfänger Prüfung auf Exchange Seite ist hier Architektur bedingt. Eine Mail wird vom “Default Frontend”-Empfangsconnector immer angenommen und stumpf an den “Default”-Empfangsconnector weitergeleitet:

Die Empfängerverifizierung ist in diesem Fall also immer für die Mail Protection der UTM erfolgreich, denn erst der nachgelagerte Connector führt die Validierung des Empfängers durch. Dies ist übrigens auch der Fall, wenn die Exchange AntiSPAM Agents installiert werden.

LDAP SSL abschalten?

Äh? Nein, weil NEIN!

Sophos UTM Mail Protection anpassen (Workaround)

Das Anpassen der UTM Konfiguration via Shell wird wohl Probleme beim Support nach sich ziehen, darauf wird bereits beim Login hingewiesen:

NOTE: If not explicitly approved by Sophos support, any modifications
done by root will void your support.

Das Vorgehen sollte also mit dem Support abgesprochen werden. Ich habe nur die Home Version, also kann ich eh nicht auf den Support zurückgreifen.

Nachdem man sich auf der Shell mittels “sudo su –“ Root-Rechte verschafft hat, kann die folgende Datei mittels VI editiert werden:

vi /var/chroot-smtp/etc/openldap/ldap.conf

In der Datei wird die folgende Zeile hinzugefügt:

TLS_REQCERT allow

Danach die Datei speichern und die Mail Protection neustarten. Jetzt klappt auch die Empfängerprüfung mittels LDAP SSL:

2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 [127.0.0.1] F= R= Verifying recipient address in Active Directory 
2016:11:16-20:46:23 utm exim-in[24512]: 2016-11-16 20:46:23 H=mx.frankysweb.com [127.0.0.1]:46468 F= rejected RCPT : Address not present in directory 

Der Beitrag Sophos UTM Email Protection: Empfänger verifizieren mit LDAP SSL erschien zuerst auf Franky's Web.

Vorwort

In dieser Artikelreihe geht es um das manuelle Entfernen eines Exchange 2016 Servers aus dem Active Directory. Dieses Vorgehen sollte nur in besonderen Fällen angewendet werden. Die folgenden Fälle kommen in Frage:

• Es gab schon “früher” mal eine Exchange Installation die unvollständig oder fehlerhaft ist
• Der Exchange Server ist abgebrannt und kann nicht per Desaster Recovery wiederhergestellt werden (Kein Backup vorhanden, AD Computer Konto gelöscht)
• Ein neuer Exchange Server soll in einem misshandelten Active Directory installiert werden in dem einer oder beide der oben genannten Punkte zutreffen

Das im folgenden geschilderte Vorgehen muss mit Vorsicht durchgeführt werden und ist ENDGÜLTIG. Also bitte genau lesen und UNBEDINGT eine Sicherung der Domain Controller erstellen.

Falls das Computer Konto des Exchange Servers noch existiert, sollte zunächst ein Desaster Recovery versucht werden. Das manuelle Entfernen ist das aller letzte Mittel.

Umgebung

Dieser Artikel bezieht sich auf ein Active Directory in dem der einzige Exchange 2016 Server zerstört wurde und nicht aus der Sicherung wiederhergestellt werden kann. Der Domain Controller auf einem anderen Server ist allerdings noch intakt. Nehmen wir also an, dass der Exchange Server mit dem Namen FWCOMEX1 zuerst vom Blitz getroffen wurde, in dessen Folge der Server abgebrannt ist und durch die Hitze eine Wasserleitung gebrochen ist, die den Server geflutet hat:

Nachdem dann eine Wiederherstellung nicht mehr geklappt hat, weil auch schon das AD Computer Konto gelöscht wurde und alle Heilungsversuche fehlgeschlagen sind, soll nun von vorne begonnen werden. Einen kleinen Hoffnungsschimmer gibt es sogar noch für die Daten. FWCOMEX1 wurde also würdevoll beerdigt:

Vorgehen

In welche Reihenfolge vorgegangen wird, spielt eigentlich keine große Rolle, ich fange mit dem DNS an. Alle der hier erwähnten Schritte finden auf dem Domain Controller FWCOMDC1 statt.

DNS Einträge entfernen

Im DNS gibt es je nach Konfiguration mehrere Einträge die auf den kaputten Exchange Server verweisen. Die Einträge lassen sich meist einfach anhand der IP-Adresse identifizieren. Diese Einträge werden gelöscht:

In der DNS Zone könnte je nach Konfiguration auch noch ein SRV-Record für Autodiscover existieren. Dieser wird wird ebenfalls gelöscht:

Gleiches gilt für die Reverse Lookup Zone, alles was die IP des Exchange Servers trägt, wird gelöscht (wenn vorhanden)

Konfiguration aus Active Directory löschen

Nachdem die DNS Einträge gelöscht wurden, kann die Exchange Konfiguration aus der Active Directory Konfigurations Partition gelöscht werden. Dazu wird sich mittels ADSIEdit zuerst mit den Konfigurationspartition verbunden:

Unter “Services” finden sich die beiden Einträge “Microsoft Exchange” und “Microsoft Exchange Autodiscover”. Beide werden gelöscht:

Danach wird sich zum Namenskontext verbunden. Hier werden nun die Einträge “Microsoft Exchange Security Groups” und “Microsoft Exchange System Object” gelöscht:

Weiter geht es mit der Konsole “Active Directory-Benutzer und Computer”. In der OU Users werden alle Exchange Systempostfächer gelöscht:

Die Exchange Konfiguration ist jetzt bereits Geschichte.

Attribute der Benutzerkonten zurücksetzen

Auch die AD Benutzerkonten enthalten noch Attribute die auf den Exchange Server verweisen. Die Attribute können am einfachsten per PowerShell zurückgesetzt werden, da es sich um recht viele Attribute handelt. Für einen einzelnen Benutzer funktioniert es mit folgenden Befehl:

Get-ADUser frank | Set-ADUser -Clear msExchAddressBookFlags,msExchArchiveGUID,msExchArchiveName,msExchArchiveQuota,msExchArchiveWarnQuota,msExchBypassAudit,msExchCalendarLoggingQuota,msExchDumpsterQuota,msExchDumpsterWarningQuota,msExchELCMailboxFlags,msExchGroupSecurityFlags,msExchHomeServerName,msExchMailboxAuditEnable,msExchMailboxAuditLogAgeLimit,msExchMailboxGuid,msExchMailboxSecurityDescriptor,msExchMDBRulesQuota,msExchModerationFlags,msExchPoliciesIncluded,msExchProvisioningFlags,msExchRecipientDisplayType,msExchRecipientSoftDeletedStatus,msExchRecipientTypeDetails,msExchTextMessagingState,msExchTransportRecipientSettingsFlags,msExchUMDtmfMap,msExchUMEnabledFlags2,msExchUserAccountControl,msExchWhenMailboxCreated,showInAddressBook,proxyAddresses,legacyExchangeDN

Für alle Benutzer kann der folgende Befehl verwendet werden:

Get-ADUser -filter * | Set-ADUser -Clear msExchAddressBookFlags,msExchArchiveGUID,msExchArchiveName,msExchArchiveQuota,msExchArchiveWarnQuota,msExchBypassAudit,msExchCalendarLoggingQuota,msExchDumpsterQuota,msExchDumpsterWarningQuota,msExchELCMailboxFlags,msExchGroupSecurityFlags,msExchHomeServerName,msExchMailboxAuditEnable,msExchMailboxAuditLogAgeLimit,msExchMailboxGuid,msExchMailboxSecurityDescriptor,msExchMDBRulesQuota,msExchModerationFlags,msExchPoliciesIncluded,msExchProvisioningFlags,msExchRecipientDisplayType,msExchRecipientSoftDeletedStatus,msExchRecipientTypeDetails,msExchTextMessagingState,msExchTransportRecipientSettingsFlags,msExchUMDtmfMap,msExchUMEnabledFlags2,msExchUserAccountControl,msExchWhenMailboxCreated,showInAddressBook,proxyAddresses,legacyExchangeDN

Jetzt ist auch die Exchange Konfiguration der Postfächer Geschichte.

Computer Account löschen

Falls das Computer Konto des Exchange Servers noch existiert, kann es ebenfalls gelöscht werden:

Neuen Exchange Server installieren

Bevor ein neuer Exchange Server mit neuen Namen installiert wird, sollte das das Active Directory einmal per Kommandozeile vorbereitet werden, damit die notwendigen Einträge wieder angelegt werden.

Dazu kommt noch ein separater Artikel.

Der Beitrag Exchange 2016: Manuelles Entfernen eines Exchange Servers (Single Server) erschien zuerst auf Franky's Web.

Der Termin für das nächste Treffen der Exchange User Group OWL (EUGO) steht fest:

Freitag den 10.02.2017 19:30 Uhr

Hotel zur Spitze in Bielefeld Senne

Windelsbleicher Str. 215
33659 Bielefeld

Link: Google Maps

Link: Website Hotel zur Spitze

Anmeldungen nehmen Andi und Ich unter den folgenden Seiten entgegen:

• http://asichel.de/eugo/
• https://www.frankysweb.de/eugo/

Andi und Ich freuen uns schon jetzt wieder auf interessante Gespräche. Weitere Infos zur EUGO folgen.

Falls jemand aus dem Raum Berlin kommt, dann könnte auch das Treffen unserer Partnercommunity interessant sein. Das Treffen der Exchange User Group Berlin findet am 15.12.2016 statt. Hier sind allerdings nur noch wenige Plätze frei:

http://exusg.de/events/auftakttreffen-der-exchange-user-group-berlin/

Der Beitrag EUGO: Nächster Termin steht fest erschien zuerst auf Franky's Web.

Vorwort

Wie auch schon im ersten Teil dieser Artikelserie geht es um das manuelle Entfernen eines Exchange Servers. Dieses Vorgehen kann in “unsauberen” Umgebungen nötig sein. Dieses Vorgehen sollte nicht nach einer Migration angewendet werden. Die saubere Deinstallation ist hier der beste Weg. Folgende Fälle kommen für ein manuelles Entfernen in Frage:

• Es gab schon “früher” mal eine Exchange Installation die unvollständig oder fehlerhaft ist
• Der Exchange Server ist abgebrannt und kann nicht per Desaster Recovery wiederhergestellt werden (Kein Backup vorhanden, AD Computer Konto gelöscht)
• Ein neuer Exchange Server soll in einem misshandelten Active Directory installiert werden in dem einer oder beide der oben genannten Punkte zutreffen
• Die Migration wird vorbereitet, die alten Leichen verhindern aber eine erfolgreiche Installation

Das im folgenden geschilderte Vorgehen muss mit Vorsicht durchgeführt werden und ist ENDGÜLTIG. Also bitte genau lesen und UNBEDINGT eine Sicherung der Domain Controller erstellen.

Falls das Computer Konto des Exchange Servers noch existiert, sollte zunächst ein Desaster Recovery versucht werden. Das manuelle Entfernen ist das aller letzte Mittel.

Umgebung

Im ersten Artikel gab es nur einen Exchange Server und die Umgebung sollte zu einer grünen Wiese zurückgesetzt werden. Der nun folgende Fall dürfte etwas häufiger der Fall sein.

Es gibt einen produktiven Exchange Server (FWCOMEX1) und einen Exchange Server, der als Leiche in der Umgebung existiert (FWCOMEX2):

Für diese Umgebung hatte ich den Exchange Server FWCOMEX2 installiert, eine Datenbank und zwei Postfächer angelegt und den Server direkt wieder gelöscht. So etwas habe ich schon häufiger gesehen, meistens als Teil einer gescheiterten Migration.

In dieser Umgebung soll also FWCOMEX1 erhalten bleiben und nur FWEXCOM2 entfernt werden.

Vorgehen

In welche Reihenfolge vorgegangen wird, spielt eigentlich keine große Rolle, ich fange mit dem DNS an. Alle der hier erwähnten Schritte finden auf dem Domain Controller FWCOMDC1 oder auf dem verbleibenden Exchange Server FWCOMEX1 statt.

DNS Einträge entfernen

Je nach Umgebung findet sich hier eine unterschiedliche DNS Konfiguration vor, aus dem DNS können nun zunächst alle Einträge entfernt werden, die auf den defekten Exchange Server verweisen:

Hier einen Fehler zu machen ist noch relativ unkritisch. Wer aus “Versehen” den falschen DNS-Eintrag löscht, kann ihn einfach wieder anlegen. In den folgenden Schritten darf so etwas allerdings nicht mehr passieren.

Ich habe in diesem Fall alle Einträge gelöscht die auf den Server FWCOMEX2 verweisen:

Falls mehrere DNS-Zonen zum Einsatz kommen,, müssen diese ebenfalls kontrolliert werden.

Konfiguration aus Active Directory löschen

Beim Löschen des Exchange Servers aus dem Active Directory sollte besser kein Fehler passieren.

Mittels ADSIEdit wird zunächst das Exchange Server Objekt des defekten Exchange Servers gelöscht:

Danach sollten nur noch der oder die produktiven Exchange Server angezeigt werden:

Auch die Datenbaken die noch auf den defekten Exchange Server verweisen, können gelöscht werden:

Auch hier ist wieder Vorsicht geboten, das Löschen der produktiven Datenbanken hat unangenehme Folgen. Es bleiben also nur die produktiven Datenbanken über:

Aus dem Active Directory ist der defekte Server nun entfernt.

Neue Mailbox an Benutzer zuweisen

Wenn es in der Postfachdatenbank des defekten Exchange Servers noch Postfächer gab, werden die Postfächer nun als inkonsistent aufgeführt. Hier mal als Beispiel die Postfächer von Hans Dampf und Lucky Luke:

Hier ist zu sehen, dass den beiden Postfächern keine Datenbank mehr zugeordnet ist:

Mit dem folgenden Befehl lässt sich eine vorhandene Datenbank allen inkonsistenten Postfächern zuweisen:

get-mailbox | where {!$_.database} | set-mailbox -Database FWDB1

In der neu zugewiesenen Datenbank gibt es natürlich keinen Inhalt, es handelt sich um leere Postfächer, die aber wieder im konsistenten Zustand sind. Die Benutzer können sich an ihrem leeren Postfach anmelden.

Computer Account löschen

Jetzt kann auch das Computer Konto des defekten Exchange Servers gelöscht werden, auch hier lieber wieder zwei mal hinschauen um nicht das falsche Konto zu erwischen:

Neuen Exchange Server installieren

Bevor ein neuer Exchange Server mit neuen Namen installiert wird, sollte das das Active Directory einmal per Kommandozeile vorbereitet werden, damit die notwendigen Einträge wieder angelegt werden.

Dazu kommt noch ein separater Artikel.

Der Beitrag Exchange 2016: Manuelles Entfernen eines Exchange Servers (Mehrere Server) erschien zuerst auf Franky's Web.

Nur eine kleine Warnung vor dem Sophos UTM Update 9.408. Dieses Update verursacht gleich mehrere Probleme. Wer die UTM als virtuelle Maschine auf VMware ESXi betreibt sollte das Update lieber nicht einspielen und abwarten.

Das Update 9.408 würfelt die Zuordnung der virtuellen Netzwerkkarten durcheinander, dies war auch schon ein Problem, wenn in vorherigen Versionen nachträglich neue Netzwerkkarten zur VM hinzugefügt wurden. Jetzt kommt es allerdings vor, dass nicht mehr alle Netzwerkkarten von der UTM erkannt werden. Die Zuordnung der Netzwerke kann zwar ESXi-seitig schnell korrigiert werden, allerdings werden zumindest in meiner Umgebung keine weiteren Netzwerkkarten mehr erkannt. In meinem Fall werden nur noch 4 virtuelle Netzwerkkarten erkannt. Ich nehme an, dass dieser Fix die Probleme verursacht:

• NUTM-488 [Virtualization] Fix unstable NIC ordering on VMWare

Des weiteren scheint es Probleme mit dem Abfragen des Active Directory zu geben. Der Verbindungstest ist noch erfolgreich, wird die Konfiguration allerdings abgespeichert, scheint das Passwort nicht korrekt übernommen zu werden. In Folge schlagen alle Abfragen gegen das Active Directory fehl. Gerade die Empfängerverifizierung der Mail Protection könnte so im schlimmsten Fall alle Mails ablehnen.

Manche Benutzer berichten ebenfalls von Problemen mit dem SSL-VPN.

Scheinbar haben sich in diesem Update gleiche mehrere grobe Fehler eingeschlichen. Die Probleme konnte ich (bis auf das SSL-VPN) soweit nachvollziehen, Eigentlich wollte ich das Update nur wegen diesem Fix hier installieren:

• NUTM-5599 [Email] Mails with the same recipient set twice lead to corrupt mail queue

Ich warte mal noch etwas ab…

Der Beitrag Sophos UTM: Update 9.408 macht Probleme erschien zuerst auf Franky's Web.

Die Exchange Toolbox ist ein neues Projekt von mir um mir das Leben etwas einfacher zu machen. Bei der täglichen Arbeit mit Exchange Server brauche ich meist immer nur ein paar Befehle oder Informationen um Konfigurationen zu überprüfen oder Probleme zu identifizieren. Mit der Exchange Toolbox versuche ich ein kleines Tool zu erstellen, welches die wichtigsten Informationen in einer Oberfläche verfügbar macht.

Mittlerweile ist die Exchange Toolbox soweit, dass man sie als Beta Version bezeichnen kann. So sieht es bisher aus:

Auf dem ersten Tab “Network” lässt sich ein Host pingen und DNS Einträge intern (mit dem Standard DNS Server des Clients) oder extern via Google-DNS Server auflösen. Hier lässt sich auch der MX Record ermitteln. Das spart schon mal ein paar Zeilen in der Shell.

Am Design und an der Beschriftung muss ich noch ran und auch alle Funktionen laufen noch nicht ganz rund.

Das Tab Autodiscover ruft die Autodiscover.xml vom Exchange Server ab. Dazu wird Outlook benötigt. Im Prinzip wird hier der Test “E-Mail Auto Konfiguration testen” ausgeführt. Nur eben etwas einfacher zugänglich:

Hier fehlt es allerdings auch noch an Funktionen, bisher wird nur die XML angezeigt und noch nicht ausgewertet und validiert.

Mittels “Mail Test” lässt sich schnell eine Testmail verschicken, auch mit Anmeldeinformationen. “Port Test” kann einen beliebigen TCP Port testen, finde ich ganz nützlich bei Firewall Themen, bei UDP gibt es allerdings noch Probleme.

Mittels “Windows Services” lassen sich die Dienste auf einem Server prüfen und auch nach Exchange Diensten filtern.

Das Tab “Certificates” ruft das SSL Zertifikat von einem Server ab und zeigt es an, aber auch hier gibt es noch eine Baustelle: Wird das Zertifikat als ungültig erkannt, werden keine Daten angezeigt.

“Queues” kann den Status der Exchange Warteschlangen anzeigen und “Blacklist Check” prüft bekannte Blacklisten ob die IP gelistet ist. Aber auch hier wieder eine Baustelle: Derzeit akzeptiert die Exchange Toolbox nur IPs und keine FQDNs.

Folgende Punkte muss ich generell noch angehen:

• Fehlerbehandlung
• Beschriftungen und Layout
• die oben aufgeführten Probleme
• vieles mehr…

Außerdem soll die “GUI für die Nachrichtenverfolgung” in der Exchange Toolbox integriert werden. Somit wären dann alle Funktionen in einem Tool vereint. Die Exchange Toolbox benötigt für manche Funktionen ein installiertes und konfiguriertes Outlook sowie die Exchange Management Shell.

Wer die Beta 1 schon einmal ausprobieren möchte, kann die Exchange Toolbox hier runterladen:

Exchange Toolbox 132.91 KB

Download

Da es sich um eine beta Version handelt, werden sicherlich noch mehr Probleme und Bugs in der Exchange Toolbox stecken. Wer Probleme findet, oder Vorschläge für neue Funktionen hat, darf gerne das Formular nutzen:

* Erforderliches Feld

Name:*

Email:*

Screenshot hochladen

Acceptable file types: doc,docx,pdf,txt,gif,jpg,jpeg,png.
Maximum file size: 1mb.

Vorschlag / Problem*

CAPTCHA Code:*

Viel Spaß beim Ausprobieren. Ich würde mich über zahlreiche Rückmeldungen freuen.

Der Beitrag Exchange Toolbox für Exchange Server 2016 (Beta 1) erschien zuerst auf Franky's Web.

Freigegebene Postfächer werden häufig eingesetzt, wenn mehrere Personen Zugriff auf ein Postfach haben sollen, um zum Beispiel im Team zusammenzuarbeiten.

Es gibt aber ein paar Dinge zu beachten, daher beschreibt dieser Artikel die Einrichtung und die Funktionsweise.

Das folgende Beispiel zeigt die Einrichtung eines freigegebenen Postfachs:

Die Postfächer die unter “Benutzer (blauer Kasten)” angegeben werden, erhalten Vollzugriff auf das freigegebene Postfach. Dies lässt sich mit folgendem Befehl prüfen:

Get-MailboxPermission team | where {$_.AccessRights -contains "FullAccess"}

Für das freigegebene Postfach wird automatisch ein Benutzer im Active Directory angelegt. Das Benutzerkonto ist standardmäßig deaktiviert:

Damit die Benutzer auf das freigegebene Postfach zugreifen können, wird es per Autodiscover in Outlook eingebunden. Damit ein zusätzliches Postfach per Autodiscover verteilt wird, wird das Active Directory Attribut “msExchDelegateListLink” mit dem Distinguished Name (DN) des Benutzers gefüllt, der auf das freigegebene Postfach zugreift:

Hier noch einmal im Detail, der DN von Benutzer Frank wird in das Attribut “msExchDelegateListLink” des freigegebenen Postfachs “Team” eingetragen:

Outlook prüft zyklisch ob es neue Autodiscover Informationen gibt. Nach kurzer Zeit wird Outlook das freigegebene Postfach als zusätzliches Postfach einbinden, da es die nötigen Informationen per Autodiscover erhält:

Da der entsprechende Benutzer Vollzugriff auf das freigegebene Postfach hat, kann er nun beliebige Aktionen in dem Postfach ausführen:

Hier gibt es allerdings ein paar Dinge zu beachten:

Löscht ein Benutzer Mails aus dem freigegebenen Postfach, werden in der Standard Einstellung die Mails in den “Gelöschte Elemente” Ordner des Benutzers verschoben, somit lassen sich Mails durch andere Benutzer des freigegebenen Postfachs nicht wiederherstellen.

Dieses Verhalten lässt sich allerdings ändern. Damit gelöschte Elemente aus dem freigegebenen Postfach auch im Gelöschte Elemente Ordner des freigegebenen Postfachs landen, muss ein Registry Schlüssel für Outlook gesetzt werden:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Options\General]
"DelegateWastebasketStyle"=dword:00000004

Der Schlüssel General und das DWORD DelegateWastebasketStyle müssen angelegt werden. Leider verursacht dies meist Probleme: Meldet sich der Benutzer an einem anderen Rechner an und besitzt kein Roaming Profil, wirkt diese Einstellung nicht. Daher sollte diese Einstellung am besten via Gruppenrichtlinie gesetzt werden:

Bei Rechnern außerhalb des Active Directory muss man sich hier eine geeignete Verteilungsmethode überlegen. Nachdem die Einstellung vorgenommen wurde, landen gelöschte Mails im dafür vorgesehenen Ordner:

Ebenfalls erhalten Benutzer “Senden-Als” Rechte für das freigegebene Postfach:

Auch hier gibt es einen ähnlichen Stolperstein wie mit den gelöschten Elementen. Mails die im Namen oder im Auftrag des freigegebenen Postfachs gesendet werden, laden nur im “Gesendete Elemente” Order des Benutzers der die Mail geschrieben hat, nicht aber im Gesendete Elemente Order des freigegebenen Postfachs. Allerdings lässt sich dieses Verhalten aber mit weniger Aufwand ändern:

Set-Mailbox Team -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true

Somit landen Mails im Namen und im Auftrag des freigegebenen Postfachs auch im Gesendete Elemente Ordner des freigegebenen Postfachs. Wie der Name der Parameter aber schon vermuten lässt werden diese Elemente sowohl im Gesendete Elemente Ordner des freigegebenen Postfachs, als auch im Benutzerpostfach angezeigt (Kopie).

Der Beitrag Exchange 2016: Freigegebene Postfächer (Shared Mailbox) erschien zuerst auf Franky's Web.

Nach gefühlten 300 km Stau auf den Autobahnen bin ich endlich zurück vom Technical Summit 2016. Wie auch im letzten Jahr fand der Technical Summit 2016 in Darmstadt im Darmstadium statt. Dieses Jahr gab es allerdings eine Neuerung: Schon am 05.12. gab es den Community Pre Day mit vielen interessanten Leuten und Vorträgen. Leider waren die Vorträge doch eher an Entwickler gerichtet, was aber den Vorteil hatte, das IT Pros Zeit hatten literweise Kaffee zu trinken und sich über die wirklich spannenden Dinge auszutauschen.

Es gab einige interessante Vorträge und auch die HoloLens um ausprobieren. Meine persönlichen Highlight waren die Vorträge von Sigi Jagott natürlich zum Thema Exchange Server, Thomas Maurer mit einem Vortrag zu Nano Server und Carsten Rachfahl zu Azure Stack.

Sigi hat sogar ein paar Informationen zu den anstehenden Neuerungen für Exchange Server mitgebracht:

Die geplanten Neuerung für Exchange Server dürften einige sich schon lange gewünscht haben:

• Wiederherstellung von gelöschten Elementen in den korrekten Ordner (kommt zuerst für OWA, später auch für Outlook)
• REST API für lokale (on-premises) und hybride Exchange Organisationen (Exchange 2013 und Exchange 2016)
• Migration von Öffentlichen Ordnern zu Office 365, Office 365 Groups und entsprechender AAD Connect Unterstützung

Gerade die Wiederherstellung der gelöschten Elemente in die entsprechenden Ordner dürfte vielen das Leben erleichtern, es geht hierbei übrigens um die Wiederherstellung aus dem Dumpster, nicht aus dem Ordner “Gelöschte Elemente”. Auch die REST API dürfte interessant werden. Die Rest API ist bereits für Office 365 verfügbar und wird in Zukunft auch für lokale Exchange 2013 und 2016 Server zur Verfügung stehen.

Das Microsoft Team war übrigens sehr schnell mit der Veröffentlichung der Sessions. Einige wurde Live auf Channel 9 gestream und lassen sich natürlich auch jetzt noch anschauen. Wer also nicht dabei sein konnte, kann sich die Sessions auch nachträglich anschauen:

https://channel9.msdn.com/Events/microsoft-techncial-summit/Technical-Summit-2016

Ich freue mich schon auf das nächste Jahr, ein paar Gesichter sieht man leider sieht man schließlich nur auf dem MSTS (oder unter dem Tannenbaum )

Der Beitrag Microsoft Technical Summit 2016 – Endlich zuhause erschien zuerst auf Franky's Web.

Ich musste mir ja heute ein bisschen das Lachen verkneifen als ich diese Meldung hier gelesen habe:

Datenleck in der Telekom-Cloud ermöglicht Zugriff auf fremde Adressbücher

Kurzfassung: Der Telekom Cloud Manager hat da den Namen “Globale Adressliste” zu wörtlich genommen. Daraufhin konnte mindestens ein Kunde alle Einträge der Adressliste einsehen. Bei 2300 Kunden dürfte das etwas unübersichtlich geworden sein…

Die Telekom gibt den Fehler zu und informiert die betroffen Kunden. Auch auf der Telekom Website findet sich der Hinweis:

Fehler bei Softwareumstellung

Gut, Fehler passieren jedem und es war ja auch alles gar nicht so schlimm, nicht schön, aber ist jetzt auch nicht unbedingt die riesen Katastrophe (meiner Ansicht nach). Es hat scheinbar ja nur ein Postfach alle Einträge in der GAL gesehen.

Was mich zum Schmunzeln gebracht hat ist die Tatsache, dass ich gestern vom Technical Summit zurück gekommen bin und auf eben jenem Technical Summit natürlich Azure Germany (Die deutsche Cloud) ein großes Thema war.

Für Azure Germany gibt es den so genannten Datentreuhänder, der sicherstellen soll, das die Verarbeitung und die Aufbewahrung der Daten in Azure Germany nur in Deutschland geschieht. “Datentreuhänder” war eines der Buzzwords.

Und nun ratet mal was ich so lustig finde:

Telekom wird Daten-Treuhänder für Microsoft Cloud in Deutschland

Soweit so gut, wir haben unsere eigene deutsche Cloud, vollkommen NSA und GCHQ sicher… Es sei denn Agent Smith legt sich dort ein Postfach an…

Ja, ich weiß, Hosted Exchange und Azure Germany sind zwei paar Schuhe, aber mal ehrlich, ein bisschen lustig ist das schon…

Ich bin ja schon still und entschuldige mich für diesen zynischen Beitrag beim DatentreuhändLer.

Der Beitrag Der Datentreuhänder erschien zuerst auf Franky's Web.

Heute wurden neue Updates für alle Exchange Server Versionen veröffentlicht. Hier geht es direkt zum Download:

• Exchange Server 2016 CU4
• Exchange Server 2013 CU15
• Exchange Server 2010 SP3 UR16
• Exchange Server 2007 SP3 UR 22

Hier geht es zu den Details der Änderungen:

• Exchange Server 2016 CU4
• Exchange Server 2013 CU15
• Exchange Server 2010 SP3 UR16
• Exchange Server 2007 SP3 UR22

Wichtigste Neuerungen für Exchange Server 2016

Exchange 2016 DAG auf Windows Server 2016

Mit dem KB3206632 stürzt der IIS nicht mehr ab, nachdem eine Exchange DAG auf Server 2016 angelegt wurde. Das Update ist nun Voraussetzung für die Installation von Exchange 2016 auf Windows Server 2016.

.NET Framework 4.6.2

Exchange 2013 und Exchange 2016 unterstützen nun .NET Framework 4.6.2. Ab März 2017 (also für das nächste CU) wird .NET 4.6.2 Voraussetzung sein.

Installationsvoraussetzungen

Exchange 2016 CU4 benötigt nicht mehr das Windows Feature “Desktopdarstellung”. Es wird nur noch das Feature “Media Foundation” benötigt.

Änderungen am OWA Design

Es gab eine kleine Änderungen am OWA Design. Das Nachrichten Feld hat einen Rahmen bekommen um es besser abzugrenzen und die Darstellung an Office 365 anzugleichen.

Hinweis

Damit das CU4 für Exchange Server 2016 auf Server 2016 installiert werden kann, müssen zunächst die Windows Updates installiert werden (siehe oben). Das CU4 eignet sich für eine Update Installation, sowie für eine Neuinstallation und wird als ISO Datei angeboten.

Der Download umfasst für das CU4 5,3 GB:

Der Beitrag Neue Updates für Exchange Server erschien zuerst auf Frankys Web.