Alle Aktivitäten

Zusätzlich: TLS Inspection vom AV / Sonstige AV Funktionen, die im Outlook / Webtraffic "rumwuseln"?

Zertifikate? TLS Inspection auf der Firewall? TLS Versionen in GPO ein-/ausgeschaltet?

Danke Evgenij für Deinen Hinweis. Das Ergebnis der Abfrage lautet: Invoke-RestMethod : Die Anfrage wurde abgebrochen: Es konnte kein geschützter SSL/TLS-Kanal erstellt werden.. In Zeile:1 Zeichen:1

Moin, was bekommst Du von Invoke-RestMethod -Uri "https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/<user>@<domain>?Protocol=EWS" zurück? Vom Domänen-Client, <user>@<domain> durch die Mail-Adresse des angemeldeten Users ersetzt.

Danke, der Vorfall ist mir bekannt und dieser ist auch noch offen. Allerdings bekomme ich nun eine Verbindung, nur nicht mehr aus dem betroffenen internen Netzwerk. Deshalb ist mein Gedanke, dass es doch nicht mehr an MS liegen könnte.

Hi, kann ich grad nicht testen, aber seit einigen Tagen ist das hier bei MS immer noch als Problem gelistet: https://admin.microsoft.com/Adminportal/Home?source=applauncher#/servicehealth/:/alerts/EX1113110

Hallo zusammen, folgendes Problem habe ich in einer AD-Domäne. Seit vergangenen Donnerstag, Patchday Microsoft, funktioniert kein Zugriff mehr über Outlook Classic, auch die Neueinrichtung eines Exchange Online Kontos ist in Outlook Classic nicht möglich. Der Zugriff über OWA funktioniert intern tadellos. Ebenfalls funktioniert der Zugriff über Outlook Classic und die Neueinrichtung eines Kontos tadellos, wenn die Clients sich außerhalb der internen Domäne und des dazugehörigen Netzwerkes befinden. Bei der Umgebung handelt es sich um eine mit HCW nach EXO migrierte Exchange 2019 Umgebung. Der Rückbau der Hybrid Struktur erfolgte, allerdings keine Deinstallation des Exchange onPrem 2019, dieser wurde nur heruntergefahren. Die Hardware Firewall habe ich ausgeschlossen, da ich testhalber keine Einschränkungen hatte. Überprüft habe ich im DNS den autodiscover Eintrag, dieser zeigt nach autodiscover.outlook.com. Weiterhin geprüft habe ich am onPrem Exchange den ClientAccessService Eintrag "AutoDiscoverServiceInternalUri", dieser ist leer. Jetzt fällt mir nichts mehr ein. Im Verdacht habe ich das AD, bin mir aber unsicher. Habt Ihr noch eine Idee? Danke Euch. Mario

Wenn man den Zustand hat,, kann man mit der Process Explorer den zuständigen Thread ermitteln, die CPU-Last verursacht. Wenn das nicht gerade eine OS-Thread ist, kann da Rückschlüsse auf den zuständigen Treiber finden. Ich könnte mir z.B. vorstellen, dass irgendein Consumer-Treiber eine interne Update- oder nach-Hause-Telefonier-Funktion hat und einfach seinen C&C-Server nicht erreichen kann. Wir hatten früher von Mutterkonzern DNS-Auflösung für alle Internetadresse, ohne dass die Server eine Verbindung herstellen konnten. Das kann zu Hängern führen, weil Verbindungsversuche in einen Timeout laufen.... https://learn.microsoft.com/de-de/sysinternals/downloads/process-explorer

Du musst Dir ein dickeres Fell zulege. Am Ende hat es was mit IT-Sicherheit zu tun. Und die MA wollen doch sicher nicht, dass Ihre Anforderungen dazu führen, dass man Richtlinien NIS2 oder DORA nicht einhalten kann. Und bloß keine Erklärungen gegen. Die will eh nicht hören. Bei uns kann niemand außer der Helpdesk USB-Sticks einlesen. Und sie müssen auch noch ein Ticket dazu stellen. Funktioniert. Musst aber die Transitionsphase meistern. Und wenn Mails nicht ankommen, meldet mach sich beim Helpdesk. Meist liegt es an einer fehlerhaften SPF-Konfig des Absenders. Oft ist die ungültig oder man hat irgendwas am Betrieb geändert und hat den SPF vergessen. Ein extremes Beispiel aus meiner Vergangenheit. Der Chef hatte damals keinen Computer und die Chefsekretärin hat ihm alle Mails ausgedruckt. Damals hatten wir eine Notes-Version, die bei Mails mit einer Löschmarkierung einen Papierkorb vor die Mail gemacht hat. Nun hat die Dame das Symbol umgedeutet. Da sie ja jede Mail ausgedruckt hat und den Ausdruck in das "Posteingangskörbchen" bei Chef gelegt hat, hat sie danach diese Mail mit dem "Körbchen" markiert. Sie wollte sie so nur markieren, aber nicht löschen. Plötzlich waren alle diese Mails weg, weil sie die Löschung final ausgeführt hatte. Und natürlich verstand sie es nicht, dass die Software richtig funktioniert hat...

Das begreifen IT-Deppen aber nicht. Für die ist das ein Fehler und es muss sofort eine Lösung her. Letztens wurde ich sogar gefragt was wir gedenken zu tun, wenn unsere Mails bei einem ganz bestimmten Empfänger in den Spamordner landen (trotz korrektem SPF und DKIM). Es ist manchmal echt zum Kopfschütteln. Die begreifen nicht oder wollen es nicht, dass ich keine fremden Mailsysteme administrieren kann.

Auch solche Fehler findet man ja nur, weil man sauber konfigurierte Systeme verwendet. ;)

In dem besagten Fall mit den 30 % waren nicht die Absender das Problem sondern es waren Fehler in den Mailservern von unserem Mailprovider. Aber komm da mal hinter, manche Mails gingen durch, manche nicht.

Ja genau. Dann erklärt man denen einfach, dass sie als Absender das Problem sind. In der allergrößten Not definiere ich eine Ausnahme mit einem Ablaufdatum. Haben sie es bis dahin nicht gelöst geht der Spaß von vorn los. Die wollen ihre Mail loswerden und ja ich hab auch schon mit Geschäftsführern deswegen zu tun gehabt, deren Mails ja immer die wichtigstens sind. ;) Hast du ne Ahnung. ;) Hinsichtlich Mail hab ich vermutlich häufiger Kontakt mit Anwendern als du. Im Übrigen mach ich mir sogar die Arbeit Fehler der Absender im Logfile proaktiv zurückzumelden. Und man staune es gibt sogar Absender die sich für die Meldung solcher Fehler bedanken.

Sorry für diesen Thread. Ich seh erst jetzt, dass es dieses Thema schon gab!

Na klar, das Log ist auf der richtigen Seite. Nur wie ich sagte, die IT-Deppen interessiert das nicht, die wollen ihre Mails fehlerfrei empfangen und senden. Kann mich noch eine Story erinnern, liegt schon länger zurück, da liefen die Mails ja noch über das Sammelpostfach. Unser Mailprovider hatte da bei etwa 30% aller Mails, die an unser Sammelpostfach gingen einen Fehler geworfen und die Absender mit tollen Fehlermeldungen informiert. Der Fehler war also nicht direkt bei uns, sondern beim Provider und trotzdem wurde bei uns geschimpft und gemeckert was das Zeug hielt und wir hätten da ja alle 10 Minuten beim Support anrufen und nach einem Status fragen müssen.

Das Skript macht im wesentlichen nichts anderes wie die hier bereits genannten Kommandos auszuführen inkl. der ProvisionedPackages. Nur halt in einer Schleife für alle gewünschten Apps und das Ganze dann mit Ergebnissen in einer Log-Datei.

Ich hab noch ein Script im Netz gefunden https://lukasz.de/anleitungen/copilot-von-windows-10-und-windows-11-mit-intune-entfernen/ Was haltet ihr davon?

Dann erklärt man denen, dass das Problem auf der anderen Seite liegt und man selbst da nichts machen kann. Muss ich unseren Leuten regelmäßig mitteilen, wenn mal wieder Mails wegen fehlerhaftem DKIM oder Absender-IPs auf RBLs abgelehnt werden. Ich gebe denen dann die entsprechende Info, die die dann im Zweifel dem Absender mitteilen können. Muss man halt nur durchziehen, das Log ist auf meiner Seite.

Irgendwie glaube ich, dass du nicht oft mit einfachen Anwendern Kontakt hast. Oder irre ich mich da? Versuch das mal IT-Deppen zu erklären, die wollen keine technischen Details hören sondern immer sofort ne Lösung. Auch wenn man selbst bzw. das eigene Mailsystem nicht das Problem ist.

Gut zu wissen, dass das Paketabhängig ist. Wäre ja auch zu schön, wenn sich das konsistent verhalten würde.

Das ist fast korrekt. Aber die Packages werden nachinstalliert, wenn sie provisioniert sind. Somit sind User, bei denen Remove-AppXPackage gemacht wurde, im Sinne der Provisioned Packages quasi "neu". Das ist aber keine Universalwahrheit, sondern von Paket zu Paket unterschiedlich. Manche respektieren das einmalige Entfernen, andere brauchen die Keule.

Doch nur das hilft. Wenn jeder sein System sauber konfiguriert hat, gibt es solche Probleme so gut wie nie. Ich werde den Teufel tun, und wegen solcher Kommunikationspartner mein sauberes System zu zerkonfigurieren. ;) bye norbert

Hast du die Befehle in einer administrativen Powershell laufen lassen? Nur dann funktioniert der Schalter -AllUsers. Ansonsten deinstalliert er nur für den angemeldeten Benutzer. Gilt das nicht nur für Nutzer, die noch nie angemeldet waren? Ich hatte das so verstanden, dass das Remove-AppxPackage mit -AllUsers für alle vorhandenen Profile greift und die ProvsionedPackages dann für neue.

Du musst noch die AppxProvisionedPackages entfernen, damit sie nicht wieder auftauchen.

Ok, ich belasse es so. Wenn mir die Jammerei zu viel wird gibt es ne Rundmail mit deutlichen Worten.