Application rollout and setup

Putting an application on every device is only part of the job. The rest is getting it configured, reporting and accepted by the people who use those devices, for one client or across your client base.

ThreatLocker is a common example. The same approach applies to other tools that run on every device.

Request a quote for this project
First client Live Second client Second stage Third client Pilot
A rollout across three clients, part-way through. Each client starts with a pilot and moves in stages, and the devices that haven’t checked in are named rather than assumed.

Five checks between pushed and working

An RMM job that reports success tells you an installer ran. It doesn’t tell you the agent is talking to its console, sitting in the right group with the right policy, or doing the job it was bought for. Rollouts that go wrong usually fail without an error, at one of these links.

  1. Pushed

    The job reached the device. Laptops that are rarely online, machines with a pending restart and anything outside the RMM drop out here, and they’re often the devices you most need covered.

  2. Installed

    The service is present and running. Clashes with existing security software show up here, along with old copies of the same agent left behind by a previous provider.

  3. Checked in

    The device appears in the application’s console, under the right client. When it doesn’t, the cause is usually web filtering, a proxy, or an install key that belongs to a different client.

  4. Configured

    It’s in the right group with the policy meant for it, not a default and not a copy of another client’s. Most unnoticed problems are here.

  5. Working

    It does what it was bought for, its alerts reach someone who will act on them, and the people using the device can get on with their day.

A stage isn’t finished until the console matches the list of devices it was meant to cover. Each missing device is listed by name.

A pilot only counts if it includes the awkward cases

A pilot of five well-behaved desktops proves the installer works. It says nothing about the people the rollout will trouble. We choose the pilot group with you, and it’s deliberately uncomfortable.

After the pilot, devices move in stages sized to what the client can absorb if something needs fixing: a team, a site, or for a client base, a few clients at a time. The next stage starts when the last one has gone quiet. Deployment runs through your RMM if you prefer, so it stays where your team will look for it later.

  • The one person who runs the odd line-of-business program. If anything is going to break, it’s that.
  • Someone in finance, across a month-end. Payroll and reporting tools run on their own schedule.
  • A laptop that lives away from the office. It tests deployment and check-in over home internet and hotel wifi.
  • Someone who will describe a problem clearly. A good pilot user saves days of guessing.
  • Not the director’s laptop. That goes in a later stage, once the policy has settled down.

When the tool has to learn the client first

Allowlisting tools such as ThreatLocker block anything that hasn’t been approved. Before that can be switched on, the tool has to learn what the client runs, and most of the risk in these rollouts sits in what happens next.

  1. Learning

    The agent records what runs on each device. The judgement is how long to leave it: long enough to see the client’s real working cycle, including the jobs that only happen at month-end or end of quarter. A learning period that only saw quiet weeks will block the busy ones.

  2. Review

    What was learned is a list, not a policy. We allow software by publisher or by the tool’s own application definitions where we can, so the next update doesn’t break it. Anything that shouldn’t be there gets questioned rather than approved because it happened to run.

  3. Secured

    Devices move to secured mode in groups, pilot first. After each group we watch the requests that come in. A rush of them means the review missed something, and that gets fixed in the policy, not one approval at a time.

Then the approvals queue becomes part of support

Once devices are secured, requests for new software arrive as tickets. Your team gets an approvals process to handle them: who can approve, what needs the client’s sign-off, and what to check before saying yes.

One client, or your whole client base

Across a client base, the trap is copying one client’s finished setup to the next. It carries their exceptions with it, and a year later nobody knows why a program is allowed at a client that has never used it. Each client starts from the same baseline and earns its own exceptions.

Set once, the same everywhere

  • How devices and groups are named in the console
  • The baseline policy every client starts from
  • How alerts reach your team, and which of your systems the tool connects to
  • The deployment method, built once in your RMM

Set for each client

  • Exceptions for their own line-of-business software
  • Who at the client can ask for changes, and who signs them off
  • Which devices and users are in scope, and the order they go in
  • Their pilot group

What your team is left with

  • The application deployed and configured

    On the devices in scope, each one checked in under the right client with the policy meant for it.

  • Documented settings

    The policies, groups, integrations and alerts for each client, and the reason behind each exception, so the next engineer doesn’t have to guess.

  • A handover for your team

    Day-to-day running passes to your team, with an approvals process where the tool needs one.

Related projects