The digital workplace from the portal · As of September 2026 (Server 1.0.31, Agent 1.0.36)

Policies and templates

Policies control settings on devices and for users centrally from the portal: drives, printers, shortcuts, desktop, scripts, lockdowns for terminal servers and VDI, and not least the rule whether a package is delivered as MSIX or as App Attach. This document explains what policies are, what they are good for, how you create them, and when which policy applies. The technical appendices (custom templates, PowerShell, agent, troubleshooting) are at the end.

1. What is this?

A policy in ZeroPortal is what a group policy is in Active Directory, only without being tied to the AD structure and without Group Policy Management: a group of settings that the ZeroPortal agent applies on the device during a sync and takes back as soon as the device or the user is no longer in scope.

Four terms are enough:

2. What is this good for?

For the digital workplace from a single source. What is otherwise spread over logon scripts, Group Policy Preferences, BGInfo and manual work sits in one policy set next to the packages, with the same scope and the same rollback:

• Setting up the workplace: network drives, printers, shortcuts, environment variables, folders, copying files and adapting them on the way, scripts with a checksum.
• Look and lockdown: wallpaper and theme, dark mode, icons, a desktop info overlay as a BGInfo replacement, visual effects, drive visibility, restrictions for VDI and terminal servers, Remote Desktop settings, proxy, Store access.
• Controlling delivery: the MSIX delivery format policy decides per package family whether a package is installed as MSIX, mounted as App Attach, or not delivered at all. Package Downgrade Control allows downgrades selectively.
• Controlling the agent: every agent setting can be set as a policy, for example sync intervals or purging the Kerberos tickets before the user sync.

On top of that comes what group policies do not offer: every saved change to a policy is a revision, and an earlier state can be restored (section 3). If a policy is removed or a device leaves the scope, the agent restores the previous state; nothing stays "tattooed". Existing Group Policy Preferences (registry, drives, shortcuts, environment variables, printers, folders) are imported, not retyped.

The templates shipped:

3. How do I use this?

A policy set is created in five steps. The example sets up a "VDI" set for session hosts that delivers Firefox as App Attach and designs the desktop.

Step 1: Create the set. Policies → Policy sets → New set. Enter a name, description and priority, then Create. The smaller number wins in case of conflicts. New sets start inactive.

Step 2: Set the scope. On the Set scope card, choose Edit scope and set filters, for example the organizational unit of the session hosts or a computer name pattern such as VDI-*. Several filters are combined with AND or OR, and each can be negated.

Step 3: Add a policy. Add policy opens the template selection, filterable by category and context (computer, user). The Reuse existing tab adds a policy that already exists to the set, for example the same drive policy for several sets.

Step 4: Enter values. The editor is generated from the template. List types such as MSIX delivery format or Map drives show a table, with new rows through Add entry; the order matters, the first matching rule wins. Switch types such as Desktop show fields and a checklist with a tick (on), a cross (off) and a dash (not configured). A policy created from a template is active right away; it takes effect only when the set is active too.

Step 5: Activate the set. Save and set the set to Active. At the next sync the agent fetches the policies, applies them before package processing, and reports the result in the tray. Prerequisite: policy processing is turned on on the devices (group policy Enable policy sync, section 7.3); otherwise a freshly installed agent processes no policies.

Three more things that help in daily work:

• Revisions and restore: every saved change to a policy is a revision; the current number is shown on the policy page. Reading the history and restoring an earlier state is done in PowerShell: Get-ZeroPortalPolicyHistory -Name 'VDI Desktop' shows the revisions with date and editor, Restore-ZeroPortalPolicy -Name 'VDI Desktop' -Revision 3 restores revision 3. The restore itself becomes a new revision; the agents see a normal change. By default the portal keeps the last 20 revisions (section 7.1).
• Expert view: the XML (expert view) icon in the policy list shows a policy's XML; on the policy page it can also be edited under Policy XML (Save (new revision)). Handy for copying between environments, never required.
• Export and import: sets and policies can be saved as building blocks with Export and brought into another installation with Import, also in PowerShell (Export-ZeroPortalPolicyBuildingBlock, Import-ZeroPortalPolicyBuildingBlock). Imported sets start inactive. Import also accepts the XML files of Group Policy Preferences (Registry.xml, Drives.xml, Shortcuts.xml, EnvironmentVariables.xml, Printers.xml, Folders.xml); each file becomes an inactive policy. Item-level targeting of individual entries is not carried over; you set the scope on the set.

4. Scope: when does what apply

A scope describes where (computer) or for whom (user) a set applies. The agent processes policies twice: in the computer sync the computer parts (delivery rules, agent configuration, HKLM, services) and in the user sync the user parts (drives, printers, desktop, HKCU). This matches loopback processing of group policies: a set that targets a computer also brings its user parts to every user who signs in there. That is exactly what VDI and terminal servers need.

Which filter applies in which sync:

Two rules follow from this:

• A set with computer and user parts targets a computer name, IP range or organizational unit. These three apply in both syncs. A computer group as the only filter carries only the computer parts.
• A set that targets only users (user group, user OU) carries no computer parts.

Further rules in operation:

• Priority: if two settings contradict each other, the first match wins: first by the priority of the set, then by the priority of the policy within the set. The smaller number comes first. All matching sets are processed. If a set's scope does not match, none of its policies apply, not even those with filters of their own.
• Time windows are checked during the sync. A setting whose window has closed is taken back at the next full run, by default every 24 hours, or at the next sync after a change in the portal.
• Repeated sync: mapped drives are not mapped again as long as the letter points to the desired path; only the "Replace" action maps again every time. User registry values (wallpaper, theme) are written right away and take effect at the next sign-in at the latest.
• Rollback: if a device or user leaves the scope or a policy is removed, the agent restores the previous values. Only registry entries explicitly marked "permanent" stay.
• Unknown filters (for example from a newer portal version) make a policy not apply, to be safe; the agent reports this in the log (event 3612).

5. Delivery rules: MSIX or App Attach

The MSIX delivery format policy is the most important policy for MSIX. Without it, every package is installed the classic way as MSIX. With it, you set per package family:

Each rule consists of a pattern on the family name (* allowed), optionally a package type, and the format. The list is evaluated from top to bottom and the first matching rule wins; specific rules at the top, the * rule at the bottom. It is a computer policy: the format applies to all packages on the device. A new policy already contains the rule * / Framework → Msix, because frameworks always come as MSIX.

Typical terminal server set: Contoso.Legacy_* → Deny, * / Framework → Msix, * → AppAttachCim. Workstations without a rule of their own keep getting classic MSIX.

6. For integrators: custom templates

If a template is missing, reach for Registry first. Custom templates pay off for settings with their own editor and help texts that are needed more than once:

• Template <Name>.zppx under C:\Program Files\ZeroPortal\PolicyDefinitions, following the ADMX principle (fields and their mapping to registry values), language file en-US\<Name>.zppl, further languages (de-DE\<Name>.zppl) optional. In a cluster, copy them to every node.
• The portal reads the files every time the template selection opens, no restart. Faulty templates are skipped (warning in the portal log); with a faulty language file, raw text IDs appear. After changing the registry mapping of a template in use, save a policy again.
• The agent only sees finished registry values including rollback; no code on the device. Minimal example for a proxy server (CorpProxy.zppx and 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>

More (type="enum" with min/max, type="tristate" with onValue/offValue, mask bits, when, DefaultEntries, entryTargeting="1") is shown in InternetSettings.zppx, RdsHost.zppx, Delivery.zppx. Take registry paths from the ADMX files under C:\Windows\PolicyDefinitions (watch out for inverted logic such as fDenyTSConnections); test values including the previous state: HKLM\Software\NickIT\ZPAgent\AppliedPolicies\Registry (user: HKCU).

7. Appendix: PowerShell, agent and troubleshooting

7.1 PowerShell

The ZeroPortal module is installed with the portal; the cmdlets do the same as the portal interface.

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

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

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

The GUID for the export comes from (Get-ZeroPortalPolicySet -Name 'VDI').SetGuid or (Get-ZeroPortalPolicy -Name 'VDI Desktop').PolicyGuid.

Full administrators set two portal-wide values with Set-ZeroPortalConfigurationValue -Name <Name> -Value <Value>: PolicyHistoryDepth (default 20, revisions kept per policy) and PolicyAssetMaxKB (default 256, size limit per uploaded file such as a script, icon or overlay; also in Global Configuration).

7.2 Delegating policy management

Full administrators grant each portal group the level Read or Administrate in the Policies area under Global Configuration → Permissions (see Users, permissions, licences and logs); in PowerShell Add-ZeroPortalRoleAssignment -RoleName PolicyAdmin -GroupName 'ZP-PolicyAdmins' (read only: PolicyReader). The permission takes effect from the next sign-in to the portal.

7.3 Processing on the device

The agent processes policies in the computer and in the user sync, each time before the packages; an error in policy processing never aborts the sync, and the delivery rules last in effect stay valid. Without a server connection, the cached state applies. Every run ends with event 2600, a notice in the tray, and a report to the portal.

Set the switches by group policy (ADMX, takes precedence), locally with Set-ZPAgentConfiguration -<switch> <value>, or centrally through the Agent configuration policy as Policy/<switch>; Get-ZPAgentConfiguration -Policy shows all effective values. The four that matter:

7.4 Storage on the device

7.5 Events in the agent log

7.6 For evaluations: two queries

Only through the portal API (in the browser with Windows sign-in, or with Invoke-RestMethod -UseDefaultCredentials):