Der digitale Arbeitsplatz aus dem Portal · Stand September 2026 (Server 1.0.31, Agent 1.0.36)

Richtlinien und Vorlagen

Richtlinien steuern Einstellungen auf Geräten und für Benutzer zentral aus dem Portal: Laufwerke, Drucker, Verknüpfungen, Desktop, Skripte, Sperren für Terminalserver und VDI, und nicht zuletzt die Regel, ob ein Paket als MSIX oder als App Attach ausgeliefert wird. Dieses Dokument erklärt, was Richtlinien sind, wofür sie gut sind, wie Sie sie anlegen und wann welche Richtlinie greift. Die technischen Anhänge (eigene Vorlagen, PowerShell, Agent, Fehlersuche) stehen am Ende.

1. Was ist das?

Eine Richtlinie in ZeroPortal ist das, was eine Gruppenrichtlinie in Active Directory ist, nur ohne Bindung an die AD-Struktur und ohne Gruppenrichtlinienverwaltung: eine Gruppe von Einstellungen, die der ZeroPortal-Agent beim Abgleich auf dem Gerät anwendet und wieder zurücknimmt, sobald das Gerät oder der Benutzer nicht mehr im Geltungsbereich liegt.

Vier Begriffe genügen:

2. Wozu ist das gut?

Für den digitalen Arbeitsplatz aus einer Hand. Was sonst über Anmeldeskripte, Gruppenrichtlinien-Einstellungen, BGInfo und Handarbeit verteilt ist, steht in einem Richtliniensatz neben den Paketen, mit demselben Geltungsbereich und derselben Rücknahme:

• Arbeitsplatz einrichten: Netzlaufwerke, Drucker, Verknüpfungen, Umgebungsvariablen, Ordner, Dateien kopieren und dabei anpassen, Skripte mit Prüfsumme.
• Aussehen und Sperren: Hintergrund und Design, Dark Mode, Symbole, Desktop-Info-Overlay als BGInfo-Ersatz, visuelle Effekte, Laufwerkssichtbarkeit, Einschränkungen für VDI und Terminalserver, Remotedesktop-Einstellungen, Proxy, Store-Zugriff.
• Verteilung steuern: Die Richtlinie MSIX-Bereitstellung entscheidet je Paketfamilie, ob ein Paket als MSIX installiert, als App Attach eingehängt oder gar nicht ausgeliefert wird. Paket-Downgrade-Steuerung erlaubt Rückstufungen gezielt.
• Agent steuern: Jede Einstellung des Agenten lässt sich als Richtlinie setzen, etwa Abgleichintervalle oder das Leeren der Kerberos-Tickets vor dem Benutzerabgleich.

Dazu kommt, was Gruppenrichtlinien nicht bieten: Jede gespeicherte Änderung einer Richtlinie ist eine Revision, und ein früherer Stand lässt sich wiederherstellen (Abschnitt 3). Wird eine Richtlinie entfernt oder ein Gerät verlässt den Geltungsbereich, stellt der Agent den vorherigen Zustand wieder her; nichts bleibt „eintätowiert". Bestehende Gruppenrichtlinien-Einstellungen (Registrierung, Laufwerke, Verknüpfungen, Umgebungsvariablen, Drucker, Ordner) werden importiert, nicht abgetippt.

Die mitgelieferten Vorlagen:

3. Wie nutze ich das?

Ein Richtliniensatz entsteht in fünf Schritten. Das Beispiel richtet einen Satz „VDI" für Sitzungshosts ein, der Firefox als App Attach ausliefert und den Desktop gestaltet.

Schritt 1: Satz anlegen. Richtlinien → Richtliniensätze → Neuer Satz. Name, Beschreibung und Priorität vergeben, Anlegen. Die kleinere Zahl gewinnt bei Widersprüchen. Neue Sätze sind zunächst inaktiv.

Schritt 2: Geltungsbereich setzen. Auf der Karte Geltungsbereich den Knopf Bereich bearbeiten wählen, Filter setzen, etwa die Organisationseinheit der Sitzungshosts oder ein Computernamensmuster wie VDI-*. Mehrere Filter werden mit UND oder ODER verknüpft, jeder lässt sich negieren.

Schritt 3: Richtlinie hinzufügen. Richtlinie hinzufügen öffnet die Vorlagenauswahl, filterbar nach Kategorie und Kontext (Computer, Benutzer). Der Reiter Vorhandene verwenden nimmt eine bereits angelegte Richtlinie in den Satz auf, etwa dieselbe Laufwerksrichtlinie für mehrere Sätze.

Schritt 4: Werte eintragen. Der Editor entsteht aus der Vorlage. Listentypen wie MSIX-Bereitstellung oder Laufwerke zeigen eine Tabelle, neue Zeilen über Eintrag hinzufügen; die Reihenfolge zählt, die erste passende Regel gewinnt. Schaltertypen wie Desktop zeigen Felder und eine Checkliste mit Häkchen (an), Kreuz (aus) und Strich (nicht konfiguriert). Eine aus der Vorlage angelegte Richtlinie ist sofort aktiv; wirksam wird sie erst, wenn auch der Satz aktiv ist.

Schritt 5: Satz aktivieren. Speichern und den Satz auf Aktiv stellen. Beim nächsten Abgleich holt der Agent die Richtlinien, wendet sie vor der Paketverarbeitung an und meldet das Ergebnis im Tray. Voraussetzung: Auf den Geräten ist die Richtlinienverarbeitung eingeschaltet (Gruppenrichtlinie Sync Richtlinien einschalten, Abschnitt 7.3); ein frisch installierter Agent verarbeitet sonst keine Richtlinien.

Noch drei Dinge, die im Alltag helfen:

• Revisionen und Wiederherstellen: Jede gespeicherte Änderung einer Richtlinie ist eine Revision; die aktuelle Nummer steht auf der Richtlinienseite. Die Historie lesen und einen früheren Stand zurückholen geht per PowerShell: Get-ZeroPortalPolicyHistory -Name 'VDI Desktop' zeigt die Revisionen mit Datum und Bearbeiter, Restore-ZeroPortalPolicy -Name 'VDI Desktop' -Revision 3 stellt Revision 3 wieder her. Die Wiederherstellung wird selbst eine neue Revision; die Agenten sehen eine normale Änderung. Das Portal behält standardmäßig die letzten 20 Revisionen (Abschnitt 7.1).
• Expertenansicht: Das Symbol XML (Expertenansicht) in der Richtlinienliste zeigt das XML einer Richtlinie; auf der Richtlinienseite lässt es sich unter Richtlinien-XML auch bearbeiten (Speichern (neue Revision)). Praktisch zum Kopieren zwischen Umgebungen, nötig ist es nie.
• Export und Import: Sätze und Richtlinien lassen sich mit Exportieren als Bausteine sichern und mit Importieren in einer anderen Installation einspielen, auch per PowerShell (Export-ZeroPortalPolicyBuildingBlock, Import-ZeroPortalPolicyBuildingBlock). Importierte Sätze sind zunächst inaktiv. Importieren nimmt auch die XML-Dateien von Gruppenrichtlinien-Einstellungen an (Registry.xml, Drives.xml, Shortcuts.xml, EnvironmentVariables.xml, Printers.xml, Folders.xml); daraus entsteht je Datei eine inaktive Richtlinie. Die Zielgruppenadressierung einzelner Einträge wird nicht übernommen; den Geltungsbereich setzen Sie im Satz.

4. Geltungsbereich: wann wirkt was

Ein Geltungsbereich beschreibt wo (Computer) oder für wen (Benutzer) ein Satz gilt. Der Agent verarbeitet Richtlinien zweimal: im Computer-Abgleich die Computeranteile (Bereitstellungsregeln, Agent-Konfiguration, HKLM, Dienste) und im Benutzer-Abgleich die Benutzeranteile (Laufwerke, Drucker, Desktop, HKCU). Das entspricht der Loopback-Verarbeitung von Gruppenrichtlinien: Ein Satz, der auf einen Computer zielt, bringt jedem Benutzer, der sich dort anmeldet, auch die Benutzeranteile mit. Genau das braucht man für VDI und Terminalserver.

Welcher Filter in welchem Abgleich greift:

Daraus folgen zwei Regeln:

• Ein Satz mit Computer- und Benutzeranteilen zielt auf Computername, IP-Bereich oder Organisationseinheit. Diese drei greifen in beiden Abgleichen. Eine Computergruppe als einziger Filter trägt nur die Computeranteile.
• Ein Satz, der nur auf Benutzer zielt (Benutzergruppe, Benutzer-OU), trägt keine Computeranteile.

Weitere Regeln im Betrieb:

• Priorität: Widersprechen sich zwei Einstellungen, gewinnt der erste Treffer: zuerst nach der Priorität des Satzes, dann nach der Priorität der Richtlinie im Satz. Die kleinere Zahl kommt zuerst. Alle zutreffenden Sätze werden abgearbeitet. Trifft der Geltungsbereich eines Satzes nicht zu, gilt keine seiner Richtlinien, auch nicht mit eigenen Filtern.
• Zeitfenster werden beim Abgleich geprüft. Eine Einstellung, deren Fenster geschlossen ist, wird beim nächsten vollständigen Lauf zurückgenommen, standardmäßig alle 24 Stunden oder beim nächsten Abgleich nach einer Änderung im Portal.
• Erneuter Abgleich: Verbundene Laufwerke werden nicht neu verbunden, solange der Buchstabe auf den gewünschten Pfad zeigt; nur die Aktion „Ersetzen" verbindet jedes Mal neu. Benutzer-Registry-Werte (Hintergrund, Design) werden sofort geschrieben und wirken spätestens mit der nächsten Anmeldung.
• Rücknahme: Verlässt ein Gerät oder Benutzer den Geltungsbereich oder wird eine Richtlinie entfernt, stellt der Agent die vorherigen Werte wieder her. Nur Registry-Einträge mit ausdrücklichem „dauerhaft" bleiben stehen.
• Unbekannte Filter (etwa aus einer neueren Portalversion) lassen eine Richtlinie vorsichtshalber nicht gelten; der Agent meldet das im Log (Ereignis 3612).

5. Bereitstellungsregeln: MSIX oder App Attach

Die Richtlinie MSIX-Bereitstellung ist die wichtigste Richtlinie für MSIX. Ohne sie wird jedes Paket klassisch als MSIX installiert. Mit ihr legen Sie je Paketfamilie fest:

Jede Regel besteht aus einem Muster auf den Familiennamen (* erlaubt), optional einem Pakettyp und dem Format. Die Liste wird von oben nach unten ausgewertet, die erste passende Regel gewinnt; spezifische Regeln nach oben, die *-Regel nach unten. Es ist eine Computerrichtlinie: Das Format gilt für alle Pakete des Geräts. Eine neue Richtlinie enthält bereits die Regel * / Framework → Msix, weil Frameworks immer als MSIX kommen.

Typischer Terminalserver-Satz: Contoso.Legacy_* → Deny, * / Framework → Msix, * → AppAttachCim. Arbeitsplätze ohne eigene Regel erhalten weiterhin klassisches MSIX.

6. Für Integratoren: eigene Vorlagen

Fehlt eine Vorlage, nimmt man zuerst Registrierung. Eigene Vorlagen lohnen sich für Einstellungen mit eigenem Editor und Hilfetexten, die mehrfach gebraucht werden:

• Vorlage <Name>.zppx unter C:\Program Files\ZeroPortal\PolicyDefinitions nach dem ADMX-Prinzip (Felder und ihre Abbildung auf Registry-Werte), Sprachdatei en-US\<Name>.zppl, weitere Sprachen (de-DE\<Name>.zppl) optional. Im Cluster auf jeden Knoten kopieren.
• Das Portal liest die Dateien bei jedem Öffnen der Vorlagenauswahl, kein Neustart. Fehlerhafte Vorlagen werden übersprungen (Warnung im Portal-Log), bei fehlerhafter Sprachdatei erscheinen rohe Text-IDs. Nach Änderung der Registry-Zuordnung einer verwendeten Vorlage eine Richtlinie neu speichern.
• Der Agent sieht nur fertige Registry-Werte samt Rücknahme; kein Code auf dem Gerät. Minimalbeispiel für einen Proxy-Server (CorpProxy.zppx und en-US\CorpProxy.zppl):

<ZpPolicyDefinition provider="CorpProxy" version="1.0" category="Workspace" context="User"
    settingsElement="CorpProxySettings" entryElement="CorpProxy" displayName="$(string.DisplayName)" description="$(string.Description)">
  <Attributes>
    <Attribute name="server" type="string" required="1" displayName="$(string.server)" description="$(string.server.desc)"/>
  </Attributes>
  <RegistryMappings>
    <Setting id="ProxyServer">
      <RegistryValue hive="HKEY_CURRENT_USER" key="Software\Microsoft\Windows\CurrentVersion\Internet Settings" name="ProxyServer" type="REG_SZ" valueFrom="server"/>
    </Setting>
  </RegistryMappings>
</ZpPolicyDefinition>

<ZpPolicyLanguage provider="CorpProxy" culture="en-US">
  <String id="DisplayName">Corporate proxy</String>
  <String id="Description">Sets the WinINET proxy server for the user.</String>
  <String id="server">Proxy server</String>
  <String id="server.desc">host:port, e.g. proxy.corp.local:8080.</String>
</ZpPolicyLanguage>

Mehr (type="enum" mit min/max, type="tristate" mit onValue/offValue, Maskenbits, when, DefaultEntries, entryTargeting="1") zeigen InternetSettings.zppx, RdsHost.zppx, Delivery.zppx. Registry-Pfade aus den ADMX-Dateien unter C:\Windows\PolicyDefinitions übernehmen (Vorsicht bei invertierter Logik wie fDenyTSConnections); Testwerte samt Vorzustand: HKLM\Software\NickIT\ZPAgent\AppliedPolicies\Registry (Benutzer: HKCU).

7. Anhang: PowerShell, Agent und Fehlersuche

7.1 PowerShell

Das Modul ZeroPortal wird mit dem Portal installiert; die Cmdlets erledigen dasselbe wie die Portaloberfläche.

Import-Module ZeroPortal
Set-AppvZeroPortalCmdLetConfiguration -BaseUrl 'https://zeroportal:8080' -SkipCertificateCheck $true

New-ZeroPortalPolicySet -Name 'Terminalserver' -Priority 10
New-ZeroPortalPolicy -Name 'AppAttach fuer AVD' -XmlPath .\appattach.xml -Enabled
Add-ZeroPortalPolicySetMember -SetName 'Terminalserver' -PolicyName 'AppAttach fuer AVD' -Priority 1
Set-ZeroPortalPolicySet -Name 'Terminalserver' -Enabled $true

Get-ZeroPortalPolicyHistory -Name 'AppAttach fuer AVD'
Restore-ZeroPortalPolicy -Name 'AppAttach fuer AVD' -Revision 3

Die GUID für den Export liefert (Get-ZeroPortalPolicySet -Name 'VDI').SetGuid bzw. (Get-ZeroPortalPolicy -Name 'VDI Desktop').PolicyGuid.

Zwei portalweite Werte setzen Voll-Administratoren mit Set-ZeroPortalConfigurationValue -Name <Name> -Value <Wert>: PolicyHistoryDepth (Standard 20, aufbewahrte Revisionen je Richtlinie) und PolicyAssetMaxKB (Standard 256, Größenlimit je hochgeladener Datei wie Skript, Symbol oder Overlay; auch in der Globalen Konfiguration).

7.2 Richtlinienverwaltung delegieren

Voll-Administratoren vergeben unter Globale Konfiguration → Berechtigungen je Portalgruppe im Bereich Richtlinien die Stufe Lesen oder Verwalten (siehe Benutzer, Rechte, Lizenzen und Protokolle); per PowerShell Add-ZeroPortalRoleAssignment -RoleName PolicyAdmin -GroupName 'ZP-PolicyAdmins' (nur lesen: PolicyReader). Die Berechtigung wirkt ab der nächsten Anmeldung am Portal.

7.3 Verarbeitung auf dem Gerät

Der Agent verarbeitet Richtlinien im Computer- und im Benutzer-Abgleich jeweils vor den Paketen; ein Fehler in der Richtlinienverarbeitung bricht den Abgleich nie ab, die zuletzt wirksamen Bereitstellungsregeln bleiben dann gültig. Ohne Serververbindung gilt der zwischengespeicherte Stand. Jeder Lauf endet mit Ereignis 2600, einem Hinweis im Tray und einem Bericht an das Portal.

Die Schalter setzen Sie per Gruppenrichtlinie (ADMX, hat Vorrang), lokal mit Set-ZPAgentConfiguration -<Schalter> <Wert> oder zentral über die Richtlinie Agent-Konfiguration als Policy/<Schalter>; Get-ZPAgentConfiguration -Policy zeigt alle wirksamen Werte. Die vier, die zählen:

7.4 Ablage auf dem Gerät

7.5 Ereignisse im Agent-Log

7.6 Für Auswertungen: zwei Abfragen

Nur über die Portal-API (im Browser mit Windows-Anmeldung oder per Invoke-RestMethod -UseDefaultCredentials):