winmadness

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.

Hallo Norbert, vielen Dank für Deine Antwort. Da wir mittelfristig sowieso planen auf MS 365 umzusteigen ist der Einsatz von EOP naheliegend. Im Moment haben wir ein Produkt von ESET im Einsatz. Hier ist die Bedienung "suboptimal".

Wir haben einen MS Exchange Server 2016 On-Prem im Einsatz. Ich würde gerne den bestehenden Spam-Filter ablösen und MS 365 wie folgt verwenden: über MS 365 Connectors unseren Exchange Server verbinden und darüber den gesamten SMTP Verkehr laufen lassen. Im Moment haben wir nur einige MS 365 Konten für externe Mitarbeiter und MS Teams im Einsatz. Zwei Fragen hierzu: · Reicht der MS 365 „Spamfilter“ oder benötige ich noch ein zusätzliches Produkt auf dem MS Exchange Server · Soweit ich mich informiert habe benötigen wir mindestens ein Exchange Online Protection Abo für jedes Postfach, richtig?

Na ja die Lebenserfahrung zeigt dass man solche Dinge nicht geheimhalten kann. Aber das soll nicht unser Problem sein. Hier noch ein Nachtrag bzgl. Hardware ID - mit Powershell auszulesen: get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

OK, verstanden. Was ich aber dann nicht verstehe ist das Grundproblem. So wie das klingt kann es sich nicht um ein schützenwertes Dokument handeln, wenn so viele Leute Zugriff erhalten. Also ich denke mit Geheimhaltung ist an einem "öffentlich Ort" nicht weit her, oder irre ich mich? Nachtrag: Wenn Du bei der PS Script Lösung bleiben willst würde ich nicht die MAC Adresse verwenden sondern eine "eindeutige Hardware ID" verwenden. Leider kann ich hier nicht weiterhelfen da ich mich damit nicht beschäftig habe. Evtl. das Passwort im Script verschlüsseln.

Und die nutzen alle den selben PC bzgl. der MAC? Oder hat jeder einen eigenen PC und Du musst das Skript entsprechend anpassen bzw. hunderte MAC Adressen eintragen?

Das stimmt nicht ganz - man kann durchaus aus einer exe-Datei mit etwas Aufwand ein unverschlüsseltes Passwort auslesen. Aber ich denke für Deine Anwender sollte der Schutz (evtl.) reichen. Aber das Problem bleibt, auch das Skript kann samt der PDF Datei kopiert und damit auf jedem Computer geöffnet werden. Die MAC-Adresse kann man einfach ändern (fünf Minuten googeln und es schafft jeder Laie). Was ich damit sagen will Dein Ansatz führt meiner Meinung nach in die falsche Richtung. Wenn jemand wirklich das Dokument kopieren und auf einem anderen Rechner öffnen will so kann er dies mit etwas Aufwand tun. Und wenn Du davon ausgehst dass ein Mitarbeiter das Passwort abfängt kannst Du auch davon ausgehen dass die Energie ausreicht um die MAC-Adresse zu ändern. Mein Ansatz wäre ein technischer und organisatorischer. Ich würde die PDF Datei mit Passwort und den PDF eigenen Sicherheitseinstellungen versehen. Für jede berechtigte Person eine Kopie mit individuellem Wasserzeichen und Passwort erstellen. Des Weiteren das Dokument z.B. nur über OneDrive bereitstellen. Dort kann man das Downloaden / Kopieren und Drucken verhindern (bin mir aber nicht sicher ob das nicht ein findiger Anwender umgehen kann). Den Mitarbeiter auf das individuelle Wasserzeichen hinweisen mit dem Verbot der Weitergabe. Bei einem Leak weißt Du wer es war.

"Verschlüsselt" Du das Skript auch? Wenn nicht, dann kann jeder durch einen kurzen Blick in das Skript das Passwort ermitteln und somit das PDF Dokument öffnen. Oder habe ich hier einen Denkfehler? Besser wäre es doch die PDF eigenen Zugriffsbeschränkungen / Sicherheitseinstellungen zu verwenden. Also alle Einschränkungen bzgl. Drucken, Bearbeiten und Kopieren im PDF Dokument setzen. Dann hast Du den gleichen Effekt wie mit dem Skript mit dem Vorteil, dass Du das Passwort gezielt an berechtigte Personen weitergeben kannst. Mit der derzeitigen Lösung reicht in kurzer Blick in das Skript und jeder kann das Dokument öffnen. Und wenn Du das Skript nur an berechtigte Personen weiter gibst haben die trotzdem die Möglichkeit das Passwort aus dem Skript zu ermitteln. Das große Problem bleibt, jeder der das Passwort hat (egal ob aus dem Skript ermittelt oder wie bei meinem Vorschlag von Dir mitgeteilt) kann das Dokument kopieren.

Outlook hat Selbstheilungskräfte. Nach und nach erschienen die Delegate Folder in meinen Postfach. Jetzt kann ich auch darauf zugreifen. Ich habe keine Änderungen am System vorgenommen, nur normal mit Outlook gearbeitet. Mal sehen wie lange das Wunder anhält.