Starting with release
6.11.0, the Core and APM/Trace components of the Windows Agent run under the
ddagentuser account, created at install time, instead of running under the
LOCAL_SYSTEM account, as was the case on prior versions. If enabled, the Live Process component still runs under the
ddagentuser is created at install time for the Datadog Windows Agent. When installed on an Active Directory server, the username and password must be provided to the installer. The new user is a non-privileged user. It gains the following rights during installation:
The installer changes the local group policy to allow the newly created user account,
ddagentuser, to run as a service. If the domain group policy disallows that, then the installation setting is overridden, and the domain group policy has to be updated to allow the user to run as a service.
The Agent installer creates the
ddagentuser at install time, and then registers the service (with the randomly generated password). The user is created as a local user, even in a domain environment, so that every machine on which the Agent is installed has a unique user and password.
The exception is on domain controllers (primary and backup). There is no notion of a local user on a domain controller. Therefore, the created user becomes a domain user rather than a local one.
To support this environment, the Agent installer requires that the administrator provides a username and password under which the Agent run. The username and password are provided as properties on the installation command line, i.e.
Msiexec /i ddagent.msi DDAGENTUSER_NAME=<DOMAIN>\<USERNAME> DDAGENTUSER_PASSWORD=<PASSWORD>
For installs on a domain controller, the
<PASSWORD> supplied should never be an existing “real” (human) user. The installation process changes the rights of the user and they are denied login access.
Note: These options are honored even in a non-domain environment, if the user wishes to supply a username/password to use rather than have the installer generate one.
Note: When upgrading the Datadog Agent on a domain controller or host where the user has supplied a username for the Agent, you need to supply the
<DDAGENTUSER_NAME> but not the
Msiexec /i ddagent.msi <DDAGENTUSER_NAME>=<DOMAIN>\<USERNAME>
If you use Chef and the official
datadog cookbook to deploy the Agent on Windows hosts, use version 2.18.0 or above of the cookbook to ensure that the Agent’s configuration files have the correct permissions
Every effort has been made to ensure that the transition from
ddagentuser is seamless. However, there is a class of problems that requires specific, configuration-specific modification upon installation of the Agent. These problems arise where the Windows Agent previously relied on administrator rights that the new Agent lacks by default.
For example, if the directory check is monitoring a directory that has specific access rights, e.g. allowing only members of the Administrators group read access, then the existing Agent currently can monitor that directory successfully since
LOCAL_SYSTEM has administrator rights. Upon upgrading, the administrator must add
ddagentuser to the access control list for that directory in order for the directory check to function.
Note: The same considerations apply to the log files that may be monitored by the Logs Collection features of the Agent.
The change to
ddagentuser affects your JMX-based integrations if the Agent’s JMXFetch is configured to connect to the monitored JVMs through the Attach API, i.e. if:
You’re using a JMX-based integration, i.e. one of the following integrations:
AND you’ve configured the integration with the
process_name_regex setting instead of the
If you’re using the Attach API, the change in user context means that the Agent’s JMXFetch is only be able to connect to the JVMs that also run under the
ddagentuser user context. In most cases, it’s recommended that you switch JMXFetch to using JMX Remote by enabling JMX Remote on your target JVMs and configuring your JMX integrations using
port. For more information, refer to the JMX documentation.
Now that the Agent runs under
ddagentuser, it does not have access to the full command line of processes running under other users and to the user of other users’ processes. This causes the following options of the check to not work:
exact_matchwhen set to
user, which allows selecting processes that belong to a specific user
For the Cassandra Nodetool integration to continue working, apply the following changes to your environment:
DSCINSTALLDIR) as system-wide variables instead of variables only for the user doing the Nodetool installation.
If you are using the Datadog- Win 32 event log Integration, the Datadog user
ddagentuser must be added to the Event Log Reader Group to collect logs from the Security logs channel:
ddagentuser-> Check Names.