Mass-deploying an agent: GPO, Intune, and Jamf

Deploying an agent to ten machines is a morning’s work. To a thousand, it is a question of method. Three channels cover most fleets: GPO for domain-joined Windows, Intune for cloud-managed fleets, Jamf for macOS. Each channel has its own rhythm; pick one and keep it consistent.

Before you start

Three rules prevent most failures.

• Test on a pilot group before any wide rollout.
• Map every machine to its channel: domain, Intune or Jamf.
• Keep a fallback: an attended session with a 6-digit code works even on a machine that escaped deployment.

Those three rules fit one sentence: know where every machine lands before launching the first installer.

Deploying with GPO

For Windows machines joined to an Active Directory domain, group policy remains the most direct channel.

• Create an organisational unit or a security group for the target machines.
• Point a startup script or a software installation policy at the installer provided in your console.
• Prefer a per-machine install: the agent must exist before a user signs in.
• Force a policy refresh with gpupdate, or reboot the machines.

A per-machine install avoids the classic case of a device that never saw the agent because no user signed in with the required rights.

Deploying with Intune

For cloud-managed fleets, Intune delivers the agent like any Win32 application.

• Package the installer as a Win32 app.
• Define a detection rule, file path, version or registry key, so Intune knows the install succeeded.
• Assign the app to device groups, not users: the agent installs per machine.
• Account for the enrollment status page: the agent installs before the user reaches the desktop.

Check policy exclusions too: an app blocked by another rule fails without a clear message. The goal is simple: every enrolled device carries the agent before a user needs support.

Deploying with Jamf

On macOS, Jamf Pro does the job through a policy.

• Upload the installer package to Jamf.
• Create a policy with an install trigger, at enrollment or check-in.
• Scope the policy to a smart group rather than machines listed one by one.
• Validate on a single Mac, then widen gradually.

Widen one smart group at a time, and confirm the policy completed on the test Mac before scoping further.

Checks after deployment

Deployment does not end when the installer ends. It ends when the console confirms it. Run the checks on the pilot first, then spot-check the fleet.

• Every machine appears in device management.
• Test automatic reconnection: a plain reboot, then a reboot into Safe Mode.
• Test Wake-on-LAN on a powered-off machine.
• Check firewall traversal: Ubidesk uses port 443 only.

The special cases

• Servers and kiosks: schedule the install in a maintenance window, never during activity.
• Always-on machines: prefer a check-in or startup trigger over a forced install.
• Mixed Windows and macOS fleets: keep one pilot per system; failures do not diagnose the same way.

The safety net

Machines that escape deployment, off-domain devices, personal machines, urgent replacements, stay covered through unattended access once the agent is installed, or through an attended session: 6-digit code, temporary client, no installation, no administrator rights. Remote support keeps an answer for every edge case. Even machines outside your MDM stay reachable that way.

A successful rollout is measured by the machines that report into the console, not by the installers launched. If a machine is missing, the safety net catches it: an attended session with a 6-digit code closes the gap the same day. The same method serves internal IT teams and service providers alike.