Why is my Application Restriction rule not blocking or allowing paths correctly in ProfileUnity 6.9.5?
This article documents which path syntax patterns work correctly in Application Restriction rules as of ProfileUnity 6.9.5 HF1, which patterns are known to fail, and the available workarounds.
📄 Contents
Background
Application Restriction rules are written to a .pol file on the client at logon. The rule engine processes path values using regex internally. The problem is that the Windows path separator (\) is also the regex escape character. When a \ immediately precedes a regex special character — most commonly . or $ — the engine cannot resolve the ambiguity and the rule does not apply as expected. This occurs when a path segment starts with one of these characters (e.g., \.vscode). Dots that appear within a segment — such as a dot in an FQDN hostname like \\server.corp\share\ — are not affected.
ProfileUnity 6.9.5 HF1 resolved a separate issue where Starts With rules failed entirely for UNC paths with simple hostnames. The patterns listed as Not Supported below are distinct from that fix and remain outstanding as of HF1.
✓ Supported Patterns
The following patterns have been confirmed to apply correctly via unit testing and field validation as of 6.9.5 HF1.
| Pattern | Example Value | Notes |
|---|---|---|
| Local drive paths | C:\Program Files\ | Standard local paths work reliably |
| Paths with parentheses | C:\Program Files (x86)\ | Parentheses in folder names confirmed working |
| Nested / multiple parentheses | C:\Program Files (x86)\App (v2)\ | Multiple parenthesis groups in one path confirmed working |
| UNC — simple hostname | \\server\share\ | Fixed in HF1 |
| UNC — FQDN hostname (dot within hostname) | \\server.corp\share\ | Dots within a hostname segment work correctly. The issue only occurs when a segment starts with a dot. |
| UNC — hidden share (trailing $) | \\server\c$ | Trailing $ on the share name works. Distinguished from a leading $ — see broken patterns. |
| Environment variables | %USERPROFILE%\ | Environment variables such as %USERPROFILE% are expanded and evaluated correctly |
| Special chars in folder names | \\server\Dev & Test\ |
& space # @ ! [ ] { } + $ confirmed working in folder names |
| Deny + Allow combination | Deny C:\...(x86)\ Allow ...\wordpad.exe |
Rule precedence and Allow/Deny interaction apply correctly |
| Signed match rules | Microsoft Corporation | Signature-based rules unaffected by this issue |
| Ends With match type | \Accessories\wordpad.exe | Ends With match type works correctly |
| Equals match on paths with special chars | C:\some.app\tool.exe | Equals match type works correctly even when paths contain dots or other special characters |
✗ Not Supported / Known Broken Patterns
The following patterns do not apply reliably as of 6.9.5 HF1.
\) immediately precedes a regex special character creates an ambiguous escape sequence the engine cannot resolve. This specifically occurs when a path segment starts with that character — a dot or dollar sign mid-segment (e.g., within a hostname) is not affected.| Pattern | Example Value | Why It Fails | Workaround |
|---|---|---|---|
Folder / segment starting with .
|
C:\Users\...\.vscode\ | The \. at the folder boundary is an ambiguous regex escape |
Replace leading . with *: e.g., *vscode, or use a Contains rule |
Folder starting with ..
|
C:\..cache\ | Hard-blocked by the engine | Use a Contains rule targeting the folder name without the leading dots |
UNC — $-prefixed share name |
\\server\$share | The share name starts with $, creating \$ ambiguity. Trailing $ (e.g., \\server\c$) works fine. |
No confirmed workaround at this time |
| UNC namespace paths | \\namespace\share\ | Namespaces resolve to individual hostnames at runtime; the resolved path won't match the namespace rule | Create one Starts With rule per hostname, or use a wildcard: \\*\sharename\
|
Workarounds
Replacing a leading dot with a wildcard
The * wildcard matches any character sequence, making it a safe substitution for a leading dot on a path segment.
* wildcard is broad — make the surrounding path specific enough to avoid unintended matches. Adjust specificity to your environment.UNC namespace paths
DFS namespace paths resolve to individual hostnames at the time of access. Because the resolved path reflects the actual host (e.g., \\fileserver01\...) rather than the namespace (e.g., \\corp\...), namespace-based rules will not match. Options:
- Create one Starts With rule per host in the namespace.
- Use a wildcard broad enough to cover all hosts:
\\*\sharename\
Note on Blocking Installers (MSI)
MSI packages do not run as a standalone executable in the traditional sense — they are launched by the Windows Installer service via msiexec.exe. Because of this, a path-based Application Restriction rule targeting the .msi file itself will not block the installation — the binary that actually executes is msiexec.exe.
msiexec.exe will prevent all MSI-based installations and updates from running — including Windows updates, application patches, and other system-level operations that rely on the Windows Installer service. This can have significant unintended consequences and is generally not recommended in production environments without thorough testing.If the goal is to prevent users from running installers dropped to a specific location (e.g., %USERPROFILE%\Downloads\), consider combining an Application Restriction rule with a Software Restriction Policy or AppLocker rule scoped to the path from which users could launch msiexec.exe with a user-supplied package.
Example: Blocking the Microsoft Store
The Microsoft Store app (WinStore.App.exe) runs from a versioned subfolder under the protected Windows Apps directory:
The version string in the folder name changes every time the Microsoft Store updates itself. A rule targeting the full versioned path will break silently after the next Store update without any warning.
| Field | Value |
|---|---|
| Filter | Select the user or group filter to scope this rule (e.g., all non-admin users) |
| Action | Deny |
| Match | Starts With |
| Value | C:\Program Files\WindowsApps\Microsoft.WindowsStore |
This rule matches any executable under any version of the Store package folder. Since Starts With rules support the * wildcard, you can also be explicit with the version wildcard if needed:
Finding the current installed path
To verify the current path on a machine, run in PowerShell:
How to Confirm the Issue
If applications are unexpectedly blocked after installing HF1, check whether the blocked path matches any broken pattern above. To verify, inspect the generated .pol file on the client:
If the rule you entered in the console had a leading dot on a segment (e.g., \.vscode) and the .pol file shows a backslash before it (e.g., \\.), the path is hitting this known issue.
| Product | Liquidware ProfileUnity with FlexApp |
| Applies To | ProfileUnity 6.9.5 GA and HF1 |
| Updated | July 6, 2026 |