Sunny61

Besser abschalten als konfigurieren, ist doch einfacher. :) @pischel Bitte zukünftig solche Fehlermeldungen in einem Code Block posten, ist übersichlicher.

Den Teil hatte ich schon beschrieben, und dass man meistens noch ein paar geplante Aufgaben deaktivieren muss, ist heute ja schon Standard. Und so eine Einstellung von wegen Updates deaktivieren, schreibt immer nur etwas in die GUI, deaktivieren tun es anschließend die wenigsten. Adobe und Foxit sind da sehr gute negative Beispiele. Danke auf jeden Fall für die Rückmeldung. ;)

Signiere die RDP-Dateien und arbeite diesen Artikel ab, dann sollte wieder Ruhe sein: https://www.gruppenrichtlinien.de/artikel/remoteapp-zertifikatsfehler-sha1-fingerprint

Mit einem Zertifikat signieren reicht nicht?

Doch, ich hab mehrere RDP-Dateien erfolgreich signiert. Sieht man dann auch Dialog. https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings Der Artikel wurde am 14.04.2026 aktualisiert, also gab es den Artikel schon vorher.

Du kannst mal versuchen die Update-Dienste vom Edge zu deaktivieren, allerdings befürchte ich, sie werden ziemlich schnell aktiviert werden.

Bei uns hat es nur Clients getroffen, die mit Settings vom gpPack beglückt sind, die Anzahl der Clients/User ist an der Stelle noch überschaubar. Welche Settings das verursachen weiß ich noch nicht.

Die Warnung kommt bei uns auch, mit dem Zertifikat kriegt man allerdings nur einen Teil weg, die Größe der Warnmeldung bleibt allerdings. Hinweis an die User, fertig.

Das hier könnte Besserung bringen: https://www.windowspro.de/thomas-joos/rdp-dateien-einem-zertifikat-signieren Probiert hab ich es noch nicht.

Hier mal eine von uns, Exchange SE, fully patched. Beginnt bei mir in Zeile 60 mit system.web. <system.web> <machineKey validationKey="AutoGenerate,IsolateApps" /> <authentication mode="Windows" /> <compilation debug="true"> <assemblies> <add assembly="Microsoft.Exchange.Configuration.Core, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Configuration.RemotePowershellBackendCmdletProxyModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Configuration.ObjectModel, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Configuration.RedirectionModule, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Data, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Common.Directory.DirectoryVariantConfig, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Configuration.FailFast, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Security, Version=15.0.0.0, Culture=neutral, publicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Exchange.Configuration.DiagnosticsModules, Version=15.0.0.0, culture=neutral, publicKeyToken=31bf3856ad364e35" /> </assemblies> </compilation> </system.web>

Wenn man via sich via IP zu Systemen verbindet, wird AFAIK KEIN Kerberos verwendet. Schau dir auch mal diesen Artikel an: https://www.gruppenrichtlinien.de/artikel/rdp-ohne-ntlm-richtlinien-und-verhaltensweisen-zur-reduktion-von-ntlm Weshalb auf den Domänen Laptops keine Domänenuser verwenden? Es spricht nichts dagegen. Eine einmalige Anmeldung des Users am Laptop gegen den DC, ab dann kann das Gerät offline sein. Wie im o.g. Artikel zu finden ist, immer mit dem FQDN innerhalb der Domain arbeiten.

Die Registry Keys in der Fehlermeldung habt ihr sicherlich schon kontrolliert, oder? Auch wenn es in dieser URL um Ex2016 geht, der Fehler geht IMHO in diese Richtung: https://azure365pro.com/exchange-management-shell-failurecategory-authz-setupversioninformationcorruptexception/ https://support.microsoft.com/en-us/topic/event-id-258-unable-to-determine-the-installed-file-after-you-uninstall-windows-powershell-2-0-1b34cdcf-7039-ff1f-af78-4e6c78cfe39d Die 'normale' PS funktioniert einwandfrei?

Zukünftig bitte als Text in einen Code-Tag posten, das erleichtert das Lesen ungemein. Bei deinem Bild sind am Anfang der ersten Zeile zwei Semikolon drin, die gehören dort bestimmt nicht rein. So sieht es von einem Windows Client aus: C:\Users\ich>echo %PATH% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps;C:\adb;C:\ADB\;C:\Users\ich\AppData\Local\Microsoft\WindowsApps; C:\Users\ich>

Besser Du verwendest einen DC mit W2022, 2025 soll man als DC noch nicht einsetzen. Hier noch 2 Artikel: https://borncity.com/blog/2026/01/16/windows-server-2025-drittanbieter-dienste-starten-auf-dcs-nach-kb5072033-nicht-mehr/ https://borncity.com/blog/2025/02/27/windows-server-2025-probleme-mit-msi-installationen-im-betrieb-als-dc/ Es findet sich auch hier im Forum den ein oder anderen Thread zu dem Thema. BTW: Überprüf doch nochmal die Domain Namen in deinen angegebenen Logauszügen.

Von mir auch gute Besserung. ;)