Exchange 2019: Die Basiskonfiguration

Nach einem kleinen Howto zur Exchange 2019 Installation folgt nun eine Anleitung zur Erstkonfiguration. Die Basiskonfiguration ist nahezu identisch mit der Konfiguration eines Exchange 2016 Servers. Wer also schon mit Exchange 2013/2016 gearbeitet hat, findet sich hier schnell zurecht.

Wenn Exchange 2019 auf Server 2019 Core installiert wurde, können die hier beschriebenen Schritte der in der Exchange Management Shell direkt auf dem Exchange Server ausgeführt werden. Die Exchange Management Shell lässt sich auf Server Core mit dem Befehl “LaunchEMS” starten.

Für dieses HowTo wurde Exchange 2019 auf einem Windows Server 2019 mit grafischer Benutzeroberfläche installiert, dieses Howto zur Basiskonfiguration gilt aber genauso für eine Installation auf Server Core.

Nach der Installation von Exchange habe ich es mir angewöhnt zuerst die Datenbank umzubenennen und an ihren Bestimmungsort zu verschieben, dies geschieht via Shell mit den folgenden Befehlen:

Get-MailboxDatabase -Server LABEX1 | Set-MailboxDatabase -Name MBXDB01
Move-DatabasePath MBXDB01 -EdbFilePath c:\MBXDB01\MBXDB01.edb -LogFolderPath c:\MBXDB01

Exchange 2019: Die Basiskonfiguration

Jetzt können die Domänen angegeben werden, für die Exchange zuständig ist. Als akzeptierte Domänen werden alle Domänen angegeben, über die zukünftig E-Mails empfangen oder versendet werden sollen. Für dieses Beispiel habe ich nur die Domain “frankysweb.de” hinzugefügt:

Exchange 2019: Die Basiskonfiguration

Damit Benutzer automatisch eine entsprechende E-Mail Adresse erhalten, kann eine E-Mail Adressrichtlinie konfiguriert werden. Die Adressrichtlinie kann nach den Vorgaben des Unternehmens erzeugt werden. Für dieses Beispiel habe ich den Alias (entspricht dem Benutzernamen) verwendet:

Exchange 2019: Die Basiskonfiguration

Nachdem die Adressrichtlinie erstellt wurde, muss die neue Richtlinie noch angewendet werden:

Exchange 2019: Die Basiskonfiguration

Damit E-Mails ins Internet verschickt werden können, wird ein Sendeconnector benötigt. Es muss mindestens einen Sendeconnector mit dem Adressraum “*” geben, über diesen Connector werden alle Mails versendet, für die Exchange nicht selbst zuständig ist. Für dieses Beispiel lege ich den Sendeconnector “Route-to-Internet” an:

Exchange 2019: Die Basiskonfiguration

Je nach Umgebung muss der Weg ausgewählt werden, wie Exchange die Mails weiterleiten soll. Dies kann entweder anhand der MX Records der Domänen erfolgen, oder über einen Smarthost (Provider, SPAMFilter, etc):

Exchange 2019: Die Basiskonfiguration

Hier wird nun der Adressraum des Connectors angegeben. Da dieser Connector alle Mails für die Exchange nicht selbst zuständig ist an einen Smarthost schicken soll, wird hier der Adressraum “*” angegeben:

Exchange 2019: Die Basiskonfiguration

Im letzten Schritt wird nun noch der (oder die) Exchange Server eingetragen, welche den Connector benutzen:

Exchange 2019: Die Basiskonfiguration

Der Sendeconnector ist nun angelegt. Zum Schluss müssen noch einmal die Eigenschaften des Connectors geöffnet werden.In den Eigenschaften des Sendeconnectors kann jetzt noch der HELO / EHLO Hostname konfiguriert werden:

Exchange 2019: Die Basiskonfiguration

Zu guter Letzt folgt noch die Konfiguration der virtuellen Verzeichnisse. Hier werden die URLs festgelegt die von den Clients benutzt werden. Die festgelegten URLs werden auch via Autodiscover direkt an die Clients verteilt. Die virtuellen Verzeichnisse enthalten also die URLs, die von den Clients / Benutzern später für den Zugriff auf Exchange benutzt werden. Alle konfigurierten Hostnamen müssen auch auf dem Zertifikat vorhanden sein, da es sonst zu Zertifikatswarnungen kommt.

Damit alle URLs in einem Schritt identisch konfiguriert werden können, kann das folgende kleine Script benutzt werden. Im Script müssen nur die ersten 4 Zeilen an die eigene Umgebung angepasst werden. Die Empfehlung ist internen ($internalhostname) und externen Hostnamen ($externalhostname) gleich zu lassen.

Den Autodiscover Hostname ($autodiscoverhostname) empfehle ich auf autodiscover.domain.tld zu belassen.

Es würde allerdings auch funktionieren, alle 3 Namen auf dem gleichen Hostname zu konfigurieren. In diesem Fall muss es der Hoster der Domain aber erlauben, dass DNS SRV Einträge gesetzt werden können, dies ist leider nicht immer der Fall.

Hinweis: Alle angegebenen Namen müssen auch für das Zertifikat konfiguriert werden.

Das folgende Script kann nach dem Ändern der ersten 4 Zeilen in der Exchange Management Shell ausgeführt werden:

$servername = "LABEX1"
$internalhostname = "outlook.frankysweblab.de"
$externalhostname = "outlook.frankysweblab.de"
$autodiscoverhostname = "autodiscover.frankysweblab.de"
$owainturl = "https://" + "$internalhostname" + "/owa"
$owaexturl = "https://" + "$externalhostname" + "/owa"
$ecpinturl = "https://" + "$internalhostname" + "/ecp"
$ecpexturl = "https://" + "$externalhostname" + "/ecp"
$ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx"
$ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx"
$easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync"
$easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync"
$oabinturl = "https://" + "$internalhostname" + "/OAB"
$oabexturl = "https://" + "$externalhostname" + "/OAB"
$mapiinturl = "https://" + "$internalhostname" + "/mapi"
$mapiexturl = "https://" + "$externalhostname" + "/mapi"
$aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml"
Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl -Confirm:$false
Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl -Confirm:$false
Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl -Confirm:$false
Get-ActiveSyncVirtualDirectory -Server $servername | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl -Confirm:$false
Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl -Confirm:$false
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl -Confirm:$false
Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'  -Confirm:$false
Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri -Confirm:$false
Get-OwaVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-EcpVirtualDirectory -server $servername | fl server,externalurl,internalurl
Get-WebServicesVirtualDirectory -server $servername | fl server,externalurl,internalurl
Get-ActiveSyncVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-OabVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-MapiVirtualDirectory -Server $servername | fl server,externalurl,internalurl
Get-OutlookAnywhere -Server $servername | fl servername,ExternalHostname,InternalHostname
Get-ClientAccessService $servername | fl name,AutoDiscoverServiceInternalUri

Das Script kann entweder in eine PS1 Datei kopiert werden, oder direkt auf der EMS ausgeführt werden:

Exchange 2019: Die Basiskonfiguration

Das oben angegebene Script konfiguriert alle virtuellen Verzeichnisse gemäß der Vorgabe. Bei Bedarf lassen sich jetzt die Einstellungen anpassen:

Exchange 2019: Die Basiskonfiguration

Jetzt muss nur noch das Zertifikat konfiguriert werden. Das Zertifikat wird genauso wie bei Exchange 2013/2016 erstellt. Der Zertifikat muss gemäß dieses Beispiels die Namen “outlook.frankysweb.de” und “autodiscover.frankysweb.de” enthalten. Der Vorgang ist hier ausführlich beschrieben:

Für die Exchange 2019 RTM Version ist außerdem noch dieser Artikel zu beachten:

Für das Thema Exchange Autodiscover habe ich hier ein Whitepaper veröffentlicht, welches auch für Exchange 2019 gilt:

27 Kommentare zu “Exchange 2019: Die Basiskonfiguration”

  1. Das Skript müsste zu einem Fehler führen, da es keinen ClienAccessServer mehr gibt, sondern ClientAccessService, außer MS hat das cmdlet reaktiviert.

    1. Hallo Sebastian,
      vielen Dank für den Hinweis, ich habe es gerade korrigiert (Das CMDLet get-clientaccessserver gibt es noch, warnt aber schon seit Exchange 2016, dass es entfernt wird).
      Das Schöne ist, dass auch noch die alten Scripte noch funktionieren, aber du hast natürlich Recht, ich hab es vergessen zu ändern :-)
      Gruß,
      Frank

  2. Damit man z.B. ein öffentliches Zertifikat, was man extern nutzt auch intern direkt nutzen kann und somit alle Browser, besonders Firefox, kein Zertifikatsfehler melden.

  3. Guten Abend zusammen,
    versuche gerade etwas warm zu werden mit Thema „Server 2019 Core & Exchange Server 2019 Core“ aber bis dato verlief auch alles nach Plan :)

    – Installation Server 2019 Core
    – Installation Exchange 2019 Core

    Alles tutti bis ich „LaunchEMS“ direkt nach der Installation starten wollte :( Zur Zeit kämpfe ich mit dieser Fehlermeldung und die Möglichkeit an dieses Problem ranzugehen beschreibt google.de ^^ vielseitig.

    AUSFÜHRLICH: Verbindung mit SRV03-EX.ad.lohnsteuerhilfe-niedersachsen.de wird hergestellt.
    New-PSSession : [srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de] Beim Verbinden mit dem Remoteserver
    „srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de“ ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung
    nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt
    oder ist ungültig. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
    gTransportException
    + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

    Ich würde mich freuen wenn mir jemand eine Stups :) oder Hinweis geben kann wie ich dieses Problem angehen kann.

    Im Vorfeld möchte ich allen danken und wünsche euch ein schönes Wochenende.

    Mit freundlichen Grüßen
    Philipp Blaschke

    1. Kurzes Feedback zum WINRM Problem :)

      WINRM QUICKCONFIG
      Der WinRM-Dienst wird auf diesem Computer bereits ausgeführt.
      WinRM ist bereits für die Remoteverwaltung auf diesem Computer eingerichtet.

      Hatte dann noch mal TrustedHosts angeschaut und im Vorfeld mit einem Powershell-Befehl die TrustedHost auf „*“ gesetzt.

      Get-Item WSMan:\localhost\Client\TrustedHosts |fl Name, Value
      Name : TrustedHosts
      Value : *

      Die Fehlermeldung beim Aufruf von „LaunchEMS“ besteht trotzdem noch.
      Aufgefallen ist mir der Fehler erstmal bei hinzufügen des Servers in das „Windows Admin Center“ zu meiner Schande muss ich gestehen habe ich mir dabei erstmal nix gedacht und weitergemacht :(

      1. So habe noch mal ein wenig gelesen und probiert aber bis dato leider kein Erfolg!

        VOR DEN ÄNDERUNGEN:
        Get-PowerShellVirtualDirectory|fl
        RequireSSL : True
        CertificateAuthentication : False
        VirtualDirectoryType : PowerShell
        Name : PowerShell (Default Web Site)
        InternalAuthenticationMethods : {}
        ExternalAuthenticationMethods : {}

        NACH DEN ÄNDERUNGEN:
        Get-PowerShellVirtualDirectory|fl
        RequireSSL : True
        CertificateAuthentication : False
        VirtualDirectoryType : PowerShell
        Name : PowerShell (Default Web Site)
        InternalAuthenticationMethods : {Basic}
        ExternalAuthenticationMethods : {Basic}

        Nach den Änderungen hat sich auch der ursprüngliche Fehler verändert beim Aufruf „LaunchEMS“. Bekomme nun diesen fehler angezeigt:

        AUSFÜHRLICH: Verbindung mit SRV03-EX.ad.lohnsteuerhilfe-niedersachsen.de wird hergestellt.
        New-PSSession : [srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de] Beim Verbinden mit dem Remoteserver
        „srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de“ ist folgender Fehler aufgetreten: Der WinRM-Client hat einen
        HTTP-Statuscode „403“ vom Remote-WS-Verwaltungsdienst erhalten. Weitere Informationen finden Sie im Hilfethema
        „about_Remote_Troubleshooting“.
        In Zeile:1 Zeichen:1
        + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
        gTransportException
        + FullyQualifiedErrorId : -2144108273,PSSessionOpenFailed

        Auch hierzu gibt es viele, viele Anregungen und doch hat mich irgendwie noch keine ans Ziel gebracht. Hatte auch schon den Versuch gewagt diese Option auf „False“ zu stellen:

        CertificateAuthentication : True

        Auch kein Erfolg!

        1. Update:
          winrm enumerate winrm/config/Listener
          Listener
          Address = *
          Transport = HTTP
          Port = 5985
          Hostname
          Enabled = true
          URLPrefix = wsman
          CertificateThumbprint
          ListeningOn = 127.0.0.1, 192.168.179.5, ::1, 2a02:8108:8d40:1010:8010:64e9:91e2:e99f, fe80::8010:64e9:91e2:e99f%5

  4. Guten Abend zusammen,
    bezugnehmend auf diesen Artikel vom 11. Januar 2019 um 19:29 möchte ich mitteilen, dass ich alles platt gemacht habe und neu aufgesetzt habe inkl. AD.
    Bin aber nun wieder beim selbigen Punkt angelangt wie vorher:

    New-PSSession : [srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de] Beim Verbinden mit dem Remoteserver
    „srv03-ex.ad.lohnsteuerhilfe-niedersachsen.de“ ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig

  5. Ich habe einen Ex2016 am laufen und habe im 2.ten Versuch den EX2019 mal aufgesetzt.
    (Beim ersten Versuch habe ich es irgendwie hinbekommen nicht mehr auf die ecp Seite zu kommen, nachdem ich ein Zertifikat installiert habe).
    Nun ja …
    Also alles nach Anleitung hier nachgespielt (danke, war sehr gut hier beschrieben) und dann kommt plötzlich bei der /owa Eingabe (intern und extern):

    :-(
    Da hat etwas nicht geklappt.
    Beim Abrufen Ihres Postfachs besteht zurzeit ein Problem. Aktualisieren Sie die Seite, oder versuchen Sie es später noch mal.
    X-ClientId: 842C70FBC18B4479B01846F1BCE5B4F9
    request-id ce97c78d-5d43-4c23-a814-a37701514ceb
    X-OWA-Error Microsoft.Exchange.Data.Storage.ConnectionFailedTransientException
    X-OWA-Version 15.2.221.12
    X-FEServer MAIL
    X-BEServer MAIL
    Date:22.03.2019 08:00:15
    InnerException: Microsoft.Mapi.MapiExceptionNetworkError
    ————–
    Gleich mal gegoogelt usw. nix gefunden.
    Nach ca. 5 min aus versehen nochmal probiert und es klappt …
    Da war der Server wohl noch beschäftigt? … Hauptsache es klappt.
    Nunja, die E-Mail die über OWA testweise rausgehen soll steckt noch in „Entwürfe“ fest.
    Dürfte doch eigentlich nicht an den noch fehlenden Zertifikaten liegen?
    (der Sendeconnector „Route-to-Internet“ gibt über den MX ins Internet ab … ) … schauen wir mal …

    1. … wie üblich DNS Problem (im Exchange 2019 nur den DNS Server des DCs eintragen, dann klappts) … hatte hier 2 DNS drin stehen …

  6. Hallo,

    erstmal vielen Dank für diese Anleitung (und die vielen anderen)!

    Kann man den Zertifikatsassistent auch für den 2019er Exchange benutzen bzw. gibt es eine angepasste Version?

  7. Hallo Zusammen,
    ich habe bei einer komplett neuen Umgebung (Server 19 mit neuem AD, eigener Exchangeserver 2019) das Problem, dass, wenn ich z.B. Postfächer (bestehende User im AD) beim Speichern den Fehler:

    Bei diesem Fehler ist kein Wiederholungsversuch möglich. Zusätzliche Informationen: Die Zugriffsrechte reichen für diesen Vorgang nicht aus. Active Directory-Antwort: 00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

    erhalte. Die Rechtevergabe wie in Google oft zu finden (AD, erweiterte Ansicht, Exchange Trusted…) hab ich schon gemacht (OU-Ebene). Wenn ich dann aber bei den Benutzern in Sicherheit nachsehe … „Unbekanntes Konto …und die UserSID“…

    Ich weiss mir einfach nicht mehr zu helfen !!!!

    Alle Dienste, auch die EX-AD-Topo… laufen… Kann mir hier jemand weiterhelfen ??

    Danke Euch !
    Tom

  8. Noch ein Nachtrag … so wie es aussieht betrifft das nur die bestehenden AD-User
    Neue Verteilergruppen, neue User über das ECP angelegt – klappt !!!

    Nochmals DANKE
    Tom

  9. Hallo Franky,

    vielen dank für deinen Hilfreichen Beitrag.
    Hat bei mir alles super funktioniert bis auf zwei Sachen.
    Trotz nicht angegebener ExternalUrl in den virtuellen Verzeichnissen von ECP und Powershell komme ich von außen per https://domain.de/ecp und https://domain.de/powershell auf die Verzeichnisse dies sollte so nicht sein.
    Zudem ist es mir nicht möglich per Outlook Mobil auf den Exchange zu zugreifen.

    Hättest du, da vielleicht eine Idee?

    Gruß Sascha

      1. Hallo Frank,

        vielen Dank für deine rasche Antwort.
        Das hilft mir sehr beim Problem mit EAC und RPS, aber auf die Verbindung per Handy hat das wohl laut deiner Ausführung keine Auswirkung… Hast du dazu vielleicht auch noch einen Tip? Ich nutze Exchange 2019 Standard.

        Gruß Sascha

  10. Hallo Franky,
    Ich habe eine neue Domäne mit 2 2019 Server aufgestellt. Nun habe ich die Exchangeinstallation nach deiner Vorlage vollzogen und er läuft im Test (ohne Anbindung ins Internet) erstmal sauber. OWA funktioniert super.
    Leider funktioniert die Outlook Anbindung nicht (2019) Outlook scheint den Exchange nicht zu finden.
    DNS Technisch ist im Netz alles Ok.
    Ich steh ein bischen Ratlos da, da ich auch auf die Schnelle im Internet dazu keinen Hinweise gefunden habe.
    Hast du einen Tip?

    MfG
    Gero

    1. @ Gero :
      Gleiches Problem,alles rennt, bis auf Outlook und gleiche Ahnungslosigkeit…..Hast du einen Ansatz gefunden ?
      Danke und Grüße
      Sunny

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.