DFS Namespace Paths Are Not Supported in Certain Application Restriction Match Types

DFS namespace paths are not supported as Application Restriction rule values when the match type is Contains, StartsWith or EndsWith. On ProfileUnity Client 6.9.5 and later these rules never match, and no error is reported — the rule is present in the console and simply has no effect. Equals, Hash and Signed rules are unaffected. The cause is the path normalization introduced in 6.9.5, and this article describes it along with the supported alternatives.

Affected Match Types

Only DFS namespace paths are affected. Local paths and UNC paths naming a file server directly work normally in every match type, and dots in a value are not themselves a problem.

Cause

Beginning in 6.9.5 the client resolves paths before comparing them. Windows reports the image path of a launched executable as the DFS namespace path, and the client resolves it to the target node path — the file server and share behind the namespace folder. It resolves rule values the same way when the policy loads, so both sides normally arrive at the same path and agree.

Contains, StartsWith and EndsWith values are escaped so that the * wildcard can be supported, and an escaped value cannot be opened, so it is excluded from that step and kept exactly as authored. For an ordinary path this costs nothing, because the value is already in the form the client will see and the escaping is transparent to the comparison. A namespace path is the case where the step was doing real work, so excluding the value leaves the rule holding the namespace form while the launched path holds the server form:

:: StartsWith rule value, kept as authored
\\domain.local\Apps\Tools\

:: launched path after the client resolves it
\\FILESRV01\Apps$\Tools\Editor\editor.exe

Supported Alternatives

Pick the first one that fits. The earlier options are simpler and need no knowledge of the namespace targets.

Option A — Change the rule to Equals

Where the rule names a single executable, an Equals rule takes the namespace path unchanged and resolves it:

\\domain.local\Apps\Tools\Editor\editor.exe

Equals matches the whole path and nothing less, so this only works when you are targeting one file rather than a folder. It is also more specific than the rule it replaces, which can change the outcome in a policy that mixes Allow and Deny rules.

Option B — Match by hash or publisher instead of by path

A Hash rule identifies the executable by its contents and a Signed rule by its publisher certificate. Neither compares paths, so neither is affected by which namespace target served the file, and neither needs updating when the namespace gains a target.

Option C — Keep the match type, drop the namespace from the value

When you need Contains, StartsWith or EndsWith to cover a folder, write the value against something the client will actually see. Either name the targets directly:

\\FILESRV01\Apps$\Tools\
\\FILESRV02\Apps$\Tools\

or replace the server and share with a wildcard so one rule covers every target:

\\*\Tools\

A wildcard expands greedily and crosses path separators, so a single * covers both the server name and the share name. Keep enough of the path after it to scope the rule to what you mean, and do not carry the wildcard across to an Equals rule — there it is a literal character and matches nothing.