none
Outlook 2016 fragt ständig nach Benutzernamen und Kennwort

    Frage

  • Hallo,

    Auch wenn mein Problem ähnlich klingt, wie das von Herrn Schmidt, so haben mir die dortigen Lösungsvorschläge nicht weitergeholfen, da unsere Konten auf einem lokalen Exchange Server 2016 liegen.

    Hier nun das Problem, dass uns hier so langsam zu verzweifeln bringt.

    Am Montag, den 08.01.2018 wurden die letzten Windows Sicherheitsupdates auf den Arbeitsstationen installiert. inkl. Office 2016 Klick und Run Updates.

    Seit diesem Zeitpunkt kommt es bei 3 von 5 Outlook 2016 Clients vor, dass ständig nach Benutzername und Kennwort gefragt wird. Die Aufforderung kommt nicht nur beim Start, sondern ständig.

    Das Problem tritt unabhängig von der Windows Version auf, aber nur im Outlook 2016. Die Outlook 2013 Clients sind davon nicht betroffen.

    An dieser stelle möchte ich noch kurz unsere Serverumgebung erläutern:

    Der Exchange Server 2016 Standard läuft auf einem Windows Server 2012 R2 seit einem guten Jahr. Bisher hatten wir keine derartigen Probleme. Die Updates der Server werden monatlich durchgeführt. Der Windows Server 2012 R2 ist zusätzlich zu dem bestehenden Windows Small Business Server 2011 hinzugekommen. Der Exchange Server 2010 des Small Business Servers wird nur noch, aus Speicherplatzgründen, für nicht kritische Postfächer verwendet.

    Die Postfächer der Benutzer wurden alle erfolgreich auf den Exchange Server 2016 migriert. Wie gesagt, lief das ganze System auch bis zum Montag, den 08.01.2018 Stabil und ohne Probleme.

    Wir haben auf den Clients auch schon auf Grund des anderen Beitrags die Windows-Anmeldeinformationen der betroffenen Computer überprüft. Dort ist uns aber folgendes Aufgefallen:

    Es existieren 2 generische Anmeldeinformationen für Office

    Eine mit dem Namen "MicrosoftOffice16_Data:SSP:User@doman.local" mit leeren Eintrag unter Benutzername

    Und Anmeldeinformation Namens "Outlook.office365.com" mit dem lokalen Domain Logindaten des Users unter Benutzernamen

    Dieses ist für mich dahingehend verwunderlich, da wir Office365.com nicht nutzen.

    Bei den Systemen, wo nur die erste Anmeldeinformation steht, funktioniert alles ohne Probleme.

    Auch, wenn wir alle beiden Anmeldeinformationen löschen, so bleibt das Problem bestehen, da alle beiden Anmeldeinformationen beim nächsten Outlook 2016 Start wieder neu erstellt werden.

    Ich weiß jetzt nicht, ob das die Ursache ist oder ob mit einem Mal ein Problem mit dem Autodiscover auftritt.

    Jedenfalls wäre ich über einen Lösungsvorschlag sehr, sehr dankbar.

    Mit viele Grüßen

    Heiko Witt


    Heiko

    Dienstag, 9. Januar 2018 16:40

Alle Antworten

  • Hallo,

    Das darf ja wohl nicht wahr sein, Microsoft. Wir haben hier denselben Fehler, aufgetreten zum selben Zeitpunkt ohne jedwede Veränderung am Server und auch ich habe mich über diese merkwürdige Office365.com Anmeldeinformation gewundert. Ich habe auf dem Server keinen Fehler finden können, dabei sämtliche Virtual Directories neu erzeugt und die Authentifizierungsmethoden geprüft, leider ohne Erfolg.

    Durch das Tool "E-Mail-Autokonfiguration Testen" von Outlook werden auch ebendiese Zeile ausgegeben:

    AutoErmittlung für https://outlook.office365.com/autodiscover/autodiscover.xml wird gestartet.
    GetLastError=0; httpStatus=401.
    AutoErmittlung für https://outlook.office365.com/autodiscover/autodiscover.xml Fehlgeschlagen (0x80040413).

    Zwischen der zweiten und dritten Zeile kommt hierbei auch die Aufforderung ein Kennwort einzugeben.

    Wie kann es sein, dass wir eine Offline-Installation nutzen und dabei dennoch von Microsoft über deren Server einen Fehler aufs Auge gedrückt bekommen?

    Mit freundlichen Grüßen,

    Bernd Rinker


    • Bearbeitet RBCOM Dienstag, 9. Januar 2018 20:43
    Dienstag, 9. Januar 2018 20:43
  • Wie kann es sein, dass wir eine Offline-Installation nutzen und dabei dennoch von Microsoft über deren Server einen Fehler aufs Auge gedrückt bekommen?

    Moin,

    ein Teil der Antwort ist hier enthalten: https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover . Versuch mal, die beiden Abfragen nach O365 Endpoints in der Registry zu deaktivieren, wie in dem Artikel beschrieben.

    Ob ihr eine "offline" Installation nutzt, spielt übrigens keine Rolle. Es gibt haufenweise Firmen, die eine VL-Installation nutzen, um auf Exchange Online zuzugreifen, und es gibt euch viele, die eine O365-Installation nutzen, um auf on-premises-Exchange zuzugreifen.


    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 -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 9. Januar 2018 21:27
  • Hallo,

    habe exakt das gleiche Problem. Seit gestern soll bei einigen Windows 10 Rechnern laufend das Passwort in Outlook eingegeben werden.

    Tritt soweit ich bisher sehe nur bei Windows 10 und Outlook 2016 auf.

    (Unter Windows 7 ist das Problem bisher nicht aufgetreten.)

    Auch hier wird der Eintrag für die Office365.com Anmeldedaten erstellt.

    Zugegriffen wird auf einen Hosted Exchange (kein Office365) - und komischerweise tritt das Problem nicht überall auf.

    Kann das Problem auf meinem Windows 10 Rechner mit Outlook 2016 (und dem gleichen Hosted Exchange) NICHT nachvollziehen - dafür haben mehrere Kunden das Problem.

    Habe den Verdacht dass das Problem durch zusätzliche Postfächer "verschlimmert" wird. Bei einem Account habe ich alle zusätzlichen Postfächer (Vollzugriff) entfernt - und die Passwort-Abfragen haben aufgehört. Kann aber auch Zufall sein...

    Mal sehen ob das deaktivieren der Autodiscover-Abfragen etwas bringt...

    Gruss

    Stefan Schuster

    Dienstag, 9. Januar 2018 23:56
  • Ob ihr eine "offline" Installation nutzt, spielt übrigens keine Rolle. Es gibt haufenweise Firmen, die eine VL-Installation nutzen, um auf Exchange Online zuzugreifen, und es gibt euch viele, die eine O365-Installation nutzen, um auf on-premises-Exchange zuzugreifen.

    Guten Morgen,

    prinzipiell mag ich Ihnen da recht geben, aber zum einen sehe ich es nicht unbedingt als notwendig an, "heuristisch" festzustellen, ob es sich um eine O365 Anmeldung handelt. Ich hätte beispielsweise bei der Einrichtung kein Problem damit, dem Programm eindeutig zu sagen, dass es sich um eine On-Premise Lösung handelt. Das wäre ein Radiobutton, dann wäre diese Problematik nie aufgetreten.

    Und bei einer On-Premise Lösung sehe ich nicht ein, dass es einem O365-Server meinen Benutzernamen und mein Kennwort überträgt, um dann einen 401-Fehler zurück zu bekommen.

    Da der Fehler zeitgleich bei mehreren Kunden aufgetreten ist, bedeutet das ja, dass irgendetwas an den Servern von Microsoft verändert wurde, um diese Fehlermeldung hervorzurufen. Und das ist genau der Punkt, der mich daran aufregt. Dass ein Produkt von heute auf morgen nicht mehr richtig funktioniert - und zudem eine "Fehlermeldung" ausspuckt, die in Verbindung mit dem Exchange Server ohnehin gerne auftritt und für die man im Internet eine massive Zahl an Lösungen findet - ohne es auf ein Update oder eine andere Einflussnahme zurückführen zu können, ist eine beabsichtigt eingebaute Zeitbombe. An dieser Stelle wäre zumindest in der Eingabemaske ein Text wie der Server, der nach dem Benutzernamen und dem Kennwort fragt ein unfassbar hilfreicher Hinweis.

    Aber gut, es hat noch nie etwas gebracht, sich über Microsoft aufzuregen, die interessieren sich ohnehin nicht dafür, wie viel Zeit die Suche nach ihren Fehlern kostet. Ihnen auf jeden Fall vielen Dank, der Registrierungseintrag

    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
    "ExcludeExplicitO365Endpoint"=dword:00000001
    
    funktioniert. Outlook versucht offensichtlich nicht mehr auf den O365 Server zuzugreifen und die Fehlermeldung kommt nicht mehr. 

    Gruß,

    Bernd Rinker

    • Als Antwort vorgeschlagen CGM777 Donnerstag, 11. Oktober 2018 10:14
    Mittwoch, 10. Januar 2018 08:55
  • Habe das soeben auch getestet - funktioniert bisher einwandfrei.

    Danke.

    Gruss

    Stefan Schuster

    Mittwoch, 10. Januar 2018 13:32
  • Hallo,

    Vielen Dank,

    Ich habe es eben auch auf den betroffenen Systemen getestet und bisher funktioniert es auch dort wieder einwandfrei.

    Bis zum nächsten Update. ;-)

    Vielen Dank noch einmal.

    Viele Grüße,

    Heiko


    Heiko

    Mittwoch, 10. Januar 2018 14:49
  • Hallo Herr Rinker,

    ich kämpfe ebenfalls mit dem selben Problem. Leider bin ich nicht so firm in der Änderung von Registry-Einträgen. Wäre es möglich, dass Sie mir die Änderungen Schritt für Schritt erläutern?

    Über eine Rückmeldung wäre ich Ihnen sehr dankbar.

    Beste Grüße

    Stefan Preuß

    Montag, 26. Februar 2018 20:46
  • Hallo

    Auf dem Computer den Registry Editor starten (regedit.exe)

    HKEY_CURRENT_USER erweitern bis zu Autodiscover:
    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]

    Rechter Mausklick in das rechte Fenster - New - DWORD (32-bit) Value

    Diesen mit ExcludeExplicitO365Endpoint benennen und den Wert auf 1 setzen.

    Hoffe das hilf weiter.

    Gruss
    Pano


    Pano Boschung, PageUp AG

    Dienstag, 27. Februar 2018 10:37
  • Vielen Dank!

    Das habe ich soweit gemacht. Das Exchange-Konto ist eingerichtet und ich kann senden / empfangen. Aber das Problem ist noch nicht vollständig behoben. Leider erscheint noch ständig das Anmeldefenster mit Benutzername / Passwort.

    Was kann ich noch tun?

    Gruß

    Stefan

    Dienstag, 27. Februar 2018 13:30
  • Moin,

    dann mache bitte einen eigenen Thread auf und verlinke auf diesen Beitrag hier.

    Es muss meiner Meinung nach bei euch eine andere Ursache haben.

    Bist du auch der Exchange-Admin?


    Gruß Norbert

    Dienstag, 27. Februar 2018 13:49
    Moderator
  • Vielen Dank für den Hinweis, hatte selbiges Problem nach Install. von Office 2016!

    Mfg

    Argie1707

    Mittwoch, 7. März 2018 12:15
  • genial - Danke - das funktioniert phantastisch!

    Freitag, 13. Juli 2018 22:32
  • Hallo,

    vielen Dank. Hat bei uns auch gut funktioniert.

    Viele Grüße.

    Donnerstag, 11. Oktober 2018 10:15
  • ExcludeExplicitO365Endpoint=1 hat in einem Kundensetup heute nicht funktioniert. Dort trat das Problem bei manchen Nutzern seit heute andauernd auf. Aufgefallen ist es wegen einem neuen Eintrag in der Anmeldeinformationsverwaltung für outlook.office365.com, der die gespeicherten Anmeldedaten local-AD-domain\b.enutzername enthielt. Die einzige Möglichkeit, die das Problem behoben hat, war Schaffung von Split-DNS für outlook.office365.com auf dem lokalen DNS Server. Dort haben wir dann einen A-Record gesetzt, der auf den lokalen Exchange 2016 Server zeigte.

    split dns outlook.office365.com

    Wenn das Problem mit Outlook besteht, wandern ungefragt und untransparent Zugangsdaten an Microsoft Server – aber die Daten sind bestimmt sicher und werden nur "zur Verbesserung der Servicequalität aufgezeichnet ®".



    • Bearbeitet L_Herzog Montag, 15. Oktober 2018 09:33
    Montag, 15. Oktober 2018 09:29
  • Wenn das Problem mit Outlook besteht, wandern ungefragt und untransparent Zugangsdaten an Microsoft Server – aber die Daten sind bestimmt sicher und werden nur "zur Verbesserung der Servicequalität aufgezeichnet ®".

    Naja, "ungefragt" ist in diesem Fall eine Frage der Definition.

    Der User wird ja nach einer Anmeldung gefragt, und es ist *auch* eine Aussage über die Qualität und Quantität der User-Schulung, ob er in jedes Fenster, was da aufpoppt, seine AD-Creds eingibt.

    Und ja, ich meine ganz im Ernst, dass in einer sicherheitsbewussten Organisation den Nutzern dringendst eingeschärft werden sollte, den SD anzurufen, bevor sie ihre Creds irgendwo eintippen, was sie bisher noch nicht kannten.


    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 -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 15. Oktober 2018 10:11
  • Wie du schon schreibst, ist es eine Frage der Definition. Outlook fragt berechtigt gelegentlich, z.B. nach Postfachmigration oder Kennwortänderung nach Credentials. Das ist also ein Fenster, das die User kennen , das auch sichtbar mit Outlook zusammenhängt und wo sie auch die Daten eintragen *sollen*. Untransparent hieran ist nur, dass weder der User noch der Admin auf den ersten oder zweiten Blick sieht, wohin die Credentials geschickt werden.



    • Bearbeitet L_Herzog Montag, 15. Oktober 2018 10:35
    Montag, 15. Oktober 2018 10:34