basstscho

Ich hab zwei VMs mit 22H2: 1x quasi alles deaktiviert (Smart Control, Defender, .... alles was ich irgendwie in den Zusammenhang mit SRP bringen konnte), die zweite frisch installiert und die neusten Updates von Microsoft geladen. Bei beiden ging SRP nicht, aber dafür der AppLocker. Was mir noch einfällt: Ich konnte den AppIdSvc nicht deaktiveren. Läuft auf deinen Rechnern der Dienst?

Neuinstalliert hab ich jetzt nicht, aber auf zwei VMs ist es eindeutig: Wenn ich eine Pfad-Änderung in der AppLocker-GPO durchführe (z.B. Ausführen von Anwendungen vom Desktop aus), dann werden die angewendet bzw. auch nicht, wenn sie gelöscht werden. Die müssten bei Win11 Pro ja eigentlich ignoriert werden.

Da ich mich schon damit abgefunden habe zukünftig auf die Enterprise-Version wechseln zu müssen, hab ich mich in meinem Testsystem mal mit dem Thema AppLocker beschäftigt. Ich hab aus Faulheit die AppLocker-Einstellungen einfach mal in der gleiche GPO gepackt, wie die vorab konfigurierten SRP. Dann hab ich mich auf dem Win 11 Pro 22H2 eingeloggt und konnte auf einmal meine Test-exe auf dem Desktop nicht mehr ausführen - interessant! Den "erzwingen"-Haken entfernt -> ich konnte die Datei wieder ausführen. Auf meinem Testsystem ziehen die vollen AppLocker-Regeln auf der Pro-Version. Kann das eventuell auch erklären, dass bei manchen Installationen vermeintlich die "SRP" funktioniert hat, es aber in Wahrheit die parallel konfigurierten AppLocker-Einstellungen waren? SRP deaktivieren und dafür den AppLocker auf den Pro-Versionen zu aktivieren wäre für mich fair und verständlich.

Über den Link bin ich auch schon gestolpert, aber ich möchte ja eigentlich in Summe nicht auf den AppLocker setzen, sondern einfach die SRP nutzen. Sollte also jemand erfolgreich Win11 Pro 22H2 mit SRP im Einsatz haben bitte melden. Bei mir hat es bei zwei Installationen nicht geklappt!

Hallo zusammen, hat in der Zwischenzeit jemand ne Info bzgl. der SRP in Win11 Pro 22H2 bekommen können? Danke und Grüße, Johannes

Zusammengefasst: - Win11 Pro 21H2: funktioniert wie erwartet - Win11 Pro 22H2: keine Funktion des SRP Ich hab nun aber mal das Detail-Logging auf beiden Rechnern aktiviert. Interessant ist Folgendes: - Auf dem 21H2 erscheint wie erwartet im Log: ....exe as Unrestricted using path rule, Guid = ... ....exe as Disallowed using default rule, Guid = ... - Auf dem 22H2 erscheint immer die für mich unbekannte Regel SRPv2 ....exe as Unrestricted using SRPv2 rule, Guid = ... Es sieht also so aus, wie wenn sich da was einmischt - vermutlich der AppLocker. Dem bin ich nochmal etwas nachgegangen und hab festgestellt, dass auf dem 22H2 der Anwendungsidentität-Dienst ausgeführt wird (obwohl der Service auf manuell steht) und auf dem 21H2 nicht. Ich hab daraufhin lokal auf dem 22H2 die AppLocker-Einstellungen geprüft: Sie sind leer, ich hab sie dennoch zurückgesetzt und unter C:\Windows\System32\AppLocker die Regel-Dateien gelöscht. Den Dienst beendet und mein Glück erneut versucht. Es greift immer noch die SRPv2-Regel. Nach nem Neustart war der Anwendungsidentität-Dienst wieder gestartet (Abhängigkeiten und Beschreibung des Dienstes sind 1:1 wie im 21H2). Daher habe ich in der Registry den Dienst manuell auf Status 4 gesetzt (=deaktiviert). Nach dem Neustart war der Dienst nicht aktiv, aber die SRPv2 hat immer noch gezogen. Eine Suche in der Registry nach SRPv2 war leider auch ergebnislos. Ebenso sind die klassischen Reg-Speicherorte für die SRP auch leer. Frage 1 ist somit, wieso in der Installation vom 22H2 der Anwendungsidentität-Dienst nun wohl standardmäßig ausgeführt wird und Frage 2), wie ich ihn wieder los werde ;) Vielleicht hat ja jemand von euch AppLocker-Profis ne Idee dazu. Grüße, Johannes

Hab ich gerade versucht - leider erfolglos. Auf einem W11 Pro 21H2 funktionieren die SRP dahingegen einwandfrei.

Gestern hab ich noch nen PC mit Win 10 Pro in die OE umgehängt und die Einstellungen haben sofort funktioniert. Es hängt also scheinbar am Win11 Pro 22H2. Leider hab ich nicht die Enterprise im Einsatz :/ Hintergrund der Einführung ist natürlich der erweiterte Schutz gegen Schadsoftware. Habt ihr neben der SRP (/Applocker) noch eine Empfehlung dafür?

Vielen Dank für eure Rückmeldungen. Ich möchte das tatsächlich auf Computer-Ebene umsetzen, habe es aber nun zwischenzeitlich auch mal parallel auf Benutzer-Ebene konfiguriert und per default auf "nicht erlaubt" gesetzt. Zur Eingewöhnung wollte ich zunächst mal mit der Blacklist anfangen. Meine Konfiguration ist also vergleichbar mit der von Sunny61, aber es möchte einfach nicht funktionieren. Die GPO greift (ich kann über rsop die Einstellungen auf Computer und Benutzerebene sehen), zeigt aber keine Wirkung. In der Ereignisanzeige taucht diesbzgl. auch kein Fehler auf. Bei der weiteren Suche bin ich nun auf ein paar Artikel gestoßen, in denen beschrieben wird, dass Microsoft das Feature ab 1803 nicht mehr aktiv weiterentwickelt. Ich hab hier ein Win 11 Pro 22H2. Hat zufällig jemand die SRP unter dieser Version laufen? SRP_GPO.pdf

Hallo zusammen, ich bin gerade dabei in einer Testumgebung die "Richtlinien für Softwareeinschränkungen" zu testen. Das ganze ist in einer GPO konfiguriert und ich verwendet den "Blacklist-Ansatz". Sprich standardmäßig ist alles erlaubt, aber in einigen Verzeichnissen sollen keine exe-Dateien ausgeführt werden dürfen. Dazu habe ich ein paar Pfade konfiguriert (siehe Screenshot). Die GPO wird auch auf dem Rechner angewendet (der Screenshot ist von rsop.msc). Allerdings kann ich nach belieben exe-Dateien in den angegeben Pfaden ausführen (egal ob als Administrator oder Benutzer). Die Reg-Pfade sind "C:\windows" und "C:\Program Files\Common Files" und dürften folglich nicht vorab greifen. Hab ich noch irgendeine Einstellungen übersehen, bzw. kann die Richtlinie von einer anderen "übersteuert" werden? Danke und Grüße, Johannes

Vielen Dank für eure Rückmeldungen. Die Lancom sehen von der Beschreibung tatsächlich vielversprechend aus - werde ich definitiv ausprobieren. Mir kam am Wochenende noch eine Idee: An manchen dieser mobilen Arbeitsplätze haben wir auch ein Notebook, dass zur Eingabe verwendet wird. Ich möchte daher mal Versuchen diese ominöse Windows-Verbindungsbrücke zu verwenden. In Theorie könnte das klappen, über die Praxis halte ich euch auf dem Laufenden :) Grüße, Johannes

Hallo zusammen, wir haben auf einem mobilen Arbeitsplatz (ein Rollwagen mit Batterie und DC/AC-Wandler) ein Gerät, dass leider nicht WLAN fähig ist. Ich würde daher gerne einfach einen AP im Client-Mode dazwischen schalten und das Gerät somit WLAN-fähig machen. Da der Arbeitsplatz mobil ist, wechselt er zwischen mehreren Hallen und folglich sollte der AP die Verbindung zu den entsprechenden APs mitziehen. Wir haben aktuell einen älteren Cisco-AP dazu im Einsatz, der sich leider nur zur MAC-Adresse eines AP verbindet. Sobald dieser außer Reichweite ist, ist somit auch die Verbindung weg. Laut Dokumentation haben viele APs die Client-Funktion. Eine tiefere Funktionsbeschreibung bzgl. Roaming bleibt aber leider aus. Bevor ich nun alle günstigen Geräte kaufe und Teste: Kennt ihr einen AP (egal welche Marke, egal ob auch mehr Funktionen), der genau das kann? Ein kurzer Verbindungsabbruch zwischendurch ist unproblematisch, die Datenrate ist absolut vernachlässigbar und 2,4 und 5 Ghz sind als Host-Netz verfügbar. Danke und Grüße, Johannes

Hallo zusammen, das Thema Bildschirmhintergrund über GPO ist eigentlich ausführlichst im Internet dokumentiert - bisher habe ich es auch immer hinbekommen. Nun habe ich aber ein Problem bei dem ich nicht weiterkomme: Bei einigen unserer Arbeitsplätze wurde bisher mittels einer .theme-Datei die grundlegende Design-Einstellung erzeugt. Das soll sich nun ändern und ich habe alles relevante direkt über die entsprechenden GPOs angepasst. Ebenfalls soll in dem Zusammenhang auch der Bildschirmhintergrund über die GPO gesetzt werden. Die Datei wird hierzu lokal auf den Rechner kopiert wird und entsprechend darauf verwiesen. Logge ich mich mit einem neuen Benutzer ein klappt das wunderbar und der Desktophintergrund ist gesetzt. Bei den bestehenden Profilen, die ursprünglich mittels der .theme "erstellt" wurden, verhält es sich anders: Der Desktophintergrund ist schwarz. Folgendes habe ich geprüft und getestet: - Da es bei neuen Benutzern funktioniert, gehe ich davon aus, dass mit meinen GPOs soweit alles passt - Wenn ich bei bestehenden Benutzern das Profil lösche und mich dann wieder neu einlogge funktioniert es auch -> Rechte sollten also auch nicht das Problem sein. Das Löschen der Profile ist aber natürlich keine Option. - Bei den bestehenden Benutzern habe ich das Windows-Design gewählt und das alte gelöscht. - In der Registry der Benutzer ist der richtige Pfad zum Hintergrund-Bild gesetzt (kommt also über die GPO an - das zeigt ebenfalls die rsop.msc) - In den "Energieoptionen" und der "Erleichterten Bedienung" ist der Bildschirmhintergrund ebenfalls überall aktiv - Die Vorschau bei "Anzeigeeinstellungen->Hintergrund" zeigt das Hintergrundbild, das eigentlich angezeigt werden soll - es erscheint nur nicht auf dem Desktop. - Ich habe testweise die typischen Cache-Files gelöscht: "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Themes\TranscodedWallpaper" & "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Themes\CachedFiles\*" Was mir aufgefallen ist: - Bei den neuen Profilen wird sowohl das TranscodedWallpaper als auch das Bild in den CachedFiles erzeugt. Bei den bestehenden Profilen wird nur das TranscodedWallpaper erzeugt. Der Cached-Files-Ordner bleibt aber leer. Hat jemand von euch eine Idee an was das noch liegen kann? Danke für eure Hilfe und Grüße, Johannes

Hallo zusammen, es gibt mehrere Internetanschlüsse, die alle über einen Loadbalancing-Router zusammengefasst werden und somit den Clients/Servern eine "eindeutige" Route aufweisen. Ich möchte aber für einen Admin-PC, dass dieser unabhängig vom Loadbalancing-Router (falls da mal was ausfällt) ins Internet kommt, um im Notfall über z.B. Teamviewer auf zumindest diesen PC zuzugreifen und dann nötige Maßnahmen ergreifen zu können. Daher möchte ich testen ob die Gateways tatsächlich ins Internet kommen und dann das default-Gateway automatisch ändern. Das Problem konnte ich nun identifizieren: Bei meinen Tests hab ich den Zugriff auf die 192.168.249.2 einfach komplett in der Firewall des Gateways blockiert. Somit hat Windows keine Antwort vom Gateway erhalten und dann das nächst beste (=das default-Gateway) als Route genommen. Ich hatte fälschlicherweise erwartet, dass der Ping in einen timeout läuft. Mein Script habe ich daher wie folgt angepasst: Ich prüfen zunächst ob das Gateway überhaupt erreichbar ist und erst bei Erfolg setze ich die Route und prüfe die Verbindung ins Internet. Danke und Grüße, Johannes

Hallo zusammen, ich habe hier im Netz zwei Gateways (192.168.249.1 und 192.168.249.2). Default Gateway ist das 192.168.249.1. Nun möchte ich überprüfen, ob über das Gateway 192.168.249.2 eine Verbindung ins Internet funktioniert. Dazu möchte ich eine Test-IP anpingen (in dem Fall die 8.8.8.8). Unter Linux habe ich den Ansatz schon öfters verwendet, unter Windows klappt das aber aus mir nicht erklärlichen Gründen nicht: - route add 8.8.8.8 mask 255.255.255.255 192.168.249.2 - ping ausführen - route löschen IPv4-Routentabelle =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.249.1 192.168.249.40 281 8.8.8.8 255.255.255.255 192.168.249.2 192.168.249.40 26 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 192.168.249.0 255.255.255.0 Auf Verbindung 192.168.249.40 281 192.168.249.40 255.255.255.255 Auf Verbindung 192.168.249.40 281 192.168.249.255 255.255.255.255 Auf Verbindung 192.168.249.40 281 224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331 224.0.0.0 240.0.0.0 Auf Verbindung 192.168.249.40 281 255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 255.255.255.255 255.255.255.255 Auf Verbindung 192.168.249.40 281 =========================================================================== Ständige Routen: Netzwerkadresse Netzmaske Gatewayadresse Metrik 0.0.0.0 0.0.0.0 192.168.249.1 Standard =========================================================================== Ergebnis: tracert 8.8.8.8 Routenverfolgung zu dns.google [8.8.8.8] über maximal 30 Hops: 1 <1 ms <1 ms <1 ms 192.168.249.1 ... Windows verwendet also trotz der spezifischen Route zum anderen Gateway offensichtlich das Standard-Gateway. Das Verhalten kann ich mir leider nicht erklären. Muss man die routing-Tabelle in Windows "aktualisieren"? Danke und Grüße, Johannes