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
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:
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:
Nachdem die Adressrichtlinie erstellt wurde, muss die neue Richtlinie noch angewendet werden:
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:
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):
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:
Im letzten Schritt wird nun noch der (oder die) Exchange Server eingetragen, welche den Connector benutzen:
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:
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:
Das oben angegebene Script konfiguriert alle virtuellen Verzeichnisse gemäß der Vorgabe. Bei Bedarf lassen sich jetzt die Einstellungen anpassen:
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:
- Exchange 2013: Zertifikatsanforderung für öffentliche CA erstellen
- Exchange 2013: SAN Zertifikat und interne Zertifizierungsstelle (CA)
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:
Hallo zusammen,
ich habe schon oft gesucht, aber nicht die passende Antwort gefunden.
Es geht um das Zertifikat. Extern geht alles prima, intern kommt bei Outlook die Warnung, dass der Name des Zertifikates nicht zum Servernamen passt. Auf der entsprechenden Meldung steht oben der interne Mailservername wie exchange.domain.local, das Zertifikat ist aber auf exchange.domain.de ausgestellt. Habe ich das einen Gedankenfehler: Müsste sich nicht einfach der IIS auf dem Exchange als exchange.domain.de melden und alles wäre super?
Die entsprechenden DNS-Einträge sind erstellt und funktionieren auch. Mir fällt sonst nicht mehr viel ein, was dem System zum Glück (ohne Meldung) fehlen könnte.
Solange exchange.domain.local nicht im Zertifikat ist, bekommst immer einen Zertifikatsfehler.
Im internen DNS dein exchange.domain.de per A-Record auf die interne IP des Exchange-Servers verweisen lassen und nur noch über die exchange.domain.de darauf zugreifen. Wenn intern auf exchange.domain.de gehst, bleibst du somit auch intern. Zertifikat ist aber gültig, da für exchange.domain.de ausgestellt ist.
Hallo Frank.
Danke für Deine vielen nützlichen Beiträge und Erläuterungen.
Bei der Konfiguration von Exchange Server 2019 zusammen mit dem MS Server 2019 ist mir aufgefallen, hier mit der altbekannten Trennung in .local und .de Domänen und AD Bezeichnungen, dass es unter Windows Server 2019 es keine direkte Option zum Bearbeiten der Namensschemainerweiterungen über die Active Directory-Domänen- und -Vertrauensstellungsverwaltung mehr gibt.
Da die versendeten Emails jedoch trotz korrekter Einstellungen im DNS, Empfangsdomänen, Empfänger-Emails und Sendeconnectoren (FQDN) aufgrund der AD-Konfiguration die .local im Header trägt, kommt es zu Problemen mit der DNS query der empfangenden Server, die die Fehlermeldung ‚451 4.4.0 DNS query failed:‘ zurückgeben.
Bisher habe ich dafür noch keine Lösung gefunden, ausser einen SmartHost zu verwenden.
Nicht zuletzt noch ein politisches Statement: Ich werden den Eindruck nicht los, dass Microsoft die Konfiguration von einer Exchange-Version zur nächsten immer umständlicher gestaltet, um die Leute schließendlich in die Cloud zu treiben.
Danke für Eure Aufmerksamkeit.
Ich versuche seit 2 Wochen mit dem neuen EX 2019 auf Server 2019 E-Mail´s über einen erstellten Sendeconnector zu versenden. Läuft einfach nicht. In den Log-Files sind keine Einträge obgleich diese aktiviert sind. Könnten Sie mir helfen wo der Fehler liegt?
AddressSpaces : {SMTP:*;1}
AuthenticationCredential : System.Management.Automation.PSCredential
CloudServicesMailEnabled : False
Comment :
ConnectedDomains : {}
ConnectionInactivityTimeOut : 00:10:00
ConnectorType : Default
DNSRoutingEnabled : False
DomainSecureEnabled : False
Enabled : True
ErrorPolicies : Default
ForceHELO : False
Fqdn :
FrontendProxyEnabled : False
HomeMTA : Microsoft MTA
HomeMtaServerId : SERVER
Identity : T-Online
IgnoreSTARTTLS : False
IsScopedConnector : False
IsSmtpConnector : True
MaxMessageSize : 35 MB (36,700,160 bytes)
Name : T-Online
Port : 25
ProtocolLoggingLevel : Verbose
Region : NotSpecified
RequireOorg : False
RequireTLS : False
SmartHostAuthMechanism : BasicAuthRequireTLS
SmartHosts : {securesmtprelay.t-online.de}
SmartHostsString : securesmtprelay.t-online.de
SmtpMaxMessagesPerConnection : 20
SourceIPAddress : 0.0.0.0
SourceRoutingGroup : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers : {SERVER}
TlsAuthLevel :
TlsCertificateName :
TlsDomain :
UseExternalDNSServersEnabled : False
Hallo Franky,
vielen Dank für die Super Anleitungen. Ich habe jedoch ein Problem nach der Einrichtung mit Outlook und Autodiscover.
Mein Setup ist ein Windows Server 2022 mit Exchange 2019 und einer Sophos XGS die ebenfalls nach deiner Anleitung konfiguriert ist.
Die Verbindung mit iPhone oder OWA funktionieren und auch Emails gehen rein und raus. Lediglich beim Setup (Systemsteruerung -> Mail -> Profil hinzufügen -> manuelles Setup) von Outlook kommt die Meldung, dass der EAS Server nicht gefunden werden kann. Das komische ist, dass wenn ich diese Fenster offen lasse und Outlook starte, funktioniert Outlook mit dem Konto bis ich das Fenster mit dem Setup schließe, da das Profil nicht gespeichert werden kann.
Das Microsoft-Remoteverbindungsuntersuchung Tool funktioniert erfolgreich beim Exchange ActiveSync Test bis auf die Warnung: Die Zertifikatketten werden auf Kompatibilitätsprobleme mit Windows-Versionen analysiert und das Autodiscover nicht funktioniert.
Würde mich freuen, wenn du oder jemand anderes eine Idee hat, woran es liegen könnte.
Viele Grüße
Thomas
Hallo,
tolle Anleitung!
Du machst ja die interne und externe URL gleich, was mir auch einleuchtet, weil das dann einfacher ist und überall gleich heisst.
Hier basiert das AD aber nicht auf example.org, sondern auf sowas wie kürzel.example.org, d.h. im DNS verwalte ich nur diese Subdomain. example.org ist auf externem DNS gehostet.
Schön wäre ja, wenn sich dann mail.example.org intern auf eine interne IP und von extern auf die Public-IP des Servers (bzw. Routers) auflöst.
Wie kann ich das konfigurieren, oder macht das wenig Sinn?
Und wenn man intern und extern untschiedlich belässt, wie kann ich mein Zertifikat für die öffentliche Domäne example.org nur für die externen URLs einbinden, ohne das für intern zu ändern (ist insbesondere ungünstig, da was zu ändern, wegen des OWA/ECP HMAC Fehlers, sobald man die Zertifikate anfasst.)
Grüße,
Thomas.
Hallo Thomas,
du kannst auch in deinem Fall Split DNS nutzen. Dazu musst du am internen DNS nur zwei DNS Zonen (nicht Records) mit dem Namen mail.example.org / autodiscover.example.org anlegen. Innerhalb der Zonen legst du dann einen HOST-A Record ohne Namen, sondern nur mit der IP des Exchange Servers an. Somit wird http://www.example.org weiterhin per Forward an die externen DNS Server weitergeleitet, mail.example.org löst dann aber die interne IP auf.
Beste Grüße,
Frank
Guten Tag
Ich stehe momentan etwas auf dem Schlauch…
Ich muss einen Exchange 2019 Standard aufsetzen mit unterschiedlichen Domains.
Von Extern kommen 3 verschiedene Domains (alle im Besitz des Kunden) soweit kein Problem.
Jedoch ist die interne Domane kunde.ch (das ist die AD- Domäne) nicht im Besitz des Kunden, und kann somit nicht in ein öffentliches Zertifikat eingebunden werden (Problem der Validierung).
Wenn ich aber den obigen Artikel richtig verstehe, muss alles via https:// adressiert angesprochen werden, wozu auch ein Zertifikat benötigt wird.
Soweit ich weiss, kann ich doch bei Exchange nur ein Zertifikat für alles hinterlegen -> oder bin ich da falsch?
Wenn ich mit einer eigenen Zertifizierungsstelle das Zertifikat mache, ist die Sache zwar Intern gelöst aber nicht von Extern (OWA, Mobile usw.).
Hat mir Jemand bitte eine verständliche Anleitung, wie dies gelöst werden muss?
Vielen Dank im Voraus
Hallo Franky
Ich habe einen Exchange mit deiner Anleitung aufgesetzt. Alles Top alles gut gelaufen.
Soweit auch alles gut. Der Exchange Server dient ausschließlich dem Abruf und versenden von Emails und der Mailverteilung in der Firma. Er steht nicht öffentlich im WEB.
Die Virtuellen Ordner habe ich alle auf remote.office.firma.de (so heißt auch der MX)
Die Adressräume sind natürlich unterschiedlich, Intern heißt der Server Exchange.firma.local
Extern lautet die Domain Firma.de
Am Woe habe ich den neuen Exchange testweise in Betrieb genommen um zu schauen ob es funktioniert. Erstmal nur per OWA aus dem Internen Netz heraus.
Emails kommen rein und Emails gehen raus. Aber ich habe festgestellt das versendette Emails im Spamordner des Empfängers landen. Woran liegt das? Schließe ich den alten Exchange (SBS 2011) wieder an, dann geht alles wie gewohnt.
Wir versenden über einen Smarthost, da unser Provider / Hoster das nicht anders zulässt.
Ich würde mich sehr ehr freuen, wenn Sie mir einen Tip geben würden woran das liegen kann.
Die Anbindung interner Clients (Outlook 2019) werde ich erst testen wenn der Exchange seine Funktion fehlerfrei bereitstellt.
Mfg Gero
Konntest du das Problem schon Lösung? Wenn nein, was ist der Grund für die SPAM-Filterung (ggf. steht etwas im E-Mail-Header)?
Beste Grüße
Oliver
Hallo aus München,
erstmal einen herzlichen Dank für die ausführliche Beschreibung zum Installieren eines Exchange 2019 und dieser Basiskonfiguration. Davor hatte ich eine Anleitung „zum perfekten Domänencontroller“ befolgt und somit funktioniert nun (sicher bald, gerade erstelle ich noch das Zertifikat) alles wie gewünscht.
Was bei mir (Windows Server 2019 mit GUI, dort DC und Hyper-V, als einen virtuellen Server der Exchange Server 2019) beim Aufrufen des Exchange Admin-Center geschah, ist ein Zertifikatsfehler. Diesen konnte ich mir nicht erklären, da auch die Forward und Backward Lookup-Zonen, sowie die PTR-Records im DNS am DC existierten.
Die Lösung war sehr simpel, daher möchte ich sie hier teilen, falls jemand auf ein ähnliches Problem stoßen sollte: Ich musste einfach nur am DC den DNS-Service einmal neustarten – und schon konnte ich mich im Exchange Server 2019 problemlos am Exchange Admin Center im Browser anmelden, ganz ohne Zertifikatswarnung. Somit konnte ich dann dieser Anleitung weiter folgen.
Vielen lieben Dank,
Alexander
Guten Abend,
ich habe die Testinstallation entsprechend Anleitung aufgebaut und konfiguriert.
Mit Server 2019 Standard und Exchange 2019 Upd4. Es hat alles wie beschrieben bestens geklappt. Nur kann ich jetzt die Konfiguration nicht starten, weil wenn ich auf die ecp Administrations – Seite zugreifen will, immer die Fehlermeldung „Service Unavailable“ (HTTP Error 503) erscheint und fertig.
Komme nicht weiter. Alles Exchange Services sind gestartet.
Was kann ich tun?
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
@ Gero :
Gleiches Problem,alles rennt, bis auf Outlook und gleiche Ahnungslosigkeit…..Hast du einen Ansatz gefunden ?
Danke und Grüße
Sunny
Ich habe meine Installation und Einrichtung noch vor mir aber einige Fehler bei 2016 konnte ich beheben, indem ich einfach in der Netzwerkkarte IPv6 deaktiviert habe. Gegebenenfalls auf dem Server & Client.
Vielleicht wäre das noch eine Möglichkeit?
mfg.
Thomas
Hallo Thomas,
IPv6 muss auf dem Exchange Server aktiviert bleiben.
Gruß,
Frank
Hallo zusammen,
hatte wohl das gleiche Problem. Outlook 2019 hat beim Start gemeldet: „Microsoft Outlook kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie ihre Verbindung mit Microsoft Exchange mit Ihrem aktuellen Profil herstellen.“
Nach ewigem testen und recherchieren habe ich die Lösung gefunden. Es lag wohl an der Testumgebung bzw. dem dort nicht erreichbaren Gateway. Nachdem ich als Gateway einfach die IP des Exchange-Servers angegeben habe (Es muss wohl einfach ein Gateway erreichbar sein.) hat alles funktioniert.
Hatte auch zuerst alles in Richtung Autodiscovery / DNS abgeklopft. Aber das war wohl die Falsche Fährte…
Gruß
Dominik
Hallo Dominik,
ich habe leider genau das selbe Problem und suche schon seit vielen Tagen. Ich bin auch schon die DNS- und Autodiscoverschiene erfolglos gefahren. Wie meinst Du das mit dem Gateway ? Wo muss die IP-Adresse des Exchange als Gateway eingestellt sein ? Würde mich sehr über Deine oder die Antwort von jemand anders freuen. Bin schon kurz davor, den DC und den Exchange neu aufzusetzen, aber ich glaube noch daran, dass das noch mit einer einfachen Einstellung gehen sollte. Ich habe schon 4 Exchange 2019 erfolgreich eingerichtet, aber das hatte ich noch nie.
Viele Grüße
Andreas
Mein Problem: Beim Ersteinrichten von Outlook an dem Exchange 2019 kommt der Fehler: Das Outlook-Fenster kann nicht geöffnet werden. Diese Ordnergruppe kann nicht geöffnet werden. Bevor Sie Ihre Ordner mit Ihrer Outlook-Datendatei (.ost) synchronisieren können, müssen Sie ihre Verbindung mit Microsoft Exchange mit Ihrem aktuellen Profil herstellen.“
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
Hallo Sascha,
siehe hier:
https://www.frankysweb.de/exchange-2019-client-access-rules/
Gruß,
Frank
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
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
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
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?
Vermutlich war er nicht als Domänen Admin, sondern als lokaler Admin angemeldet.
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 …
… wie üblich DNS Problem (im Exchange 2019 nur den DNS Server des DCs eintragen, dann klappts) … hatte hier 2 DNS drin stehen …
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
Guten Abend! Problem fixed :)
was war die Lösung?
Hallo Herr Blaschke,
wie haben Sie das Problem gelöst? – Habe das gleiche.
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
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 :(
Sorry… hab noch etwas vergessen :)
Das Admin Center vom Exchange Server lässt sich fehlerfrei öffnen!!
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!
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
Im Script haben sich ein paar “ “ eingeschlichen. Ich denke dir haben dort nichts zu suchen ^^
Hallo Dave,
danke für den Hinweis. Habe es korrigiert.
Gruß,
Frank
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.
Warum sollte man die URL für das Autodiscover virtual Directory ändern wollen?
Das Skript müsste zu einem Fehler führen, da es keinen ClienAccessServer mehr gibt, sondern ClientAccessService, außer MS hat das cmdlet reaktiviert.
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