Senergy's policy calculation process is designed to ensure data integrity. Part of this design involves path overlap checking, which can create behaviors administrators might not expect if they're unfamiliar with how Senergy works.
Why Are Overlapping Policy Paths Bad?
One of Senergy's fundamental design assumptions is that managed paths are only created, changed, moved, and deleted by Senergy. Senergy is also designed so that it acts explicitly on each managed path—it should never affect one managed when operating on another. If policies were permitted to overlap, a delete action against one managed path might delete other managed paths contained within it without applying relevant vault and delete rules—an unacceptable loss of data and a violation of policy.
Thus, several steps are taken to validate policy paths and avoid policy path overlap.
Policy Creation and Management
If a Senergy administrator creates a policy "A" with a given target path, then later creates another policy "B" (of any type) where the target path is the same as or subordinate to the original policy path in policy "A", policy "A" will lose its target path association with that path. This helps to ensure that administrators do not accidentally create scenarios where multiple policies are effective against a given path. This check is subject to certain naming constraints (described in the next section) but will catch any case where UNC paths obviously overlap.
Path Overlap Checking in Events
In a Windows environment, it's possible to present a given path to a network under a variety of names through various technologies:
- DNS aliases can present a single server on the network through multiple DNS names
- Windows permits administrators to create multiple shares (with different names and permissions) for a single local path
- Windows permits administrators to create nested shares
- DFS namespaces mask share names and provide a different naming scheme for users to access shared resources
These may be changed behind the scenes without Senergy knowing anything about those changes. While these rarely cause problems in well-managed environments, accidents do happen and any risk to the integrity of data in Senergy's managed paths must be mitigated.
As a result, whenever Senergy moves a managed path, it performs a path overlap check as part of that event. That path overlap check determines the local path on disk to the managed path in question and compares that against the local path on disk of all other policy paths. The move event is only permitted to proceed if the path overlap check passes.
Path Overlap Checking Errors
The path overlap checking described above can result in two categories of event processing errors.
Policy Path Overlaps
In the rare case that certain configurations of the network environment and Senergy's policy paths cause policy target paths to actually overlap, events will fail to progress after a policy path overlap check with an error "The source & target paths overlap each other in some way." Administrators will want to double-check the event's new target path and determine why this is. Once that issue is resolved, the event should be able to proceed on the next retry attempt.
Path Overlap Checking Failures
As mentioned above, Senergy's path overlap checking validates the local path on disk of the target path against every other policy's local path on disk. This check is done in real-time against all policy target paths. As a result, if a different policy's target path is unavailable (e.g. due to a server outage), the path overlap check will fail and the event will not proceed until that path can be checked. In most cases, this is a transient issue—network and server outages are typically resolved quickly, and once those issues are resolved, events in Senergy's event queue will successfully pass the path overlap check on the next retry attempt.
However, it may be unclear which path is causing problems in Senergy's path overlap checking, especially since these errors may be reported as name resolution errors (if a server is down) or some other error. To troubleshoot this, Senergy admins should check the transaction log for the event in question. These are located (by default) in
%ProgramData%\Condrey Corporation\Senergy\Engine\log\translog\, and the file name for each event's translog matches the event ID. A line similar to the following should appear for each retry attempt:
Current State: 10 (Verifying paths or waiting for more paths defined for the policy to be reachable) - Path conflict check failed while analyzing path info, target: \\server-one.domain.local\share01 Policy path: \\server-two.domain.local\other-share
In this example, the event's new target path is
\\server-one.domain.local\share01. The path overlap check is failing on
\\server-two.domain.local\other-share, which is inaccessible to Senergy for some reason. The latter path should be restored if this is an unexpected outage; or, if this is a case where a path used as a policy target path was decommissioned or renamed, the policies using that path should be adjusted so that the path overlap check can successfully resolve all target paths.