Performance Monitor is a great tool for collecting and analyzing performance data in Windows and Windows Server. There are many counters available that one can look at to help understand how the system is performing. Unfortunately analysis of performance data may not always be straightforward for some system administrators. Luckily, there is the built-in Data Collector Set for Active Directory Diagnostics in Windows Server once the Active Directory Domain Services role is installed on a machine. This feature makes the life of an Active Directory administrator easy as most of the analysis is automated.
In this blog post, I briefly explain how the Active Directory Diagnostics works. I also take you through what I see in some environments where this feature does not work due to inadequate user rights.
The Active Directory Diagnostics Report
Say you are already familiar with the Active Directory (AD) Diagnostics Data Collector Set (DCS) in Performance Monitor, or you have read this blog post and are interested in a report similar to the one below created by the default AD DCS. In the example, we see that there is a warning indicating that the system is experiencing excessive paging. The cause here is that available memory on the system is low. The report also suggests that we upgrade the physical memory or reduce system load. This report allows us to drill into desired areas of interest such as Active Directory, CPU, network, disk, memory, etc.
The Data Collector Set Fails to Start
Unfortunately the AD DCS may fail to start in some instances due to inadequate user rights, which I see often in the field. Instead of starting up and visually indicating with the green play icon as depicted below, there would not even be a pop-up dialog box with a warning or error indicating that there is a problem – the DCS just does not start!
Attempting to kick of the DCS via command line also does not help:
Logman Start "System\Active Directory Diagnostics" –ets Behind The Scenes
Before we get into what exactly the issue is and how we would go about resolving it, let us briefly take a look at how this feature works.
Working environment
The Active Directory Diagnostics DCS leverages the Windows Task Scheduler in order to complete what it is requested to perform. I grabbed a screenshot from the Task Scheduler to help paint a picture:
Following the sequence of events that took place (reading from bottom to top), we get an idea on what happens behind the scenes when the play button is pressed in Performance Monitor. Here are a few informational events that stand out:
- Event ID 100 – Task Started
- Event ID 200 – Action Started
- Event ID 201 – Action Completed
- Event ID 102 – Task Completed
Broken environment
Looking at the task where the Data Collector Set fails to launch, we see the following:
From the image above, we can see Event ID 101. This event means the Task Scheduler failed to start the AD Diagnostics task for the currently logged on user.
Note: These tasks are created under Microsoft | Windows | PLA |System
Taking a look in the Event Viewer (Microsoft-Windows-TaskScheduler | Operational), there is also an Event ID 104 logged indicating that the task scheduler failed to logon…
Required Rights
How do we proceed with this background information? Taking a look back at the scheduled task, we see the following under general options. The specified account is the currently logged on user (which is also reflected in Event ID 101):
You may begin to wonder at this stage as you are currently logged on to the DC with an account that is in the Domain Admins group. What permissions/rights are missing? The log on as a batch job user right assignment, which determines which accounts can log on by using a batch-queue tool such as the Task Scheduler service.
Default Behavior
In Windows Server 2012 R2, this setting is set to “Not Configured” in the Default Domain Controllers Policy. Domain Controllers would then assume the default behavior, which assigns this user right to the following security groups:
- Administrators
- Backup Operators
Common Case
If you look at the policy setting (where the DCS fails to start), you would see that user accounts or groups have explicitly been granted the right. This unfortunately overrides the default behavior – only the accounts and/or security groups listed here have this right (the explain tab lists the default groups):
I observed something interesting when I tested on a few Windows Server 2016 machines in my lab. Default groups are pre-populated when you modify this setting, therefore, chances of accidentally hurting yourself are lower.
The Fix is Very Easy
Administrators and Backup Operators would have to been added over and above the IDRS\fw-service account (in this example) if you still want them to have this user right, as depicted below:
After adding the Administrators group back to the list of security principles allowed to log on as a batch job, the DCS successfully starts:
Logman Query “System\Active Directory Diagnostics” – ets
Closure
Be careful when modifying policy settings such as User Rights Assignments as you could end up seeing unexpected results if they are not properly configured. In this instance, the Administrators and Backup Operators groups would have to be explicitly added with the IDRS\fw-service account in order not to negatively impact the default behavior. Be sure check tools such as the Policy Analyzer and the Security Compliance Manager for guidance on what the recommendations are. This is one example and there are others, such as the inability to add a new DC to an existing domain due to lack inadequate rights!
Till next time…