Exchange 2016 CU4 und 2013 CU15 verfügbar!

Gestern, am 13.12., hat Microsoft für Exchange neue Updates veröffentlicht. Für Exchange 2016 ist es das CU4 und für Exchange 2013 ist es das CU15.

Neuerungen:
Die wichtigsten Neuerungen sind hier, neben einer veränderten Web-Oberfläche (bei neuen Mails ist die Bearbeitungsleiste jetzt unten statt oben), ist vor allem die Unterstützung für .Net 4.6.2 herauszuheben. Exchange-Installationen welche bereits .Net 4.6.1 haben, können 4.6.2 vor oder nach dem CU einspielen. Installationen die noch 4.5.2 haben, benötigen erst das neue CU bevor sie auf .Net 4.6.2 gehen.

Neuer Receive Connector in Exchange 2016

Microsoft Exchange Server 2016 ist ja (wie schon seine Vorgänger) von Haus aus mit Empfangsconnectoren ausgestattet, welche die Basisfunktionalitäten (Mails von überall über Port 25 empfangen) abdeckt. 
Folgende Connectoren sind hier eingerichtet:

Autodiscover

"Die Geschichte von Exchange Autodiscover ist eine Geschichte voller Missverständnisse...."


Autodiscover ist eines der wichtigsten Tools bei dem man leider auch immer wieder viel falsch machen oder vergessen kann. 

Vor allem im Hinblick auf Hochverfügbarkeit mit einem Loadbalancer oder bei einer Hybridkonfiguration gibt es hier einige Stolpersteine die es zu meistern gibt. 

Wichtigste Features in Exchange 2016

Immer wieder wird man gefragt was denn die wichtigsten Gründe sind auf Exchange 2016 umzusteigen. Gibt es "Killer-Features" die man unbedingt haben muß?

Rein vom optischen Eindruck her, ist Exchange 2016 ja nicht wirklich von 2013 zu unterscheiden. Die ECP sieht genauso aus, die Shell ist.... naja die Exchange Powershell halt - schaut auch gleich aus. Sogar die Serverversion in der ECP hat sich von Ex2013 (Version 15.0) auf Ex2016 (Version 15.1) nur hinter dem Punkt verändert und schaut eher nach einem "R2" anstatt einem Major Release aus.

Exchange 2016 CU3 auf Windows Server 2016 nicht supported!

Wie Microsoft vor einigen Tagen bekannt gegeben hat, gibt es auf beim Exchange Server mit demaktuellen Kumulativen Update 3 (CU3) Probleme damit, dass der IIS - um genauer zu sein der Prozess w3wp.exe abstürzen kann. 

Mehrere SMTP (oder auch andere) Adressen entfernen

Es kommt immer wieder vor, dass es in einer Exchange Organistion eine oder mehrere Domains gibt, welche nicht mehr vorhanden sind oder einfach von den Mailboxen entfernt werden sollen. 

Handelt es sich nur um eine oder wenige Mailboxen spricht nichts dagegen, wenn man in der ECP einfach die nicht benötigten Adressen entfernt. 

ActiveSync Devices lassen sich für manche Benutzer nicht einrichten

Sollte ActiveSync grundsätzlich funktionieren, aber sich für manche Benutzer nicht einrichten lassen, lohnt es sich mal einen Blick auf die zugehörigen Gruppen und die Sicherheits-Einstellungen des ActiveDirectory User-Objects zu schauen.

2 Voraussetzungen gibt es nämlich für die erfolgreiche Verbindung mit ActiveSync zu beachten:

Kein Mailflow zu Office365 möglich (Event 2015)

Ein Kunde mit einer Hybridumgebung bat mich um Hilfe dass seit 2 Tagen (inkl. Wochenende) keine Mails mehr an die Mailboxen in Office365 zugestellt wurden. Lokale Mails (zwischen OnPrem-Mailboxen) und Mails ins Internet funktionierten einwandfrei.

Ein Blick in das Eventlog brachte folgenden Fehler (2015) zutage:

HealthManager Bug mit Zeitzone

Ein merkwürdiges Phänomen mit dem HealthManager und der Zeitzone ist scheinbar auch noch auf Exchange 2016 zu finden. 

Wie vielleicht bekannt ist, überwacht sich Exchange nahezu komplett mit unzähligen Probes und Monitoren und der findige Administrator ist so klug und hat dies in sein Monitoring-Tool eingebaut oder überwacht diese Dinge regelmässig. 

OneDrive-Verzeichnisse und Dateien in Outlook einbinden.

Benutzer von OneDrive und Outlook können sich ein nettes Feature freischalten, mit dem man sich OneDrive-Ordner in Outlook einbinden kann. (ja richtig gelesen)

Die Handhabung ist denkbar einfach:

ECP Zugriff vom Internet blockieren

Wenn man sich eine Standard-Exchange-Installation ansieht, und dabei auf die Webseite des EAC (Exchange Admin Center) schaut, wird man schnell feststellen, dass diese Seite auch sehr leicht vom Internet aus aufgerufen werden kann. Es reicht leider nicht, wenn man die "External URL" für das ECP-Verzeichnis nicht setzt. Solange OWA (Outlook Web App) verfügbar ist, kann man mit einer geänderten URL auch auf das EAC zugreifen.

Mail Relay

Auf nahezu jedem Exchange Server ist es erforderlich dass teilweise anyonyme Sender den Exchange als Mailserver nutzen dürfen. Diese Sender können Multifunktionsgeräte wie Scanner/Kopierer, Maschinen oder einfach diverse Software wie ein Intranetserver, Monitoring usw. sein. 

Es gibt hierbei 2 Ausprägungen welche

Message Header Analyzer

Ein hilfreiches Tool bei der Fehlersuche beim Mailflow ist der Message Header Analyzer von Microsoft. 

Dieser ist als Tool auf der Seite von Testconnectivity.microsoft.com bzw direkt zu finden unter https://testconnectivity.microsoft.com/MHA/Pages/mha.aspx

Die Bedienung ist denkbar einfach. Man kopiert einfach den Text einer Unzustellbarkeitsmeldung (NDR) in das Feld kopieren und auf Analyze drücken.
Das Ergebnis liefert jetzt keine "geheimen versteckten" Erkenntnisse, bereitet den Header jedoch in klarer strukturierter Form auf, sodass eine Kontrolle und Fehlersuche stark vereinfacht wird. 

Load Balancer Health URLs

Um die ClientAccess-Rolle auf einem Exchange Server 2013 oder 2016 Hochverfügbar zu machen, ist es erforderlich einen seperaten Load-Balancer einzusetzen. (Die Möglichkeiten über DNS-RoundRobin oder Windows NLB, blende ich hier bewußt aus)

Damit ein eingesetzter LoadBalancer auch mitbekommt, dass die unterschiedlichen Dienste auf den jeweiligen CAS-Servern verfügbar sind, und keine Daten auf inaktive Server schickt, ist es wichtig dies auch regelmässig zu überprüfen.

Seit Exchange Server 2013 gibt es "Managed Availability" welche es für LoadBalancer einfach macht dies festzustellen. Exchange erstellt für jeden der Dienste ein eigenes virtuelles Verzeichnis welches ein LoadBalancer (oder natürlich auch andere Monitoring Tools) lediglich abfragen muß.

Man kann einen Dienst auch einfach mittels Web-Browser auf seine Verfügbarkeit hin überprüfen

Es kommt als Antwort lediglich eine Seite mit "200 OK" und dem abgefragten Servernamen:

Folgende Liste der Healtchecks ist verfügbar:

OWA - Outlook Web App

https://Servername.domain.local/owa/healthcheck.htm

ECP - Exchange Control Panel
https://Servername.domain.local/ecp/healthcheck.htm

OAB - Offline Addressbook
https://Servername.domain.local/oab/healthcheck.htm

RPC - RPC Zugriffe
https://Servername.domain.local/rpc/healthcheck.htm

MAPI
https://Servername.domain.local/mapi/healthcheck.htm

Autodiscover
https://Servername.domain.local/autodiscover/healthcheck.htm

Active Sync
https://Servername.domain.local/Microsoft-Server-ActiveSync/healthcheck.htm

Wichtig dabei ist natürlich die FQDN des abzufragenden Servers einzutragen anstatt "Servername.domain.local"

"451 4.7.0 Temporary server error" in Test Environment

Eine Exchange Testumgebung ist eine tolle Sache um Dinge auszuprobieren. 
Zeitweise hat man damit jedoch auch Probleme welche man in einer normal installierten Umgebung nicht hätte. 

So zum Beispiel auch der Fehler:
"451 4.7.0 Temporary Server error. Please try again later. PRX2"

Eine kurze Recherche ergab, dass das Problem wieder mal mit DNS zu tun hat. 
Das Problem tritt nämlich dann auf, wenn bei der Netzwerk-Konfiguration als zweiter DNS-Server ein "Router" angegeben wird.

Einfach den zweiten DNS-Server von der Netzwerkkarte rausgelöscht und siehe da: keine Fehlermeldung mehr :-)

Update:
Sollte das nichts bringen, kann es auch helfen die Einstellung "Register this connection's addresses in DNS" und "Use this connection's DNS suffix in DNS registration" anzuhaken.

 

Hierarchisches Adressbuch

Ein hierarchisches Adressbuch (kurz: HAB), ist eine "zusätzliche" Ansicht im Outlook-Adressbuch bei der die Empfänger analog zu den Abteilungen im Firmen-Organigramm sortiert sind.

Powershell 5 und Exchange - keine gute Idee

Das Windows Management Framework 5.0 oder auch kurz gesagt "Powershell 5" ist eine tolle Sache. Viele nette Neuerungen wie CopyPaste mit den Windowstastaturkürzeln, Verwendung von ZIP-Archiven, Pakete aus Internet-repositorys importieren usw...

Langer Zeitraum für NDR-Meldung

Zeitraum für NDR 550 5.1.1 User unknown

Seit Exchange 2013 arbeiten Empfängerfilter anders als früher. Wenn ein Email mit einem "Tippfehler" in der Adresse oder an eine nicht vorhandene Adresse verschickt wird, dauert es dadurch meist recht lange bis eine Entsprechende Fehlermeldung beim Absender ankommt.

Kalenderdelegation wird an ausgetretenen Empfänger geschickt.

Diese Zusammenfassung ist nicht verfügbar. Klicke hier, um den Post aufzurufen.

DNS Error bei Mailversand

Sollte beim Mailversand ein Fehler wie "451 4.4.0 DNS query failed" auftauchen, kann man dem Problem auf 2 Arten begegnen.

Zuerst sollte man natürlich mal den Fehler eingrenzen.

In diesem Fall ist festzustellen, ob der Fehler nur bestimmte Domains, oder alle ausgehenden Mails betrifft.

 

Kein Mail an eine bestimmte Domain

Sollte es sich nur um eine bestimmte Domain handeln, kann man (temporär - bis das DNS-Problem behoben ist) einen expliziten Send Connector erstellen.

 

Dazu einfach unter Mail Flow / Send Connectors mit dem "+" einen neuen Connector erstellen.

 



Und in diesem als Smart-Host die IP des jeweiligen Empfänger-Servers eintragen.

Als SourceServer dann noch den oder die eigenen Server auswählen und mit Finish den Connector erstellen.

Mails für diese Domain sollten damit direkt zugestellt werden.

 

Überhaupt keine Mails nach Extern

Wenn an überhaupt keinen externen Empfänger verschickt werden kann, sollte mal überprüft werden ob mittels Ping, nslookup etc die jeweiligen Domains überhaupt aufgelöst werden. Exchange verwendet standardmäßig die DNS-Einstellungen der Netzwerkkarte. Sollte die Namensauflösung nicht erfolgreich sein, oder es mehrere Netzwerkkarten mit unterschiedlichen DNS-Settings geben, sollte man am  für den/die Exchange Server explizit angeben welchen DNS-Server Exchange verwenden soll. In diesem Fall habe ich die Server 8.8.8.8 u. 8.8.4.4 (Google DNS-Server) genommen.

 

Danach werden die Mails wieder erfolgreich verschickt. Mails in der Warteschlange (Queue) brauchen ein paar Minuten oder man stösst das ganze mittel dem Cmdlet Retry-Queue an.

Fehleranalyse: Verschwundene Kalendereinträge

Auf unerklärliche Weise sind immer wieder Termine zwischen 2 Usern verschwunden.

Problemstellung:

User A hat eine Einladung an mehrere User verfasst welche dann auch angenommen wurde.

Alle (oder zumindest mehrere) User haben die Einladung angenommen und der Termin scheint im kalender der jeweiligen Benutzer auf. Nach mehreren Minuten/Stunden, verschwindet der Eintrag jedoch aus dem Kalender von User A und 1 weiteren Benutzer (User B). Die anderen haben den Eintrag noch im Kalender stehen.

 

Analyse:

Zuerst wurden alle Outlook-PlugIns deaktiviert. Weiters wurde auch überprüft ob es Inbox-Rules in den Mailboxen gab und dann wurden auch noch die Mobilgeräte als Verursacher ausgeschlossen.
 

Danach wurde das "Mailbox Audit Log Search" für die 2 betroffenen Mailboxen aufgedreht.

Dies kann am besten über die Shell erfolgen:

Set-Mailbox -Identity "Vorname Nachname" -AuditEnabled $true

siehe dazu auch https://technet.microsoft.com/en-us/library/ff461937%28v=exchg.160%29.aspx

Kurz vor Dienstschluss der Mitarbeiter wurde noch eine Test-Einladung von dem Benutzer mit der Problem-Mailbox verschickt um sicherzugehen, dass die Einladung auch dann verschwand, wenn keiner der Benutzer Outlook geöffnet hat.

Ergebnis:

Die Logs können mittels Exchange Admin Center einfach exportiert werden.

 

Danach bekommt man ein XML-File welches man mit einem x-beliebigen Editor ansehen kann.

Ich habe dazu einfach mal Notepad++ verwendet.

Das Ergebnis sah dann folgendermaßen aus:

 <Event MailboxGuid="4d9e36ca-1d1e-40ee-92dd-fe6e5740671b" Owner="Vorname Nachname" LastAccessed="2016-04-28T17:33:41+02:00" Operation="HardDelete" OperationResult="Succeeded" LogonType="Admin" FolderId="LgAAAABV5Gs0nfPsRqWTLmX3wbUoAQDDErzhrPTHTbQDBLYqsdv1AAAAAAEOAAAC" FolderPathName="\Calendar" ClientInfoString="Client=WebServices;ExchangeServicesClient/15.00.0516.014;" ClientIPAddress="10.2.36.18" InternalLogonType="Owner" MailboxOwnerUPN="Vorname.nachname@domain.com" MailboxOwnerSid="S-1-5-21-3475737579-2923169912-4130912164-2264" CrossMailboxOperation="false" LogonUserDisplayName="svcCRMCorp" LogonUserSid="S-1-5-21-7563437579-2923166392-4130993384-87952" OriginatingServer="Exchange1 (15.00.1104.002)">

    <SourceItems>
      <Item Id="RgAAAABV5Gs0nfPsRqWTLmX3wbUoBwDDErzhrPTHTbQDBLYqsdv1AAAAAAEOAADDErzhrPTHTbQDBLYqsdv1AAFeq/6MAAAP" Subject="TEST 2" FolderPathName="\Calendar" />
    </SourceItems>
  </Event>
  <Event MailboxGuid="5d8b10ca-2c1f-41fe-97dd-fe6f6529671c" Owner="Vorname Nachname" LastAccessed="2016-04-28T17:33:41+02:00" Operation="SendAs" ItemId="RgAAAABV5Gs0nfPsRqWTLmX3wbUoBwDDErzhrPTHTbQDBLYqsdv1AAAAAAEQAADDErzhrPTHTbQDBLYqsdv1AAFerAccAAAN" ItemSubject="Canceled: TEST 2" OperationResult="Succeeded" LogonType="Admin"
Die relevanten Stellen habe ich zur Übersichtlichkeit mal gelb markiert.

Wie sich hier zeigt, handelt es sich um die Einladung "TEST 2"

 

 

Diese ist um 17:33 vom User svcCRMCorp gelöscht (siehe Marker "HardDelete" und LogonUserDisplayName=svcCRMCorp) worden.

Wie sich in weiterer Folge herausgestellt hat, handelte es sich hier bei dem User um einen Service-Account mit administrativen Rechten, welcher in regelmässigem Intervall die Kalender der Mitarbeiter mit dem CRM-System synchronisierte.

Die weitere Fehlerbehandlung erfolgte danach auf dem CRM-Server.

Nicht vergessen:

Das Logging für die Mailbox sollte wieder deaktiviert werden.

 

Set-Mailbox -Identity "Vorname Nachname" -AuditEnabled $false

 

Migration von O365 Mailboxen nach Exchange OnPremise

Eine Migration von Microsoft Exchange 2013, nach Office 365 ist in der Regel, bei korrekt konfigurierter Hybrid-Umgebung, kein Problem.

Man braucht dazu lediglich das Postfach im Exchange Admin Center mittels einem Migrationsbatch nach O365 verschieben.

Möchte man hingegen von Office 365 nach OnPremise verschieben (also offboarding) kann sich das Ganze schon etwas schwieriger gestalten.

Sofern der User schon einmal OnPremise war und dann nach O365 verschoben wurde ist es noch ohne Probleme möglich. Falls die Mailbox jedoch nur in O365 angelegt wurde, gibt es allerdings einige Hürden zu meistern.

 

Zunächst einmal muss dazu überprüft werden ob im lokalen ActiveDirectory die Mailbox als "Mail-User" aufscheint.

Dies kann im Exchange Admin Center leicht überprüft werden. Einfach suchen ob das Postfach unter Contacts aufscheint:

 

 

Sollte das nicht der Fall sein, kann mittels dem Cmdlet

Enable-MailUser -ExternalEmailaddress name@domain.xyz

das benötigte Userobjekt hergestellt werden.

 

Danach ist es noch erforderlich das Benutzerobjekt im AD von "Mail-User" noch manuell umzuändern auf den Typ RemoteMailbox

Wir müssen dazu den Wert für das AD-Attribut msExchRecipientTypeDetails von 128 auf 4 ändern:

 

Auch die Werte für msExchRecipientDisplayType und msExchRecipientTypeDetails sollten angepasst werden.

 

 

Am einfachsten lässt sich das Ganze mittels 3 Powershell-Befehlen erledigen:

Set-ADUser Username –Replace @{msExchRecipientDisplayType = “-2147483642”}

Set-ADUser Username –Replace @{msExchRecipientTypeDetails = “2147483648”}

Set-ADUser Username –Replace @{msExchRemoteRecipientType = “4”}

 

Damit die nun erzeugte Remote-Mailbox jetzt auch noch die Verbindung zu seinem Pendant im O365 hat, muß man noch die ExchangeGUID dafür setzen:

Zuerst muß man die GUID herausfinden. Dazu muß man sich mittels (normaler) Powershell (nicht die Exchange Management Shell) zur Exchange Online Powershell verbinden.

Mittels dem Befehl:

Get-Mailbox <alias of mailbox to move> | Format-List ExchangeGUID

bekommt man die ExchangeGUID.

Diese dann kopieren und in der lokalen Exchange Management Shell den Befehl 

Set-RemoteMailbox <MailboxName> -ExchangeGUID <GUID>

absetzen.

 

Danach kann ein normaler Moverequest von Exchange Online nach OnPremise gestartet werden.

Ausführlichere Informationen kann man auch hier finden:

http://www.msexchange.org/articles-tutorials/office-365/exchange-online/match-office-365-mailbox-new-premises-user-hybrid-deployment.html



 



SMTP-Empfang/Versand per Telnet überprüfen

Wenn es zu Empfangsproblemen auf einem Exchange-Server kommt oder auch an bestimmte Server nicht geschickt werden kann, sollte eines der ersten Dinge die überprüft werden sein, ob der Empfänger-Server überhaupt entsprechend antwortet.

 

Was wir dazu benötigen:

1. Telnet-Client
2. Absender u. Empfängeradresse
3. FQDN der zu überprüfenden SMTP-Server
   mittels nslookup kann dies ganz einfach herausgefunden werden:
   zb:

C:\>nslookup

Standardserver:  vieintdc002.internal.network
Address:  10.184.50.2
> set type=mx
> macho.solutions
Server:  vieintdc002.internal.network
Address:  10.184.50.2
Nicht autorisierende Antwort:
macho.solutions MX preference = 10, mail exchanger = macho-solutions.mail.protection.outlook.com

Wie in der Rückantwort ersichtlich ist der Empfänger-Server:
          macho-solutions.mail.protection.outlook.com

 

Folgende Commands kann man absetzen:

Die Gelb-Markierten Passagen sind die erforderlichen Eingaben die man machen muß. Entsprechende Adressen u. Domänen muß man entsprechend anpassen.

 

Telnet FQDN.Zielserver.com 25

Dadurch wird die Verbindung mit dem Zielsystem über den Standard-SMTP-Port 25 hergestellt.

220 AM1FFO11FD029.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready

 at Wed, 11 May 2016 14:22:37 +0000
EHLO AbsenderDomain.com
250-AM1FFO11FD029.mail.protection.outlook.com Hello [xxx.xxx.xxx.xxx]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250 CHUNKING
MAIL FROM:absenderadresse@domain.com
250 2.1.0 Sender OK
RCPT TO:Empfängeradresse@zieldomain.com
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Testmail

Das ist ein Testmail von Telnet

.

250 2.6.0 <5c2fa5c5-18c0-4640-81c5-ce69364d1c85@AM1FFO11FD029.protection.gbl> [InternalId=40072044877570, Hostname=DB5PR06MB1317.eurprd06.prod.outlook.com] 6235 bytes in 1:00.559, 0.101 KB/sec Queued mail for delivery

quit

221 2.0.0 Service closing transmission channel

Connection to host lost.

Wir überprüfen ob das Mail angekommen ist und siehe da: Das Testmail ist im Posteingang:

Selbstverständlich ist dies auch eine gute Methode um seinen eigenen Exchange-Server zu überprüfen. Man sollte hier jedoch auch beachten, dass - abhängig von der Messaging Infrastruktur - natürlich noch andere Komponenten wie Spamfilter, Firewall etc.. in das Troubleshooting miteinbezogen werden sollten.