fetch Guide

What is fetch?

fetch is the Software Centre on your PC. It lets you install and update software your IT team has approved - things that would normally need an administrator - without needing an admin password. You click Install; fetch checks the item against your organisation's policy and installs it for you.

Installing software

1. Open fetch - Software Centre from the Start menu or system tray.
2. On the Available to install tab, find the app (use the search box at the top) and click Install.
3. A progress window shows the install. When it finishes you'll see it move to Installed software.

Most installs are silent - no setup wizard, nothing to click. A few apps (e.g. large vendor suites) show their own installer; just follow the prompts.

If an install fails, note the message and tell IT - they can see the detailed reason on the hub.

Install with approval (right‑click)

For an installer you've downloaded (an .exe or .msi), right‑click it and choose “Install with approval”. fetch checks it against policy and, if it's from an approved publisher, installs it with elevation. If it isn't approved, you'll be offered the chance to request it (below).

Requesting software

Need something that isn't in your catalogue, or an installer that wasn't approved? Click Request software… (or choose to request when an install is blocked). Add a short note about what you need and why, and submit. If you have the installer you can add its file path, and if you know where it's downloaded from you can paste a download link - either helps IT check and approve it faster.

Your IT team is notified and can approve it. Once approved, the item becomes installable (an approval typically lasts 24 hours for that exact file).

Tracking your requests

When IT makes a decision, fetch pops a tray notification - approved (you can install it now) or declined. If you miss it, open the My requests tab in fetch: it lists everything you've asked for with its status (Pending / Approved / Declined), when it was decided, and your original note.

Updates

On the Installed software tab, apps with a newer approved version show an Update option. Click Check for updates to refresh. Some updates are required by your organisation and may prompt you to install them (or install automatically when your PC is idle).

Restarting to finish updates

Windows security updates only protect your PC once it restarts. When a restart is needed, fetch shows a Restart needed window that stays until you answer: Restart now (it asks you to confirm, so you can save your work first) or Remind me later.

If you keep putting it off, the reminder becomes firmer: after a few days it turns red, says how many days the updates have been waiting and how long the PC has run without a restart, and comes back more often. Pick a moment that suits you - for example once a render or long job has finished - and choose Restart rather than Shut down (with Windows Fast Startup, shutting down doesn't count as a restart).

Activity - what's happening on your PC

The Activity tab lists installs, updates and uninstalls on this PC - the ones you started, and the ones your IT team sent from the hub - with their status: queued, running, done or failed. Installs run one at a time, so you can queue several and they'll follow on. Open an entry to see its progress, or cancel it if it hasn't started.

Requests from IT reach your PC when it next checks in with the hub, every few minutes. Press Refresh (or open Activity) and fetch checks straight away, so a job IT has just sent appears within seconds.

Freeing up space & tidying shortcuts

Where your organisation has enabled it, a Maintenance tab appears in fetch with two housekeeping tools. If you don't see the tab, these haven't been turned on for your organisation.

Free up space

Click Free up space… to scan for files that can be safely removed - temporary files, Windows Update and other caches, crash reports and the Recycle Bin. You'll see how much each category holds; tick what you want to clear and press Clean selected. Your open apps and documents are not affected, and it only ever clears this fixed, safe list - never programs, Windows features or System Restore.

Tidy desktop shortcuts

Click Tidy shortcuts… to list the shortcuts on your desktop, tick the ones you don't want and press Remove selected. Shortcuts marked (all users) sit on the shared desktop, so removing them clears them for everyone on that PC - you'll be asked to confirm before that happens. Removing a shortcut only deletes the shortcut, never the program it points to.

Getting help

Use the Contact IT button in fetch to reach your support team (and, where enabled, start a remote‑support session). For anything about a specific app or install, include the app name and any error message you saw.

How fetch works

fetch has four parts:

The policy is a signed JSON document. The Policy tool signs it with your private key; every client verifies it with the matching public key (baked in at install). Nothing a client receives is trusted unless it carries a valid signature.

First‑time setup

1. Install the Policy tool (Fetch-Admin-x.y.z.msi) on your admin machine.
2. Open it and go to the Cloud tab. Enter your licence‑server address (e.g. hub.getfetch.co.uk - https:// and /api/v1 are added for you), your portal email, and Send code. Enter the 6‑digit code and Connect. fetch pulls your organisation's licence server and enrolment key automatically, so you never copy keys by hand.
3. Create or select a signing key (see below).
4. Build your policy - rules + catalogue - then Sign & publish from the bar at the top of the window. The bar is on every tab and turns amber whenever you have changes devices don't have yet - after adding a firewall rule or changing a setting, publish from wherever you are.
5. Deploy the agent to client PCs.

The Start here tab walks you through these steps and shows what's still outstanding.

Your signing key

The policy‑signing key is yours and is critical. Two options on the Signing key tab:

• Local key - generated on your PC and stored encrypted with DPAPI (only your Windows account on that machine can use it).
• Azure Key Vault - the private key stays in the vault and signs via your az login; portable across machines.

The matching public key is what clients get (the MSI bakes it in). If you lose the private key you must re‑provision a new public key to the whole fleet, so protect it.

Locking the Policy tool (optional)

The Policy tool can sign and publish policy for every PC, and it normally stays signed in. If someone else could use your PC while you're logged on, turn on the lock: in the Policy tool, under your hub connection, tick Lock the Policy tool for my account.

• It then asks for Windows Hello (fingerprint, face or PIN) - or a code emailed to your account - when it opens, after the idle time you choose (default 15 minutes), and before Sign & publish if you haven't confirmed in that time.
• The setting is kept with your account on the hub, so it applies on every PC you use and can't be switched off by deleting a file. Turning it on first checks that Windows Hello or email works for you, so you can't lock yourself out.
• Off by default. The saved hub session is also encrypted to your Windows account.

Know when a policy is published: on the hub, Manage → Email this organisation's admins whenever a policy is published sends each admin the revision, time and PC it came from - so a publish nobody expected stands out, and you can roll it back from the Policy tool's history.

Rules - what may elevate

A rule says which files may be installed elevated. Match on publisher (certificate subject + issuer) and/or SHA‑256 hashes for unsigned files, with an optional minimum version. Each rule can be interactive (shows the vendor's UI) or silent.

Use the Inspect file tab to see exactly who signed an installer, so you create a correct publisher rule without guessing.

Rules also govern which child processes an installer may spawn (its own publisher and a small set of Microsoft tools), so an approved installer can't be used to launch a shell.

Catalog - self‑service apps

The catalog is what users see in the Software Centre. Each item has a source:

• Direct URL / path to an .msi or .exe (optionally per‑architecture).
• winget package id (e.g. 7zip.7zip) - Microsoft‑validated.

Double‑click a catalog row to edit all fields: display name, vendor, source, authorising rule, installer switches (e.g. /qn, /norestart, or /S for NSIS), Install UI (Silent / Interactive / Inherit), reboot behaviour, icon, Match installed name (how the app appears in Add/Remove - used for update detection and uninstall), audience, and version handling.

Drop folder - auto‑catalog installers

On the Drop folder tab, point fetch at a folder only admins can write to. Drop an .msi or .exe into it - or any subfolder - and the Policy tool inspects it and auto‑creates a catalog item plus its authorising rule: a publisher rule if it's signed, or a hash rule if it isn't. Use Scan now for existing files, or tick Watch to import new ones as they arrive.

New items default to silent, on‑demand install - nothing runs automatically. For an MSI silent is automatic; for an .exe, set its silent switch (e.g. /S) on the item. Review the additions, set any parameters, then Sign & publish from the bar at the top. Trust stays in the signed policy (publisher/hash), never the folder, so a file swapped in later isn't trusted until you re‑ingest and re‑sign.

Folder permissions. The Set drop‑folder permissions button makes the folder read‑only to users (admins full control) in one click - it covers Domain Admins/Users too. fetch won't watch or import from a folder users can write to until you fix the permissions or explicitly accept the risk. There's also an optional user intake folder (a drop‑box where users can submit installers but can't see each other's). For a UNC share, set the SMB share permissions on the server as well.

Point each item's Source at a path your client PCs can reach (the drop share itself, if it's a UNC, or host it on the hub).

Firewall rules

Some software needs a Windows Firewall rule (a vendor requires an open port, say). On the Firewall tab, add rules the service deploys and keeps in sync across every device on the policy. Each rule has a direction, action, protocol, local/remote ports, an optional program, and profiles. They appear on devices as “Fetch: …” and are reconciled on each sync - removing a rule here removes it from every device; fetch never touches rules you created by hand.

A rule can stand alone (e.g. allow inbound TCP 9100 for a label printer) or be attached to a catalog app. When you remove an app that has attached rules, fetch offers to remove those rules too.

Audience - who gets what

Every rule and catalog item can be scoped by audience: Active Directory / Entra / local groups and/or specific users (DOMAIN\user or SID). Leave blank for everyone. Membership is read live from the signed‑in user's token, so you manage who's in a group in your directory and fetch honours it.

Targeting is by user, not device - "Developers get X" follows whoever is logged in.

Required apps & minimum versions

Tick Required on a catalog item to mark it as software your organisation needs - that's how you push an app to a group (scope it with an audience). Combine with Update handling = Auto to keep it current.

By default, if a required app is missing (never installed, or the user removed it) the user is prompted to install it the next time they open the fetch app - it isn't reinstalled silently and nothing happens until they open it.

Self-heal (optional). Turn on "Self-heal: silently reinstall a required app if it's removed" in the Policy tool (Deployment → Required apps) and the agent will silently reinstall any required app it finds missing on its periodic catalog check - every few hours, no need for anyone to open the fetch app. So if someone uninstalls a required app, it comes back on its own within the next check, and the user gets a brief "required software restored" notice. (Detection uses the item's Match installed name, so set that for reliable matching.)

Set a Minimum version (and optionally Critical security update) on an item and the hub's Update alerts will flag any device running below it - critical ones in red.

Per-user apps (install scope). Some apps (e.g. Blender) install into the signed-in user's profile rather than for all users. These can't be installed, updated or self-healed by the background service as SYSTEM - Windows won't let SYSTEM place or replace a per-user package (the tell-tale is an upgrade failing with "uninstall 1605"). For those, set Install scope = User on the catalog item (next to the winget id). fetch then runs the install/update as the signed-in user, with no elevation, so it lands in the right place. The trade-off: a per-user item can only be installed or self-healed while that user is signed in (it's installed for that user, after all) - if no one is signed in, it's deferred to their next session. Leave scope on Machine (the default) for normal all-users apps. For apps already installed the wrong way, fetch also auto-retries a failed machine update as the user, so most per-user updates "just work" even before you set this.

Deploying the agent

On the Deployment tab, fetch generates what you roll out: an MSI command and a .reg file, with your public key and licence server filled in. Install the agent MSI on client PCs:

msiexec /i Fetch-x.y.z.msi ORGKEY=<your-enrolment-key> /qn

The enrolment key and licence server can be baked into the MSI at build time (so a plain install is self‑configuring) or supplied on the command line. Devices enrol automatically on first run and pull the signed policy from the hub.

winget provisioning

Most Windows 10/11 desktops already have winget. For machines that don't (Windows Server, LTSC, stripped images), the service provisions it automatically - it downloads the App Installer packages from the hub, hash‑verified, only on the machines that need it, so there's nothing to install on clients and no bloat in the agent MSI. (For air‑gapped sites the package can be staged alongside the service instead.)

Releases & auto‑update

The agent self‑updates: the service checks the hub daily and, when a newer signed, same‑publisher build is published, downloads and installs it silently. Only ever upgrades.

Publish from the hub's Releases page: choose a source - host on the hub (upload the MSI; the SHA‑256 is computed for you) or an external URL / CDN - set the version and channel, and Publish.

The hub console

Each organisation page is tabbed:

• Devices - enrolled machines with their health (see Device health): Windows version and support, uptime, updates, BitLocker, disk, last user, client version and policy revision. Filter with the chips or text box and sort by any column.
  Labels - tag devices with anything useful (a user's name, a service tag, "Laptop", "Finance"). Click + label under a machine name to type a new one or pick one you've already used. Click a label (under a machine or in the Labels bar) to show only those devices; the panel that opens lets you add or remove devices, see the other labels they share, rename or delete the label, and run Update Fetch, Upgrade unsupported Windows or Install security updates on just that group. Labels also match the text filter and can be sorted on. Operators and admins can change labels; viewers can only filter by them.
  Export devices (CSV) downloads an inventory, one row per device: labels, last user, manufacturer, model, BIOS, Windows version and support end date, Fetch client, BitLocker, disk, uptime, pending updates and graphics. Export software (CSV) lists every installed app on each device (name, version, publisher, install date) with the same labels, manufacturer and model columns. Both export the devices currently shown, so filter by label, chip or text first to export a group. Open them in Excel and filter there by label, manufacturer, Windows version and so on.
• Software - two tabs: Version drift (who's behind, align to latest, out‑of‑support runtimes - see below) and Installed software (everything installed across the org; sort any column, filter, click a count to see which devices have it).
• Usage - app usage and removal candidates (opt‑in).
• Deploy - push a catalog app to one or many devices.
• Updates - devices behind a minimum app version, plus Windows versions, drivers, BIOS/firmware and PC‑maker update tools.
• Activity - everything sent from the hub (waiting for device → running → done/failed, with Cancel while it's waiting), what ran on each device, and the elevation audit trail; filter and export to CSV.
• Requests - approve/deny elevation requests from users.
• Administrators - who can see/manage this org.
• Manage - licence/seats and enrolment‑key rotation.

Commands you send from the hub are collected on the device's next check‑in - every ~5 minutes - and installs run one at a time through the device's queue.

Use Refresh / Auto‑refresh to watch inventory, commands and activity update live.

Actions & timers - what happens when

Devices aren't connected to the hub all the time: each one checks in every ~5 minutes to collect anything you've sent, and runs its other jobs on their own schedules. This table shows when each thing happens on its own, how to make it happen now, and where to see that it's done - so a few minutes of "waiting" isn't mistaken for nothing happening.

Nothing seems to happen?

• Hub says waiting for device - the PC hasn't checked in yet. Check its Last seen: if it's off, asleep or offline the job runs when it's back. winget jobs (app updates, Replace) also wait for someone to be signed in. To hurry it, press Refresh in the Software Centre on that PC. You can Cancel while it's waiting.
• running for a long time - installs queue one at a time, so look at the PC's Activity tab to see what's ahead of it. A full Windows upgrade really does take an hour or more.
• done, but the hub still shows the old version - the device's report follows about 90 seconds later; press Report status now if you need it straight away.
• failed - the reason is on the Activity row (and the device page). On the PC, Event Viewer → Applications and Services Logs → Fetch has every hub command, install, and anything Fetch stopped, with why.
• No Fetch icon in the tray after an update - from 1.0.66 the service brings it back by itself within a few minutes (the Fetch event log says whether it did). Signing out and in, or a restart, always starts it.
• Start fresh on one PC - restarting the Fetch service (Restart-Service FetchService as admin) runs its start-up jobs: required apps after 1 min, Fetch update check after 2 min, report after 3 min.

Software requests

When a user asks for software, it appears under Requests for the organisation. If no custom SMTP relay is set in the policy, the hub emails the org admins so you're told rather than having to watch the page. Approving sends a one‑off, signed allow for that exact file to the device (valid 24 hours); the user gets a tray notification either way.

The tab is a 12‑month log, not just a pending list: filter by text or status, and past decisions are greyed out with who decided them and when. Each request can carry a download link - supplied by the user, or sourced and added by you (there's an inline box on each request). Use that link in the Policy tool's Add from URL to fetch, verify and catalog the app, then sign & publish.

Admin‑rights accounts

fetch flags day‑to‑day logins that hold administrative rights - the kind of thing that silently goes unnoticed, like a normal account quietly added to Domain Admins. On each check‑in the agent reports the signed‑in user's privilege level, and the Devices tab marks it: a red Domain admin pill for domain/privileged accounts (Domain/Enterprise/Schema Admins, operators), or a quieter amber Local admin for local administrators. A banner counts the flagged devices, and the first time a device shows a domain‑privileged account in daily use, the hub emails the org admins.

Local admin is often deliberate, so it's informational; a domain‑privileged everyday login is worth reviewing.

Device health & Windows updates

The Devices tab surfaces each machine's health at a glance:

• Inactive: a device not seen for over 7 days gets an amber pill, with a count per organisation on the dashboard. Type "inactive" in the filter to list them.
• Alert on return: click it on an offline device and fetch emails the org admins the moment it next checks in, then clears the flag.
• Windows version: shown under each machine (the full build is on hover). A red Unsupported OS pill marks a Windows release past Microsoft's end of support (no more security updates), and an amber one warns 90 days ahead - see Upgrading Windows.
• Windows updates: a pending-updates pill, red when any are security or critical, plus a banner counting affected devices; N overdue when a security update is still missing past your patch window.
• Uptime: days since the PC last really restarted - amber from 7 days, red from 14 - with restart pending N d underneath when updates are waiting on a restart (agent 1.0.54+).
• Disk space: a free-space pill on each device, red when the machine is low (under 10% or under 10 GB free); the device page shows free of total.

Filter and sort. The chips above the table - Needs attention, Unsupported Windows, Security updates, Restart pending, Up 14+ days, Not encrypted, Low disk, Domain admin, Inactive - show how many devices each applies to and narrow the list in one click; the text box filters by name, user, Windows version and more. Sort by any value with Sort by or by clicking a column heading (click again to reverse) - e.g. uptime, overdue updates, BitLocker, free disk or Fetch version. Your choice is remembered in your browser.

Installing security updates

On a device page, Install security updates tells that machine to install its pending Security/Critical Windows updates on its next check-in. It never touches feature upgrades or drivers, and it will not reboot on its own; the result reports whether a reboot is needed. It drives the machine's own Windows Update, so there is nothing extra to deploy. To do this automatically across the fleet, see below.

Automatic security updates & restarts

In the Policy tool (Settings → Windows security updates), tick Automatically install security updates across the fleet and set Install once this many days old (default 7). Each agent then installs pending Windows Security/Critical updates on its own every 12 hours once they reach that age - no WSUS or Intune, no feature upgrades or drivers. The same number is the hub's "overdue" threshold. On PCs already managed by WSUS/Intune, leave it off and use the reporting.

Restart reminders

An installed update isn't applied until the PC restarts. While one is pending, users get a Restart needed window that stays until they answer. "Pending" means what Windows Update itself says - the same thing that makes the Start menu offer Update and restart - and only once it has held for 5 minutes; a flag Windows sets for a moment while an update is still installing doesn't count (agent 1.0.66+). You control how it escalates:

Users always choose the moment, so nobody loses unsaved work or an overnight job such as a render.

Forcing a restart (last resort, off by default)

Last resort: force a restart if the reminders are ignored restarts a PC once the restart has been pending the chosen number of days (default 14, never earlier than the escalation point), after an on‑screen countdown (default 60 minutes). With it on, the escalated reminder tells users the date in advance. Anything unsaved, or still running, is lost - so set the days generously. Keep days old + days pending within your patch window (e.g. 14 days for Cyber Essentials).

Upgrading Windows (unsupported versions)

Each Windows 11 release gets security updates for a fixed time - 24 months for Home/Pro, 36 for Enterprise/Education. After that, Windows Update offers nothing more, so the PC can look "up to date" while being unpatched - and Cyber Essentials counts it as unsupported software. The hub flags these PCs in red (Unsupported OS) and with a banner on the Devices tab, and in amber 90 days before the date.

From the hub: on a device page, pick the version and press Upgrade Windows to … - any supported release newer than that PC is offered (e.g. try 26H2 on one PC while the rest stay on 25H2), defaulting to your target - or Upgrade N PCs to Windows 11 … in the banner for every flagged PC. By policy: set Minimum Windows version in the Policy tool (Settings → Windows version) - pick 25H2 or 26H2, or type a later release name - and PCs below it upgrade themselves (checked twice a day; after a failure it retries a day later, and weekly after three failures).

Which version? The hub upgrades to your policy's minimum if you've set one; otherwise to the newest Windows 11 release that has been out for at least six months (25H2 today; 26H2 from spring 2027). The hub keeps its list of Windows releases and their end-of-support dates up to date by itself (refreshed daily from a public lifecycle feed), so new releases are recognised without a fetch update. 26H1 is for new hardware only, so existing PCs are never upgraded to it, and PCs that shipped with it are left alone.

• A minimum, never a pin. PCs on that version or newer are never touched. fetch sets Windows Update's target‑version setting only while it upgrades and then puts it back exactly as it was, so PCs keep moving to later versions. If your own Group Policy/Intune pins a PC to an older version, the result tells you.
• Checks first: mains power, free disk space (about 20 GB for a full upgrade) and no restart already pending.
• How long: from 24H2 it's a small update; from 23H2 or older it's a full in‑place upgrade (about 4 GB, an hour or more in the background). Apps, files and settings are kept.
• Never restarts the PC itself - it finishes at the next restart, through the usual restart reminders.
• If Windows Update won't offer it (e.g. a WSUS server without feature updates), fetch asks Microsoft Update directly, then falls back to Microsoft's Windows 11 Installation Assistant (only after verifying it's signed by Microsoft). A web filter that inspects HTTPS must allow download.microsoft.com and go.microsoft.com.
• Windows 10 PCs are only offered Windows 11 if their hardware qualifies (TPM 2.0, Secure Boot, supported CPU). Server, LTSC and IoT editions are skipped.

Follow progress under Activity (on the hub and on the PC). Needs agent 1.0.54 or later.

When an upgrade fails - whether fetch started it or Windows Update tried by itself - the device reports why (agent 1.0.56+): a red Upgrade blocked / Upgrade failed pill on the Devices tab (and an Upgrade failed chip), and on the device page the reason in plain English with the apps or drivers Windows Setup says are in the way - e.g. "An incompatible app is blocking the upgrade. Blocked by: Google Workspace Sync for Microsoft Outlook (0xC1900208)". Remove or update the blocker, then upgrade again. The flag clears once the upgrade succeeds.

Version drift, runtimes & drivers

Version drift

The Software tab compares each app's version across your devices and flags the ones behind. Align to latest shows exactly which devices it will update before you confirm, then queues a winget update on each (per‑user installs are updated as that user). Filter by Out of support, Behind, Stopped updating, Runtimes, Drivers or Can align; hide a row you've decided to leave alone. Self‑updating apps (browsers, Teams…) are only flagged once they fall out of the newest few versions.

Apps that need replacing

Sometimes an app can't be updated in place: it was installed with a different kind of installer than its new version (e.g. the vendor's own setup, while winget's package is now an MSI - typical of printer/scanner add-ons). winget refuses rather than leave two copies, so fetch marks it needs replacing: the Software Centre shows Replace with X instead of Update, the hub's device page shows Replace, and "update all" lists it separately instead of failing. Replace downloads and verifies the new installer first (nothing changes if that fails), uninstalls the old copy, installs the new one for all users, confirms the version and keeps the user's shortcuts. It's never automatic - check any software that depends on it still works afterwards.

Apps installed just for one user

When an app was installed only for the signed-in user (common for downloads like Blender, Zoom or Opera), updating it as the user would hit an admin prompt. fetch instead installs the new version for all users through the service (no prompt), confirms it, then removes the old per-user copy and repoints the user's desktop and taskbar shortcuts to the new one. Apps that only come as a per-user install are updated per-user.

Out‑of‑support runtimes

.NET (judged per major version, e.g. .NET 6 and 7 are past end of support) and Visual C++ 2005-2013 redistributables are flagged when out of support. Before you remove one, each device reports which installed apps still need it - by reading the apps' own runtime files - per framework (desktop, ASP.NET Core or base .NET). The removal panel shows Needed by (kept), Not used (safe to remove) and Removal queued, and Remove from N devices re‑checks each device before uninstalling.

Drivers, BIOS & PC‑maker tools

Devices report their maker, model, graphics cards and BIOS version/date. On the Updates tab, graphics drivers are grouped by card, with devices behind a same‑card PC highlighted; Update drivers installs what Windows Update offers for each PC's own hardware (BIOS/firmware excluded, never restarts). BIOS / firmware lists firmware by maker and model - amber when older than another PC of the same model, red when over two years old - and PC maker update tools recommends Dell Command | Update, HP Image Assistant or Lenovo System Update for the makers you have. Catalog items can be limited to one maker with Only on PCs made by.

Uninstalling software

Per device: open a device → Installed software → Uninstall next to an app. Across the fleet: Software tab → click a software's device count → Uninstall from all N devices. Each device runs the uninstall on its next check‑in (~5 min). An app only shows an Uninstall button when its uninstaller is known from inventory.

Maintenance actions

Two optional self‑service tools, both off by default. Enable them in the Policy tool (under Maintenance), then sign and publish; a Maintenance tab then appears in the users' fetch app.

• Allow users to free up disk space - adds a "Free up space" action that clears a fixed, safe set of temporary files and caches (user and system temp, Windows Update and Delivery Optimization caches, Recycle Bin, thumbnail/Internet caches, crash dumps, Windows Error Reporting). The locations are hardcoded in the service - users can't point cleanup at an arbitrary folder, and it never touches programs, Windows features or System Restore.
• Allow users to tidy desktop shortcuts - lets users remove unwanted shortcuts from their own desktop and the shared (All‑Users) desktop. Removing a shared shortcut affects everyone on the PC, so the app flags those and asks for confirmation. Only the shortcut file is removed, never the target program.

Both run elevated through the hardened service and are written to the audit trail (who ran it, what was freed or removed). They need no licence seat, so they work on every plan.

Clearing disk space from the hub

Where free up disk space is enabled in the policy, you can also trigger a clean-up remotely: open a device and press Free up space. It queues a signed command the device runs on its next check-in (~5 min), clearing the same safe whitelist for every user profile on the machine, and reports back how much it freed (in the device's Commands list). The Recycle Bin is left alone unless you tick "include Recycle Bin" - that holds files a user may still want, so it's a deliberate choice. Combined with the low-disk flag on the Devices tab, you can spot a machine running out of space and clear it without touching it.

Update alerts

The Updates tab lists devices running a catalog app below its Minimum version. Apps you marked Critical security update show in red, with a ⚠ count on the tab. It's advisory reporting - to actually push the update, mark the app Required (and Auto) in the policy. Accurate matching relies on each item's Match installed name.

App usage, unused software & licences (opt-in)

Inventory tells you what's installed; App usage tells you what's actually used — so you can remove software nobody needs (Cyber Essentials Secure configuration asks you to remove or disable unnecessary software: less to patch, less attack surface) and true up paid licences, reclaiming seats nobody opens. Turn it on with Track app usage in the Policy tool (Settings → Managed updates) and re-publish the policy. Each device then reports, per signed-in user, when they last launched each app and how many times — read from Windows' own launch history. There is no foreground, keystroke or screen monitoring: only the record of which programs were launched and when.

On the hub, the org's Usage tab opens with Removal candidates: apps that nobody on a device has opened in over 90 days, grouped by app with the devices they're unused on. Check with the users before uninstalling — it only sees apps people launch themselves (background components, drivers and runtimes never appear), and an app opened only by a since-removed profile looks unused. Below that, it lists each user's apps with a status pill: active (launched in the last 30 days), stale (31–90 days) and dormant (not opened in over 90 days — a candidate to reclaim). Filter by an app name to see everyone using it, so before a renewal you can match seats bought to people actively using the software, and reclaim the rest.

Admin tools (elevate with your authenticator) (opt-in)

When you're at a user's PC (or remote-controlling it) and need admin rights — a Command Prompt, Device Manager, the registry — you don't need a local admin password. In the Software Centre press Ctrl+Alt+D (the hidden support window) and choose Admin tools… — it's kept out of everyday view — then pick the tool and enter the 6-digit code from your authenticator app (Authy, Microsoft or Google Authenticator). The tool opens with admin rights on the user's desktop and closes automatically after the time limit.

Set it up

1. Turn it on in the Policy tool: Settings → Admin tools (elevate with an authenticator code). Choose the tools offered (Command Prompt, PowerShell, Device Manager, Computer Management, Services, Registry Editor, Event Viewer, Task Manager), whether to allow Other program…, offline unlock, the auto-close time (default 30 minutes) whether to email the organisation's admins on every use, and optionally an admin email to prefill (so you only type the code; the PC also remembers the last email that worked there). Sign & publish.
2. Each admin sets up their authenticator once on the hub: Authenticator (top right) → scan the QR code → confirm a code.

Who can, and what's recorded

The hub checks the code (each works once), that the person is an Admin or Operator for that organisation, and that the policy allows the tool. Every use — and every refused attempt — is recorded in the organisation's Activity tab with who, which device, which tool and when. Five wrong codes on a PC lock it out for 15 minutes; ten in 24 hours lock its admin tools for 24 hours and email the organisation's admins. Removing someone from the organisation on the hub stops their codes working immediately.

Offline PCs

If the PC has no internet, the person at it presses Ctrl+Alt+D in the Software Centre, opens Admin tools… → Offline unlock, chooses a tool and reads you the challenge (e.g. AQ6B-8LKR-4SYV). On the hub, open that device → Offline admin unlock → Check challenge. Before anything is issued, the hub shows you exactly what was asked for — the tool, the signed-in Windows user (and whether it matches the user the PC last reported) and how old the challenge is. The challenge is sealed with a key unique to that PC, so an altered challenge, or one read from a different PC, is rejected. If it's what you expect, enter your authenticator code and read back the response; it works once, for that challenge only, within 15 minutes.

Offline is deliberately narrower than online. By default only Device Manager, Services, Event Viewer and Task Manager are available offline — Command Prompt, PowerShell and Registry Editor give complete control of the PC, so you opt them in separately. Instead of "Other program", offline offers pre-approved programs you add in the Policy tool, each pinned to its exact file (SHA-256): if the file on the PC has changed, it won't run. Offline sessions close sooner (15 minutes by default). The PC must have reported to the hub at least once while offline unlock was allowed.

BitLocker encryption

fetch reports BitLocker on every device, can escrow each device's recovery key to the hub, and can turn BitLocker on for you — without Intune, a domain or Group Policy. Encryption at rest is what protects data on a lost or stolen laptop (Cyber Essentials, ISO 27001, GDPR).

Requirements

• Windows 10/11 Pro, Enterprise or Education (Home has no BitLocker management) and a ready TPM — check Windows Security → Device security. Turning it on is TPM-only: no start-up PIN or USB key.
• Agent 1.0.35 or later (status from 1.0.32; per-device selection and instant reporting from 1.0.35).
• On a self-hosted hub, run the BitLocker migrations (_all-migrations.sql includes them).

Set it up

1. Create the company's recovery key. In the Policy tool, pick the company, open Settings → BitLocker recovery keys and press Generate recovery key…. When it asks, back it up to offline storage — see Recovery keys & backups. Each company gets its own key.
2. Turn on escrow (tick Escrow BitLocker recovery keys) and Sign & publish from the bar at the top. Devices that are already encrypted escrow their existing keys on their next report — use Report status now on a device page to do it straight away.
3. Optionally turn BitLocker on. Choose Turn on BitLocker for the system drive:
   • Off (default) — status and escrow only.
   • All devices (except any excluded on the hub) — every unencrypted device turns it on. To leave a device out, open it on the hub and set BitLocker for this device → Exclude.
   • Only devices I select on the hub — nothing happens by itself; open a device on the hub and set BitLocker for this device → Turn on. Good for a pilot, or a phased roll-out.
   Then Sign & publish. Device selection lives on the hub because that's where your devices are — no Active Directory needed.

What happens on a device

Escrow comes first, every time: the device adds a recovery password, seals it to your recovery key, sends it to the hub and waits for the hub to confirm it's stored. Only then does it add the TPM protector and start encrypting (XTS-AES 256, used space only by default). If escrow fails, nothing is encrypted and it retries — so a drive is never encrypted with a key you don't hold.

It runs about 10 minutes after the agent starts and every 6 hours after that — or within ~5 minutes when you press Turn on on the hub. Encryption runs in the background; the PC stays usable, no reboot is needed, and the user sees nothing beyond Windows' own BitLocker status. Laptops that shipped with Windows "device encryption" waiting for activation (encrypted, but not actually protected) are activated the same escrow-first way.

Where you see it on the hub

• Devices list → BitLocker column: encrypted encrypting 37% suspended not encrypted or — (not reported), with selected / excluded tags. Type not encrypted in the filter to list the gaps.
• Device page → BitLocker encryption: every drive, its protectors, and Recovery key: ✓ escrowed · Key ID 1A2B3C4D (or ⚠ not escrowed).
• Updates tab → Disk encryption: a fleet summary, and which devices can't be turned on, and why.

If a device won't turn on

The device page (and the column) says why:

Recovery keys & backups

Who can read a recovery key: only you. Each device seals its recovery password to your company's recovery key, whose private half lives only in your Policy tool (encrypted to your Windows account) and in your offline backup. The hub stores sealed keys it cannot open — so a hub breach exposes no recovery keys. That's also why you can't download a key from the hub: recovery happens in the Policy tool.

Unlocking a device

1. On the locked PC, the BitLocker recovery screen shows a Recovery key ID (8 characters, e.g. 1A2B3C4D).
2. In the Policy tool (connected to that company, on a PC that holds its recovery key) open Settings → BitLocker recovery keys → Recover a key….
3. Search for the machine name or that Key ID. The 48-digit recovery password is shown on screen (never saved to disk). Type it into the recovery screen.

The hub's device page shows the Key ID of each escrowed key, so you can confirm in advance that a device's key is safely stored.

Back up your keys — do this first

• Back up… (BitLocker section) — one company's recovery key, as a passphrase-encrypted file.
• Signing key tab → Back up all keys… — your policy-signing key and every company's recovery key, one encrypted file each, in one dated folder with a list of what's inside. It checks every company you're connected to and warns about any recovery key that isn't on this PC.
• Moving to a new PC? Run Import all keys… on the new PC and pick that folder — everything is restored, matched to the right companies.

Rotating a recovery key

A company needs only one recovery key. Use Rotate key… only if the key or its backup may have been exposed. New escrows use the new key; keys already escrowed stay sealed to the old one, so keep the old key's backup — the Policy tool keeps every key it has held and picks the right one automatically.

Users & roles

Each person is given access to specific organisations, with one of three roles per organisation:

Add people on the org's Users & access tab and pick their role. An MSP typically holds Admin on each customer organisation it manages, and might give front-line staff Operator.

Security model

fetch is designed so that elevating an install never becomes a way to gain broader administrator rights - standard users stay standard users. Approved installs run with elevated privileges, but under tight controls:

• Only approved software elevates. Nothing runs with elevation unless it matches your signed policy - by publisher or by file hash. The policy is signature‑verified on every client, so it can't be altered in transit.
• Least privilege & containment. An approved installer runs in a locked‑down, monitored sandbox for the duration of the install and no longer. It can't be repurposed to do anything beyond installing that software.
• Interactive installers are supervised. When a vendor's own setup screen must be shown, fetch keeps it constrained to the install task.
• Scoped by identity. What each person can install is governed by their group/user audience, evaluated live from their Windows identity.
• Everything is audited. Every elevation - allowed or denied - is recorded with who, what and when, visible on the hub and exportable to CSV.

App Control / WDAC (advanced, optional)

What it is. App Control for Business is Microsoft's name for WDAC (Windows Defender Application Control) — kernel‑level application allow‑listing. Where the rest of fetch governs what may install with admin rights, WDAC governs what may run at all — including software installed without elevation (per‑user Chrome, portable .exes) that elevation rules never see.

What fetch does — and doesn't. fetch does not author the policy for you. You build and sign a WDAC policy yourself (a compiled .cip file), host it, and point fetch at it on the Policy tool's Deployment tab. fetch then fetches that file and applies it fleet‑wide with the in‑box CiTool.exe, refreshing it whenever the policy reloads. Whether the policy runs in audit or enforce mode is baked into the .cip by you — fetch only distributes and applies it.

How to build a policy. Use Microsoft's WDAC Wizard (or New‑CIPolicy in PowerShell) to create, sign and compile the .cip, and note its policy GUID: Microsoft — App Control Wizard.

Safe rollout. Always ship an audit‑mode .cip first, leave it for a while, and review what would have been blocked in the Windows CodeIntegrity event log on representative devices. Only once that's clean do you compile and publish an enforce‑mode policy. Give each policy a stable GUID so a new version replaces the old rather than stacking.

Requirements & limits. Needs Windows 11 / Server 2022+ (for CiTool.exe); on older systems it's skipped with a warning. WDAC audit/block events are reviewed in the device's own CodeIntegrity event log — they are not yet surfaced in the hub. To set it up: tick Deploy an App Control (WDAC) policy on the Deployment tab, give the .cip source (HTTPS URL, UNC or local path) and its policy GUID, then bump the Revision and sign.

Troubleshooting

Where the logs are

On a client PC, service diagnostics and audit events are in the Windows Event Log → Applications and Services Logs → fetch. Quick pull (elevated PowerShell):

Get-WinEvent -LogName Fetch -MaxEvents 20 | Format-List TimeCreated, LevelDisplayName, Message

An install fails

The hub's device page and the Event Log show the reason. If a particular app's installer won't run, prefer that app's winget or MSI source where available, or set the correct silent switch on the catalog item.