none
Anmeldung in Outlook am Exchange 2016 funktioniert bei vorhandenen Rechnern nicht

    Frage

  • Servus,

    ich habe folgendes Problem nach der Migartion eines SBS 2011 zu einem Exchange 2016.

    Die Postfächer sind auf den Exchange 2016 umgezogen worden, die Links zu Autodiscover usw. wurden angepasst, der Kunde hat ein Zertifikat für remote.domain.de und eins für autodiscover.domain.de.

    Wenn ich an einem der vor der Migration vorhandenen Rechner Rechner Outlook starte, kommt die bekannte Meldung der Kennwortabfrage. Die kommt auch wenn ich mich auf dem Client mit einem neuen Benutzer anmelde.

    Wenn ich einen Rechner neu installiere (leere Festplatte oder virtuell) und Office installiere, meldet der sich fehlerfrei am Exchange an, ohne eine Abfrage von Benutzername und Kennwort. Zertifikatsmeldungen kommen keine. 

    Es spielt keine Rolle welches BS oder welche Outlook BVersion es ist, habe schon mit Windows 7, 10 und Outlook 2010 und 2013 getestet, es ist immer das Gleiche. Wenn der Rechner neu aufgesetzt wurde funktioniert alles, aber keiner der alten Systeme. 

    Ich habe auch testweise einen Rechner aus der Domain genommen und wieder hinzugefügt, leider ohne Erfolg.

    Woran kann das hier hängen?

    Grüße

    Norbert

    Mittwoch, 6. Dezember 2017 12:19

Alle Antworten

  • Hallo,

    ich gehe mal davon aus, das ist eine Migration von SBS 2011 auf Exchange 2016 innerhalb der gleichen Domäne. Ich gehe auch davon, dass die URLs für die Virtuellen Verzeichnisse korrekt gesetzt worden und Clients über die URLs zuerst auf dem neuen Exchange zugreifen.

    Es wird ein Zertifikat benötigt, mit dem Namen des Exchange Servers (z.B. exchange.domain.de) und dem Autodiscover-Eintrag (autodiscover.domain.de). Zwei Zertifikate bringen gar nichts, oder ich interpretiere den Satz des TO falsch.

    Das Problem hört sich nach Caching an. Am Besten mal mit dem Tool aus folgendem Technet-Link (funktioniert auch mit Ex2016) den Autodiscover-Prozess von einer Bestands- und einer neuen Maschine vergleichen. Der Link "AutodiscoverTest.zip" ist etwas unscheinbar: AutodiscoverTest


    Grüße Steve (P.S.: War die Antwort hilfreich, dann bitte links markieren.)

    Mittwoch, 6. Dezember 2017 13:25
  • Moin,

    zusätzlich prüfen, ob Split-DNS passt und alle URL intern und extern gleich sind.

    https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershell-konfigurieren/

    Das Zertifikat braucht zwei Namen im Cert, webmail oder owa oder was immer ihr verwendet und autodiscover.

    Alle URL müssen ohne Cert-Warnung von jedem Client aus aufgerufen werden können.

    Stimmt der SRV-Record im AD?

    ;)


    Gruß Norbert


    Mittwoch, 6. Dezember 2017 15:20
    Moderator
  • Servus,

    so, ich hab mal das Autodiscovertool getestet, ich bekomme folgenden Fehler:

    ..starting SCP Lookup for domainName=domain.de
    ..Scanning for SCP urls for the current computer Site=Standardname-des-ersten-Standorts
    ..SCP matching Site keyword found, 'https://remote.domain.de/Autodiscover/Autodiscover.xml' for the Site=Standardname-des-ersten-Standorts 
    ..trying 'administrator@domain.de' at 'https://remote.domain.de/Autodiscover/Autodiscover.xml'
    ..error. message: Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
    status code: ProtocolError

    ..trying 'administrator@domain.de' at 'https://domain.de/autodiscover/autodiscover.xml'
    ..info: failed and skipped.
    ..message: Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..
    status code: SendFailure

    ..trying 'administrator@domain.de' at 'https://autodiscover.domain.de/autodiscover/autodiscover.xml'

    User/DisplayName=Administrator
    User/LegacyDN=/o=INTERNALDOMAIN/ou=first administrative group/cn=Recipients/cn=Administrator
    User/DeploymentId=da209944-00a0-437a-988d-2677e3a8bbdb
    Account/AccountType=email
    Account/Action=settings
    Account/Protocol/Type=EXCH
    Account/Protocol/ASUrl=https://remote.domain.de/EWS/Exchange.asmx
    Account/Protocol/DirectoryPort=0
    Account/Protocol/MdbDN=/o=INVIVO/ou=Exchange Administrative Group (FYDIBOHF23SPD
    LT)/cn=Configuration/cn=Servers/cn=18a9c953-c7be-4003-9189-c705e983652d@domain.de/cn=Microsoft Private MDB
    Account/Protocol/OABUrl=https://remote.domain.de/OAB/3db9adc0-a96a-459c-bc59-04803954f8ad/

    Wobei die Meldung auf allen Clients die Gleiche ist, auf den alten Rechnern wo Outlook nicht connectiert und auf den neu installierten wo die Verbindung funktioniert.

    Wenn ich mir die Einstellungen -Sicherheit von Outlook auf den Rechnern anschaue die funktionieren ist diese anders als bei den wo es hängt. Hier ist bei den Rechnern die funktionieren die Aushandlungsauthentifizierung eingetragen, bei denen die nicht connectieren nichts, einstellen kann man hier nichts. 

    Werden die Daten irgendwo auf dem Client zwischengespeichert?


    • Bearbeitet Norbert Horn Donnerstag, 7. Dezember 2017 08:50
    Donnerstag, 7. Dezember 2017 08:48
  • Niemand eine Idee?
    Donnerstag, 7. Dezember 2017 17:05
  • Moin,

    evtl. ist auf den Maschinen per Registry Hack irgendwas verbogen, entweder im Autodiscover (z.B. lokale XML eingetragen) oder bei Outlook Anywhere (RPC/HTTPS). Das würde auch das Verhalten aus Deinen Screenshots erklären.

    Was immer es ist, Du kannst es mit Group Policy überschreiben - oder Du findest das, dann kannst Du es auch löschen. Schau Dir in der Registry die Office- bzw. Outlook-Einstellungen im Maschinen-Hive an und, wenn Du nicht fündig wirst, in einem neu erstellten Benutzer-Hive BEVOR man Outlook zum ersten Mal startet.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Donnerstag, 7. Dezember 2017 20:33
  • Am 07.12.2017 um 21:33 schrieb Evgenij Smirnov:
    Nabend,
     > evtl. ist auf den Maschinen per Registry Hack irgendwas verbogen, entweder im Autodiscover (z.B. lokale XML eingetragen) oder bei Outlook Anywhere (RPC/HTTPS). Das würde auch das Verhalten aus Deinen Screenshots erklären.


    Was immer es ist, Du kannst es mit Group Policy überschreiben - oder Du findest das, dann kannst Du es auch löschen. Schau Dir in der Registry die Office- bzw. Outlook-Einstellungen im Maschinen-Hive an und, wenn Du nicht fündig wirst, in einem neu erstellten Benutzer-Hive BEVOR man Outlook zum ersten Mal startet.

    Proxyeinstellungen für die "alten" PCs wären noch ein klassischen Kandidat fürs Fehlersuchen.

    Bye
    Norbert

    Donnerstag, 7. Dezember 2017 23:03
  • Registry oder GPO, da könntest du ev. fündig werden.

    https://social.technet.microsoft.com/wiki/contents/articles/37418.office-365-credential-prompts-after-migration.aspx

    https://support.microsoft.com/en-us/help/2984912/outlook-continually-prompts-for-your-password-when-you-try-to-connect


    Georg

    Freitag, 8. Dezember 2017 07:27
  • Problem gelöst:

    Ich habe Office deinstalliert, danach in der Registry den Pfad HKEY_CURRENT_USER\Software\Microsoft\Office vollständig gelöscht. Nach einem Neustart Office neu installiert und der Fehler war behoben.

    Ich hatte vorher schon eine Reparaturinstallation und eine Neuinstallation von Office durchgeführt, ohne Erfolg.

    In dem Pfad war aber kein Eintrag bezüglich der Autentifizierung zu finden, auch Autodiscover war es nicht. Erst das Löschen des vollständigen Pfad hat geholfen.

    Danke allen fleißigen Helfern.... :-)

    Grüße
    Norbert

    Freitag, 8. Dezember 2017 15:53