So, ich habe hier schon viel gesucht und auch google bemüht.
Bei mir sieht es wie folgt aus :)
Wir haben einen Exchange 2010 Standard und der Outlook Client liefert eine Meldung,
dass das Zertifikat nicht übereinstimmt.
Gut, das Zertifikat ist mit der externen URL versehen, Outlook sucht sich wohl per Autodiscover den internen.
Nun habe ich rumgeforstet und wollte mit der Powershell das Autodiscover für die interne uri, das oab und ews anpassen und um wurde auch erwähnt.
Im DNS exisitiert eine Forward Zone für die externe Domäne und dort ist ein reiner A Eintrag auf den CAS Server gesetzt(es existiert nur 1 Exchange).
Weiterhin wurde in der lokalen Domänenzone auch ein SRV Eintrag für _Autodiscover gesetzt.
Nun wollte ich wie erwähnt die Pfade anpassen, bekomme aber eine Meldung in der Powershell :
Beim verbinden mit dem Remoteserver ist folgender Fehler aufgetreten : Die Anforderung kann von WinRM bucgt verarbeitet werden.
Bei Verwendung der Kerberos-Authentifizierung ist folgender Fehler aufgetreten : Eine angegebene Anmeldesitzung ist nicht vorhanden....
OK, wieder google bemüht und Einträge gefunden wie den da(ist rauskopiert)
In IIS Verzeichnis Powershell unter Module muss man zuerst Kerbauth und Wsman hinzufügen (Wenn Sie fehlen):
Systemeigene Modul Registrieren gibt es nicht (Lieber Aze), also muss man Verwaltetes Modul Hinzufügen:
Kerbauth
C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll
und dann
WSMan
C:\Windows\system32\wsmsvc.dll
aber das reicht nicht, weil die module sind noch "verwaltet" und nicht "systemeigene" oder "native".
um das zu ändern, muss man die Datei applicationhost.config unter C:\windows\system32\inetsrv\config\ öffnen (Editor)
und unter <globalModules>
die 2 Zeilen hinzufügen:
<add name="kerbauth" image="C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll" />
<add name="WSMan" image="C:\Windows\system32\wsmsvc.dll" />
Speichern und fertig!
jetzt sind WSMan und Kerbauth systemeigene.
Nun waren bei mir beide Einträge in der applicationhost.config eingetragen, jedoch bei kerbauth noch mit der bitness64 option für 64 Bit Systeme(Exchange 2010 läuft auf einen Server 2008)
Was mir jedoch aufgefallen ist, wenn ich im IIS unter PowerShell Module reinschaue bei kerbauth, dann sehe ich unter Code, normalerweise den Pfad zu der kerbauth.dll, der ist dort jedoch leer der Wert und unter Modultyp steht "verwaltet" wo bei
WSMan Systemeigen steht und als Eintragstyp steht bei beiden lokal.
Der auszuführende Benutzer(Administrator) ist auch in der Exchange Gruppe Organisation Management enthalten.
Vermutlich muss ich es also erstmal nur schaffen, dass der Code, also der Wert für kerbauth im Powershell Modul wieder erscheint und dann auch nicht als "verwaltet", sondern "systemeigen"
Wenn mir jetzt jemand verraten könnte, wie ich das schaffe, wäre ich sehr dankbar, denn dann kann ich an das eigentliche PRoblem mit dem Zertifikat rangehen(und hoffen, dass es so funktioniert).
Viele Grüße
