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, which are known to fail, and the available workarounds. ProfileUnity 6.9.5 HF2 resolves the regex escape ambiguity behind most of the previously broken patterns, so folder and share names beginning with ., .. or $ now apply as written.
📄 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, and the Windows path separator (\) is also the regex escape character. When a path segment starts with a regex special character — most commonly . or $ — the value reaches the engine as a separator immediately followed by an escape. Through 6.9.5 HF1 the separator was consumed as the escape of the character after it, the two could not be told apart, and the rule did not apply.
., .. or $ applies as written. The separator is still required, so a rule for \.vscode matches a folder named .vscode and does not match one named bob.vscode.Dots that appear within a segment — such as a dot in an FQDN hostname like \\server.corp\share\ — were never affected and continue to work in every release.
6.9.5 HF1 had earlier resolved a separate issue where Starts With rules failed entirely for UNC paths with simple hostnames. HF2 additionally hardened UNC path normalization and long-path handling.
✔ Supported Patterns
Confirmed to apply correctly via unit testing and field validation. Rows marked Fixed in HF2 were listed as broken in earlier revisions of this article.
| Pattern | Example Value | Notes |
|---|---|---|
Folder / segment starting with .
|
C:\Users\bob\.vscode\ | Fixed in HF2. Matches the dot-prefixed folder, and not a name that merely ends in the same text |
Folder starting with ..
|
C:\Users\bob\..cache\ |
Fixed in HF2. Only a path component that is exactly .. is treated as traversal and blocked |
UNC — $-prefixed share name |
\\server\$share |
Fixed in HF2. A leading $ is no longer read as a regex anchor |
| 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 have always worked correctly |
| UNC — hidden share (trailing $) | \\server\c$ | Trailing $ on the share name has always worked |
| 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 and Hash match rules | Microsoft Corporation | Identify the file by publisher or contents rather than by path, so path syntax does not apply |
| Ends With and Equals match types | C:\some.app\tool.exe | Both work correctly, including on paths containing dots or other special characters |
✖ Not Supported
One pattern remains unsupported after HF2.
| Pattern | Example Value | Why It Fails | Workaround |
|---|---|---|---|
| DFS namespace paths, in Contains, Starts With and Ends With rules | \\domain.local\namespace\share\ | The launched path is resolved to the file server behind the namespace before it is compared, while the rule value for these three match types is not, so the two never agree. Equals, Hash and Signed rules are unaffected | Use Equals, Hash or Signed, or name the file servers directly: \\*\sharename\
|
Workarounds
DFS namespace paths
A DFS namespace path resolves to the file server hosting the content at the time of access. Because the launched path reflects the actual host (e.g. \\fileserver01\...) rather than the namespace (e.g. \\corp\...), a namespace value in a Contains, Starts With or Ends With rule will not match. Options:
- Use an Equals, Hash or Signed rule, which are unaffected.
- Create one Starts With rule per host in the namespace.
- Use a wildcard broad enough to cover all hosts:
\\*\sharename\
Dot-prefixed folders on 6.9.5 GA and HF1
Before HF2, a leading dot on a path segment could be replaced with the * wildcard, which matches any character sequence.
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 a Rule Applied
Application Restriction records an event for every process it evaluates. On the machine where the application launched, open Event Viewer › Windows Logs › Application and filter by event source:
Event ID 5001 is a permitted launch, 5002 a launch blocked by an AllowList policy, and 5003 a launch blocked by a DenyList rule. The Matched Rule field names the rule that decided the outcome, and is empty when no rule matched.
The generated policy file can also be inspected directly on the client:
A doubled backslash before a special character in that file, such as \\.vscode, is the correct encoding of a separator followed by a literal character. On HF2 that is expected and the rule applies as written; on 6.9.5 GA and HF1 it indicates the rule is hitting the escape ambiguity described above.
| Product | Liquidware ProfileUnity with FlexApp |
| Applies To | ProfileUnity 6.9.5 GA, HF1 and HF2 |
| Updated | August 26, 2026 |