Deploy with Microsoft Intune

With Microsoft Intune you roll out BeeSensible centrally: the browser extension installs by itself, employees sign in with their work account, and the desktop app installs silently. Put this page next to Intune and work top to bottom; the tables follow the fields of the Intune screen.

#What you need

• Devices running Windows 10 (64-bit) or Windows 11, joined to Microsoft Entra ID (Entra joined) and enrolled in Intune. TestedWindows 11, 31 August 2026
• A verified domain and a connected identity provider in BeeSensible; see Identity below.
• A target group: a security group in Entra with the users you are rolling out to. Preferably start with a small pilot group, then assign the same profiles to the rest of the organisation.

#Network and firewall

On a network with outbound filtering, allow these hosts on port 443. The endpoints Intune itself needs are not in this list; Microsoft publishes those.

If you also allowlist applications: the desktop app starts a helper process on the device that does the detection. In Task Manager and in EDR reports that process is called python.exe, and it runs from the BeeSensible installation folder:

C:\Program Files\BeeSensible\resources\sidecar\python\python.exe

#Identity

The sign-in hint from step 1 only works when BeeSensible knows your employees' email domain and which identity provider belongs to it. Without that connection, the sign-in falls back to the regular account picker. Arrange this before step 1, in the console under Identity.

1. Verify the domain. Add your employees' email domain and create the DNS record the console shows. Only after verification can an identity provider be connected to it.
2. Connect the identity provider. Under Business sign-in (Microsoft Entra ID) you find the steps for the app registration in Entra; the console shows the redirect URI and the fields for Directory ID, Application ID and client secret.
3. Neutral app name. Name the app registration in Entra BeeSensible, for example: Microsoft shows that name to every employee on the sign-in screen. You can rename it later via Entra, App registrations, Branding.
4. Client secret lifetime. A client secret in Entra expires. Note the end date: once it expires, the work sign-in stops until you paste a new secret into the console.
5. Emergency access. Employees who come in through the identity provider have no password of their own. Make sure at least one administrator does have a password and a second factor; the console shows under Emergency access whether that is the case.

#Step 1: provide the work sign-in

The sign-in script tells the extension and the desktop app which work address belongs to the signed-in Windows user. Employees then skip typing an address and picking an account.

The script runs as system, because a standard user has no write access to the protected policy branch of the registry. It looks up the signed-in work accounts on the device itself and writes the browser policy for Chrome and Edge plus the key for the desktop app, per user. On a device with only a local Windows account, the script fails visibly in Intune: a green check always means something was actually written.

Windows fetches newly assigned scripts on every restart and periodically in between. To force it right away: Settings → Accounts → Access work or school → the connected work account → Info → Sync. If your organisation uses the Company Portal app, its sync button works too.

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

#Step 2: install the extension automatically

The forced installation works through the ExtensionInstallForcelist browser policy: the extension appears in the browser by itself and cannot be removed.

#Automatic Microsoft sign-in

With steps 1 and 2 in place, the extension recognises the work account: the employee types no address and picks no account. Whether a Microsoft screen still appears depends on the browser.

This needs a recent extension. Since5.5.14 the extension recognises the work account from the sign-in script; Since5.5.17 it also tries to complete the sign-in in Edge without an account picker. Check the version on chrome://extensionsCopy or edge://extensionsCopy. When a version arrives is up to the store; an organisation cannot pin the store version.

After a successful sign-in, BeeSensible keeps using the existing session for as long as it is valid.

#Optional hardening

Both measures below are optional: the extension and the sign-in work without them. Optional

#Silent sign-in in Chrome (CloudAPAuthEnabled)

Chrome only passes the Windows sign-in on to Microsoft with this policy (Chrome 111 or newer):

Search the settings catalog for the name above; that finds it faster than the full display name "Allow automatic sign-in to Microsoft cloud identity providers". Pick the device variant, set it to Enabled and assign to your target group. The policy applies to the whole device by definition, not per browser profile, and does not work in Incognito windows.

With this policy, Chrome shares device and account information with Microsoft during Microsoft sign-ins, the same exchange Edge performs by default.

#Private windows (Incognito and InPrivate)

Forced installation does not automatically apply in private windows: whether an extension may run there is a permission the user sets themselves, and browser policy cannot switch it on by design. Without an extra measure, a private window is a window without BeeSensible.

Since5.5.17 the extension reports at sign-in whether it may run in private windows; the deployment console counts how many clients are covered.

If you withdraw the forced installation later, remove these policies as well; see Rolling back.

#Deploying the desktop app

For Intune, BeeSensible provides a ready-made Win32 package (.intunewin) containing the enterprise installer. Packaging with IntuneWinAppUtil yourself is not needed.

signtool verify /pa BeeSensible-Enterprise-Setup-<version>.exe

BeeSensible-Enterprise-Setup-<version>.exe /S

"C:\Program Files\BeeSensible\Uninstall BeeSensible.exe" /S

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\7181cf82-0fd7-4079-86fa-1d55be2016d3

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\7181cf82-0fd7-4079-86fa-1d55be2016d3" /v DisplayVersion

#macOS

For macOS, the console generates a configuration profile (.mobileconfig) that handles the forced installation of the extension for the browsers in your deployment profile. Prerequisites: the Mac is enrolled in Intune and the browser is already installed; the profile does not install a browser.

#Verifying the rollout

Walk through the whole chain on the test device, signed in with the work account of a test user without admin rights. The per-step checks above remain the place to zoom in.

#Troubleshooting

The detailed blocks sit with the step where the problem arises; this is the signpost.

#When someone leaves

Blocking or deleting an employee in Entra does not end the BeeSensible session right away: the running session stays valid until it expires. So end the access in BeeSensible as well. On the members page of the dashboard: Actions → Sign out everywhere, then Remove member. If your organisation uses SCIM provisioning from Entra, the directory pushes the block through by itself; BeeSensible sets up SCIM for you on request.

#Rolling back

Everything in this work instruction is reversible.

Get-ChildItem C:\Users -Directory | ForEach-Object {
  Remove-Item -Recurse -Force -ErrorAction SilentlyContinue (Join-Path $_.FullName "AppData\Local\beesensible-desktop")
  Remove-Item -Recurse -Force -ErrorAction SilentlyContinue (Join-Path $_.FullName "AppData\Roaming\beesensible-desktop")
}
Remove-Item -Recurse -Force -ErrorAction SilentlyContinue "C:\ProgramData\BeeSensible\engine-cache"

reg delete "HKCU\Software\Classes\beesensible" /f