This is the first in a series of blogs called ‘Tachyon Tuesday’ which has been created to answer the questions you’ve been asking about Tachyon and the benefits it brings to enterprises. In this week’s blog, Jason Keogh, Partner Chief Technologist at 1E, explores “Service state management, at scale and by exception”.
Every company has certain services that they want to always be running (or perhaps never run) on their endpoints. There are a host of services that are important, but typical examples are anti-virus software, patch deployment, and software deployment tools (think Microsoft MEM/SCCM).
Without these services running as they should, end-users may not get software updates, their machines could be exposed to security risks or outages and their data could be at risk.
Service control should be simple. It should be simple to identify a number of critical services that need to be on all machines and which should be in a given state (let’s say “running”) and startup mode (“automatic”), all the time.
BUT…it isn’t that simple, because:
- There are exceptions to every rule—so what should be on “all” machines quickly turns into “all but that one, oh, and the other one…”.
- Setting a Group Policy for something doesn’t necessarily make it always so, isn’t implemented in real-time, and can be changed by the end-user if they have admin rights.
- Getting status information about which machines are currently adherent to, or in breach of, that policy isn’t always possible.
And… all of these challenges get harder when you have a Work From Anywhere estate, which most enterprises found themselves challenged with from March 2020 onwards.
We’ve created a set of Tachyon instructions, coupled with a single Guaranteed State (GS) rule.
The instructions allow you to:
- Define a “Service Automation List” (SAL for short). This is stored in encrypted local agent storage. It defines which services should be in what state, where state is a combination of required:
- Startup mode
- Running state
- Apply that list to one, many, or all endpoints
- Edit that list on an endpoint-by-endpoint basis to create exceptions
- Report on that list and on the compliance status of services in it at any time
- Make endpoints comply with the required state at any time
The GS rule runs every 2 minutes (that’s the default trigger, but as with any rule, that can be changed) to:
- Examine the SAL that’s specified on this endpoint
- Get a list of current status for all services
- Compare running state and startup mode to the required state in the SAL. It then either reports the machine as being compliant to the requirements or, if it isn’t compliant, sets the required startup mode and running state.
Et voila! We now have a customizable list of services and required state for each endpoint that can be managed in real-time and is continuously enforced by Guaranteed State. It works for all endpoints, regardless of network connectivity type or status (if the machine is offline and running, GS rules will still be in effect).
It’s a simple and elegant solution that works brilliantly for remote and office-based machines alike, and is usable for end-users’ machines or servers, with fully customizable rules.
This is just one example of using Guaranteed State to act on something, likely before an end-user or IT administrator is aware of it, to proactively predict and prevent an issue – so I like to call it Proactive Prediction and Prevention, or PPP for short.
In the next part of the Tachyon Tuesday series, Jason Keogh walks you though a demonstration of Windows Services Management and Automation.
If you’re a Tachyon customer and would like to find out more – feel free to reach out.