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. ;)

Bei uns hatte es ein Praktikant geschafft, die SSD aus dem Surface auszubauen, ohne das Gerät zu schrotten. Wenn es noch angeht, kannst Du mit Hilfe von ShredOS die Daten überschreiben lassen.

Bei unseren 2 Ex SE auch alles in Butter. ;)

Löscht Du denn auch das Computerkonto in der Domain, bevor du den Server wieder neu aufnimmst? Falls nein, dann mach das mal.

Es ist schon sehr lange dass ich ein Surface in Händen hatte, aber wie rudimentär das UEFI war, weiß ich heute nicht mehr. ;)

Wenn es die Möglickeit gibt, kannst Du es auch mal auf Default Einstellungen setzen. Ansonsten ist das mit dem Modern Standby ein ziemlicher Krampf.

Bei unseren HP-Laptops (HP EliteBook 660 G11) gab es dazu im BIOS/UEFI eine Einstellung die verändert werden musste. Evtl. ist das ja beim Surface ebenfalls der Fall. Du könntest auch schauen ob es eine aktueller BIOS/UEFI Version für das Gerät gibt.

WindowsUpdate mit allen Unterschlüsseln und Werten löschen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate Gleichzeitig den Server aus dem WSUS löschen! net stop wuauserv net stop bits rd /s /q %windir%\softwaredistribution shutdown -r -t 0 Anschließend in einer Admin Commandline: wuauclt /resetauthorization /detectnow [ENTER] 2 Minuten warten wuauclt /reportnow [ENTER] Die WSUS-Konsole aktualisieren, vermutlich musst Du den Server wieder in die richtige Gruppe verschieben, anschließend einfach mal über Nacht warten, sollte sich bis in der Früh wieder erholt haben.

@phatair Danke für die Infos. ;) BIOS-Updates enthalten immer wieder sehr viele Fehlerkorrekturen und es werden auch Sicherheitslücken gepatcht. Grundsätzlich ist es also eine gute Idee die von den Herstellern angebotenen BIOS-Updates regelmäßig zu installieren. EDIT: Die Discovery Services von Docusnap sind IMHO der DocusnapScript.exe vorzuziehen, da die Möglichkeiten an der Stelle der Discovery Services einfach viel umfangreicher sind. ;)

Ich bin mir nicht sicher, aber melde dich am Client doch mal mit dem MS-Konto an und ruf dann WU auf. Oder ist dein Weg genau der, der von MS exakt so dokumentiert wurde?

Wo versuchst du dich anzumelden? Am Kühlschrank oder an der Waschmaschine oder am Windows 10? Genauigkeit hat noch nie geschadet. ;)