philippr 10 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Hallo, ich habe folgendes Problem bei einem Exchange 2013 CU3 auf einem Server 2012. Bei einem Outlook Client wurde das Zertifikat abgelehnt da der eingetragene Name "server.domain.local" nicht mit dem vom Autodiscover zurückgegebenen Namen "SERVER.domain.local" übereinstimmt. Der vergebene Servername selbst ist Kleingeschrieben. Die Managementshell liefert folgendes: Get-ClientAccessServer Name : SERVERFqdn : SERVER.domain.local Get-WebServicesVirtualDirectory MetabasePath : IIS://SERVER.domain.local/W3SVC/1/ROOT/EWS Server : SERVERInternalUrl : .ttps://server.domain.local/EWS/Exchange.asmxExternalUrl : .ttps://server.domain.local/EWS/Exchange.asmx Sämtliche änderbare Einträge in der Verwaltungskonsole sind kleingeschrieben, außer in der Serverauswahl bei "virtuelle Verzeichnisse", dort habe ich 2 Exchange zur Auswahl und der Eintrag für den Exchange 2013 Servernamen ist auch dort komplett in Großbuchstaben. Ein nslookup liefert den korrekten Namen "server.domain.local" , im DNS ist ebenfalls alles in kleinbuchstaben. bei unserem alten Exchange 2007 liefert Get-ClientAccessServer die korrekte Ausgabe: Name : SERVER1Fqdn : server1.domain.local Unter Name scheint wohl generell alles in Großbuchstaben geschrieben zu sein, allerdings stimmt es dann im fqdn wieder. Nach stundenlangem Suchen bin ich mit meinem Latein am Ende und Ich hoffe Ihr könnt mir bei diesem Problem helfen. mfg Phil Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 (bearbeitet) Moin, wenn das wirklich im Autodiscover war, findest Du die Einstellung mit "Get-ClientaccessServer | ft name,autodiscoverserviceinternaluri". EWS ist für OAB, Kalender und OOF zuständig. bearbeitet 5. Februar 2014 von RobertWi Zitieren Link zu diesem Kommentar
FrankysWeb 0 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Hallo, normalerweise sind Zertifikate nicht case-sensitive. Zumindest wurde das mal so im RFC2459 definiert. Zitieren Link zu diesem Kommentar
philippr 10 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 bei "Get-ClientaccessServer | ft name,autodiscoverserviceinternaluri kommt die korrekte adresse zurück: https://server.domain.local/Autodiscover/Autodiscover... das ist es also leider nicht. und in RFC2459 steht das es case sensitve ist: (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects); Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Moin, na ja, Du hast oben behaupt, die fehlerhafte Adresse käme bei Autodiscover zurück. - Installiere CU 3, nicht dass das ein Fehler ist, der behoben wurde - Prüfe mit Outlook und "E-Mail-Autokonfiguration testen...." welche Adresse wirklich falsch zu sein scheint - Ändere die in Exchange an der entsprechenden Stelle (ich würde die auch mal auf einen komplett "falschen" Wert ändern, um die Auswirkungen zu sehen) Und wenn der Fehler immer noch bleibt, ärgere Dich über die Tatsache, dass Du Beta-Tester spielen darfst und mach einen Call bei Microsoft auf. Zitieren Link zu diesem Kommentar
philippr 10 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 CU3 ist installiert. die Fehlerhafte einstellung scheint ja schon direkt am Server zu sein da er ja wie gesagt dort den Servernamen im fqdn in Großbuchstaben anzeigt, ebenso auch den iis Metabase Path. gibt es denn keine Möglichkeit den fqdn der dort hinterlegt ist zu ändern ? Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Willst Du jetzt das man Dir hilft oder einfach nur selbst rumbasteln? Zitieren Link zu diesem Kommentar
philippr 10 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 "Rumgebastelt" hab ich schon zu lange , deswegen frag ich ja hier bis zu dem den Punkt "E-Mail-Autokonfiguration testen...." kommt es leider garnicht erst, da er sich die falschen Einstellungen ja bereits beim Neueinrichten des Clients zieht, und diese unter "Exchange Proxyeinstellungen" dann am Client einträgt "https://SERVER.domain.local". danach kommt sofort die Zertifikatswarnung das er "server" im Zertifikat erwartet allerdings "SERVER" im fqdn steht. Interne und externe URLs habe ich nun an diversen stellen in der Verwaltungskonsole in andere werte geändert, er übernimmt diese zwar, allerdings ändert er automatisch sämtliche Werte von Großschreibung in Kleinschreibung. Was vielleicht zur Problemfindung auch noch wichtig sein könnte: Auf unter XP mit Office 2007 funktioniert das ganze wunderbar, dort kommt der Servername in Kleinschreibung beim Client per Autodiscover an. Unter Windows 7 und Office 2010 nicht. Nun dachte ich mir erstell ich einfach als Übergangslösung ein Zertifikat mit "SERVER.domain.local", allerdings ist dies mit der Verwaltungskonsole nicht möglich da er alles durch Kleinschreibung ersetzt. Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 OK. Ist schon vorstellbar, dass XP und Windows 7 sich hier unterschiedlich verhalten, da liegen ja auch Jahr dazwischen. Könnten also auch Outlook Anywhere Einstellungen sein, prüfe mal hiermit: Get-OutlookProvider | ft Identity,CertPrincipalName Get-OutlookAnywhere | ft Server,ExternalHostname,InternalHostname Zitieren Link zu diesem Kommentar
philippr 10 Geschrieben 5. Februar 2014 Autor Melden Teilen Geschrieben 5. Februar 2014 ok, hab das gerade mal überprüft. Get-OutlookProvider | ft Identity,CertPrincipalName Identity CertPrincipalName-------- -----------------EXCH msstd:server.domain.localEXPR msstd:server.domain.localWEB Get-OutlookAnywhere | ft Server,ExternalHostname,InternalHostname Server ExternalHostname InternalHostname------ ---------------- ----------------SERVER server.domain.local server.domain.local Zitieren Link zu diesem Kommentar
RobertWi 81 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Und nur um ganz sicher zu gehen und wegen der Pferde vor der Apotheke: Die Zertifikatsfehlermeldung bezieht sich wirklich auf den Namen und nicht auf die Gültigkeit oder die Vertrauenswürdigkeit? Ein solcher "Fehler" ist bisher nicht aufgetreten und er müsste prinzipbedingt (weil Exchange 2013 immer RPC/HTTPS benutzt) ziemlich hohe Wellen machen. Ansonsten fürchte ich, wird sich das in einem Forum nicht klären lassen. Da Du hier alle Servernamen verschleierst, was grundsätzlich nicht schlimm ist, könnten auch bei der Übermittlung hier ins Forum diverse Fehler geschehen. Wir können Dir nur sagen, welche Stellen du prüfen musst und die haben wir durch. Mit den von Dir in Post #1 genannten Einstellungen hat das nichts zu tun, da dies keine URLs sind, die dem Client übermittelt werden. Also entweder jemanden einladen oder Microsoft Support einschalten. Und danach hier berichten, das klingt schon ziemlich schräg, das ganze. Ach so, Nachtrag: Und wie immer Ausschließen, dass hier ein anderes Netzwerkgerät, DNS, o.ä. oder ein Proxy dazwischen funkt. Also falls ein Proxy im Einsatz ist, den Exchange als Ausnahme dort definieren. Zitieren Link zu diesem Kommentar
testperson 1.660 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Hi, ist es ein self signed Zertifikat? Hatte bei einer Migration ebenfalls das Problem, das Outlook nur mit einer Warnung aufging, obwohl das Zertifikat als vertrauenswürdig installiert war. Hatte mich dann aber nicht damit aufgehalten, da ein vertrauenswürdiges Zertifikat quasi schon unterwegs war. Gruß Jan Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Wenn der Server von aussen erreichbar ist, kann eventuell https://testconnectivity.microsoft.com/ weiterhelfen, das Problem zu analysieren. Zitieren Link zu diesem Kommentar
FrankysWeb 0 Geschrieben 5. Februar 2014 Melden Teilen Geschrieben 5. Februar 2014 Kann es sein das der DNS Eintrag in Großbuchstaben erstellt wurde? Zitieren Link zu diesem Kommentar
philippr 10 Geschrieben 6. Februar 2014 Autor Melden Teilen Geschrieben 6. Februar 2014 Kann es sein das der DNS Eintrag in Großbuchstaben erstellt wurde? das hatte ich auch schon vermutet, allerdings ist im DNS der Eintrag in Kleinbuchstaben und nslookup liefert ja immer Kleinschreibung auch bei großgeschriebenem DNS Eintrag. @RoberWi, die Fehlermeldung bezieht sich direkt auf den Namen server.domain.local ... entspricht nicht SERVER.domain.local Die Ausgabe von Get-ClientAccessServer Name : SERVER Fqdn : SERVER.domain.local müßte eigentlich auch so aussehen: Name : SERVER Fqdn : server.domain.local irgendwoher muß er doch diesen falschen Fqdn Eintrag holen Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.