Wir setzen Windows Server 2025 als Basis für unsere Terminalserver ein. Auf diesen Systemen richten wir lokale Benutzerkonten mit eingeschränkten Rechten ein, die ausschließlich für den Zugriff auf ausgewählte Anwendungen vorgesehen sind.
Im Rahmen der Grundinstallation treten jedoch bei jedem RDP-Benutzer Fehlermeldungen im Zusammenhang mit dem PowerShell-Deployment auf (siehe Anhang). Diese Problematik wurde bereits in der Vergangenheit mit Ihrem Support besprochen, konnte jedoch bislang nicht zufriedenstellend gelöst werden.
Unser Ziel ist es, die Pakete aus dem neo42-Depot mindestens für die Basisinstallation, z. B. Notepad++, Firefox ESR, 7-Zip, usw. nutzen zu können. Aktuell ist das jedoch nicht möglich, da die Anwendungen unter den gegebenen Benutzerrechten nicht fehlerfrei ausgeführt werden können.
Wir möchten bewusst keine generellen Rechteanhebungen für die lokalen RDP-Benutzer vornehmen. Daher sind wir auf der Suche nach einer Lösung oder einem Workaround, der den Einsatz der Pakete im genannten Szenario ermöglicht, ohne die Sicherheitsrichtlinien aufzuweichen.
Hallo @Klaus ,
Grundsätzlich empfehlen wir in dem Fall, PowerShell-Skripte signiert und mit einem im Zertifikatsspeicher hinterlegten Zertifikat auszuführen. neo42 Leitfaden zur APD Einführung
Sollte es jedoch eine Vorgabe geben, dass PowerShell generell von Benutzern nicht ausgeführt werden darf, auch nicht signierte Skripte, bleibt nur die Möglichkeit, die Userparts zu deaktivieren. Bestimmte Aktionen, wie das Setzen von Einstellungen beim Benutzer, können dann aber nicht mehr ausgeführt werden.
Wenn die Deaktivierung der Userparts tatsächlich gewünscht ist, kannst du beispielsweise einen Pipeline-Task einsetzen, der die Werte UserPartOnInstall und UserPartOnUninstall in der Datei neo42PackageConfig.json auf false setzt. Dadurch werden die Userparts beim Installieren und Deinstallieren nicht mehr ausgeführt und die gezeigte Fehlermeldung wird nicht auftreten.
Hier ein Beispiel, wie man diese Anpassung automatisieren kann:
Nun läuft die Standard Pipeline und holt die neue Version für das Notepad++ in die Umgebung.
Die 2. Pipeline läuft aber auf ein „Conditioned Stop“ weil sie natürlich keine neue Version findet.
Wie kann ich die Pipelines so konfigurieren, dass auch die 2. Pipeline das neue Notepad++ für die Terminalserver deployen kann?
Hallo @Klaus
Produkt Automationen benötigen immer den Smart Update Task, und wenn dieser ein Paket bereits in der neuesten Version im Zielsystem vorfindet, wird er immer den Bedingten Stop auslösen.
Zwei mal das selbe Paket mit dem Selben Namen und der selben Version importieren ist ebenfalls nicht möglich.
Was man machen könnte:
Nur eine Produktautomation anlegen
alles gleich lassen bis nach Empirum Deploy Task und delete from Filestorage deaktivieren
Einen Trigger Pipeline Task einfügen, der eine Minute später läuft:
Variable zum übergeben: PackageID
kein smartupdate task
Download Task mit PackageID (wird das bereits heruntergeladene im Filestorage verwenden)
Extract
Notwendige Änderungen an Packageconfig durchführen für andere config + Koexistenz der Pakete in Empirum (weiß ich so leider nicht also vorher herausfinden, vermutlich ein AppName Postfix hinzufügen) → PowerShell Task
Config einlesen Task
Apply Empirum Wrapper
Empirum Deploy
Delete from Filestorage
Cleanup
Genauere Details weiß ich so nicht, im Zweifel helfen unsere UEM Berater bei der Umsetzung.
