In Windows Server operating systems, a Domain Controller (DC) is a server that responds to security authentication requests (logging in, checking permissions, etc.) within a Windows Server domain. A Group Policy Object (GPO) is a collection of settings that define what a system will look like and how it will behave for a defined collection of user of computer objects.
If you have environments, customer devices, or networks that are controlled by Windows Server Active Directory DCs, you can leverage the Active Directory GPO framework to deploy the Datto RMM Agent to Windows devices joined to the domain. This is the quickest and most scalable method of Agent deployment.
NOTE A standard software installation GPO relies on the availability of the software installer to be attached as a Microsoft Installer (MSI) file. Since the Datto RMM Agent is offered as an EXE file, a standard software installation GPO cannot be used.
There is a component available in the ComStore that you can use to target all of your domain-controlled environments. It is called Deploy RMM Agent by AD GPO [WIN]. This component features the following:
- Functionality for both on-premises and hosted (for example, on Azure or Amazon Web Services) DCs, as well as Azure Active Directory Domain Services (AADDS) environments.
- Automatic downloading of the necessary Agent for the site in which the DC resides, negating the need to download individual Agents on a per-site basis. This means you can run the same component on any DC (or Management Server, in the case of AADDS environments) in any site. The download feature has been confirmed to work behind proxy servers.
- A simple batch file, which is copied into a sub-folder within the System Volume (SYSVOL) share together with the downloaded Agent installer file. This feature has two benefits:
- For on-premises and hosted DCs, it leverages the File Replication Service (FRS) and Distributed File System (DFS) replication in order to automatically replicate to other DCs in the domain.
- For AADDS environments, you do not have to keep a Management Server online 24/7 to host the files, since they are stored directly on Microsoft’s Azure DCs.
- Deployment via an Immediate Scheduled Task GPO, which launches the batch file to install the Agent. This means that all Windows devices joined to the domain will install the Agent automatically upon next policy refresh, which by default is 90 minutes (plus 0-30 minutes randomization). The GPO will also successfully target remote domain-joined devices connected via VPN.
IMPORTANT The default for a GPO script timeout is 10 minutes, but it can be configured for longer. The Agent deployment will fail against VPN-connected devices with slow WAN links if the total of the download, execution, and completion times is longer than the timeout period.
NOTE If you would like to deploy Agents to your endpoints immediately without waiting for the next automatic policy refresh, we recommend installing Specops GPUpdate (a free software application) on your DCs. This will add a "Gpupdate" entry to the context menu within Active Directory Users and Computers to enable you to run GPUpdate both immediately and silently. Windows Server 2012 and above can run GPUpdate natively, but the GPUpdate CMD window will be displayed on all client devices (which may cause concern to your users and result in a brief increase in tickets). Additionally, it can take up to ten minutes to launch. Note that your client devices must respond to PING for Specops GPUpdate to work.
- Full error trapping in the event that something does not work as expected, for example if the download fails due to incorrect proxy credentials or the GPO is not created successfully due to the user context of the job run. In this example, the status of the job run will be "Failed", with a useful message in StdErr explaining the reason for the error.
- Optionally, the component can also deploy via a Startup script GPO, in case you have any Windows XP machines that do not respond to an Immediate Scheduled Task due to updates in the task scheduler in Windows 7.
NOTE The component is written in PowerShell and leverages the Immediate Scheduled Task Group Policy Preference (GPP). Therefore, if you are running any Windows Server 2003 DCs, you must ensure both Powershell 2.0 or above and GPP Client Side Extensions have been installed prior to running this component.
IMPORTANT Datto formally discontinued support for Windows XP and Windows Server 2003 devices as of December 2019. Refer to Discontinuation of support for Windows XP and Windows Server 2003.
With these features, you must be mindful of the user context in which the component is run. The context must allow for the downloading of files from the Internet, writing to the SYSVOL share, and creating and modifying GPOs. By default, a quick job or a scheduled job that has not been configured to run in the logged-in user context will always run in the NT AUTHORITY\SYSTEM user context. Refer to Quick jobs and Job scheduler.
If any of your environments have been configured not to allow the local SYSTEM user account for the DC to create or modify GPOs (this is not the default behavior of a DC, but can be configured), then once you download the component from the ComStore, you will need to make a copy of it, check the This component requires site credentials box, save the copy, and delete the original. Refer to Create a component. For any site where the domain does not allow the local SYSTEM account of the DC to download files, write to the SYSVOL share, or create or modify GPOs, navigate to Settings > Credentials > Edit to configure the credentials for a user account that does (this will normally be a user with membership of the Domain Admins group). Refer to Credentials.
NOTE If the component is configured to run using site credentials, but it is run on a DC within a site in which they have not been configured, it will revert to run as NT AUTHORITY\SYSTEM.
NOTE You can confirm the user context the component was run under in the StdOut when the job completes.
NOTE If you re-run the component on the same DC upon which it was previously run, it will merely update the Agent installer, which may be wise to do from time to time as Agent builds are updated. The batch file, GPO, and link will remain unchanged. Note that the Datto RMM Agent updates itself automatically, if configured to do so within the Account Settings page. Refer to Agent updates.
NOTE If a DC that had this component applied is ever moved to another site, ensure that you re-run it after the move in order to download the Agent for the new site and overwrite the Agent installer file accordingly. This will ensure the GPO always deploys Agents to the correct site. Failure to do so will result in new domain-joined devices being assigned to the DC's original site.
There are two variables you can configure when running the component on your DC(s):
- The CreateGPOLinkAtRoot variable will link to the GPO at the root level of the domain if the value is set to TRUE (this is the default). If you require more granular control over the targeting, for example if you only want to target particular organizational units, set this variable value to FALSE and link the GPO manually at the level(s) you require after the job run is complete.
- SupportXP will also create a Startup Script GPO in addition to the Immediate Scheduled Task GPO if the value is set to TRUE for environments that have Windows XP devices that cannot run an immediate scheduled task, as explained above. This is usually not the case, so the default is FALSE. This is used in conjunction with the CreateGPOLinkAtRoot variable to optionally link this additional GPO at the root level of the domain if set to TRUE.
NOTE If you are currently using the legacy GPO deployment model that runs as a Startup Script, you can deploy this component to the same DC(s). Both models will work simultaneously without issue, similar to setting the SupportXP variable above to TRUE. However, if you would like to clean up after applying the legacy model, delete the \\server\share\folder folder as per the variable values set for mapped_drive_folder (share), the install_folder_name (folder) when you ran that component, and the "AEM Agent Deploy" GPO.