Provide the work sign-in
The sign-in script on Windows, and the device profile that does the same on a Mac.
Provide the work sign-in
On Windows
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.
Download the sign-in script
Add it as a platform script
Intune: Devices → Scripts and remediations → Platform scripts → Add → Windows 10 and later.
Fill in the settings like this
| Intune field | Enter |
|---|---|
| Run this script using the logged on credentials | No (that is the system mode) |
| Enforce script signature check | No |
| Run script in 64 bit PowerShell Host | Yes |
Assign to your target group
Assign to the security group from What you need.
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.
The script does not seem to run
Check with dsregcmd /status that the device is Entra joined and that the user has a work account sign-in (AzureAdPrt: YES). A device that is only registered receives no scripts; in a session with a local Windows account there is nothing to set and the script fails visibly in Intune.
The script shows Succeeded, but loginHint is missing
Three causes, checked in this order:
- The user was not signed in when the script ran. The script only writes keys for the profiles loaded at that moment. Run it again while the user is signed in (see the callout above).
- The user's sign-in address is on a domain that is not verified in BeeSensible. The hint is written, but the extension does not recognise it. Verify that domain under Identity.
- The session runs on a local Windows account; there is no work account to set.
What the script did per user is on the device in this log:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AgentExecutor.log
The script already ran, but a new user has no hint
Edit the script in Intune and save it again; it then runs again for all signed-in users on the device. Whether this is still needed after the pilot is covered in the callout Once per target.
Where do I see what the script did?
In Intune, under the script at Monitor, you see the status per device. The lines the script writes itself (set or skipped, per user) are on the device in AgentExecutor.log; the management extension logs the delivery of the script in IntuneManagementExtension.log. Both live here:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
On a Mac
There is no such script on macOS, and that is a platform boundary rather than an omission: a configuration profile on the device channel cannot carry a per-user address, and fixing an address in machine policy makes the device belong to exactly one person.
Instead of who the user is, you supply which organisation the device belongs to. That is one value that applies to everyone on that Mac. The employee then arrives at the right organisation without any choice; which account it is, the Mac decides.
Download the profile
The rollout console generates it at this step, as soon as your organisation has a connected identity provider. Without a connection there is nothing to put in the profile, and the console does not show the button.
Rollout console, Provide the work sign-inThe profile is there, with your organisation's identity provider already in it.Add it as a custom profile
Intune: Devices → macOS → Configuration → New policy → Templates → Custom, and choose the device channel.
Assign it
To the same target group as the other steps.
What we cannot remove here
The choice on the BeeSensible side is gone. Whether the sign-in is then completely silent depends on whether the browser may reuse the existing session with Microsoft, and that is up to the operating system:
- macOS does this through Microsoft's Enterprise SSO plug-in and Platform SSO. You roll those out through Intune yourself; they are Microsoft components. Without that plug-in, Microsoft asks for a confirmation once.
- Conditional Access can always enforce an extra check, however you set this up.
Both also apply on Windows, there through CloudAPAuthEnabled and the Windows sign-in proof.
