During monitoring domain controllers working on Windows 2012R2 Sometimes one encounters servers persistently shown as "Critical," although none other than one monitor (ATQ Average Threads Monitor) Symptoms do not indicate their poor condition. After examination with Health Explorer, you will find that it is not a matter of the counter value exceeding the permissible values, but a monitoring error - the counter value cannot be retrieved.
A monitor that persists in an error state uses a script VBS (Atq_Thread_Usage.vbs) to check the performance counter, but in the script itself there is a fragment whose operation manifests itself just in our case:
Of course, in this situation it does not make sense to change the script, but it is necessary to check that indeed retrieving the counter value is not possible.
Since the query is explicitly given here WQL, So you can query the system (for example, using the built-in wbemtest tool) and see what you get.
On a "healthy system" we get the answer:
As it happens, in the presence of monitoring error it turns out that the query is considered incorrect (refers to a non-existent class). So maybe performance counters don't exist at all? It turns out that they do, and the corresponding key in the registry all the way "yawns empty":
In comparison, a "healthy" domain controller shows variables:
How to fix it? It turns out that it's not too difficult:
- Perform an export (from a healthy Windows 2012R2 domain controller) of the registry key HKLM\SYSTEM\NCurrentControlSetServices\NTDSPerformance.
To file. - Copy the obtained REG file to the controller on which the error occurs and perform its import
- Finally, call the command
lodctr /R
A system reboot is not required. The switch in the command must be an uppercase, not lowercase "R". When everything runs successfully in the registry entries will be present (ObjectList will change the value by the way), and after some time the error will stop.
If we now notice errors, they will not just be errors in the monitoring itself, but incorrect meter values.
I have the impression that putting in script examining the efficiency of setting the value "BAD" due to the inability to obtain values was not a very good idea. Such a test should be carried out by another monitor placed in Configuration (not Performance) category. Then it would be easier to know that it's a configuration error, not system performance.
- Support and development of Microsoft and Nintex based applications
- Application design and development including digital processes
- Invoice management
- Requisition management
- Contract management
- Modern Intranet
ISCG sp. z o.o.
Al. Jerozolimskie 178, 02-486 Warsaw
NIP: 5262798378
KRS: 0000220621
Phone