Provide the work sign-in
How to save employees from typing their work address: 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 no longer have to type an address or pick an account.
The script runs in the system context, because a standard user cannot write to the protected policy branch of the registry. It finds the signed-in work accounts on the device itself and, for each user, writes the browser policy for Chrome and Edge plus the key for the desktop app. On a device with only a local Windows account, the script fails visibly in Intune, so a green tick 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 as follows
| Intune field | Enter |
|---|---|
| Run this script using the logged on credentials | No (this runs it in the system context) |
| Enforce script signature check | No |
| Run script in 64 bit PowerShell Host | Yes |
Assign to your target group
Assign it to the security group from What you need.
Windows fetches newly assigned scripts at every restart and periodically in between. To force it straight 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
Use dsregcmd /status to check that the device is Entra joined and that the user is signed in with a work account (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
There are three possible causes; check them 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 uses a local Windows account, so there is no work account to set.
The device logs what the script did for each user in this file:
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; it then runs again for every user signed in on the device. The callout Once per target explains whether this is still needed after the pilot.
Where can I see what the script did?
In Intune, the script's Monitor section shows the status for each device. The lines the script writes itself (set or skipped, per user) are in AgentExecutor.log on the device; the management extension logs the delivery of the script in IntuneManagementExtension.log. Both are in this folder:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs
On a Mac
There is no equivalent script on macOS. That is a limit of the platform, not an omission: a configuration profile on the device channel cannot carry a per-user address, and hard-coding an address in machine policy ties the device to exactly one person.
Instead of telling the device who the user is, you tell it which organisation it belongs to: one value that applies to everyone on that Mac. The employee then lands in the right organisation without having to choose; the Mac decides which account is used.
Download the profile
The rollout console generates it at this step, as soon as your organisation has a connected identity provider. Without one there is nothing to put in the profile, and the console does not show the button.
Rollout console, Provide work sign-inYou will find the profile here, with your organisation's identity provider already filled in.Add it as a custom profile
Intune: Devices → macOS → Configuration → New policy → Templates → Custom, and choose the device channel.
Assign it
Assign it to the same target group as the other steps.
What this does not cover
That takes care of the choice on the BeeSensible side. Whether the sign-in is then completely silent depends on whether the browser may reuse the existing Microsoft session, and that is up to the operating system:
- macOS handles this through Microsoft's Enterprise SSO plug-in and Platform SSO. You deploy those yourself through Intune; they are Microsoft components. Without the plug-in, Microsoft asks for confirmation once.
- Conditional Access can always enforce an extra check, however you set this up.
Both apply on Windows too, where the equivalent runs through CloudAPAuthEnabled and the Primary Refresh Token (PRT) that Windows holds.
