Domain Controller - Replication - DFS Namespace Status

Monitoring Benefit

The DFS Namespace test reads the event log on the monitored domain controller and looks for events relating to the DFS Namespace service, over a configurable lookback window. If any qualifying event IDs are found in that window, an alert is raised and the condition appears on the dashboard.

The namespace is what turns a share path into a resolvable target. When the namespace service is unhealthy, shares that clients reach through a namespace path stop resolving even though the underlying file servers are perfectly healthy — and because the files themselves are fine, the fault is routinely misdiagnosed as a client or network problem. Reading the namespace events directly is the shortest route to the real cause.

What the results page shows

The page is titled <server> AD DFS Namespace Status. Above the results it states the window it is reporting on:

RESULTS BELOW ARE FROM THE LAST <n> HOURS

When nothing qualifying has been logged in that window the page reads:

There are no warning or critical AD DFS Namespace Events

When events are found, they are listed so you can see the event ID, source and message without opening Event Viewer on the server.

Two things follow from this that are worth being explicit about:

• A clean result means no qualifying events were logged in the window. It is not a positive test of the namespace — the test does not resolve a namespace path or contact a namespace server.
• Because the window is a rolling lookback, an event will clear itself from the page once it ages out, even if the underlying cause was never addressed. A condition that keeps reappearing and clearing is a recurring fault, not a resolved one.

This test is the counterpart to DFS Functionality Status. The two are easily confused and check entirely different things: DFS Namespace reads the event log, while DFS Functionality measures replication timing between two named servers. A healthy namespace result does not mean replication is working, and vice versa.

How do we verify the results?

The ENow agent collects the result periodically. This information is not written to a log, but the most recent result is cached on the monitored server:

\Program Files (x86)\ENow\Mailscape Agent\Cache\

The cache folder holds one *AgentMessage.xml file per agent area. Open the file whose name matches the agent reporting this test to see the events behind the dashboard.

To read the same events by hand on the monitored DC, matching the lookback window configured for the test:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-DFSN-Server/Admin'
    StartTime = (Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Older builds, and some namespace conditions, log to the System event log under the DfsSvc provider instead. Check both:

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'DfsSvc'
    StartTime    = (Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Change AddHours(-1) to match the lookback configured for the test. If the command returns nothing and the dashboard is showing events, widen the window — the event is very likely just outside the period you queried.

To confirm the namespace service itself is running and the server is hosting the namespaces you expect:

Get-Service Dfs, DfsSvc

Get-DfsnRoot

Common warning or error results, and potential solutions