When setting up a Dynatrace lab, a practical question comes up: can we use the same Windows Server for both OneAgent traffic routing and the Synthetic engine?
To investigate this, I installed a routing/monitoring ActiveGate on a Windows Server and then attempted to install a Synthetic-enabled ActiveGate on the same operating system.
The first installation succeeded. The second attempt opened the existing installation’s maintenance workflow and eventually failed. This case study explains the experiment, the exact installer error, and the deployment approach Dynatrace engineers should follow.
1. Understanding the two ActiveGate purposes
ActiveGates and their purpose
Routing/monitoring: Routes OneAgent traffic to Dynatrace and supports cloud monitoring or remote-technology monitoring through applicable modules and extensions.
Synthetic: Runs Synthetic monitors from a private location, allowing tests against applications reachable from that location.
These are different installation purposes, rather than two unrelated products. Dynatrace assigns different functional modules to each purpose and does not support mixing modules between purposes.
2. Objective and lab configuration
The objective was to check whether a routing/monitoring ActiveGate and a Synthetic-enabled ActiveGate could operate together within the same Windows Server installation.
The experiment did not separately record whether the 30 GB represented total disk capacity or available free space. This distinction matters when checking installation prerequisites.
3. Installing the routing/monitoring ActiveGate
For the first installation, I selected the purpose: Route OneAgent traffic to Dynatrace, monitor cloud environments, or monitor remote technologies with extensions.
The installation proceeded, and the ActiveGate subsequently appeared in the Dynatrace UI.
Routing/monitoring ActiveGate installation downloads additional capabilities. This confirmed a successful installation and registration. Testing actual OneAgent routing, cloud integrations, or extension execution would require additional functional checks.
4. Attempting the Synthetic ActiveGate installation
Next, I attempted to install the Synthetic purpose on the same Windows Server. The relevant arguments in the attempted installation included:
ENABLE_SYNTHETIC=true
--set-group=default
- These arguments describe the captured attempt; they are not a complete installation command.
- The installer opened a welcome page that described updating additional capabilities or removing the existing ActiveGate.
The installer log confirmed the behaviour:
- Product registered: entering maintenance mode
This is a key observation. The second execution was operating on the registered ActiveGate installation rather than creating an independent second instance.
5. The installation error
Once you choose any one option (Update capabilities or Remove), the wizard proceeds to the Ready to Install page.
During the operation, the following error appeared:
ERROR: Group cannot be specified for an update or maintenance. To proceed with the installation, remove the network zone parameter and restart the installation process.
The wording is slightly inconsistent: the first sentence identifies a group restriction, while the second mentions a network zone parameter.
To understand the actual failure, I checked the surrounding log entries:
ADDITIONAL_CONFIGURATION is (--set-group=default)
Parsing (--set-group=default)
Found group in ADDITIONAL_CONFIGURATION
Extracted group as (default)
- These entries identify the group argument being processed immediately before the error.
- The immediate failure was the use of --set-group=default during maintenance mode.
Note: Dynatrace documents that --set-group can be used during installation but cannot be used during an ActiveGate update. Group changes after installation have separate supported methods.
6. Understanding error 1603
After the validation error, the setup wizard ended prematurely.
The log recorded:
- Action ended 15:56:08: ParseAdditionalConfiguration. Return value 3.
- Action ended 15:56:08: INSTALL. Return value 3.
- MainEngineThread is returning 1603
Windows Installer error 1603 indicates a fatal installation error. It does not identify the underlying cause by itself. Here, the earlier group-validation message explains why the operation stopped.
Keyfinding: For engineers investigating similar failures, the useful approach is to find the failing action and read the messages immediately before it.
7. Can removing the group parameter enable both purposes
Removing the parameter would address the argument rejected in this attempt. However, it would not make combining routing and Synthetic purposes a supported deployment.
Dynatrace requires a clean installation for Synthetic monitoring. If an existing ActiveGate host is reused, its current ActiveGate must first be uninstalled. A Synthetic-enabled installation is dedicated to Synthetic execution and disables other ActiveGate functionality, including OneAgent communication.
This gives us two separate findings:
- The screenshots show Remove as a maintenance option. They do not contain an explicit error instructing the user to uninstall the routing ActiveGate before installing Synthetic. That requirement comes from the documentation.
- A retry without the group parameter and a successful clean Synthetic installation were not part of the documented results.
8. Were CPU, memory, disk space, or ports responsible
The recorded failure does not identify a resource shortage or port conflict. It identifies an installer configuration restriction. Nevertheless, resource and network checks remain necessary before deploying a Synthetic node.
Engineers should verify:
- Available RAM and free disk space after Windows and other applications are accounted for.
- Requirements for browser-enabled or browserless Synthetic nodes.
- Connectivity to Dynatrace, monitored applications, and required download endpoints.
- Capacity appropriate to monitor frequency and execution workload.
By default, a routing ActiveGate receives OneAgent connections on TCP 9999 and connects to Dynatrace on TCP 443. Simply stating that both ports are enabled does not establish the required connection direction or complete network reachability. Increasing server resources would not resolve the documented separation between ActiveGate purposes.
10. Key lessons for Dynatrace engineers
This experiment highlights several useful operational practices:
- Select the ActiveGate purpose before installation.
- Recognise when an installer has entered maintenance mode.
- Check whether installation arguments are valid for an update or maintenance operation.
- Investigate the messages preceding error 1603.
- Distinguish the observed installer failure from the product’s deployment requirements.
- Validate monitoring functionality after installation.
- Remove credentials from screenshots, commands, and logs before publishing them.
The experiment’s conclusion
The attempted Synthetic installation detected the existing ActiveGate, entered maintenance mode, and failed while processing the group parameter.
The broader deployment answer comes from Dynatrace’s requirements: use separate operating-system instances for routing/monitoring and Synthetic purposes when both must run simultaneously. Reusing an existing routing host for Synthetic requires a clean installation after removing its current ActiveGate.
