Rolling back and offboarding
Reversing everything, what deliberately stays behind and what to do when someone leaves the organisation.
Rolling back
If you want to remove BeeSensible from the devices again, you reverse the rollout in three steps: you withdraw the forced installation of the extension, clean up the sign-in policy and remove the desktop app. A few items deliberately stay on the device afterwards. Each step lists what stays behind and how to remove that too.
Withdraw the forced installation
Remove the assignment of the configuration profile you used to force-install the extension. The extension then disappears from the browser as soon as it processes the policy again. At the same time, remove any of the optional policies you set: MandatoryExtensionsForInPrivateNavigation, CloudAPAuthEnabled and IncognitoModeAvailability.
Clean up the sign-in policy
Clean up the sign-in policy by carrying out the following actions in this order:
- Remove the assignment of the sign-in script. If you do not, a later edit runs the script again and it writes the keys back.
- Assign the cleanup script from the console, with the same settings as the sign-in script (logged on credentials: No).
- Use the registry commands for the sign-in script to check that the keys are gone, then remove the cleanup script's assignment as well.
The cleanup script removes exactly what the sign-in script wrote, per user, but only for the user profiles loaded at that moment. Running it more than once does no harm. If a sign-in hint stays behind for a user who was not signed in, that is harmless, because the hint only contains that user's work address.
Cleanup script in the rollout consoleAt Provide work sign-in, under Rolling back.Remove the desktop app
On the Win32 app, add an assignment under Uninstall for the target group and remove the Required assignment. If you only remove the Required assignment, Intune uninstalls nothing and the app stays on the devices.
After removal, a few items deliberately stay behind: the data folder in each user profile (with sign-in tokens and settings), the shared model cache and two registry keys per user. The table shows where they are.
| What stays behind | Where |
|---|---|
| Data folder per user | %LOCALAPPDATA%\beesensible-desktop |
| Old data folder (older versions) | %APPDATA%\beesensible-desktop |
| Model cache, machine-wide | C:\ProgramData\BeeSensible\engine-cache |
| Sign-in hint (the cleanup script removes it) | HKCU\Software\Policies\BeeSensible |
| Protocol registration of the app | HKCU\Software\Classes\beesensible |
If you want to hand a device back completely clean, remove the folders with the block below. Run it in the system context, for example as a platform script in Intune:
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"
The protocol registration is in the user's own part of the registry, so you remove it per user, in that user's session:
reg delete "HKCU\Software\Classes\beesensible" /f
When someone leaves
If you block or delete an employee in Entra, BeeSensible does not notice this by itself, and their current BeeSensible session stays valid until it expires. So end their access in BeeSensible too: on the Members page of the dashboard, choose Actions → Sign out everywhere for that employee, then Remove member.
If you have set up synchronising employees automatically, Entra passes the block on to BeeSensible itself through SCIM. An employee you deactivate in Entra then also loses access to BeeSensible, without you having to do anything in the dashboard.
