Verifying the rollout
Check the whole chain on a test device: what to expect on the device and in the console, and what to do if it differs.
Verifying the rollout
Before you roll out organisation-wide, check with the pilot group that the whole chain works: from the policy on the device to the sign-in and the registration in the console. Do this on a test device, signed in with the work account of a test user without admin rights, because an admin account runs scripts with different rights from your employees. The steps below go through the chain in order. Each article in this guide also has its own checks with more detail on each part.
Sync the device
First make sure the device has fetched the latest scripts and profiles. You do this in the same way as for the sign-in script, through Settings → Accounts → Access work or school → the connected work account → Info → Sync, or by restarting the device.
Check the policy
Open chrome://policy or edge://policy. Expected: the BeeSensible entry is under ExtensionInstallForcelist, and the BeeSensible section shows configVersion with the value 1 and loginHint with the work address, both with source Platform and status OK.
Check the extension
The extension is in the browser and has no button to remove it. Check at chrome://extensions or edge://extensions that the version is at least the one given in Automatic Microsoft sign-in.
Check the sign-in
Open a site where BeeSensible works. Expected: the extension recognises the work account and starts the sign-in by itself, without the test user typing an address or picking an account. In Chrome with CloudAPAuthEnabled this happens silently; in Edge a Microsoft window may still appear. Note whatever does still appear, for example a prompt for two-factor authentication, so that you can prepare employees for it.
Check the console
After sign-in, the test member appears in the rollout console under Observed usage, and on the Members page their sign-in shows as Managed. This tells you that BeeSensible recognises the sign-in as a managed sign-in.
Check a second user
Sign in as a second standard user on the same device. Expected: that user has their own sign-in hint with their own work address, and sees nothing of the first user's data or sign-in.
Check the desktop app
If you have rolled out the desktop app, sign in to Windows again. Expected: after that sign-in the BeeSensible icon is in the system tray, and the app is signed in with the work account or asks you to sign in once.
Check private windows
This check is only needed if you have set up a measure for private windows. Open an InPrivate or Incognito window and compare what you see with the description under Private windows.
Troubleshooting
The full fixes are always with the step in which the problem occurs. Below, each symptom points you to the step where you should look.
Nothing arrives on the device
Sync the device. Bear in mind that scripts and configuration profiles arrive through different channels and at their own moment. The extension being there therefore tells you nothing about the sign-in script, and the other way round.
The sign-in script does nothing
Provide the work sign-in lists the causes and how to check them: whether the device is joined to Microsoft Entra ID (Entra joined), whether the user is signed in with a work account, whether their profile was loaded when the script ran and whether the domain is verified. It also tells you where to find the logs on the device.
The sign-in is not silent in Chrome
A sign-in without a Microsoft screen in Chrome requires the CloudAPAuthEnabled policy. How to set it up and check it is described under Silent sign-in in Chrome in Optional hardening.
The extension version lags behind
New versions of the extension arrive through the browser's store, and you cannot pin or force a version. More on this is in Install the extension automatically, and what to do when Edge lags behind is under Automatic Microsoft sign-in.
The desktop app shows Pending or Failed
The possible causes and the logs to check are in the Verify step of The desktop app.
