Heute von Sophos ein Update für die UTM 9 veröffentlicht. Das Update aktualisiert die UTM auf Version 9.508-10. Das Update ist knapp 170 MB groß und soll diese Probleme beheben:

• [NUTM-8739]: [Access & Identity] Argos segfault and coredump after update to v9.502
• [NUTM-9164]: [Access & Identity] SSLVPN installation packages fail to copy user profile during installation
• [NUTM-9344]: [Access & Identity] All users are locked when a lockout policy via GPO was set
• [NUTM-9047]: [Basesystem] VLAN interface on the bridge doesn’t come up when slave becomes the master
• [NUTM-9296]: [Configuration Management] Report Auditor is unable to open the dashboard in UTM
• [NUTM-9397]: [Configuration Management] Log Remote Archiving via SCP fails when used with OpenSSH >= 7.0
• [NUTM-9497]: [Documentation] ATP – Invalid status display on Webadmin for Japanese,Russian,Spanish language
• [NUTM-4174]: [Email] POP3 spool cleanup does not work
• [NUTM-8794]: [Email] Wrong MIME Type detection
• [NUTM-8937]: [Email] Upgrade SMIME
• [NUTM-9046]: [Email] SPX binary error with Office365
• [NUTM-9098]: [Email] Mail stuck in work queue
• [NUTM-9252]: [Email] Patch Exim for CVE-2014-2972 and CVE-2016-9963
• [NUTM-9259]: [Email] POP3 Proxy coredump in „libc_start_main“
• [NUTM-9337]: [Email] Selecting an AD Server for AD Recipient Verification in SMTP isn’t possible after update to v9.506
• [NUTM-9382]: [Email] WebAdmin user not able to disable the „Recipient Verification“ in SMTP Routing
• [NUTM-9303]: [HA/Cluster] HA „max_nodes“ option set to 3 causes named to fail to start
• [NUTM-9405]: [HA/Cluster] Interface MAC addresses shouldn’t get replicated on slave node if virtual_mac is set to 0
• [NUTM-3497]: [Network] BGP soft-reconfiguration not working
• [NUTM-8118]: [Network] After upgrading to 9.500 „Service Monitor not running – restarted“ notifications being received
• [NUTM-8432]: [Network] Local Privilege Escalation via confd Service
• [NUTM-8604]: [Network] Changing a bridge IP address causes bridge to go down when using vlans
• [NUTM-8887]: [Network] DNS group objects doesn’t delete old IP addresses
• [NUTM-9064]: [Network] Network monitoring daemon constantly restarts since upgrade to 9.503
• [NUTM-9177]: [Network] Disabled static routes are being put into the routing table
• [NUTM-9465]: [Network] Wrong/Old IPv6 Tunnel Broker URLs in Webadmin
• [NUTM-8759]: [Sandboxd] Add support for Sandstorm’s Asia data centre
• [NUTM-9006]: [UI Framework] Not possible to download different SSLVPN User Profiles in one Firefox session
• [NUTM-6955]: [WebAdmin] Error text appears in dialog when trying to view user object usage
• [NUTM-8567]: [WebAdmin] Update to ImageMagick-7.0.7-11
• [NUTM-9116]: [WebAdmin] Object information can’t be displayed for specific objects
• [NUTM-9128]: [WebAdmin] PCI Scan failing on UserPortal due to missing HSTS and CSP
• [NUTM-9430]: [WebAdmin] Issue with X-Content-Type-Options header presented by UTM
• [NUTM-7201]: [Web] HTTP Proxy connections hang in CLOSE_WAIT state
• [NUTM-8638]: [Web] Add group visibility in log with unlimited AD groups
• [NUTM-8746]: [Web] After changing group membership, old one is still available from winbind
• [NUTM-8886]: [Web] TLS Input/output error when connecting to web site
• [NUTM-9113]: [Web] HTTP Proxy coredump on 9.505
• [NUTM-9166]: [Web] HTTP Proxy coredump on function deny_ntlm_auth
• [NUTM-9332]: [Web] DNSExpire coredump causes slow browsing
• [NUTM-9416]: [Web] HTTP Proxy coredump on 9.506 with signal SIGFPE Arithmetic Exception
• [NUTM-3127]: [Wireless] AP55/100 connection issues – disconnected due to excessive missing ACKs
• [NUTM-6640]: [Wireless] Fix visibility of Fast Transition option in different security modes
• [NUTM-7013]: [Wireless] Frequent disconnects on guest wifi network after >1 week
• [NUTM-8243]: [Wireless] Update dropbear SSH Server to fix CVE-2016-7409, CVE-2016-7408, CVE-2016-7407, CVE-2016-7406
• [NUTM-8299]: [Wireless] UTM stops broadcasting SSIDs for the built-in wireless after upgrade to 9.5
• [NUTM-8781]: [Wireless] W-appliance – wireless network connection issue with Bridge to AP LAN
• [NUTM-8827]: [Wireless] Internal wireless not broadcasting SSID after updating to 9.503
• [NUTM-8832]: [Wireless] Integrated wireless adapter can be deleted
• [NUTM-8930]: [Wireless] Unable to see the SSID and connect to local wifi on 2.4 Ghz band
• [NUTM-8940]: [Wireless] kernel: [ xxxx.xxxxx] CPU: 0 PID: 13902 Comm: iw Tainted: G W O 3.12.74-0.265397234.g263c982.rb6-smp64 #1
• [NUTM-8945]: [Wireless] SG115w SSID not broadcasted since updated to 9.503

Die Liste der Fixes ist ziemlich lang, unter anderem sollen auch die doch ziemlich nervigen Probleme der E-Mail Protection behoben worden sein. Da Sophos in der Vergangenheit kein glückliches Händchen mit Update hatte, sollte hier ausgiebig getestet werden und ein Backup erzeugt werden. Das letzte Update wurde am 21.November veröffentlicht, ich hoffe Sophos hat sich Zeit für intensive Tests genommen.

Das Update lässt sich unter folgenden Link runterladen:

• http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.507001-508010.tgz.gpg

Falls das Update noch nicht via Up2Date angeboten wird, lässt es sich dann manuell installieren:

Wer nicht sofort aktualisiert, findet hier eine gute Anlaufstelle um sich über ggf. auftretende Probleme vorab zu informieren:

• UTM Up2Date 9.508 Released

Update 01.03.2018:

Es sind sogar 2 Updates die heute veröffentlicht wurden:

• http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.506002-507001.tgz.gpg
• http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.507001-508010.tgz.gpg

Das Update auf 9.507-1 ist Voraussetzung für 9.508-10. Das erste Update behebt diese beiden Probleme und ist 44 MB Groß:

• [Basesystem] Support for new SG1xx(w) models
• [WAF] Certificate dropdown is visible for virtual webserver using HTTP

Der Beitrag Sophos UTM: Neues Update (9.508-10) erschien zuerst auf Frankys Web.

Letzten Montag hatte ich eine überarbeitete Version des Exchange Certificate Assistant veröffentlicht. Die letzte Version unterstützte bisher nur Exchange 2016 auf Windows Server 2016. Mit der jetzigen Version wird nun auch Windows Server 2012 R2 und Exchange 2013 unterstützt. Neu ist auch die Möglichkeit die Benachrichtigungsmails mit Authentifizierung am SMTP Server zu verschicken. Außerdem wurden ein paar kleinere Probleme behoben und das Logging verbessert.

Im Archiv finden sich nun 2 Ordner- Der Ordner Exchange 2013 enthält logischerweise das Script für Exchange 2013, der Ordner Exchange 2016 entsprechend das Script für Exchange 2016:

Wie gehabt müssen innerhalb des Scripts die ersten paar Zeilen angepasst werden:

Der Task zum Erneuern des Zertifikats muss nach wie vor manuell angelegt werden. Ich denke, dass werde ich auch so beibehalten. Ich finde es schöner, wenn man selbst bestimmen kann, wann das Zertifikat ausgetauscht wird. Im oben verlinkten Artikel ist beschrieben, wie der Task zum Erneuern angelegt werden kann. Der nächsten Version werde ich eine kleine Anleitung beilegen.

Es fehlt jetzt also noch die Unterstützung für Exchange 2010 und Server 2008 R2. Ich installiere jetzt erst einmal eine neue Testumgebung für Exchange 2010.

Hier noch der Link für den Download der aktuellen Version:

Exchange Certificate Assistant 12.14 KB

Download

Wenn es Probleme mit dem Script gibt, könnt ihr gerne das Logfile zuschicken. Nur so kann ich das Script verbessern und Fehler beheben.

Der Beitrag Certificate Assistant jetzt auch für Exchange 2013 und Server 2012 R2 erschien zuerst auf Frankys Web.

Ich bin letztens bei einem Kundenprojekt auf das Problem gestoßen, dass eine Cloud Only Shared Mailbox in eine User Mailbox umgewandelt werden soll.

Da das Active Directory (AD) aber mit Azure Active Directory (AAD) gesynct wird, habe ich hier mal die Vorgehensweise beschrieben.

Als erstes muss man sich mit der Exchange Online PowerShell verbinden um zu prüfen, ob das anzupassende Postfach auch eine Shared Mailbox ist. Dies erkennt man daran, dass das Attribut RecipientTypeDetails den Wert Shared Mailbox hat.

Anschließend kann man mit folgendem Powershell befehl die Mailbox umwandeln.

Set-Mailbox -Identity <Mailboxname> -Type Regular

Bei der erneuten Überprüfung sehen wir, dass der Typ unter RecipientTypeDetails nun UserMailbox ist.

Nun muss im lokalen AD noch ein User für die Mailbox angelegt werden. Wichtig ist hierbei, dass der User den gleichen User Principal Name (UPN) bekommt, wie die Adresse der soeben geänderten Mailbox. Dadurch wir der UPN auf die E-Mail Adresse geprüft und entsprechend „gematched“.

Nachdem der User im AD erstellt wurde muss noch die Default SMTP eingetragen werden. Die Adresse wird beim Userobjekt unter dem Reiter Attribute Editor eingetragen. Dieser Reiter wird Standardmäßig in der Active Directory Users and Computers Management Console jedoch nicht angezeigt. Dazu muss man unter View die Advanced Features aktivieren.

Da der Reiter Attribute Editor auch nur in der Organization Unit (OU) des Userobjektes zu sehen ist, muss zuerst in die OU des Users gewechselt werden. Um in größeren Organisationen die OU zu finden, kann man den User über die Such Funktion heraussuchen und unter dem Reiter Object findet man den Pfad, wo das Userobjekt abgelegt ist.

In den Eigenschaften des Users kann man nun den Attribute Editor Reiter öffnen und beim Attribute proxyAddress die Default SMTP (Absender) Adresse eintragen. Wichtig ist, dass SMTP: groß geschrieben wird, was die Default Adresse deklariert. Wenn vor der Adresse ein smtp: in Kleinbuchstaben vorangestellt wird, wird damit eine weitere Empfangsadresse (Alias) angelegt.

Nachdem die Änderungen im lokalen AD abgespeichert sind muss nur noch der AAD Connect Sync abgewartet werden oder diesen einmal manuell starten. Sobald der User synchronisiert wurde, erscheint dieser in Office 365 Admin Center unter Users wo man nun eine entsprechende Lizenz zuweisen kann und die Mailbox aktiv wird.

Der Beitrag Eine Cloud Only Shared Mailbox in eine AD synchronisierte User Mailbox umwandeln erschien zuerst auf Frankys Web.

Kürzlich hat Sophos ein Update für UTM 9.5 veröffentlicht. Mit dem Update wurden auch die Algorithmen der E-Mail Protection hinsichtlich der Signierung von Mails mittels S/MIME angepasst:

· S/MIME Encryption updates: This release brings changes to the S/MIME feature to fully conform with new GDPR regulatory requirements for encryption. Core to these changes are new algorithms to perform encryption and signatures within S/MIME. Due to the changes in the signature algorithms, older implementations of S/MIME – including previous Sophos UTM releases – can no longer verify signatures produced with the new algorithms. Encryption and decryption of emails is not affected by this change. For details, please read the following KBA at https://community.sophos.com/kb/en-us/131727.

Quelle: UTM Up2Date Release notes

Aktuell kommt es aber scheinbar häufiger zu Problemen, wenn die UTM Mail Protection E-Mails mittels S/MIME signiert. Hier findet sich schon ein Thread dazu:

• Version 9.508 – report on experience

Ich konnte ebenfalls bereits das Problem nachvollziehen, meine UTM signiert ausgehende Mails mittels gültigem SMIME Zertifikat:

Bei bestimmten Empfängern, schlägt allerdings die Zustellung von signierten Mails fehl. Der Mailserver lieferte in meinem Fall diesen Fehlercode:

550 5.7.1 The digital signature of the mail is invalid

Sobald eine Ausnahme konfiguriert wird, geht die Mail sauber durch:

Auch wenn die Mail vom Zielmailserver angenommen wird, die SMIME Signatur kann nicht geprüft werden, hier als Beispiel Outlook:

Ein Update von Sophos gibt es bisher nicht. Bisher kann man also die Signierung von Mails an der UTM nur abschalten:

Keine schöne Lösung, aber was soll man machen, wenn ständig die NDRs zurück kommen?!

Der Beitrag Sophos UTM 9.508-10: Signierung von Mails mittels S/MIME problematisch erschien zuerst auf Frankys Web.

Jetzt kann ich Vollzug melden, die aktuelle Version des Certificate Assistant für Let’s Encrypüt unterstützt nun auch Exchange 2010 und Server 2008 R2. Ich habe den Download noch einmal aktualisiert und es sind nun 3 Versionen des Scripts enthalten:

Somit werden nun die folgenden Betriebssysteme unterstützt:

• Windows Server 2008 R2
• Windows Server 2012 R2
• Windows Server 2016

Ich habe das Script mit den jeweils aktuellen Exchange Versionen getestet:

• Exchange 2016 CU8
• Exchange 2013 CU 19
• Exchange 2010 SP3 UR 19

Die Exchange 2010 Version des Scripts benötigt als Voraussetzung das Windows Management Framework 4 und .NET Framework 4.5.2. Diese beiden Komponenten müssen installiert sein, bevor das Script ausgeführt wird. Die Download Links für die Voraussetzungen finden sich im Ordner “Exchange 2010” in der Datei README.txt des Archivs.

Noch ein kleiner Hinweis an dieser Stelle:

Öffentliche CAs wie Let’s Encrypt können und dürfen keine Zertifikate für “private” FQDNs ausstellen. FQDNs wie “srv1.domain.local” oder “exchange.domain.intern” können also nicht auf einem öffentlichen Zertifikat aufgenommen werden. Das Script versucht in der Standardeinstellung die erforderlichen FQDNs für das Zertifikat aus den Virtual Directorys des Exchange Servers zu ermitteln (InternalURL und ExternalURL). Damit das Zertifikat von Let’s Encrypt ausgestellt werden kann, muss der Exchange Server unter allen konfigurierten FQDNs aus dem Internet erreichbar sein. Wenn dies nicht der Fall ist, lässt sich im Script die automatische Ermittlung abschalten und eigene FQDNs festlegen.

Mit dem Small Business Server 2011 habe ich das Script nicht testen können.

Den Download Link habe ich entsprechend aktualisiert:

Exchange Certificate Assistant 18.51 KB

Download

Der Task zu Erneuerung des Zertifikats muss manuell erstellt werden. Hier das Beispiel für Server 2008 R2:

Als Trigger könnten zum Beispiel alle 2 Monate ausgewählt werden, so bleibt genug Zeit zum manuellen Eingreifen falls etwas schief geht:

Als Aktion wie gehabt den Pfad zur PowerShell angeben und als Argument den Pfad zum Script:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Wenn es Probleme oder Fehler mit dem Script gibt, dann schickt mir bitte das komplette Logfile per Mail. Ich versuche gerne zu helfen, kann dies aber nur mit dem kompletten Log. Daher auch bitte nicht das Logfile kürzen oder Teile davon entfernen.

Der Beitrag Certificate Assistant: Jetzt auch für Exchange 2010 und Server 2008 R2 erschien zuerst auf Frankys Web.

Nur kurz zur Information: In einem Monat endet der Mainstream Support für Exchange 2013. Der Extended Support läuft dann noch bis zum 11.04.2023:

Quelle: Microsoft product lifecycle

Mit dem Beginnen des Extended Supports wird es im wesentlichen keine neuen Funktionen mehr für Exchange 2013 geben. Im Extended Support gibt es nur noch Sicherheitsupdates und Bug Fixes.

Somit befinden sich dann Exchange 2010 und ab dem 10. April auch Exchange 2013 im Extended Support. Eine neue Exchange Version wird noch dieses Jahr erwartet, die Migration von Exchange 2013 zur neuen Exchange Version wird aller Wahrscheinlichkeit möglich sein. Eine Migration von Exchange 2010 zur neuen Exchange Version wird allerdings nicht mehr unterstützt werden.

Der Beitrag Exchange 2013: Mainstream Support endet am 10.04.2018 erschien zuerst auf Frankys Web.

In meiner privaten Umgebung mit einer Sophos UTM 9.508-10 hatte ich bisher immer das Problem, dass die Empfängerverifizierung der Email Protection mittels Active Directory nicht funktioniert hat. Im Live Log der Email Protection war immer nur die folgende Warnung zu finden:

Warning: ACL „warn“ statement skipped: condition test deferred: failed to bind the LDAP connection to server 192.168.5.1:636 – ldap_bind() returned –1

Die normale Authentitifizierung gegenüber dem Active Directory von Benutzern lief problemlos, auch der Test der Authentifizierungsdienste war möglich. Nur die Email Protection weigerte sich beharrlich die E-Mail Adressen anhand von Active Directory zu verifizieren.

In den Authentifizierungsdiensten der UTM hatte konfiguriert, dass die Verbindung zum Domain Controller mittels SSL verschlüsselt sein soll. Scheinbar macht dies aber Probleme mit der Email Protection der UTM und sorgt zumindest in meinem Fall zu dem oben genannten Fehler.

Das Importieren des Zertifikats des Domain Controller hat ebenfalls nicht geholfen, so blieb mir nur noch übrig eine unverschlüsselte Verbindung zu nutzen.

Hier also einmal die Konfiguration die in meiner Umgebung funktioniert:

Damit die Empfängerverifizierung funktioniert, musste ich die Einstellung “Domänencontroller: Signaturanforderungen für LDAP-Server” auf den Wert “Keine” ändern. Die Einstellung lässt sich entweder in der Gruppenrichtlinie “Default Domain Controllers Policy” festlegen oder über eine neue zusätzliche Richtlinie für die Domain Controller festlegen. Ich bin ein Freund der unveränderten Default Richtlinien, daher würde ich hier empfehlen eine neue Gruppenrichtlinie zu erstellen, hier muss dann auf die Reihenfolge der GPOs geachtet werden, damit die Default Richtlinie den Wert nicht überschreibt:

Zur Verifizierung von E-Mail Adressen und Benutzern benötigt die UTM einen Benutzer im ActiveDirectory. Der Benutzer muss nur der Gruppe “Domänen Benutzer” angehören. Das Passwort des Benutzers darf nicht ablaufen:

Aus den Attributen des Benutzers wird der Distinguished Name (DN) benötigt, dieser kann schon einmal kopiert werden:

Ausserdem wird auch noch der Distinguished Name (DN) der Active Directory Domain benötigt:

In den Authentifizierungsdiensten der UTM wird nun ein neuer Server mit de Typ “Active Directory” angelegt. SSL wird deaktiviert und als Port 389 gewählt. Der Wert “Bind-DN” entspricht dem Distinguished Name (DN) des Benutzerkontos. Der Wer für BaseDN entspricht dem DN der Domain:

Die Einstellungen können mit “Servereinstellungen testen” und einer beliebigen Benutzer/Passwort Kombination getestet werden.

In den Einstellungen der Email Protection kann nun unter dem Menüpunkt Routing die Empfängerauthentifizierung mittels Active Directory aktiviert werden. Als “Alternativer BaseDN” kann wieder der DN der Domain angegeben werden:

Mit diesen Einstellungen funktioniert zumindest in meiner Umgebung die Empfängerverifizierung mittels Active Directory. Wenn es jemand mit SSL hinbekommen hat, dann würd ich mich über Rückmeldung freuen.

Der Beitrag UTM Email Protection: Empfänger Verifizierung mit Active Directory erschien zuerst auf Frankys Web.

Ich habe nun schon mehrere Mails mit Fragen zum Exchange Backend Zertifikat bekommen,daher gibt es an dieser Stelle mal einen kleinen Beitrag dazu. In den meisten Fällen wurde das Backend Zertifikat beim Aufräumen gelöscht. Der folgende Artikel behandelt die Funktion und Notwendigkeit des Backend Zertifikats und auch die Wiederherstellung falls es versehentlich gelöscht wurde.

Was ist das Backend Zertifikat?

Bei dem Backend Zertifikat handelt es sich um ein selbst signiertes Zertifikat, welches bei der Installation eines Exchange Servers erstellt wird. Das Backend Zertifikat enthält den NetBIOS Namen und den FQDN des Exchange Servers und ist 5 Jahre gültig.

Das Zertifikat wird mit dem Anzeigenamen “Microsoft Exchange” erstellt und an den IIS Dienst gebunden:

Das Zertifikat wird von Exchange allerdings nur für die IIS Website “Exchange Back End” verwendet und ist an den Port 444 gebunden:

In der Zertifikate MMC stellt sich das Backend Zertifikat als selbstsigniertes Zertifikat dar. Hier ist zu erkennen, dass NetBIOS und FQDN als SANs (Subject Alternate Names) enthalten sind:

Wenn dieses Zertifikat gelöscht wird, ist also keine verschlüsselte Verbindung mit der Website “Exchange Back End” mehr möglich, dies wird jedoch von der Website vorausgesetzt:

Wozu dient das Exchange Backend Zertifikat?

Der IIS Server eines Exchange Servers stellt zwei Webseiten für Exchange Server bereit, die “Default Web Site” ist im Prinzip das Frontend, also die Website die auch Benutzer aufrufen, wenn sie beispielweise auf OWA zugreifen. Auch fast alle anderen Dienste werden über das Frontend dem Benutzer zugänglich gemacht (kleine Ausnahme ist Exchange UM). Die “Default Web Site” verfügt daher über das Zertifikat, welches dem Benutzer präsentiert wird.

Bei der zweiten Website handelt es sich um das “Exchange Back End”. Der Benutzer ruft das Backend nicht direkt auf, sondern das Frontend arbeitet vom Prinzip her wie ein Proxy für das Backend. Das Frontend leitet die Verbindungen der Benutzer für die unterschiedlichen Protokolle an das Backend weiter. Das Backend übernimmt die eigentliche Verarbeitung der Verbindung. Der Benutzer ruft das Backend also nicht direkt auf, sondern wird bis auf eine Ausnahme (Exchange UM) über das Frontend an das Backend weitergeleitet.

Zurück zum Backend Zertifikat: Mit dem Backend Zertifikat wird die Verbindung zwischen Frontend und Backend auf Port 444 ver- bzw. entschlüsselt. In einer Umgebung mit nur einem Exchange Server kommuniziert das Frontend des Exchange Servers also verschlüsselt mit dem Backend, hierzu wird das Backend Zertifikat benötigt. In Umgebungen mit mehreren Exchange Servern kommunizieren die Exchange Server untereinander ebenfalls über das Backend miteinander, auch hier wird das Backend Zertifikat benötigt. Ebenfalls können in Umgebungen mit mehreren Exchange Servern die Frontends auf andere Exchange Backends zugreifen.

Die Prüfung des Backend Zertifikats durch die Exchange Server ist dabei nicht so streng, wie die Prüfung von Outlook zum Frontend. Das Backend Zertifikat muss daher nur den Namen des Exchange Servers enthalten und darf auch selbst signiert sein. Der Benutzer bekommt das Backend Zertifikat nicht zu sehen, daher muss das Backend Zertifikat auch nicht durch ein gültiges Zertifikat einer öffentlichen CA ausgetauscht werden.

Beim Austausch des Backend Zertifikats durch ein öffentliches Zertifikat kann es sogar zu Problemen zwischen der Kommunikation mehrere Exchange Server kommen. Ursache ist dann meist der fehlende Exchange Server Name auf dem Backend Zertifikat.

Daher gilt: Backend Zertifikat einfach so lassen wie es ist, nicht löschen, nicht austauschen, nur erneuern wenn es abläuft.

Backend Zertifikat gelöscht, wie wiederherstellen?

Für diesen Beitrag habe ich das Backend Zertifikat des Exchange Servers gelöscht:

Da dass Zertifikat gelöscht wurde steht die “Exchange Back End” Website im IIS nun ohne Zertifikat dar, eine https Verbidnung auf Port 444 von Front End zu Backend ist folglich nicht mehr möglich:

Die Folgen: Die Exchange Management Shell verbindet sich nicht mehr, die Fehlermeldung ist allerdings wenig hilfreich:

New-PSSession : [ex1.cloud.frankysweb.de] Beim Verbinden mit dem Remoteserver „ex1.cloud.frankysweb.de“ ist folgender
Fehler aufgetreten: [ClientAccessServer=EX1,BackEndServer=ex1.cloud.frankysweb.de,RequestId=d6f8b99b-0d90-4ca5-b814-375
235837774,TimeStamp=13.03.2018 21:10:45] [FailureCategory=Cafe-SendFailure]  Weitere Informationen finden Sie im
Hilfethema „about_Remote_Troubleshooting“.

Die Login Maske für das EAC wird zwar noch angezeigt, da sie vom Frontend ausgeliefert wird:

Aber nach der Eingabe von Benutzernamen und Passwort wird nur noch eine leere Seite angezeigt:

Auch im Eventlog rufen Exchange Dienste um Hilfe. Hier erhält man eine Fehlermeldung die aussagekräftig ist und in die entsprechende Richtung weißt:

Event ID: 12014

Quelle: MSExchangeFrontEndTransport

Microsoft Exchange could not find a certificate that contains the domain name EX1.cloud.frankysweb.de in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default Frontend EX1 with a FQDN parameter of EX1.cloud.frankysweb.de. If the connector’s FQDN is not specified, the computer’s FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

Outlook kann in diesem Fall auch keine Verbindung mehr herstellen, also muss ein neues Zertifikat für das Backend her. Ein neues selbstsigniertes Zertifikat kann einfach über den IIS-Manager erzeugt werden.

Um ein neues Zertifikat zu erstellen, wird im IIS Manager der Punkt Serverzertifikate aufgerufen:

Unter “Aktionen” findet sich der Menüpunkt “Selbstsigniertes Zertifikat erstellen”:

Der Anzeigename spielt keine Rolle, der Ordnung halber kann hier wieder “Microsoft Exchange” eingetragen werden:

Das Zertifikat wurde erstellt und wird nun mit dem Namen “Microsoft Exchange” angezeigt:

Nun muss das Zertifikat nur noch an die Backend Website gebunden werden:

Nachdem das neue selbst erstellte Zertifikat zugewiesen wurde, verbindet sich auch die Exchange Shell wieder:

Auch ECA verbindet sich direkt wieder, ein Neustart des Servers ist in der Regel nicht nötig.

Der Beitrag Exchange 2016: Backend Zertifikat neu erstellen erschien zuerst auf Frankys Web.

Das folgende Problem gibt es schon sehr lange: Benutzer sollen einheitliche Signaturen für E-Mails verwenden, am besten auch über alle Geräte und Clients hinweg. Bisher ist dafür zusätzliche Software nötig, mit denen Signaturen erstellt und verwaltet werden können.

Exchange Server selbst bietet bisher nur die Möglichkeit Signaturen für OWA zentral zu verwalten. Für Outlook und ActiveSync Clients muss dann wieder auf zusätzliche Software zurückgegriffen werden.

Jeff Guillet hat den Vorschlag gemacht, E-Mail Signaturen im Postfach zu speichern und damit über alle Clients zu synchronisieren. Der Vorschlag hat bei der Outlook und Exchange Product Group Gehör gefunden und es liegt nun an den Stimmen der Benutzer, ob an der Umsetzung gearbeitet wird.

Ich finde die Idee großartig und habe bereits meine Stimme abgegeben. Jeder der sich ebenfalls diese Möglichkeit wünscht, sollte ebenso für die Umsetzung stimmen.

Hier könnt ihr eure Stimme abgeben:

• Email Signature Sync across devices

Die Idee von Jeff steht jetzt schon auf Platz 1 der meist gewünschten Features. Also abstimmen und Daumen drücken, dass es umgesetzt wird.

Hier findet sich der Artikel von Jeff:

• Storing email signatures in the Exchange mailbox

Der Beitrag Outlook Signaturen im Postfach speichern – Unterstützung erforderlich erschien zuerst auf Frankys Web.

Gerade habe ich eine neue Version der Message Tracking GUI für Exchange 2016 und Exchange 2013 hochgeladen. Die aktuelle Version behebt das Problem, dass bei englischem Betriebssystem keine Ergebnisse angezeigt wurden, wenn Start- und/oder End-Datum gesetzt wurden.

Das Problem lag in der Formatierung des Datums. Im Script gab es eine Stelle, die das Datumsformat auf „Tag.Monat.Jahr“ festgelegt hat. Leider habe ich schon wieder übersehen, dass dieses Format nicht überall genutzt wird. Schande auf mein Haupt, denn genau dieses Problem wurde auch schon in einer früheren Version der Message Tracking GUI gemeldet und behoben. Leider hat sich dieser Fehler wieder erneut eingeschlichen.

Vielen Dank an Andreas, der das Problem mit der Datumsformatierung behoben hat und nun auf diesem Weg auch allen zugänglich macht.

Bisher erfordert die Message Tracking GUI die Exchange Verwaltungstools und muss daher auf einem Exchange Server oder einem Client mit installierten Verwaltungstools ausgeführt werden. Eine Alternative habe ich schon auf meiner ToDo Liste.

Den Download Link habe ich bereits aktualisiert. Hier kann die aktuelle Version direkt runtergeladen werden:

Exchange Message Tracking GUI 122.13 KB

Download

Noch ein kleiner Hinweis: Die Message Tracking GUI ist ein  PowerShell Script, welches in einer EXE-Datei verpackt wurde. In der EXE ist nur das Script enthalten. Wenn jemand das Script als lesbares PowerShell Script benötigt, dann bitte einfach melden. Ich schicke es gerne zu. Ich habe das Script nur in eine EXE-Datei verpackt, damit es direkt ausführbar ist, nicht um den Quelltext zu verstecken (Einige User hatten Probleme das Script auszuführen).

Der Beitrag Message Tracking GUI: Neue Version erschien zuerst auf Frankys Web.

Es wurden neue Updates für alle Exchange Server Versionen veröffentlicht. Auch Exchange 2010 befindet sich darunter. Hier geht es direkt zum Download:

• Exchange Server 2016 CU9
• Exchange Server 2013 CU20

Hier geht es zu den Details der Änderungen:

• Exchange Server 2016 CU9
• Exchange Server 2013 CU20

Artikel zu den Updates auf dem Exchange Team Blog:

• Exchange Team Blog

Für mich persönlich sind dies die wichtigsten Neuerungen für Exchange 2016:

• TLS 1.2 wird nun von Exchange 2013 und Exchange 2016 unterstützt. Die alten Protokolle TLS1.0 und TLS1.1 können also abgeschaltet werden, dies wird auch bald bei Office 365 der Fall sein. Mehr dazu folgt noch.

Hier findet sich ein Artikel über Punkte die bei der Installation von CUs für Exchange 2016 beachtet werden müssen:

Exchange 2016: Kumulative Updates (CU) installieren

Insbesondere der Windows Defender und andere Virenscanner sollten für die Dauer der Installation deaktiviert werden, diese verursachen gern mal Probleme während der Aktualisierung. Der Windows Defender sorgt insbesondere dafür, das Exchange CUs mehrere Stunden für die Installation benötigen.

Auch die Server Component States sollten nach der Installation eines Updates kontrolliert werden, hier finden sich entsprechende Informationen:

Exchange 2016: Server Component States

Hier findet sich auch noch ein Artikel über mögliche Stolpersteine bei den .NET Framework Abhängigkeiten der CUs für Exchange 2013 und Exchange 2016:

Exchange 2013: Stolperstein beim Update einer alten Version auf das aktuelle CU

Der Beitrag Exchange Server: Neue Updates (März 2018) erschien zuerst auf Frankys Web.

Heute hat Microsoft die erste Technical Preview von Windows Server 2019 öffentlich zum Download bereitgestellt. Wer schon mal vorab einen Blick auf das neue Server Betriebssystem werfen will, benötigt nur einen kostenlosen Windows Insider Account.

Die Preview trägt die Versionsnummer 17623 und kann hier als ISO und VHDX-Datei runtergeladen werden:

• Windows Insider for Business

Die neue Windows Sevrer Version bringt vor allem Verbesserungen in den Punkten Hybrid Cloud und Sicherheit. Die Container Unterstützung wird noch einmal deutlich ausgebaut und das Windows Subsystem für Linux (WSL) ist enthalten.

Hier findet sich ein paar Details zu den Neuerungen:

• Introducing Windows Server 2019 – now available in preview

Die finale Version wird in der zweiten Jahreshälfte veröffentlicht werden und nach dem gleichen Prinzip wie Windows Server 2016 lizensiert werden (per-Core), allerdings werden wohl die Preise für die CALs steigen.

Erste Eindrücke

Ich habe die Preview runtergeladen und in einer VM installiert, hier die ersten Eindrücke. Es handelt sich hier nur um die ersten Gehversuche, weitere Tests folgen in den nächsten Tagen.

Ich hatte zumindest schon einmal einen schlechten Start, der Download schwankte zwischen 150 KB/s und 900 KB/s und wurde damit zum Geduldsspiel:

Inzwischen ist es aber runtergeladen und die Installation startet in einer Hyper-V VM:

Es startet die schon gewohnte Installationsroutine, hier hat sich also bisher nichts geändert:

Ich habe die Installation durchlaufen lassen, im Gegensatz zum Download, war die Installation des Betriebssystems binnen 5 Minuten durch. Direkt nach der Installation wird nach dem lokalem Admin Kennwort gefragt:

Nachdem das Kennwort festgelegt wurde, wird direkt der Login angezeigt. Gefühlt ist die Installation um einiges schneller als Windows Server 2016. Den Login Screen kennt man ja bereits von Windows Server 2016 und Windows 10:

Nach dem Login zeigt sich auch der gewohnte Server Manager, bisher also nichts Neues:

Auf den ersten Blick gibt es hier also keine Unterschiede zwischen Server 2016 und Server 2019. Bisher lässt sich nur durch die Versionsnummer ein Unterschied erkennen. Hier einmal im direkten Vergleich:

Die neuen Features sind mir jetzt auf den ersten Blick nicht ins Auge gesprungen. Aber es handelt sich ja hier auch nur um die Preview und ich habe gerade erst die Installation abgeschlossen. In den nächsten Tagen, werde ich mich etwas eingehender mit der Preview beschäftigen. Werde berichten…

Der Beitrag Windows Server 2019: Technical Preview verfügbar erschien zuerst auf Frankys Web.

Die erste öffentliche Preview von Windows Server 2019 steht seit vorgestern zum Download bereit. Ich hatte es bereits installiert und angefangen etwas damit rumzuspielen. Hier gibt es jetzt nun einen ersten vagen Ausblick auf die Neuerungen von Windows Server 2019.

Hybrid Cloud

Einer der Schwerpunkte von Windows Server 2019 liegt in der Hybrid Cloud und damit natürlich mit besonderem Fokus auf Azure. Die neue Server Version soll es einfacher machen lokale und Cloud-Services zu verwalten. Hier wird Project Honolulu eine zentrale Rolle spielen. Die webbasierte Verwaltungsoberfläche mit dem Codenamen Project Honolulu ist aber noch nicht in das Betriebssystem integriert und muss daher separat runtergeladen und installiert werden. Möglicherweise wird Projekt Honolulu als Rolle in der finalen Version installierbar sein, aber das ist nur eine Vermutung.

Welche Funktionen jetzt genau bei der Nutzung von Hybrid Szenarien durch Windows Server 2019 verbessert werden sollen, ist mir aktuell etwas unklar. Auch die Ankündigung von Microsoft schweigt sich hier bisher aus. Es wird lediglich auf Project Honolulu verwiesen. In der aktuellen Preview von Server 2019 ist hier allerdings nichts zu entdecken, was nicht auch schon mit Windows Server 2016 funktionieren würde, bzw. funktioniert.

Container (Docker, Kubernetes)

Windows Server 2019 soll bessere Unterstützung für Container liefern. Wie auch schon bei Windows Server 2016 lässt sich das Feature via Server Manager installieren:

Bisher also alles Funktionen die auch schon von Windows Server 2016 bekannt sind. Scheinbar liegt hier der Fokus eher darauf die Container Images von Windows Server Core zu verkleinern und damit letztendlich das Handling einfacher zu machen. Die Rede ist hier von einer Reduzierung der Größe der Server Core Images auf ein Drittel der jetzigen Größe. Derzeit ist ein Server Core Image ca. 5 GB groß. Wenn die Ankündigung umgesetzt wird, sollten Server Core Images also nur noch um die 1,7 GB groß sein. Weitere Verbesserungen soll es in Zusammenhang mit Kubernetes und Server 2019 geben. Was genau, ist allerdings noch unklar: Signifikante Verbesserungen wurden zumindest angekündigt.

Linux

Das Windows-Subsystem für Linux (WSL) lässt sich jetzt als Feature zu Windows Server 2019 hinzufügen:

WSL spielt auch hier hauptsächlich eine Rolle in Verbindung mit Containern. Windows Server 2019 soll auch als Plattform für Linux basierte Container fungieren, dies ist allerdings auch nicht ganz neu. Docker Container für Windows und Linux lassen sich bereits parallel auf einem Host ausführen, wenn auch mit diversen Einschränkungen. Hier wird es sicherlich einige Verbesserungen geben.

Viele neue Features, keine neuen Rollen

Wenn man den Server Manager aufruft und die Server Rollen betrachtet, gibt es nichts Neues zu sehen. Die Rollen entsprechen fast 1-zu-1 den Rollen von Windows Server 2016. Auf den ersten Blick fehlen aber die von Windows Server 2016 bekannten Rollen „Windows Essential Backup“ und „MultiPoint Services“. Die MultiPoint Services dürften verschmerzbar sein, gerade kleine Firmen setzen aber scheinbar „Windows Server Backup“ zur Sicherung ein. Die Installation als Rolle ist zumindest in der Preview nicht mehr verfügbar. Hier mal ein Screenshot zum Vergleich:

Die meisten neuen Funktionen von Windows Server 2019 scheinen sich hinter aktivierbaren Features zu verstecken. Hier sind mir gleich ein paar neue Features aufgefallen, wobei ich nicht nicht genau weiß, wofür die alle gut sind. Vieles deutet zumindest dürftigen Beschreibung auf HCI hin.

Hyper Converged Infrastructure (HCI)

HCI – Hyper Converged – Scalable – Cloud. Bingo. Mehr Buzzwords braucht es fast nicht mehr um beim „Buzzword Bingo“ zu gewinnen. Was steckt dahinter? Nichts neues… Ich hatte kurz überlegt einen kleinen Abriss vom alten Rack-Server mit seinen lokalen Festplatten hin zur Hyper Converged Infrastructure (der Server mit seinen lokalen Festplatten) zu schreiben. Irgendwie dreht man sich dabei aber im Kreis…

Im Prinzip geht es also wieder um ganz normale Server mit lokalen Storage und ein bisschen Software welche für die Redundanz von Servern und Storage sorgt. Im Prinzip also SAN, Storage und Compute vereint über mehrere physikalische Server. Was früher in Hardware gegossen wurde (SAN, Storage, Server, etc), wird durch Server mit lokalen Storage und ein bisschen Software Logik ersetzt. Scalable und Hyper Converged. Bingo. Keine Frage, HCI macht in vielen Fällen Sinn, ist aber auch nicht das Allheilmittel.

Welche Neuerungen Windows Server 2019 da genau bringen wird, bleibt abzuwarten.

Alte Bekannte

Hier wird es wahrscheinlich auch mit Windows Server 2019 keine wirklichen Innovationen geben. Windows Server 2016 war bzw. ist, hinsichtlich der Infrastruktur Dienste wie Active Directory, PKI, WSUS, RDS nahezu auf dem gleichen Level wie Windows Server 2012 R2. Dies wird sich, allem Anschein nach, auch mit Windows Server 2019 nicht ändern. Ankündigungen zu neuen Features von beispielsweise Active Directory habe ich bisher nicht mitbekommen. Hier wird sich wahrscheinlich nicht viel gegenüber Windows Server 2012 R2 und Windows Server 2016 ändern.

Fazit

Ich bin ja sehr gespannt, was noch alles kommen mag. Viel mehr kann ich bisher nicht sagen. Windows Server 2019 zielt wie auch schon Server 2016 auf die großen Rechenzentren, der kleinere Kunde mit wenigen Servern wird von Server 2019 also eher weniger profitieren.

Der Beitrag Windows Server 2019: Die Neuerungen / Altbekanntes erschien zuerst auf Frankys Web.

Sophos hat heute ein neues Update für die Sophos UTM veröffentlicht. Das Update ist für die Version 9.508-10 und hebt die Version auf 9.509-3. Das Update behebt diese drei Probleme:

• [NUTM-9619]: [Email] CVE-2018-6789: buffer overflow in base64d function in SMTP listener
• [NUTM-9698]: [Network] After upgrade to 9.508 in VPC IPsec BGP status shows „state error“
• [NUTM-9713]: [Network] BGP not advertising network to all neighbors

Das Update erfordert einen Neustart. Das Problem mit den S/MIME Signaturen wird nicht behoben, aber dazu gibt es mittlerweile einen Workaround:

• Sophos UTM 9.508-10: Signierung von Mails mittels S/MIME problematisch

Außerdem berichten einige User über Probleme mit der MIME Typ Erkennung der Mailprotection seit Update auf 9.508-10. Dieses Problem wird ebenfalls nicht angegangen.

Das Update kann hier runtergeladen werden:

• http://ftp.astaro.de/UTM/v9/up2date/u2d-sys-9.508010-509003.tgz.gpg

Wie immer bei Sophos Updates gilt: Backup erstellen und ausführlich testen!

Der Beitrag Sophos UTM: Neues Update (9.509-3) erschien zuerst auf Frankys Web.

Das folgende Problem hatte ich nun schon häufiger und bin schon wieder darauf reingefallen. Ich möchte daher das Problem kurz schildern: Die Exchange Management Shell eines Exchange 2016 Servers wollte sich nicht mehr verbinden und zeigte nur noch Fehler. Auch mittels ECA konnte sich nicht mehr angemeldet werden. Dieses Problem ist ja nun schon recht bekannt, im IIS fehlte das Backend Zertifikat. Dieses Problem ist ja schnell behoben:

• Exchange 2016: Backend Zertifikat neu erstellen

Nachdem das Zertifikat wieder zugewiesen wurde (es war noch vorhanden) funktionierte die ECA-Webseite wieder problemlos, auch Outlook und OWA ließen sich wieder verbinden. Nur die Exchange Management Shell meldete noch einen Fehler:

New-PSSession : Beim Verbinden mit dem Remoteserver EXSERVER ist
folgender Fehler aufgetreten: Die Verbindung mit dem angegebenen Remotehost wurde zurückgewiesen. Vergewissern Sie sich, dass der WS-Verwaltungsdienst auf dem Remotehost ausgeführt wird und zum Überwachen der Anforderungen am korrekten Port und für die entsprechende HTTP-URL konfiguriert ist. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.

Manchmal sieht man ja den Wald vor lauter Bäumen nicht, daher habe ich:

• PowerShell Verzeichnisse (FrontEnd und BackEnd) neu erstellt
• WinRM kontrolliert (Listener und Ports)
• Firewall kontrolliert
• Server neugestartet
• IIS neugestartet
• Applikation Pools kontrolliert
• Rumgeheult und verzweifelt geguckt
• SSL Einstellungen und Berechtigungen kontrolliert
• IIS Website Bindungen kontrolliert

Das volle Programm eben, irgendwann sieht man dann ein: Das Problem löst du heute nicht mehr, also vertagt auf morgen. Ich hatte das Problem schon zig mal, nur die Lösung nicht mehr im Kopf.

10 Minuten später…

Das Gehirn meldet sich (wenn alle Verbindungen geschlossen sind und der PC runtergefahren ist):

• Proxy Server sind doof.

Das war dann auch der Moment als ich den Kopf auf die Tischplatte geschlagen habe. Ich habe schon wieder vergessen die Proxy Einstellungen im Internet Explorer zu kontrollieren:

Ursache des Problems war also mal wieder ein Proxy der nicht mit den entsprechenden Ausnahmen konfiguriert war. Ich habe den Proxy komplett deaktiviert. Mir fällt gerade auch kein Grund ein, warum ein Proxy auf einem Exchange Server eingetragen wird, vielleicht kommt noch was in 10 Minuten…

Typisches “Admins Life”…

Der Beitrag Exchange 2016: Exchange Management Shell verbindet sich nicht (Admins Life) erschien zuerst auf Frankys Web.

Aufgrund dessen, dass viele meiner Kollegen sehr isoliert gebaut haben und auch innerhalb unserer Büroräume der Mobilfunkempfang mehr schlecht als recht ist, war es nötig sich mit Vodafone WiFi-Calling im Zusammenhang mit der Sophos UTM 9 auseinanderzusetzen.

Vodafone nutzt hierbei kein klassisches SIP wie man erst meinen mag. Viel mehr werden die UDP Ports 500 und 4500 genutzt, welche eher im IPsec Bereich zu vermuten sind. Auf meiner privaten UTM9 habe ich das Ganze mal getestet und die Ports ausgehend für mein Subnetz freigegeben:

Dennoch bekam ich aber nicht den typischen Hinweis auf meinem Smartphone.

Weitere Recherchen ergaben, dass Vodafone Geoblocking nutzt, um den Service freizuschalten. Da ich die QUAD9 DNS Server nutze, war klar wo der Haase im Pfeffer lag. Nun wollte ich aber nicht das gesamte Netzwerk auf die vom Provider, in meinem Fall Unity Media, zugewiesenen DNS Server leiten. Also musste eine separate DNS Router eingerichtet werden:

Als Domain kommt hier vodafone-ip.de zum Einsatz, auf dem die DNS Anfragen landen. Ich habe hier eine Availability Group mit den 4 mir zugewiesenen DNS Servern von Unity Media eingerichtet.

Und schon kann ich Vodafone WiFi-Calling nutzen.

So, nun habe ich das Ganze analog auf unseren UTMs im Unternehmen installiert. Hier haben wir jedoch mehr als einen Internetanschluss. Unsere synchrone Gigabit-Anbindung soll exklusiv den Serverdiensten sowie VPN dienen. Die schwächere asynchrone DOCSIS 3.0 Leitung nutzen wir zum Surfen und als Backup. Nun möchte ich den oben genannten Traffic gerne über die UnityMedia Leitung lenken und muss zusätzlich noch zwei Multipath Rules einrichten und zwar eine für jedes Protokoll. Für Port 500:

Und für Port 4500:

Nun funktioniert WiFi-Calling auch im Unternehmen.

Wichtig hierbei zu wissen ist, dass die Technologie nicht mit einer aktivierten UltraCard funktioniert!

Der Beitrag Vodafone WiFi-Calling mittels Sophos UTM 9 erschien zuerst auf Frankys Web.

Das SMTP-Protokoll ist ja nun schon etwas in die Jahre gekommen und wurde schon oft totgesagt, aber jetzt bekommt es scheinbar seinen Todesstoß versetzt. Exchange 2019 wird kein SMTP mehr unterstützen. Als Nachfolger stehen MAPIoverHTTP und EWS in den Startlöchern.

Das SMTP Protokoll zum Austausch von E-Mails gibt es seit 1982, damit ist es nur logisch, dass langsam ein Nachfolger für das antiquierte Protokoll gefunden werden muss. Microsoft macht hier Nägel mit Köpfen und wird das alte SMTP Protokoll mit der kommenden Exchange 2019 Version nicht mehr unterstützen. E-Mails sollen zukünftig per MAPIoverHTTP oder EWS an Exchange Server zugestellt werden. Die Abkehr von SMTP als Standardprotokoll für den Mailverkehr ist allerdings nicht ohne Hürden zu meistern, hier gilt es einige Voraussetzungen zu erfüllen:

• Korrekte Autodiscover Konfiguration (damit andere Mailserver via MAPIoverHTTP oder EWS den Mailserver ermitteln können)
• Korrekt eingestellte Zertifikate, die alle entsprechenden Exchange URLs enthalten
• Gateways die SMTP als Protokoll einsetzen, müssen ausgetauscht werden

SPAM-Filter, die MAPIoverHTTP oder EWS nicht unterstützen, können somit nicht mehr mit Exchange 2019 verwendet werden. Für die Administratoren gibt es hier also viel zu tun: Anwendungen und Dienste, die bisher auf SMTP setzen, müssen aktualisiert oder ausgetauscht werden. SPAM-Filter müssen ersetzt werden und wahrscheinlich viele Scripte müssen angepasst werden.

Es gibt allerdings auch Vorteile: MX-Records werden nicht mehr benötigt.

PS: Heute ist der 1. April.

Der Beitrag Exchange 2019: Unterstützung für SMTP entfällt erschien zuerst auf Frankys Web.

Ich habe nun schon einige Mails bezüglich der Migration von Domain Controllern erhalten, die noch mit einem älteren Betriebssystem laufen. In den meisten Mails geht es darum, die IP-Adresse des ursprünglichen Domain Controllers beizubehalten.

Die Umgebungen, die in den Mails geschildert wurden, waren alle samt ähnlich, nur das Betriebssystem auf dem der ursprüngliche Domain Controller läuft variiert. In den meisten Fällen gab es nur einen Domain Controller der auf Windows Server 2008 läuft und nun durch Windows Server 2016 ersetzt werden soll. In einem Fall gab es sogar noch einen Domain Controller der auf Server 2003 läuft.

Es ist natürlich nicht empfohlen nur einen Domain Controller zu betreiben, allerdings lassen manch kleine Umgebungen auch nichts anderes zu.

Dieser Artikel widmet sich der Migration eines Active Directory mit nur einem Domain Controller basierend auf Server 2008 zu Server 2016 inklusive der Beibehaltung der ursprünglichen IP des Server 2008 DCs.

Server 2003 ist hier außen vor, kann aber mittels der gleichen Methode zunächst zu Server 2008 und danach von Server 2008 zu Server 2016 migriert werden. Eine direkte Migration von Server 2003 zu Server 2016 DCs ist nicht möglich.

Die Umgebung

Für diesen Artikel habe ich deine Testumgebung erzeugt, die wie folgt aufgebaut ist:

Es gibt einen Windows Server 2008 Domain Controller mit der statischen IP 172.16.100.10 und dem Namen DC2008. Im Netzwerk gibt es weitere Clients, welche den Domain Controller als DNS Server nutzen. Der Name des Active Directory lautet frankysweb.local.

Es wurde ein neuer Windows Server 2016 mit dem Namen DC2016 und der IP 172.16.100.20 installiert. Der Server ist bisher nur Mitglied des Active Directory und nutzt ebenfalls DC2008 als DNS Server. Nach Abschluss der Migration soll der neue Server wieder die IP 172.16.100.10 bekommen.

Neuen Domain Controller installieren

Zunächst muss die Rolle “Active Directory-Domänendienste” auf DC2016 installiert werden, bevor DC2016 zum Domain Controller hochgestuft werden kann:

Für die Zeit der Migration von DC2008 zu DC2016 werden also zwei Domain Controller laufen.

Nachdem die Rolle installiert wurde, kann DC2016 direkt zum DC hochgestuft werden:

Die Standardeinstellungen können so belassen werden:

Auch im nächsten Dialog muss nur das Kennwort für den Wiederherstellungsmodus gesetzt werden, die Häkchen bei “DNS-Server” und “Globaler Katalog” bleiben gesetzt:

Eine Delegierung wird in den meisten kleinen Umgebungen nicht benötigt, daher kann die Warnung ignoriert werden:

Die weiteren Dialoge können alle mit “Weiter” bestätigt werden. Im letzten Dialog wird noch eine Zusammenfassung mit zwei Warnungen angezeigt. In diesem Fall sind die beiden Warnungen als Hinweise anzusehen:

• Es kann keine Delegierung für den übergeordneten DNS Server erstellt werden –> wird hier nicht benötigt
• NT4 Clients können sich nicht mehr verbinden –> wird ebenfalls nicht mehr benötigt

Nachdem DC2016 automatisch neu gestartet wurde, gibt es nun also zwei Domain Controller für die Domain frankysweb.local:

Jetzt sollten noch die Ereignis Protokolle durchgesehen werden, ob es zu Fehlern bei der Replikation gekommen ist. Zum Test kann auch ein neues Benutzerkonto angelegt und dann geprüft werden, ob es auf beiden DCs angezeigt wird. Wenn die Replikation funktioniert, kann es weitergehen.

FSMO Rollen verschieben

Das Verschieben der FSMO Rollen von DC2008 zu DC2016 funktioniert am einfachsten per Command Line und dem Tool “ntdsutil”. Die folgenden Befehle können genutzt werden um alle FSMO Rollen von DC2008 zu DC2016 zu verschieben (Hinweis: Die Verbindung wird zu DC2016 aufgebaut):

roles
connection
connect to server DC2016
quit
transfer schema master
transfer naming master
transfer RID master
transfer PDC
transfer Infrastructure Master

Die Abfragen müssen dann mit “OK” bestätigt werden.

mit dem Befehl “netdom query fsmo” kann überprüft werden, ob alle FSMO Rollen verschoben wurden:

Wenn dies erfolgt ist, kann es mit dem nächsten Schritt weitergehen.

Alten Domain Controller entfernen

Ab jetzt ist etwas Downtime nötig. Der alte Domain Controller wird entfernt und damit auch der alte DNS Server. Alle Clients/Server die ausschließlich die IP 172.16.100.10 (von DC2008) als DNS-Server konfiguriert haben, können den neuen Domain Controller nicht via DNS finden. Dieser Schritt sollte also in einem Wartungsfenster erfolgen.

Um eine Downtime zu vermeiden kann auch einfach der neue Server als primärer DNS Server eingestellt werden, wenn dies auf allen Clients erfolgt, muss natürlich auch nicht die IP-Adresse des neuen Domain Controllers geändert werden. Hier geht es nun aber genau um den Fall dass der neue Server die IP des alten Servers erben soll. Daher weiter im Text.

DC2008 wird nun runtergestuft, dies funktioniert mit dem Befehl “dcpromo”:

Es öffnet sich der Dialog zum entfernen des Domain Controllers. Das Häkchen bei “Domäne löschen, da dies der letzte Domänencontroller in der Domäne ist” darf NICHT gesetzt werden:

Im darauffolgenden Dialog muss ein neues lokales Administrator Kennwort angegeben werden:

Die Zusammenfassung kann bestätigt werden:

Die Domain Controller Rolle wird nun von DC2008 entfernt und der Server kann neu gestartet werden.

Nachdem DC2008 neu gestartet wurde, gibt es in der OU “Domain Controllers” nur noch das Computerkonto von DC2016:

DC2008 kann nach dem Neustart runtergefahren werden, somit ist die IP Adresse frei und kann gleich dem neuen Domain Controller zugeordnet werden. Vorher sind allerdings noch ein paar Aufräumarbeiten nötig.

Aufräumarbeiten

Das alte Computer Konto von DC2008 findet sich nun in der OU “Computers” und kann hier gelöscht werden:

Die DNS Einstellung der Netzwerkkarte auf DC2016 kann nun korrigiert werden, hier ist noch die IP von DC2008 eingetragen:

Hier wird nun als DNS Server 127.0.0.1 verwendet. Es ist hier übrigens wenig sinnvoll einen Router oder öffentlichen DNS Server ans Sekundären DNS Server einzutragen, da diese in der Regel nicht die Zonen für das lokale Active Directory auflösen können. In Umgebungen mit nur einem DC steht hier also nur 127.0.0.1:

Im DNS-Manager müssen nun einmal alle Zonen und Subzonen durchgesehen werden, hier bleiben oft Leichen des alten Domain Controllers zurück. Hier können anhand der alten IP / Hostnamen Leichen erkannt und gelöscht werden:

Die delegierte Zone “_msdcs” hat ebenfalls noch einen alten Nameserver Eintrag, dieser muss ebenfalls korrigiert werden:

Hier ist mal ein Beispiel für eine Leiche, die bei mir nicht gelöscht wurde:

Wie gesagt, geht alle Zonen und Subzonen einmal durch und schaut nach alten Einträgen, irgendwo bleibt immer etwas zurück. Auch die Reverse Zone nicht vergessen.

IP Adresse des DCs ändern

Das Ändern der IP Adresse ist nun kein Hexenwerk mehr. Zuerst wird die IP von DC2008 auf DC2016 konfiguriert:

Danach folgt ein “ipconfig /registerdns”:

Dann wird der Anmeldedienst neu gestartet:

Jetzt noch einmal kurz im DNS Aufräumen und die folgenden drei alten Einträge löschen:

Fertig. Sicherheitshalber sollten Exchange und SQL-Server wenn vorhanden einmal neu gestartet werden.

Der Beitrag Migration Domain Controller zu Server 2016 erschien zuerst auf Frankys Web.

Die folgende Mail hat mich vor ein paar Tagen erreicht und ich denke die Lösung könnte auch anderen weiterhelfen. Es handelt sich um einen einzelnen Exchange 2016 Server auf Windows Server 2012 R2. Hier einmal ein Auszug des Problems aus der Mail:

Nun bin ich aber am Ende meines Lateins und wollte mich erkundigen ob du eventuell einen solchen Fehler in deinen Exchange Installationen auch schon einmal hattest.. Mein Exchange Server «stirbt» fast Täglich mit folgenden Effekten:

• Mails werden nicht mehr zugestellt und ich erhalte eine Fehlermeldung in der Queue Übersicht (siehe PrintScreen im Anhang)
• Vereinzelte Benutzer können sich nicht mehr mit dem Exchange Server verbinden (in der Verbindungsübersicht zählt er die Verbindungsversuche endlos hoch – es kommt aber keine Verbindung mehr zustande).

Derzeit umgehe ich das mit einem Reboot des Information Store und des RPC Client Access Dienstes. Das läuft dann wieder ein paar Stunden und schon habe ich denselben Fehler wieder.

Ein kleiner Screenshot war auch angehangen:

Hier einmal der Text der Meldung:

432 4.3.2 STOREDRV; mailbox server is offline; STOREDRV.Deliver.Exception:ConnectionFailedTransientException.MapiExceptionNetworkError; Failed to process message due to a transient exception with message Underlying MAPI stream threw exception

Ich hatte bereits eine Vermutung wo das Problem liegt und daraufhin das Eventlog angefordert. Netterweise wurde mir das Eventlog zur Verfügung gestellt und auch ein Zeitpunkt genannt, wann das Problem zu Letzt aufgetreten ist.

Im Anwendungsprotokoll wurde der folgende Fehler protokolliert:

Quelle: MSExchange Availability

ID:: 4009

Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: Unable to open connection for mailbox MAILBOX SMTP:EMAIL-Adresse. Exception returned is: Microsoft.Exchange.Data.Storage.StorageTransientException: The process failed to get the correct properties. —> Microsoft.Mapi.MapiExceptionRpcServerTooBusy: MapiExceptionRpcServerTooBusy: Unable to get properties on object. (hr=0x80004005, ec=2419)

Hiermit war dann auch die Ursache klar:

Der Server hat also viel zu tun. Um zu vermeiden das einzelne Benutzer zu viele Systemressourcen auf dem Server verbrauchen und damit andere Benutzer und/oder das System ausbremsen, gibt es Throttling Policies. Throttling Policies begrenzen die Ressourcen die ein einzelner Benutzer in Anspruch nehmen kann.

Ich stellte dann sicherheitshalber noch eine Rückfrage:

Haben bei euch viele Benutzer mehrere Postfächer geöffnet? Wie viele Postfächer sind in einer Datenbank?

Die Antwort auf meine Frage:

Anzahl Postfächer würde ich auf ca. 450 tippen und ja, die meisten meiner User (habe ca 80-100 concurrent user) haben mehrere (bis zu 20) Postfächer offen.

In diesem Fall waren alle Postfächer in einer Datenbank gespeichert.

Dem Problem auf der Spur

Ich habe empfohlen eine weitere Datenbank anzulegen und 50% der Postfächer in die neue Datenbank zu verschieben. Hier sollte ein ausgewogenes Verhältnis herrschen um die Last möglichst gleichmäßig zu verteilen. Daher sollten nicht alle Power User in eine neuen Datenbank verschoben werden, sondern nur die Hälfte, der Rest kann dann mit weniger aktiven Postfächern aufgefüllt werden. So lässt sich meist ein recht ausgeglichenes Verhältnis von Datenbankgröße und Last herstellen. Ein Exchange Server 2016 Standard Edition kann maximal 5 gemountete Datenbanken pro Server verwalten (Enterprise Edition: 100 gemountete Datenbanken pro Server).

Durch die Nutzung mehrerer Datenbanken lässt sich die Last also besser verteilen. Auch im Hinblick auf Backup und Restore machen mehrere Datenbanken Sinn, beim Backup kann je Datenbank ein Stream geöffnet werden (wenn entsprechende Software eingesetzt wird) und dadurch der Durchsatz des Backups erhöht werden. Auch die Restore Zeiten können sich verbessern, anstatt im Fehlerfall eine große Datenbank aus dem Backup wiederherzustellen, reicht es ggf. aus eine von mehreren kleineren Datenbanken wiederherzustellen.

Zurück zu den Throttling Policies:

In der Standardeinstellung gibt es für alle Exchange 2016 Server eine globale Throttling Policy. In dieser Policy wird unter anderem die Anzahl gleichzeitiger Verbindungen je Benutzer/Client/Protokoll definiert. Für den aktuellen Fall ist besonders ein Wert wichtig: RCAMaxConcurreny

The RcaMaxConcurrency parameter specifies how many concurrent connections an RPC Client Access user can have against an Exchange server at one time. A connection is held from the moment a request is received until the connection is closed or the connection is otherwise disconnected (for example, if the user goes offline). If users attempt to make more concurrent requests than their policy allows, the new connection attempt fails. However, the existing connections remain valid.

Quelle: https://docs.microsoft.com/en-us/powershell/module/exchange/server-health-and-performance/set-throttlingpolicy?view=exchange-ps

RCAMaxConcurreny legt also den Wert gleichzeitiger Verbindungen je Client fest. In der Standardeinstellungen sind es 40:

Get-ThrottlingPolicy | ft name,RcaMaxConcurrency

In dem vorliegenden Fall haben manche Benutzer allerdings bis zu 20 Postfächer geöffnet. Hier mal ein Screenshot für meinen Benutzer der 2 Postfächer geöffnet hat:

Hier sieht man 5 Verbindungen, 3 für das primäre Postfach (mein Eigenes) und 2 für das zusätzliche Postfach. Hochgerechnet auf 20 Postfächer ergibt sich folgendes:

3 Verbindungen für das eigene Postfach und 20 x 2 Verbindungen für die zusätzlichen Postfächer. In Summe 43 Verbindungen. Die Policy lässt allerdings zur 40 gleichzeitige Verbindungen zu.

Scheinbar bezieht sich der Wert RCAMaxConcurreny der Throttling Policy allerdings auch auf die Datenbank, denn alle Verbindungen können aufgebaut werden, wenn 10 der Postfächer in DB1 und die weiteren 10 Postfächer in DB2 gespeichert werden. Somit würden in Summe nur 23 Verbindungen gegen DB1 (Eigenes Postfach + 10 weitere Postfächer) und 20 Verbindungen gegen DB2 (10 weitere Postfächer) laufen.

Dies konnte ich bisher aber nicht abschließend verifizieren.

Die Lösung des Problems

Letztendlich wurden zwei Maßnahmen umgesetzt, die das Problem behoben haben:

Es wurde eine zusätzliche Datenbank angelegt und die Postfächer möglichst gleichmäßig anhand von Postfachgröße und Aktivität der Benutzer verteilt.

Es wurde eine zusätzliche Throttling Policy erstellt und der Wert für den Parameter RCAMaxConcurreny angehoben:

New-ThrottlingPolicy -Name FrankysWebPolicy -ThrottlingPolicyScope Organization -RcaMaxConcurrency 80

Bisher ist das Problem nicht wieder aufgetreten.

Der Beitrag Exchange 2016: STOREDRV; mailbox server is offline (ID 4009) erschien zuerst auf Frankys Web.

Microsoft hat heute das “Windows Admin Center” freigegeben. Den Meisten dürfte das “Windows Admin Center” unter dem Codenamen “Project“ Honolulu” bekannt sein.

Nun steht also auch der offizielle Name fest. Bei dem Windows Admin Center handelt es sich um eine webbasierte Anwendung für die Verwaltung von Windows Servern. In diesem Artikel hatte ich die Preview bereits kurz vorgestellt:

• Ein erster Blick auf Project Honolulu

Nun ist das Windows Admin Center also bereit für den produktiven Einsatz. Die MSI-Datei zu Installation ist knappe 45 MB groß und kann hier runtergeladen werden:

• Windows Admin Center (formerly Project Honolulu)

Es gibt auch ein kleines Einführungsvideo:

Das Windows Admin Center ist kostenlos und erfordert keine zusätzliche Lizenz. Es kann auf einem Windows Server oder Windows 10 Client installiert werden. Für die Verwaltung werden die folgenden Betriebssysteme unterstützt:

• Windows Server 2012
• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019

Windows Server 2008 R2 und früher wird nicht unterstützt.

Als ich die Preview ausprobiert hatte, war ich bereits sehr angetan. Es war schnell und einfach. Ich habe daher direkt die finale Version runtergeladen und daher gibt es hier meinen ersten Eindruck der finalen Version:

Es müssen keine Voraussetzungen installiert werden. Die MSI-Datei bringt alles nötige mit

Ich verwende erst einmal das selbstsignierte Zertifikat, in der Preview war es noch ziemlich hakelig ein anderes Zertifikat zu verwenden. Ich teste später mal, wie sich das Zertifikat nachträglich austauschen lässt:

Die Installation ist mit wenigen Klicks erledigt und braucht nur ein par Sekunden. Nach der Installation lässt sich direkt die Webseite aufrufen:

Der lokale Server auf dem das Windows Admin Center installiert wurde, lässt sich direkt verwalten:

Ich habe jetzt nur mal ein bisschen durchgestöbert und bin von der Geschwindigkeit wirklich beeindruckt. Da wirkt der “alte” Servermanager richtig träge gegen.

Ich hinterlege nun erst einmal meine Server und schaue mal ob auch die Webserver Protection der Sophos UTM mitspielt. Das wäre nun wirklich schon fast zu schön…

Der Beitrag Windows Admin Center ist verfügbar (Project Honolulu) erschien zuerst auf Frankys Web.