Hallo zusammen,
ich habe einen Exchange Server 2016 eingerichtet inkl. Zertifikat usw.
Der Exchange Server ist auch gleichzeitig DC.
Ich habe das Problem, dass wenn ich nun Outlook einrichten will, die Windows Sicherheit kommt und nach dem Kennwort fragt. Soweit so gut.
Aber irgendwie funktioniert das Autodiscover nicht.
Im EventMgr habe ich folgende Fehlermeldung:
Das Programm w3wp.exe mit der zugewiesenen Prozess-ID 38876 konnte sich mit dem Zielnamen HTTP/mail.xx.eu nicht lokal authentifizieren. Der verwendete Zielname ist ungültig. Ein Zielname muss sich auf einen der lokalen Computernamen beziehen, z. B. den DNS-Hostnamen.
Laut MS Remote Connectivity Analyzer ist der Exchange ActiveSync.Exchange ActiveSync Test erfolgreich ohne Fehlermeldung.
Ich habe mir Frankys Anleitung angeschaut und mir ist aufgefallen, dass ich im DNS keine Reverse-Lookupzone habe.
Kann mir da jemand weiterhelfen?
Hallo natas,
mal kommentarlos, ob man auf einem DC einen Exchange Server installieren sollte. Die Best Practices sagen da etwas anderes.
Wenn Du eine neue Domäne aufsetzt, muss man auf dem ersten Windows DC die Reverse Zone immer manuell anlegen (was auch immer MS sich dabei gedacht hat). Ins DNS gehen, Reverse Zone rechte Maustaste- -> neue Primäre Zone -> AD integriert-> IP eintragen (revers) und fertig. Sinnvoll noch die PTR Einträge automatisch erstellen und aktualisieren lassen. Danach nochmal probieren.
Du hast ansonsten sicher auch den FQDN (also inkl. Domain) angegeben?
Gruß
Kendo
Die Reverse Zone ist weder für exchange noch fürs ad zwingend notwendig. Ist halt nur bequem. ;)
Hallo natas,
mal kommentarlos, ob man auf einem DC einen Exchange Server installieren sollte. Die Best Practices sagen da etwas anderes.Wenn Du eine neue Domäne aufsetzt, muss man auf dem ersten Windows DC die Reverse Zone immer manuell anlegen (was auch immer MS sich dabei gedacht hat). Ins DNS gehen, Reverse Zone rechte Maustaste- -> neue Primäre Zone -> AD integriert-> IP eintragen (revers) und fertig. Sinnvoll noch die PTR Einträge automatisch erstellen und aktualisieren lassen. Danach nochmal probieren.
Du hast ansonsten sicher auch den FQDN (also inkl. Domain) angegeben?
Gruß
Kendo
Ok,
habe ich so eingerichtet. Der Fehler tritt aber dennoch ab und zu im EventMgr auf.
Wenn ich ein Konto in Outlook einbinden will, kommt halt unzählige Male die Aufforderung den Benutzernamen und PW einzugeben. Wnn ich da auf Abbrechen gehe, geht es gar nicht mehr weiter.
Wo sollte ich den FQDN angeben?
Also ich habe ja die Mailserver-Adresse mail.xx.eu.
Dann noch ein Autodiscover mit mail.xx.eu/autodiscover/autodiscover.xml, was auch von Outlook aufgerufen wird. Jedenfalls wird danach gefragt, ob ich das zulassen möchte.
Dann habe ich auch noch die Adresse Autodiscover.xx.eu.
Beide Adressen sind im DNS und im IIS eingetragen.
Aber der active Sync test hat nix mit Outlook zu tun. Nur mit deinen bisherigen Beschreibungen ist da im Forum nicht viel zu sagen. Versuchst du intern oder extern?
Habe beides versucht. Extern bekomme ich folgende Antwort:
An Exchange ActiveSync-E-Mail-Server anmelden (EAS): Den angegebenen Server wurde nicht gefunden. Der Benutzernamen und/oder Kennwort sind ungültig. Bitte stellen Sie sicher, dass diese Informationen richtig sind.
Und intern ploppt unzählige Male die Aufforderung nach Benutzername und Kennwort auf.
Habe jetzt auch den MS Outlook Verbindungstest gemacht. Auch der funktioniert:
Die Outlook-Verbindung wird getestet.Der Test der Outlook-Verbindung wurde erfolgreich abgeschlossen.
Testschritte
Testschritte
Wie gesagt, mit den paar Infos ist das nicht lösbar. Da müsstest du schon mal verraten, was du konfiguriert hast. ;)
OK, welche Informationen brauchst du denn?
ich habe einen Exchange Server 2016 eingerichtet inkl. Zertifikat usw.
So, das ist alles was du zu deiner konfig im Großen und Ganzen geschrieben hast. :)
hast du scp und URLs (intern und extern) konfiguriert?
Domain mit xx ersetzt.
Also SCP sieht so aus:
RunspaceId : f411cd87-7b39-4f4b-96b8-f3a76c7f18a0
Name : [ServerName]
Fqdn : [ServerName].xx.local
ClientAccessArray :
OutlookAnywhereEnabled : True
AutoDiscoverServiceCN : [ServerName]
AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://autodiscover.xx.eu/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope : {Default-First-Site-Name}
AlternateServiceAccountConfiguration :
IsOutOfService : False
Identity : [ServerName]
IsValid : True
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=[ServerName],CN=Servers,CN=Exchange Administrative Group
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xx,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=xx,DC=local
Guid : 60cc5b22-4fbc-43de-afb6-f5ffe5f287ca
ObjectCategory : xx.local/Configuration/Schema/ms-Exch-Exchange-Server
ObjectClass : {top, server, msExchExchangeServer}
WhenChanged : 08.11.2021 14:22:18
WhenCreated : 27.10.2021 22:51:58
WhenChangedUTC : 08.11.2021 13:22:18
WhenCreatedUTC : 27.10.2021 20:51:58
OrganizationId :
Id : [ServerName]
OriginatingServer : [ServerName].xx.local
ObjectState : Unchanged
autodiscover.xx.eu und mail.xx.eu sind im Zertifikat vorhanden.
Dienst / Protokoll | DNS-Name |
OWA (Interne URL) | https://mail.xx.eu/owa |
OWA (externe URL) | https://mail.xx.eu/owa |
OAB (interne URL) | https://mail.xx.eu/OAB |
OAB (externe URL) | https://mail.xx.eu/OAB |
ActiveSync (interne URL) | https://mail.xx.eu/Microsoft-Server-ActiveSync |
ActiveSync (externe URL) | https://mail.xx.eu/Microsoft-Server-ActiveSync |
MAPI (interne URL) | https://mail.xx.eu/mapi |
MAPI (externe URL) | https://mail.xx.eu/mapi |
EWS (interne URL) | https://mail.xx.eu/EWS/Exchange.asmx |
EWS (externe URL) | https://mail.xx.eu/EWS/Exchange.asmx |
ECP (interne URL) | https://mail.xx.eu/ecp |
ECP (externe URL) | https://mail.xx.eu/ecp |
Outlook Anywhere (Intern) | mail.xx.eu |
Outlook Anywhere (extern) | mail.xx.eu |
Autodiscover (Intern) | https://autodiscover.xx.eu/Autodiscover/Autodiscover.xml |
Ich kann OWA und ECP sowohl über
mail.xx.eu/OWA bzw. autodiscover.xx.eu/OWA
und
mail.xx.eu/ecp bzw. autodiscover.xx.eu/ecp
aufrufen. Also sollte die Konfiguration im IIS auch soweit stimmen.
Habe es gerade nochmal ausprobiert. Wieder ein Fehler im eventmgr
Quelle: LSA(LsaSrv)
Das Programm w3wp.exe mit der zugewiesenen Prozess-ID 43556 konnte sich mit dem Zielnamen HTTP/mail.xx.eu nicht lokal authentifizieren. Der verwendete Zielname ist ungültig. Ein Zielname muss sich auf einen der lokalen Computernamen beziehen, z. B. den DNS-Hostnamen.
Wählen Sie einen anderen Zielnamen.
RunspaceId : 6884c7db-6af4-40a6-9e30-77dcaa3e970e
Source : [Servername].xx.local
ServiceEndpoint : autodiscover.xx.eu
Scenario : AutoDiscoverOutlookProvider
ScenarioDescription : AutoErmittlung: Outlook-Anbieter
Result : Failure
Latency : 22
Error : System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten
SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. --->
System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut
Validierungsverfahren ungültig.
bei System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message,
AsyncProtocolRequest asyncRequest, Exception exception)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext,
ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
callback, Object state)
bei System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
bei System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
bei System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
bei System.Net.ConnectStream.WriteHeaders(Boolean async)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.HttpWebRequest.GetResponse()
bei
Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
Verbose : [2021-11-12 09:16:02Z] 'AutoErmittlung' stellt eine Verbindung mit
'https://autodiscover.xx.eu/Autodiscover/Autodiscover.xml' her.
[2021-11-12 09:16:02Z] Testkonto: xy Kennwort: ******
[2021-11-12 09:16:02Z] Anforderung von AutoErmittlung:
User-Agent: [Servername]/Test-OutlookWebServices/xy@xx.eu
Content-Type: text/xml; charset=utf-8
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAKADk4AAAADw==
Host: autodiscover.xx.eu
Content-Length: 0
[2021-11-12 09:16:02Z] Anforderung von AutoErmittlung:
xy@xx.eu
http://schemas.microsoft.com/exchange/autodiscover/outlook/response
schema/2006a
[2021-11-12 09:16:02Z] Antwort von AutoErmittlung:
System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten
SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. --->
System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut
Validierungsverfahren ungültig.
bei System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message,
AsyncProtocolRequest asyncRequest, Exception exception)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest
asyncRequest)
bei System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer,
AsyncProtocolRequest asyncRequest)
bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext,
ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback
callback, Object state)
bei System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
bei System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
bei System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
bei System.Net.ConnectStream.WriteHeaders(Boolean async)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.HttpWebRequest.GetResponse()
bei
Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
bei Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
MonitoringEventId : 6001
RunspaceId : 6884c7db-6af4-40a6-9e30-77dcaa3e970e
Source : [Servername].xx.local
ServiceEndpoint :
Scenario : ExchangeWebServices
ScenarioDescription : Exchange-Webdienste
Result : Skipped
Latency : 0
Error : Der Test der Exchange-Webdienste wurde aufgrund eines Fehlers beim Schritt der AutoErmittlung
übersprungen.
Verbose :
MonitoringEventId : 5002
RunspaceId : 6884c7db-6af4-40a6-9e30-77dcaa3e970e
Source : [Servername].xx.local
ServiceEndpoint :
Scenario : AvailabilityService
ScenarioDescription : Verfügbarkeitsdienst
Result : Skipped
Latency : 0
Error : Der Test des Verfügbarkeitsdiensts wurde aufgrund eines Fehlers beim Schritt der AutoErmittlung
übersprungen.
Verbose :
MonitoringEventId : 5003
RunspaceId : 6884c7db-6af4-40a6-9e30-77dcaa3e970e
Source : [Servername].xx.local
ServiceEndpoint :
Scenario : OfflineAddressBook
ScenarioDescription : Offlineadressbuch
Result : Skipped
Latency : 0
Error : Der Test des Offlineadressbuchs wurde aufgrund eines Fehlers beim Schritt der AutoErmittlung
übersprungen.
Verbose :
MonitoringEventId : 5004
zum kerberosfehler fehlt dir wohl der passende spn. Dass man einen exchange nicht unbedingt auf einen dc packen sollte, wurde ja schon gesagt.
zum kerberosfehler fehlt dir wohl der passende spn. Dass man einen exchange nicht unbedingt auf einen dc packen sollte, wurde ja schon gesagt.
Habe einen weiteren Fehler gefunden. Kann dieser auch damit zusammenhängen?
Durch die Berechtigungseinstellungen für "Anwendungsspezifisch" wird dem Benutzer "NT-AUTORITÄT\SYSTEM" (SID: S-1-5-18) unter der Adresse "LocalHost (unter Verwendung von LRPC)" keine Berechtigung vom Typ "Lokal Aktivierung" für die COM-Serveranwendung mit der CLSID
{8D8F4F83-3594-4F07-8369-FC3C3CAE4919}
und der APPID
{F72671A9-012C-4725-9D2F-2A4D32D65169}
im Anwendungscontainer "Nicht verfügbar" (SID: Nicht verfügbar) gewährt. Die Sicherheitsberechtigung kann mit dem Verwaltungstool für Komponentendienste geändert werden.
Nein. Nicht jeder Fehler ist dafür verantwortlich. ;) ich vermute, dass es einfacher wäre, wenn du dir jemanden holst, der das troubleshooted und ggf. Weiß was dir fehlt. Das hilft mehr als im Forum so unspezifisch zu fragen. Manchmal sind’s Kleinigkeiten die für jemanden schnell erledigt sind, wenn man sich auskennt.
Hi, ja das macht Sinn. Ich möchte es aber dennoch selbst versuchen. So kann ich wenigstens etwas davon lernen.
Also intern kann ich jetzt das Outlook-Profil aufrufen und ich konnte den Benutzer einrichten.
Habe
setspn -A http/mail.xx.eu [ServerName]
setspn -A http/autodiscover.xx.eu [ServerName]
ausgeführt.
Nur von aussen kann ich Outlook noch nicht einrichten.
Hallo,
ich habe genau das gleiche Problem, das sporadisch auftaucht. Lustigerweise kann ich mich von Android Apps und über OWA super darauf verbinden, es geht aber nicht mit Outlook. Ich hatte mal den Client in Verdacht, glaube aber, dass es am Server liegt.
Jetzt bitte nicht gleich drauf hauen, dass ich keine Ahnung habe und trotzdem einen Exchange Server besitze. Ja, stimmt beides. Ich möchte aber lernen, wie das geht, daher habe ich das gemacht. Und ich nutze es auch produktiv.
Ich habe einen Server 2019 als DC, auf dem auch der Exchange Server läuft. Ich wusste damals nicht, dass man das nicht macht und die Installation hatte auch einwandfrei funktioniert. Ich habe einen Mail-Server bei NetCup, bei dem ich die mail.* und autodiscover.* verbogen haben. Ich hole die Post mittels popcon ab und sende mit multisendcon. Das funktioniert soweit alles.
Und bis vor ein paar Tagen hatte auch alles einwandfrei funktioniert, bis das erste Konto entschieden hatte, sich nicht mehr zu synchronisieren. In Outlook stand dort: getrennt und Ordner letztmalig synchronisiert am. Jetzt hat es das zweite Konto erwischt.
Ich habe mal testweise ein zweites Mail-Profil auf dem Client angelegt und bekomme das gleiche Ergebnis wie von natas beschrieben.
Übrigens: Ich trenne nicht zwischen intern und extern. Ich habe im DNS-Server die externe DNS auf die interne IP umgebogen. Das funktioniert einwandfrei.
Ich habe keine Ahnung, wo ich nachgucken muss, was alles wo wie protokolliert wird in welchen Dateien und wo ich die finde. Leider ist die Exchange Community außer hier eher recht professionell unterwegs, daher kann ich Freizeitschrauber nicht wirklich irgendwo gescheite Informationen abgreifen.
Ich weiß aber, dass ich bei meinem letzten Ausflug ins ECP alle Protokolllevel auf Maximum geschraubt hatte, wenn ich mich recht erinnere. Zur Sicherheit.
Kann mir jemand helfen?
Danke und Grüße
Jens
Ach so, der Exchange Server ist auch der Exchange 2019, falls das eine Rolle spielt...
Und CU12, falls das eine Rolle spielt...
Das liegt wohl doch irgendwie am Client. Ich habe jetzt mal am gleichen PC im gleichen LAN ein lokales Benutzerkonto ohne Domäne geöffnet, dort ging es sofort. Konnte nach dem Öffnen eines jungfräulichen Outlooks ohne Probleme die beiden fraglichen Konten einrichten... Häh???
Kann mir das jemand erklären?
Was mache ich denn jetzt? Einmal Outlook komplett resetten und neu? Komisch.