winmadness

UPN auf name@firma.de geändert und Outlook Profil angelegt. Das Benutzer Zertfikat neu erstellt und in Windows Anmeldeinformationen hinterlegt. Leider das gleiche Verhalten, nach wie vor Kennwortabfrage, diesmal mit "name@firma.de" als Benutzer.

Danke für den Tipp. Ist bereits deaktiviert, da ansonsten Autodiscover nicht funktionieren würde. Bis auf "ExcludeHttpsAutoDiscoverDomain" sind alle "Exclude..." Schlüssel deaktiviert.

Ich denke ich habe eine Spur. Unser Domainname lautet intern.de. Somit ist der UPN name@intern.de und hierüber erfolgt auch die Anmeldung am AD und die Erstellung / Anmeldung des Outlook Profils. Auch das Kerberos Ticket weist unter "Client" den Eintrag "name@intern.de" aus. Die primäre SMTP-Adresse (AD Feld "mail") ist name@firma.de (unsere offizielle Firmen-Domain). Auch in Outlook wird das Postfach unter "name@firma.de" angezeigt. Wenn ich nun über Outlook den "E-Mail-Autokonfiguration" Test durchführe muss über bei Eingabe der Adresse "name@intern.de" kein Passwort eingeben. Wenn ich aber den Test mit "name@firma.de" durchführe dann verlangt Outlook die Eingabe eines Passwortes. Ich trage dann als Benutzer name@intern.de und das entsprechende Passwort ein. Dann läuft der Test ohne Probleme.

Die Frage wie löse ich das Problem. Den UPN kann ich nicht ändern. Welche Auswirkungen hätte die Änderung der Mail-Adresse (AD Feld mail)?

Ich habe ein Problem mit der Outlook Authentifizierung. Outlook verlangt die Eingabe des Benutzerkennwortes, obwohl ein Kerberos-Ticket für Outlook existiert. Wenn ich die Kennwort-Eingabe abbreche startet Outlook normal und ich habe Zugriff auf alle Outlook Elemente / Ordner. Aber es wird immer wieder die Eingabe eines Kennwortes verlangt (bei Abbruch der Anforderung).
Folgende Konfiguration:
•    Windows Server 2016 mit allen Patches – eine VM als DC und eine VM mit Exchange Server 2016 mit allen Patches
•    Client Windows 10 mit allen Patches
•    MS Office 2016 mit allen Patches
•    VPN Verbindung über OpenVPN mit SSL (als UTM einmal WatchGuard VM und einmal OPNSense VM – bei beiden der gleiche Fehler)
•    Anmeldung an der UTM über einen VPN Benutzer
•    Kerberos Ticket wird über Benutzer Zertifikat (im AD beim Benutzer hinterlegt) gezogen
•    Das Benutzer Zertifikat ist im Windows Client in den Systemsteuerungen -> Windows-Anmeldeinformationen als „Zertifikatbasierte Anmeldeinformationen“ für die Domain hinterlegt
•    Zugriff auf Netzfreigaben über das Benutzer-Zertifikat / Kerberos-Tickt ohne Probleme möglich
•    Outlook Profil mehrmals neu angelegt, mit und ohne Exchange Cache
•    Outlook Verbindung über MAPIoverHTTP
•    In der Registry den Key „AuthenticationService„ unter „Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Security“ auf 16 = Kerberos-Kennwortauthentifizierung angelegt
•    Im ECP unter Server -> Virtuelle Verzeichnisse für die Authentifizierungs-Methode für Server-Typ „mapi“ nur „Windows-Authentifizierung – Kerberos“ aktiviert.

In der Outlook Übersicht „Verbindungsstatus“ wird mir unter Servername nur https://<exchange-server>/mapi/... und als Protokoll nur „http“ angezeigt. In der Spalte „Authn“ steht „Nego*“. Bei Abbruch der Passwort-Abfrage steht in der Outlook Statusleiste „Kennwort erforderlich“. Nach Betätigung des Buttons „Verbindung wiederherstellen“ im Verbindungsstatus-Fenster  kann ich normal weiterarbeiten – bis zur nächsten Kennwort-Abfrage z.B. bei Wechsel eines Ordners innerhalb meines Postfaches.
Ich kann trotz fehlender Kennwort-Eingabe ganz normal und fehlerfrei mit Outlook arbeiten.

Was mir dazu einfällt:

Sind die Ordner-Optionen für alle User gleich - also bzgl. Ansicht (versteckte Ordner etc.), Vorschauschaufenster, Detailbereich etc.

Wenn mit servergespeicherten Profilen gearbeitet wird evtl. für einen "langsamen" Nutzer dieses löschen und testen.

Wenn möglich einen neuen User mit Grundeinstellung anlegen und testen. Dann nach und nach die Einstellungen der "langsamen" User übernehmen.

Wenn Du über die Kommandozeile (cmd) Verzeichnisse anlegst zeigt sich dann das gleich Phänomen?

Wenn Du in den Ordner-Eigenschaften die Rechte anzeigen lässt werden alle Benutzer sofort angezeigt oder zuerst die SID und nach und nach erst die Benutzernamen?

Ein Test wäre auch noch für einen Ordner die Rechte für einen „langsamen“ Benutzer zu entfernen und dann wieder zuzuteilen. Vererbung ausschalten, Order anlegen und dann Rechte vergeben.

Sind die „langsamen“ User in anderen Gruppen als die „schnellen“?

Evtl. eine Regel. Entweder Client-Outlook Regel oder Server-Regel (Powershell Get-InboxRule). Läuft eine Dritt-Software, welche Zugriff auf das Postfach hat z.B. CodeTwo Software? Könnte auch eine Windows Aufgabe sein.

Nachtrag: Grundsatzfrage vergessen - was heißt verschwinden? Also Elemente sind nicht in "Gelöschte Elemente" und können auch nicht über "Gelöschte Elemente wiederherstellen" gefunden werden? Hast Du schon einmal eine Suche über das gesamte Postfach nach den Mails durchgeführt?

Wenn Du die Anzahl der Datensätze nur für die Schleife benötigst, dann würde ich die Schleife anders gestalten. Schaue Dir mal die Beispiele für sqlsrv_fetch_array bzw. sqlsrv_fetch_object an. Hier benötigst Du die Anzahl nicht.

Wenn Du trotzdem die Anzahl benötigst dann ermittle diese wie folgt (Voraussetzung Artikelnummer ist eindeutig):

SELECT count(a.Artikelnummer) as records
FROM   KHKArtikel a

Was mir noch einfällt:

• Sind weitere Netzwerk-Adapter vorhanden - z.B. durch eine VPN-Software (in der Systemsteuerung unter "Netzwerkverbindungen")
• Evtl. mal den Virenscanner deaktivieren
• Sind in den Netzwerkeigenschaften der Netzwerkverbindungen IPv6 deaktiviert? Der "korrekte Weg" zur Deaktiviertung von IPv6 wäre über die Registry: Anleitung von Microsoft

Ich würde mal die beiden VMs mit "privaten" und "external-" vSwitches testen.

Hast Du irgendwelche zusätzliche Optionen in den vSwitch aktiviert? Evtl. mal ein Screenshot der Einstellungen posten.

Hast Du schon die IIS Logfiles für EAS überprüft? Ein Eintrag endet mit vier Zahlen, wobei die erste Zahl den HTTP-Status angibt. "200" bedeutet erfolgreiche Ausführung, einen Fehler zeigt eine Zahl >= 400 an.

Bevor Du das Postfach neu anlegst würde ich folgendes testen:

• Ich kenne die Outlook App nicht, deshalb können die folgenden Einstellungen evtl. nicht umgesetzt werden: Wenn möglich, dann die Synchronisation von einzelnen Elmenten (Email, Kalender, Kontakte, Notizen, Erinnerungen / Aufgaben) deaktivieren und testen.
• Alle Elemente im Postfach ab dem 22.02.23 (Emails, Dokumente in Ordnern, Kontakte, Kalender, Notizen, Aufgaben etc.) in z.B. in einem PST-Ordner sichern und dann im Postfach löschen. Evtl. sehr aufwendig, je nach Ordnerstruktur.

Hier noch einige Tests, welche ich durchführen würde:

• Virenscanner deaktivieren
• ein Profil mit nur einem Postfach anlegen (Du hattest ja von einem Profil mit zwei Postfächern berichtet)
• MS Office reparieren
• die betroffenen Postfächer auf einem anderem Rechner testen, auf dem der Outlook Versand funktioniert

Hast Du die beiden Postfächer schon auf einem anderem Computer getestet?

Eine Idee wäre zum Testen mal den Virenscanner zu deaktivieren.

Betrifft der Fehler interne und externe Empfänger-Mail-Adressen oder nur bestimmte?

Ausserdem würde ich die Einstellungen in Outlook -> Optionen -> Erweitert -> Bereich "Senden und Empfangen" überprüfen. Neben der Option "Bei bestehender Verbindung sofort senden" kannst Du den Versand über die  "Senden-Empfangen-Gruppen" festlegen.

Wir haben Eset für Exchange im Einsatz. Aber eine klare "Nicht-Empfehlung". Das Handling, vor allem der White-Lists, ist "gewöhnungsbedürftig".

Hier mal meine Tests, welche ich in einer solchen Situation durchführen würde:

• Anmelden mit „domain\user“ und user@domain.tld
• Anmelden und mit Get-Credenital in der Powershell testen, ob eine Anmeldung mit den „anderen“ Benutzern möglich ist
• Roaming Profile für einen „fehlerhaften“ Benutzer deaktivieren, sofern damit gearbeitet wird
• Etwas „abwegig“, aber einen Test wert: den Windows 11 Rechner an einen „funktionierende Windows 10“ LAN-Anschluss anstecken

Die Einstellungen über die Registry ist die von MS empfohlenen Vorgehensweise. Hast Du schon den DC-ping-Test durchgeführt. Das wäre mein erster Test um zu sehen ob der DC bei bestehender Internetverbindung überhaupt erreichbar ist.

Welchen Cursor Type verwendest Du? Verwendest Du den Befehl sqlsrv_num_rows zur Ermittlung der Anzahl Datenätze? Möglicherweise helfen Dir die Ausführungen auf den verlinkten MS Webseiten bei der Fehlerfindung. Evtl. mal den Cursor Typ "SQLSRV_CURSOR_CLIENT_BUFFERED" mit der Option " ClientBufferMaxKBSize" testen (Beschreibung findest Du auf der "Cursor Type" Webseite).

Aus meine Erfahrungen mit ODBC Treibern würde ich auch mal versuchern zuerst den Cursor auf den letzten Datensatz zu positionieren ("SQLSRV_SCROLL_LAST") und dann die Anzahl der Datensätze abzurufen.

Wie sieht Dein Workaround aus?

Hallo Dirk,

dann also ein MS Dienst. Da der Fehler Mitte November aufgetretetn ist könnte ein Zusammenhang mit dem MS Patch Day bestehen. Also mal die Versioninfos zum November Patch Day heranziehen und prüfen, welche Dienst auf Deinem Server vom Patch betroffen waren.

Welche Rollen sind auf dem Server installiert? Wenn Du die Möglichkeit hast würde ich die Rollen-Dienste nacheinander deaktivieren und prüfen, ob der Fehler weiterhin auftritt.

Was sagt der ping auf den DC mit  und ohne Internet-Verbindung? Wird der Hostname korrekt aufgelöst?

Wie habt Ihr IPv6 deaktiviert - über die Eigenschaften der Netzwerk-Schnittstelle oder über die Registry? Der korrekt Weg wäre die Registry.

Hast Du schon die Standard-Lösungsansätze getestet: also OWA, Profil gelöscht - neu angelegt (auch mal von einem Rechner), Outlook "E-Mail-Autokonfiguration testen ...". Existiert der Benutzer1 noch im AD, evtl. verweist noch eine Mail-Adresse (alias, mailnickname etc.) auf den alten Benutzer.

Hast Du auch den Hinweis in der sqlsrv_query Doku bzgl. "SET NOCOUNT ON" gelesen. Bezieht sich zwar auf Update-Anweisungen, aber evtl. auch für Dein Problem nützlich.

Bekommst Du das selbe, falsche Ergebniss wenn Du mit sqlsrv_execute arbeitest?

Wäre ja auch zu einfach gewesen

Ich würde im ersten Schritt folgendes prüfen: In der Registry unter dem Key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog bzw. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application

müssen alle Anwendungen (Dienste) einen Eintrag haben, wenn Sie Einträge im EventLog erstellen. Deshalb mal prüfen, ob jeder installierter Dienst einen Eintrag in der Registry hat. Wenn nicht, dann könnte dies die Ursache für den EventLog-Eintrag sein. Zuerst die "Nicht-Micrsosoft-Anwendungen" prüfen..

Ich würde die ursprüngliche Regel löschen und eine neue erstellen. Ausserdem mit dem Powershell Command "Get-InboxRule" alle Regeln für das Postach anzeigen lassen.

Da Du das Datum der ersten Meldung kennst, würde ich mal in der Systemsteuerung -> Programme  nach dem Installationsdatum suchen. Evtl. findest Du damit den Verursacher.

Der Fehler lag an meinem Telekom Speedport Router, genauer an der Einstellung „DNS-Rebind-Schutz verwenden“. Über einen Eintrag der firma1.de und firma2.de als Ausnahme wird der Fehler behoben. Über die Ausnahme werden die IP-Adressen für die Autodiscover Subdomains autodiscover.firma1.de /.firma2.de korrekt aufgelöst. Unsere interne Domain ist intern.de. Werden nun per Automapping Postfächer oder z.B. Kalender-Freigaben eingehängt, dann werden diese über firma1.de bzw. firma2.de Adresse angesprochen. Gesucht wird also nach autodiscover.firma1.de /firma2.de. Der Speedport Router verhinderte durch den aktivierten „DNS-Rebind-Schutz“ die Auflösung dieser Adressen. 

Wir haben eine ähnliche Anforderung - ein MS Office 365 Kalender mit einem Exchange On-Prem Kalender zu synchronisieren. Wir haben hier das Tool ExMixedFolders von Somebytes im Einsatz. Diese kann Business-Konten mit lokalen Exchange Konten synchronisieren. Unterstützt auch die 2FA von MS Office 365.