Roll out with Group Policy

This article is for organisations that manage their workstations with Group Policy in Active Directory rather than Microsoft Intune, for example because many of their employees work on Remote Desktop Services (RDS) servers. You go through the same steps as in the managed rollout with Intune: identity, providing the work sign-in, installing the extension automatically, optionally the desktop app, and verifying. What differs per step is described below. If you use both, for example Group Policy on the RDS servers and Intune on laptops, follow the article for the route each group of devices uses.

#What you need

• Permission to edit and link Group Policy Objects, and current Chrome and Edge ADMX templates in your central policy store.
• A verified domain and a connected identity provider in BeeSensible. This step is the same for every route and is described in Identity.
• A test OU containing the devices or RDS servers you start with.
• Outbound access to the BeeSensible hosts, as described in Network and firewall.

In the rollout console, click Change next to Deployment profile and tick the Group Policy route. If you have ticked more than one route, switch between the instructions with Instructions for. For each step the console then shows the path in Group Policy Management and offers the files you need in this article.

#Install the extension automatically

The ExtensionInstallForcelist policy force-installs the extension in Chrome and Edge. It is a computer policy, so it applies to everyone who signs in on a device the Group Policy Object (GPO) applies to.

#Provide work sign-in

The sign-in script is the same script as for Intune. For every user signed in on the device at that moment, it looks up the work address and writes it as a sign-in hint (loginHint) into the Chrome and Edge browser policy and into a registry key for the desktop app. The extension uses that hint, so employees do not have to type an address when they first sign in. Because the script only sees users who are signed in when it runs, you run it at every sign-in through a scheduled task. A startup script under Computer Configuration does not work for this, because it runs before any user has signed in.

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "\\<domain>\NETLOGON\beesensible-managed-login.ps1"

The script reads the work address from a cache in which Windows keeps track of the user's sign-in. If Windows does not know a user's work address, the script skips that user and no sign-in hint is written; the employee then enters their work address themselves once, at the first sign-in.

If the domain of the user name (UPN) differs from the domain of the email address, verify the UPN domain as well under Identity.

If you want Chrome to pass the Windows sign-in on to Microsoft, so that no Microsoft screen appears during sign-in, also set CloudAPAuthEnabled; the policy is in the same Chrome templates under Computer Configuration. The policy passes on the sign-in of devices joined to Microsoft Entra ID (including hybrid joined). On devices and RDS servers that are only joined to Active Directory, Microsoft asks the employee to confirm once.

#The desktop app

The desktop app is optional as long as detection runs in the cloud, which is the default (see Detection on the device). There is no MSI package, so you cannot deploy it with Group Policy software installation. Alongside the Intune package, the console offers a standalone installer (.exe), the enterprise installer, for other deployment tools. It installs machine-wide into C:\Program Files\BeeSensible and installs silently with the /S parameter. Deploy it with the distribution tool you already use, and decide beforehand who controls the version, as described in First, choose the installer.

#On RDS servers

On an RDS server several employees work at the same time, each with their own Windows profile. You therefore install the extension once per server: the policy from Install the extension automatically is a computer policy and applies to everyone who signs in on that server. If you want to start with a pilot group, give that group its own session host or collection, because a computer policy cannot be limited to particular users.

The scheduled task from Provide work sign-in runs at every sign-in, even when other users are already working on the server, and writes a separate sign-in hint for every signed-in user, as described under the source of the work address. During the pilot, check with two users signed in at the same time that the hints stay separate: run the two reg query commands from the check under Provide work sign-in in each session, and each session shows only its own work address.

When you roll out on RDS servers, also keep the following in mind, because this environment differs from a workstation with a single user:

• On RDS servers, use the extension only. The desktop app is built for Windows 10 and 11.
• Employees do not share a BeeSensible account. Every Windows user signs in with their own work account.

#Verifying the rollout

Verification works as described in Verify the rollout, with one difference: instead of syncing with Intune, refresh policy on the test device with gpupdate /forceCopy, or restart the device. Run the checks with a test user without administrator rights and, on an RDS server, with two users at the same time.

#Rolling back

Follow the order in Rolling back. For the parts you rolled out through Group Policy, this works as follows: