Guten Tag, ich habe nach einer Exchange 2013 to 2019 onprem ein Problem mit dem autodiscover und weiss leider echt nicht mehr worans liegen könnte und wies gefixt werden könnte, evtl. hat jemand noch eine Idee :-)
Ausgangssitation: 1x Exchange 2013 latest CU, ca. 200 Postfächer / Ziel: Exchange 2019, bereits alle Mailboxen sowie Systemmailboxen migriert Zugriff auf Exchange funktioniert korrekt.
Ich habe bereits mehrfach das Zertifikat, DNS Einträge sowie URL's und deren Auth. Methoden überprüft, leider ohne Erfolg, der alte Exchange Server läuft noch und ist noch nicht deinstalliert.
Das Problem besteht intern, extern vermutlich auch, ist momentan aber nicht wichtig.
Folgendes habe ich schon überprüft: https://www.server-essentials.com/support/autodiscover-outlook-and-soap-provider-failure-the-remote-server-returned-an-error-401-unauthorized#
Wenn ich allerdings auf dem Exchange 2019 Server einen Test ausführe, erhalte ich folgende Fehlermeldung:
[PS] C:\Windows\system32>Test-OutlookWebServices -Identity "max.muster@firma.ch" -MailboxCredential(Get-Credential firma\user01)
RunspaceId : 203a141c-dd4c-46ab-a8f2-66a268d4b5ca
Source : dkr-v-ws-ex01.firma.local
ServiceEndpoint : remote.firma.ch
Scenario : AutoDiscoverOutlookProvider
ScenarioDescription : Autodiscover: Outlook Provider
Result : Failure
Latency : 8
Error : System.Net.WebException: The remote server returned an error: (401) Unauthorized. ---> System.ComponentModel.Win32Exception: The target principal name is incorrect
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
at System.Net.NegotiateClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
at System.Net.NegotiateClient.Authenticate(String challenge, WebRequest webRequest, ICredentials credentials)
at System.Net.AuthenticationManagerDefault.Authenticate(String challenge, WebRequest request, ICredentials credentials)
at System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
at System.Net.HttpWebRequest.CheckResubmitForAuth()
at System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
at Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
Verbose : [2021-02-09 19:49:56Z] Autodiscover connecting to 'https://remote.firma.ch/Autodiscover/Autodiscover.xml'.
[2021-02-09 19:49:56Z] Test account: user01 Password: ******
[2021-02-09 19:49:56Z] Autodiscover request:
User-Agent: DKR-V-WS-EX01/Test-OutlookWebServices/max.muster@firma.ch
Content-Type: text/xml; charset=utf-8
Authorization: Negotiate oYIG0jCCBs6gAwoBAaKCBsUEggbBYIIGvQYJKoZIhvcSAQICAQBuggasMIIGqKADAgEFoQMCAQ6iBwMFACAAAACjggVSYYIFTjCCBUqgAwIBBaELGwlBWksuTE9DQUyiIDAeoAMCAQKhFzAVGwRIVFRQGw
1yZW1vdGUuYXprLmNoo4IFEjCCBQ6gAwIBEqEDAgE7ooIFAASCBPzrsDcop6DMKktqUewxT0pXGt2XT7CgAhShS/SbJYGmNpWQ6vTsAGMdRpVWYMSFXEiQ0q+B5H10XhGVnMaJRYOi2ZS6d0GBn8uYj5yR61oe+itVbfRra7Y0Y7qrOa5pu
6OmOgCisl1VdyOMDZLxxmv9daAcI/L1/dFXBXjwDNfJQt6SNbSd89rIYy7xWOOQHb+pmMpTJ6M3xwlScsWzH35syCpPOft7VgztuK8NNloaBQtf/joGUVcDNtceLQjySAPw/H+WwyW+p7EUd0o6QMe3KfvzPuuMaMIpoQq2P/DpM7P1D6Rw
iPeEheMkpNeWUgiMxlT21yF/qK2k4MywVu+5Wk1OvXeYDFQmErRVB1C6Uk0HDXja9vx65Sh0EdcXRWRKzCRQ0weCVrp8TS7JnBz4GLLrdrDVB6lSwnQf9zqiAYVXhtsihYbRm/r89ujjsqjWRBVpvuidC0Oz6PXrGl2jZ91UGeZdUKZ4lYc
PWClAde8FoVACYo8TdJpp+XBhmQHs+IlUz9vApzbl3/ZtHJzPxBLG0nfilvhyYN9pGTS7hEz0NUhbU/suh0aNkjqEifTgjD4zr+Zc6HaOYTK9u9QkNN43cCZApRJm3jLkp6+fhXg90s3F0cnGQWcZpwNGzjwRnfQVxaa9fk+Nf6Pxsueo9a
vNNYlawlFvFSUsLoNjA8SiysBd8m2Jz6dERxCDFBrAitnDVxm39tI6CsVcw8iv+80CMLLfhJx/ijPwNezp3FlDZug1bGMHMOZ+CYZCLd3c4FiGpKtC1pEwxEc/BXhr/AylFqCU3S0TPaZ5NWggSmHgHkqPcbm1fPFT+uJiKrIbG3B3XZJJu
4/tSGGTv/WJNIH2PGFYIB1V5r0MJzZApx5kql2mJrUw1BStv6/s+hY8yHr5+u/S1ao0dtihmuJeEL6FiQjdt6bTf1yT6SzeWSrYnnQcnqCzEIUQHbkS1RoULpQL97pCJGYzVmdykctK7evEx1e/cMUxVG25IgU74JmnXSxP/g8F8hys3zbo
8D3lWOh94qlgB9QkuWWWEaoTKeiZuPeZSL8dpf8DaBJosT+uVFReI/qmadoIfE0lit21NEFgpppszAflgUBK/9OpgvmplyABaoMaw9o4hkEnrNQFLN4prtP4G4B1J+bXLV95cDcB1n6nAxqaUhxK4QKpcElOkHbkx7hhY0aUd+ybUc5NhBL
ZHKDOh/uNgNyw1FhdWlcH29Kltur4tW8FCiewuIrLILf457vBFm8d5mW4sSJTWYY7V0ZFlgVOycrnLfzUM1QjF+R//rNLwPo/XalBaBAbfj9Dt2qhGohbnvLRW5QDXrfsue3iEULa7NnEUFvGkGVKCuewRr/331Heon5xEqMDOTW2oBxpdq
yirpdQPCxFWMyTxUcfuHJPAgs7SUniAr9farwOvv5aJuVg+mzXQt5cmIiih3jmTDE7V/H6Qw7xKQ0XBKNMLJld/tHngIvmvI9p0twpuwVzl1VFUUoDh+0Ow2zoi6Rd0xmb2CmbVGXOCI9G9A3ou68I/Ev910OvyqG4A2wx0uI6pd5N0Ss7b
cakM2C+1HBPtdbBb3YTVjEQaNSimEDtlynDFxqFXt9v44pMr1wt7V7C55n5JLOx1PIb/E4n+s8bAGJPjCumqG6RVpjbe+JhGEDNFpup/zjxDRj+AiCpBSD3KT6TtCQksKkvs7NrgwhbOTmMpIIBOzCCATegAwIBEqKCAS4EggEqq84GYHVT
2Tq7FTgNaOKq4qCubzmJi/GOcw1n2N5WPdo8l72y7HScteV984EMBSmygTfcgemrXGRKg7bpJEc5mWBg2D/YM6oAZqO8mDKQfPYTAev+kpmQBBDVKzUxTId51ZNj6sJW2HEMNjhXTiWFLnaDGH3UeYB8C0II6XVCvoA4qR70bW52+crnsOd
bYrCPeuj0n6h7G1N69ycrXS1XSBWeOHq61gUReUzjWrKCKUcg2DMTTCbe0j21bwtJXk7aTWT3vX8YdSoUY9IaXKxAnXT2mTpQjYi1EImDSO2zRMlEeIr/WM+9GIGox7rJ2k6fZD/mSFkaqPSIoObOmzsoh9TI3Yi+tlzZA1r19uFUS+nnMl
XDjWvO5pCcGDnYkdznFNNe/6cMcA/PUw==
Host: remote.firma.ch
Content-Length: 453
Expect: 100-continue
[2021-02-09 19:49:56Z] Autodiscover request:
<?xml version="1.0"?>
<Autodiscover xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
<Request>
<EMailAddress>max.muster@firma.ch</EMailAddress>
<AcceptableResponseSchema> http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
</Request>
</Autodiscover>
[2021-02-09 19:49:56Z] Autodiscover response:
request-id: 82ecc5d5-da34-4da0-8c06-150671f788bf
Server: Microsoft-IIS/10.0
WWW-Authenticate: Negotiate
oXEwb6ADCgEBomgEZmBkBgkqhkiG9xIBAgIDAH5VMFOgAwIBBaEDAgEepBEYDzIwMjEwMjA5MTk0OTU2WqUFAgMFePmmAwIBKakLGwlBWksuTE9DQUyqGzAZoAMCAQGhEjAQGw5ka3Itdi13cy1leDAxJA==,NTLM,Basic
realm="remote.firma.ch"
X-Powered-By: ASP.NET
X-FEServer: DKR-V-WS-EX01
Date: Tue, 09 Feb 2021 19:49:56 GMT
Content-Length: 0
[2021-02-09 19:49:56Z] Autodiscover response:
System.Net.WebException: The remote server returned an error: (401) Unauthorized. ---> System.ComponentModel.Win32Exception: The target principal name is incorrect
at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
at System.Net.NegotiateClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
at System.Net.NegotiateClient.Authenticate(String challenge, WebRequest webRequest, ICredentials credentials)
at System.Net.AuthenticationManagerDefault.Authenticate(String challenge, WebRequest request, ICredentials credentials)
at System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
at System.Net.HttpWebRequest.CheckResubmitForAuth()
at System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.InternalInvoke()
at Microsoft.Exchange.Management.SystemConfigurationTasks.ServiceValidatorBase.Invoke()
MonitoringEventId : 6001
RunspaceId : 203a141c-dd4c-46ab-a8f2-66a268d4b5ca
Source : dkr-v-ws-ex01.firma.local
ServiceEndpoint :
Scenario : ExchangeWebServices
ScenarioDescription : Exchange Web Services
Result : Skipped
Latency : 0
Error : Skipped testing Exchange Web Services because the Autodiscover step failed.
Verbose :
MonitoringEventId : 5002
RunspaceId : 203a141c-dd4c-46ab-a8f2-66a268d4b5ca
Source : dkr-v-ws-ex01.firma.local
ServiceEndpoint :
Scenario : AvailabilityService
ScenarioDescription : Availability Service
Result : Skipped
Latency : 0
Error : Skipped testing Availability Service because the Autodiscover step failed.
Verbose :
MonitoringEventId : 5003
RunspaceId : 203a141c-dd4c-46ab-a8f2-66a268d4b5ca
Source : dkr-v-ws-ex01.firma.local
ServiceEndpoint :
Scenario : OfflineAddressBook
ScenarioDescription : Offline Address Book
Result : Skipped
Latency : 0
Error : Skipped testing Offline Address Book because the Autodiscover step failed.
Verbose :
MonitoringEventId : 5004
[PS] C:\Windows\system32>
Als Outlook Client wird Outlook 2016 verwendet, alle Benutzer können auch normal arbeiten, Autodiscover und Test via Outlook funktioniert aber nicht. Den Office365 Registry Key habe ich bereits gesetzt.
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
ExcludeExplicitO365Endpoint=dword:00000001
Leider keine Besserung. Auch kann ich keine neuen Benutzer mehr einrichten weil Autodiscover nicht korrekt funktioniert.
Interessant ist noch dass wenn ich die Autodiscover.xml aufrufe ( bsp.: https://autodiscover.firma.ch/Autodiscover/Autodiscover.xml ) erscheint eine Eingabeaufforderung,
hier kann ich eingeben was ich will, keine Chance. Wenn ich dies aber mit der internen IP oder localhost versuche funktionierts ( https://localhost/Autodiscover/Autodiscover.xml )
Bei mir ist der Befehl ebenfalls nicht erfolgreich. Clients haben aber soweit keine Probleme.
Der Befehl funktioniert anscheinend nur in Exchange 2010, s. https://docs.microsoft.com/en-us/powershell/module/exchange/test-outlookwebservices?view=exchange-ps und https://www.frankysweb.de/community/exchange2016/autodiscover-test-mit-test-outlookwebservices-cmdlet-supported-auf-exchange-2016/
@jenny Ja das scheint somit auf dem Exchange 2019 nicht mehr so zu funktionieren. Dennoch besteht in meiner Umgebung nach wie vor ein Problem mit Autodiscover. Bin nun mal einen Schritt
weiter. Wenn ich auf einem Client die Hosts Datei editiere und mit der IP Adresse auf den alten Exchanger zeige, dann funktioniert Autodiscover und Einrichtung eines Outlooks funktioniert korrekt.
Wenn ich den Hosts Eintrag wieder entferne funktioniert Outlook weiterhin, allerdings Autodiscover wieder nicht mehr...
Servus,
aus deinen Screenshot kann man es leider nicht erkennen, aber ich wette du hast Autodiscover nicht auf die entsprechende URL "https://autodiscover.domain.tld/Autodiscover/Autodiscover.xml" konfiguriert. Vermutlich wird da noch der interne Hostname stehen, welcher wahrscheinlich nicht Bestandteil des Zertifikats ist.
Gruß,
Frank
@franky Hallöchen, vielen Dank für den Tip, um solche "Flüchtigkeitsfehler" zu verhindern, nehme ich die jeweiligen Namen in eine PS Script Variable und setze dann die einzelnen URL's via PS aber könnte gut sein, aber dies sieht nach mir gut aus, was mir allerdings auffällt ( weiss aber nicht ob dies einen Einfluss hat, die RunspaceId und AutoDiscoverServiceGuid sind identisch ).
Da Autodiscover ja auf dem alten Server funktioniert denke ich liegts nicht an den Einträgen, aber dennoch zur Kontrolle was existiert.
Es gibt eine interne DNS Zone welche als firma.ch definiert ist, darunter existieren folgende Einträge:
remote.firma.ch 10.10.101.25 A-Record
autodiscover.firma.ch remote.firma.ch CNAME-Record
_autodiscover._tcp.firma.ch remote.firma.ch SRV-Record
[PS] C:\Windows\system32>nslookup -q=srv _autodiscover._tcp.firma.ch
Server: dkr-v-ws-ad01.firma.local
Address: 10.10.101.1
_autodiscover._tcp.firma.ch SRV service location:
priority = 10
weight = 10
port = 443
svr hostname = remote.firma.ch
remote.firma.ch internet address = 10.10.101.25
Auf dem Zertifikat sind folgende Namen definiert (3rd Party von GoDaddy):
Subject: remote.firma.ch
Subject Alternative Name:
DNS Name=remote.firma.ch
DNS Name=www.remote.firma.ch
DNS Name=otw.firma.ch
DNS Name=rds.firma.ch
DNS Name=mail.firma.ch
DNS Name=autodiscover.firma.ch
[PS] C:\Windows\system32>Get-ClientAccessService | fl
RunspaceId : b8d12ba8-2d1e-4be1-9550-f2ddc0ee5bb0
Name : SRVEXCHANGE
Fqdn : SRVEXCHANGE.firma.local
ClientAccessArray :
OutlookAnywhereEnabled : True
AutoDiscoverServiceCN : SRVEXCHANGE
AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://remote.firma.ch/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope : {Default-First-Site-Name}
AlternateServiceAccountConfiguration :
IsOutOfService : False
Identity : SRVEXCHANGE
IsValid : True
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=SRVEXCHANGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=firma,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=firma,DC=local
Guid : 3a4ff9b9-794d-4b70-9df0-f96c1fec5f70
ObjectCategory : firma.local/Configuration/Schema/ms-Exch-Exchange-Server
ObjectClass : {top, server, msExchExchangeServer}
WhenChanged : 12/16/2020 1:27:08 PM
WhenCreated : 4/12/2016 12:19:06 PM
WhenChangedUTC : 12/16/2020 12:27:08 PM
WhenCreatedUTC : 4/12/2016 10:19:06 AM
OrganizationId :
Id : SRVEXCHANGE
OriginatingServer : dkr-v-ws-ad01.firma.local
ObjectState : Unchanged
RunspaceId : b8d12ba8-2d1e-4be1-9550-f2ddc0ee5bb0
Name : DKR-V-WS-EX01
Fqdn : dkr-v-ws-ex01.firma.local
ClientAccessArray :
OutlookAnywhereEnabled : True
AutoDiscoverServiceCN : dkr-v-ws-ex01
AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service
AutoDiscoverServiceInternalUri : https://remote.firma.ch/Autodiscover/Autodiscover.xml
AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596
AutoDiscoverSiteScope : {Default-First-Site-Name}
AlternateServiceAccountConfiguration :
IsOutOfService : False
Identity : DKR-V-WS-EX01
IsValid : True
ExchangeVersion : 0.1 (8.0.535.0)
DistinguishedName : CN=DKR-V-WS-EX01,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
Groups,CN=firma,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=firma,DC=local
Guid : 951605cd-cc10-438f-b945-4fa7a98b52e3
ObjectCategory : firma.local/Configuration/Schema/ms-Exch-Exchange-Server
ObjectClass : {top, server, msExchExchangeServer}
WhenChanged : 12/16/2020 1:24:55 PM
WhenCreated : 12/10/2020 12:20:19 PM
WhenChangedUTC : 12/16/2020 12:24:55 PM
WhenCreatedUTC : 12/10/2020 11:20:19 AM
OrganizationId :
Id : DKR-V-WS-EX01
OriginatingServer : dkr-v-ws-ad01.firma.local
ObjectState : Unchanged
Noch ein kleiner Nachtrag: mapi over http war bereits deaktiviert, habe es testeshalber mal aktiviert, brachte aber keine Aenderung, evtl. lässt sich ja was in den Autodisover Logs sichten.
Sämtliche URL's, Directory's sowie Auth. Methoden zwischen den beiden Servern verglichen, identisch, dennoch erscheint beim Email Autokonfig Test das Fenster ( egal übrigens ob der alte Exchange 2013 Server läuft oder nicht ):
So bin nun einen Schritt weiter. Bestehendes Office 2016 Autodisocver auf alten Exchange 2013 Server kein Poblem, auf Exchange 2019 besteht das Problem
Mit Office 2013 funktioniert Autodiscover auf alten und neuen Exchange Server ( 2013 und 2019 ). Von extern funktioniert Autodiscover ebenfalls korrekt.
Gemäss jensten Foreneinträgen zb.: https://kb.intermedia.net/article/20784 https://kb.intermedia.net/Article/39713 ein Problem ab Outlook 2016.
DWORD ExcludeExplicitO365Endpoint Eintrag erstellt, Problem besteht nach wie vor, Office auf aktuellsten Stand gepatcht !
Muss der Kunde in die Cloud oder funktioniert Exchange 2019 mit Outlook 2016 einfach nicht ?!?!?!
funktioniert Exchange 2019 mit Outlook 2016 einfach nicht ?!?!?!
!!!!!!!!!!???????!!!!!!!!! natürlich funktioniert das !!!!eins11elf!
Hast du mal von extern getestet? Hast du Split-DNS oder getrennte internal/external URL?
@norbertfe Hallöchen, habe nun den gleichen Test mit Office 2019 durchgeführt das gleiche Ergebnis, beim einrichten eines neuen Konto bzw. Autodiscover Funktionstest via Outlook erscheint das Anmeldefenster. Habe zudem mal die IIS Autodiscover Einstellungen mit einer Umgebung überprüft, bei der alles korrekt funktioniert, das sieht gut aus.
Von Extern funktionierts korrekt, das Problem besteht nur intern. Split DNS wird verwendet, die URL's intern und extern sind jeweils auf den gleichen Namespace konfiguriert.
Dazwischen hängt auch kein Proxy oder eine konfigurierte GPO welche etwas anpassen würde ( mit einem frischen Client getestet ). Aber es MUSS fast was an der Outlook 2016 oder 2019 liegen, da Outlook 2013 mit dem alten und neuen Server korrekt funktioniert. Irgendwass mit der Authentifizierung, nur was ?
Mapi over HTTP war bisher deaktiviert, werde das im Moment so belassen, denke das sollte keinen Einfluss auf Autodiscover haben, aber kann dies gerne mal aktivieren, allenfalls hats doch irgendwo noch einen Einfluss.
Welche IP hat der alte und welche der neue Exchange? Der Name "remote" läßt ein wenig auf SBS Ursprünge vermuten.
Den ganzen SRV record Autodiscover Kram würde ich weglassen. Das machts nur umständlicher und bringt dir keine Punkte.
@norbertfe Danke für die Info, über diesen Beitrag bin ich ebenfalls schon "gestolptert". Der alte hatte die IP 192.168.100.30, der neue 10.10.101.25. Ist ein anderes Netzwerk, wird aber entsprechend über die Firewall geroutet ( auch mit einem Client im "neuen" Netzwerk tritt das Problem auf ).
Kann gut sein dass dies von von SBS Zeiten kommt, wir haben den Kunden erst vor kurzem als aktiven Kunden. Also mal die SRV Records entfernen ?
Schau doch mal nach, obs nen SPN gibt, oder hast du das schon geprüft?
@norbertfe SPN's gibt habe die mal mit dem folgende CMD (setspn -Q */*EXCHANGE* >> d:spn_recordsOLD.txt ) exportiert.
Exchange 2013:
Checking domain DC=company,DC=local
CN=SRVEXCHANGE,OU=company-Server,DC=company,DC=local
http/srvexchange.company.local
http/remote.company.ch
POP3/SRVEXCHANGE
POP3/SRVEXCHANGE.company.local
POP/SRVEXCHANGE
POP/SRVEXCHANGE.company.local
IMAP4/SRVEXCHANGE.company.local
IMAP4/SRVEXCHANGE
IMAP/SRVEXCHANGE.company.local
IMAP/SRVEXCHANGE
exchangeMDB/SRVEXCHANGE
exchangeMDB/SRVEXCHANGE.company.local
exchangeAB/SRVEXCHANGE.company.local
exchangeAB/SRVEXCHANGE
exchangeRFR/SRVEXCHANGE.company.local
exchangeRFR/SRVEXCHANGE
SmtpSvc/SRVEXCHANGE.company.local
SmtpSvc/SRVEXCHANGE
SMTP/SRVEXCHANGE.company.local
SMTP/SRVEXCHANGE
TERMSRV/SRVEXCHANGE
TERMSRV/SRVEXCHANGE.company.local
WSMAN/SRVEXCHANGE
WSMAN/SRVEXCHANGE.company.local
RestrictedKrbHost/SRVEXCHANGE
HOST/SRVEXCHANGE
RestrictedKrbHost/SRVEXCHANGE.company.local
HOST/SRVEXCHANGE.company.local
Existing SPN found!
Exchange 2019:
Checking domain DC=company,DC=local
CN=DKR-V-WS-EX01,OU=Member Servers,OU=Servers,OU=_Computers,DC=company,DC=local
IMAP/DKR-V-WS-EX01
IMAP/dkr-v-ws-ex01.company.local
IMAP4/DKR-V-WS-EX01
IMAP4/dkr-v-ws-ex01.company.local
POP/DKR-V-WS-EX01
POP/dkr-v-ws-ex01.company.local
POP3/DKR-V-WS-EX01
POP3/dkr-v-ws-ex01.company.local
exchangeRFR/DKR-V-WS-EX01
exchangeRFR/dkr-v-ws-ex01.company.local
exchangeAB/DKR-V-WS-EX01
exchangeAB/dkr-v-ws-ex01.company.local
exchangeMDB/DKR-V-WS-EX01
exchangeMDB/dkr-v-ws-ex01.company.local
SMTP/DKR-V-WS-EX01
SMTP/dkr-v-ws-ex01.company.local
SmtpSvc/DKR-V-WS-EX01
SmtpSvc/dkr-v-ws-ex01.company.local
WSMAN/dkr-v-ws-ex01
WSMAN/dkr-v-ws-ex01.company.local
TERMSRV/DKR-V-WS-EX01
TERMSRV/dkr-v-ws-ex01.company.local
RestrictedKrbHost/DKR-V-WS-EX01
HOST/DKR-V-WS-EX01
RestrictedKrbHost/dkr-v-ws-ex01.company.local
HOST/dkr-v-ws-ex01.company.local
Existing SPN found!
Und was sagt dir das?
http/remote.company.ch
@norbertfe Dass dieser noch auf den alten Server zeigt bzw. registriert ist, sprich dieser muss da weg und auf den neuen Server zeigen. Kann dieser einfach so umgebogen werden ? Sorry für meine Unwissenheit, aber dass ist jetzt noch etwas Neuland für mich :-)
über diesen Beitrag bin ich ebenfalls schon "gestolptert".
Ich dachte, du hättest ihn auch gelesen. Lösch doch mal den SPN (siehe oben). So ist doch klar, dass das mit Kerberos nicht funktioniert und erklärt eigentlich auch den Fehler im Log "The target principal name is incorrect"
@norbertfe Besten Dank, dann werde ich das gerne testen und wieder berichten :-)
Habe nun nur diesen einzelnen SPN Record entfernt, schon funktioniert Autodiscover sowie die Einrichtung neuer Postfächer !
Vielen herzlichen Dank für den hilfreichen Support, wohin kann ich das Bier schicken ? ;-)
Kaum macht mans richtig, schon funktionierts. ;)