Installing Desktop Alerts

Make an enrolment key, take the pack from the Deployment tab, and install the whoot. Alerts app on Windows PCs with Intune, Configuration Manager or Group Policy, on Macs with Jamf or another MDM, and on Chromebooks from Google Admin, with every command, field and policy value.

Before You Start

You need devices.manage in the workspace, and your MDM or a way to run an installer on each computer. The app reaches three hosts and nothing else, all on port 443: desktop.whoot.me, api.whoot.me and downloads.whoot.me. Allow them on the school's web filter and proxy before the first install; a computer behind a filter that blocks them shows Not connected and names the filter's page on the Computers tab. No inbound ports, no VPN and no certificate are needed.

Decide which computers get the app: usually every staff computer and every classroom computer with a screen a class can see, and never a pupil's. On a Chromebook the app goes to organisational units, so staff and pupils must be in different ones.

Step 1: Make an Enrolment Key

Open Admin → Desktop alerts → Enrolment Keys and choose New key. A key is what a computer presents the first time it connects, and it carries your workspace's identity into the policy your MDM pushes.

• Name — What the key is for (Staff laptops, autumn 2026).
• Expiry — The last day a computer may enrol with it. Enrolled computers are unaffected when it passes.
• Cap — How many computers may enrol with it.
• Approval — Automatic: a computer is live as soon as it enrols. Manual: each new computer waits on the Computers tab until somebody approves it. Use manual for the first few computers, then a fresh automatic key with a cap for the roll-out.
• Network ranges — Optional: the key only works from these addresses, for example the school's own.

Step 2: Take the Pack from the Deployment Tab

Admin → Desktop alerts → Deployment holds everything below with your workspace and key already filled in: the installers with their SHA-256 (the Windows MSI for x64 and ARM64, the macOS package with its uninstall script, the Chrome extension's ID), the silent install and uninstall commands, the Intune fields, a registry policy file, the macOS configuration profile, and the Google Admin policy. Only two values ever go into a policy: your workspace's TenantId and the EnrolmentKey. Server addresses are never in a policy, so nothing has to be redeployed later.

Windows

The installer is a signed MSI (publisher Eager Lobster Ltd t/as whoot.), installed per machine. It puts a service in C:\Program Files\whoot\Alerts that runs from boot with nobody signed in, and a tray item in each session. The two values can be given to the installer or set by policy; a policy value always wins.

Intune

1. Wrap the MSI with the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) into an .intunewin file.
2. In Intune, Apps → Windows → Add → Windows app (Win32), and upload it.
3. Enter the fields below exactly as the Deployment tab shows them for your workspace.
4. Assign the app as Required to the device group that holds the staff computers.

msiexec /i whoot-alerts-0.7.0-x64.msi /qn TENANT_ID=11111111-2222-4333-8444-555555555555 ENROLMENT_KEY=wh_enrol_YOUR_KEY

• Install command — The silent install line above, with your values.
• Uninstall command — powershell.exe -NoProfile -NonInteractive -Command "Get-Package -Name 'whoot Alerts' -ProviderName msi | Uninstall-Package -Force" (by product name, because the app updates itself and the MSI you uploaded is soon not the version installed).
• Install behaviour — System.
• Detection rule — File: path C:\Program Files\whoot\Alerts\core, file Whoot.Alerts.Core.exe, detection method String (version), operator Greater than or equal to, value the release's version. Not Equal to: a computer that has updated itself would otherwise be reinstalled with the older MSI.

The same line, with the file name and your values from the Deployment tab, is what Configuration Manager, PDQ and an RMM tool run. ENROLLMENT_KEY with the American spelling is accepted too. An install over an existing one keeps the values already on the machine if you leave the properties out.

Group Policy

1. Put the MSI on a share and assign it under Computer Configuration → Policies → Software Settings → Software installation to the staff computers' OU.
2. Set the two values under Computer Configuration → Preferences → Windows Settings → Registry: key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\whoot\Alerts, two string values, TenantId and EnrolmentKey. The Deployment tab's Registry policy (.reg) holds the same two values for tools that import a .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\whoot\Alerts]
"TenantId"="11111111-2222-4333-8444-555555555555"
"EnrolmentKey"="wh_enrol_YOUR_KEY"

By hand on one PC

Download the MSI from the Deployment tab, open an administrator's command prompt, and run the silent install line above with your values. Within a minute the tray icon says Connected, or Waiting for approval under a manual key. To take it off: Settings → Apps → whoot Alerts → Uninstall, or the uninstall command above.

Optional Windows policy values

All under the same registry key, read within a minute of a change. None is needed for a working install.

• StaffGroup (string) — The group whose members see alerts in full: DOMAIN\Staff, Staff or a SID. Unset, everyone is staff.
• NonStaffBehaviour (string) — What anyone outside the group sees: discreet (the code phrase card, the default) or none.
• DeviceName (string) — Sent as the computer's name at enrolment, for an asset tag.
• UpdateChannel (string) — stable (the default) or preview. AutoUpdate (DWORD 0) turns self-update off. UpdateWindow (string) — HH:MM-HH:MM in local time for routine updates, 18:00-06:00 unless set.
• ProxyUrl / PacUrl (string) — Force a proxy (host:port) or a PAC file; otherwise the computer's own settings are used.
• AllowQuit (DWORD 1) — Shows Quit in the tray. UiAccess (DWORD 0) — Stops the alert drawing above full-screen programs and the taskbar.

macOS

The installer is a notarised package (Apple Team ID B87PJ7GURJ) that puts whoot Alerts.app in Applications with a system service that runs from boot and a login item in each session. Its settings come from a configuration profile: managed preferences for me.whoot.alerts with the two values, a Managed Login Items rule by Team ID so nobody can switch the app off in System Settings → Login Items, and its notifications pre-approved and allowed on the lock screen. The Deployment tab's .mobileconfig holds all three, filled in.

Jamf Pro

1. Upload the package under Settings → Computer Management → Packages.
2. Make a policy that installs it, triggered at Enrolment and Recurring check-in with Once per computer, scoped to the staff Macs.
3. Upload the Deployment tab's .mobileconfig under Computers → Configuration Profiles → Upload, scoped to the same Macs at computer level. Jamf's Application & Custom Settings with the Jamf schema from the Deployment tab is the alternative for the preferences alone.
4. Check a Mac's menu bar within a minute of both landing: Connected, or Waiting for approval.

Mosyle, Kandji, Addigy, Intune and Munki take the same two things: the package as a custom app, and the .mobileconfig as a custom profile at device level. The order does not matter. Without the profile the app waits as Not set up and reads the preferences again every minute, so a profile pushed after the package takes effect without a restart.

By hand on one Mac

Download the package from the Deployment tab, install it, then write the two values with defaults. Within a minute the menu-bar icon says Connected or Waiting for approval. A Mac set up this way counts as unmanaged: Quit is offered in its menu, and the app can be switched off in Login Items, so use a profile for any Mac that matters.

sudo installer -pkg whoot-alerts-0.7.0.pkg -target /
sudo defaults write /Library/Preferences/me.whoot.alerts TenantId '11111111-2222-4333-8444-555555555555'
sudo defaults write /Library/Preferences/me.whoot.alerts EnrolmentKey 'wh_enrol_YOUR_KEY'

The optional keys are the same names as on Windows (StaffGroup, NonStaffBehaviour, DeviceName, UpdateChannel, AutoUpdate, UpdateWindow, ProxyUrl, PacUrl, AllowQuit), in the profile or with defaults write. To take the app off, run the uninstall script published beside the package: sudo bash whoot-alerts-0.7.0-uninstall.sh. It keeps the Mac's device key, so a reinstall is the same computer.

ChromeOS

The app is a Chrome extension on the Chrome Web Store, unlisted: it is found by its ID, glgniclnkofakpaaochaepobdnhfahde, never by searching. It is force-installed to organisational units from Google Admin and updated by the Web Store. The Chromebooks must be enrolled in your Google domain and staff must sign in with accounts of that domain; anyone else sees Not set up.

The Deployment tab's Policy for extensions (JSON) carries the two values in the shape Google Admin takes:

{
  "TenantId": { "Value": "11111111-2222-4333-8444-555555555555" },
  "EnrolmentKey": { "Value": "wh_enrol_YOUR_KEY" }
}

1. In Google Admin, open Devices → Chrome → Apps & extensions → Users & browsers and select the staff organisational unit. Never a pupils' unit.
2. Choose Add → Add Chrome app or extension by ID, paste glgniclnkofakpaaochaepobdnhfahde, and keep From the Chrome Web Store.
3. Set the Installation policy to Force install + pin to browser toolbar.
4. Open the extension's settings panel. Under Policy for extensions, paste the JSON above.
5. Set Allow access to keys to Allow. Without it the Chromebook's key signs once, enrolment fails, and the extension stays Not set up.
6. Save. The extension arrives at the next policy refresh or sign-in, pinned to the toolbar; its menu says Connected within a minute.

Every staff profile on a shared Chromebook counts as one computer, so a classroom Chromebook keeps its room whoever signs in. A Chromebook cannot show an alert on the sign-in screen, raise its own volume, or keep an alert out of a screen share, so a shared screen there relies on discreet display. There is nothing to uninstall by hand: removing the extension from the unit removes it from the Chromebooks.

Step 3: Check the Computers Tab

Each computer appears on Admin → Desktop alerts → Computers within a minute of its first connection, with its name, platform, version and status. Under an automatic key it is Connected; under a manual key it is Waiting for approval until you approve it, and it receives nothing until then. Give it a room (Science block, Room 12) straight away, or let a location rule do it; the room is what responders see when Get help is pressed. Then send a test alert to one computer from its page: it shows a real alert on that computer and tells nobody else.

• Not connected — The computer cannot reach whoot. and says why: a web filter (the tab names its page; allow the three hosts), a proxy wanting credentials, or no network. It keeps trying.
• Not set up — No workspace or key reached it (the policy or profile is not applied), or the key was refused: expired, over its cap, revoked, or used from outside its network ranges. A fresh key and a policy update fix it.
• Waiting for approval — A manual key, or a computer that re-enrolled with a new key while the old one was recently seen, which is held on purpose. Approve it or revoke it.

Updating and Uninstalling

Windows PCs and Macs update themselves from the channel in their policy, within the update window, never while an alert is live, and put the previous version back if the new one does not come up; Chromebooks update from the Web Store. You never redeploy an installer for a new version. To take a computer out, revoke it on its page first (it stops at once), then uninstall; the computer's own key and state stay on the machine on purpose, so a reinstall is the same computer. Managing Desktop Alerts covers the rest.