Welcome back to ATA’s Learn with Me series on the 1E Tachyon Platform for Unified Experience Management! If you missed the previous posts, be sure to catch up here.
In this installment, we’re going to dive into 1E Tachyon’s Guaranteed State application. Dubbed as automated configuration management, Guaranteed State is supposed to monitor your endpoints for changes and either report and/or remediate various configurations that fall out of compliance.
Much like Microsoft Endpoint Manager Configuration Manager (MECM)’s compliance settings, Guaranteed State allows you to define various policies, assign those policies to endpoints and automatically check for and even change settings from simple items like registry keys, files or even more complex configurations like MEMCM’s client health.
Let’s continue on our 1E Tachyon journey and see if Guaranteed State lives up to the 1E hype!
Guaranteed State: Endpoint Change Control
Every organization has a specific way they configure its endpoints. Perhaps you need some software installed and configured a certain way, keep patches up to date or various departments need certain registry settings or files in specific places on their machines.
Whatever it is, your endpoints will always need to be configured a certain way. And you expect that configuration to stay that way! But, unfortunately, it’s a whole lot easier to make a change to a set of endpoints than it is to ensure they stay that way. Here is where Guaranteed State comes in.
Guaranteed States sets to control all of your endpoints’ configuration so you can monitor, via a single dashboard, their state and also automatically configure them to where they need to be. That configuration may be admin-related like some line-of-business software installed, security-related such as monitoring a known vulnerability, or even for asset management.
The state or configuration of an endpoint pertains to many different areas of an organization.
Through a system of triggers, rules, and policies, Guaranteed State allows you to monitor and maintain that state via a set of rules which then turn into policies that are deployed to your endpoints.
Defining (and Maintaining) Configurations with Rules
To control the potentially thousands of changes an IT pro may need to make to a set of endpoints, Guaranteed States uses rules. A rule is a single change that you’d like to manage on an endpoint.
For example, a rule can be:
- A file should exist and/or contain specific text.
- A registry key value should be a certain value.
- A service should be started.
- A MEMCM client should be reporting to it’s management point
You can create your own rule templates or upload one or more of 1E’s Product Packs that have pre-built rule templates inside to manage common settings on your endpoints.
Below you’ll see the Rules page which includes a grid of each defined rule. Here is where you can enable, disable and modify various rules.
Pay attention to the Compliance column. I particularly liked this one. The Compliance column gives you a visual representation as to how compliant all of your endpoints are you’ve assigned to that particular rule.
How Rules Work
Rules run on Tachyon agents deployed via policies. For the agent to know when to run the rule, what to check, and what action to take, you must define these attributes in the rule.
- Precondition – The optional precondition attribute will instruct the Tachyon agent to only execute the rule if the condition is true. For example, only run a rule on a Windows host or maybe only run the rule if the endpoint has specific software installed.
I like the Precondition element. You can target rules (via policies) to specific devices but the Precondition check available on a per-rule basis allows you to be sure your rules do not run on any unintended endpoints.
- Triggers – If the agent detects the endpoint passes the optional precondition condition, it then has the right to monitor for a trigger. Triggers can be in near real-time or defined to query on timed intervals.
Use timed intervals sparingly. Running checks at various intervals will waste system resources if no state change is found. It’s much better to rely on Guaranteed State’s real-time monitoring as the trigger.
- Check – The check consists of many different configurable conditions. You can think of the check as the actual configuration item such as free disk space, registry key existing, a service running, etc.
- Fix – If the rule is found to be out of compliance, you can optionally take the next step and automatically remediate it by issuing a Fix. A Fix is some other action to perform should the agent find the check to fail.
If you define a check that you ultimately want to remediate, there’s currently no way to simply say “Fix check” as a rule Fix. A Fix is simply another generic action to take and has no relation to the Check performed. Unlike other configuration management tools, Guaranteed State is not declarative or idempotent. To resolve an item that’s out of compliance, you must manually define its fix.
Tachyon’s tendency to rely on natural language could be a problem when it comes to rules. It’d be much better, in my opinion, if Tachyon provided a more structured approach to defining rule conditions. For example, rather than defining a condition like “Check that the system drive has at least X GB of free space”, instead define the condition like
Filesystem | Drive: X | Free Space | < | Y GB. A more structured approach would provide more flexibility.
Deploying Rules with Policies
Creating rules in the Tachyon Portal is all well and good but if the Tachyon agents installed on the endpoints don’t know about them, they’re not going to do much good. To deploy sets of rules to endpoints requires a policy.
A policy is a set of rules that dictate what, when, and how Guaranteed State manages configuration items on endpoints. Guaranteed State policies are similar to Active Directory’s Group Policy or other policy-based tools.
You’ll find that policies are are more or less rule containers. Policies are simply the delivery mechanism you must use to deliver rules to endpoints.
Assigning and Deploying Policies
You can begin using policies in one of two ways; you can create your own or you can import policies as part of a Product Pack. You’ll see in the use case walkthrough how to create your own.
Once you have a policy defined, you must then assign it to your endpoints via management groups or collections of devices. A management group is similar to a MEMCM collection which includes groups of various devices.
On the Policy administration screens below, you can see how to search for, assign and finally deploy policy changes to your endpoints.
Digging into Dashboards
Once you have one or more policies created and assigned to your endpoints is when the real magic happens! In the Overview and Reports pages below, you’ll begin to see the clients report back information to Tachyon.
Using the data received from the agents, Tachyon provides a wealth of information and beautiful dashboards to help you visualize what’s happening with Guaranteed State.
You can see below a great example of the kind of data you can visualize. In this example, you can click on any element in the Overview dashboard and drill down for more specifics.
One of the best parts about the Tachyon is the way it presents large amounts of data. I’ve noticed with multiple Tachyon applications, the visualizations are amazing, easy to navigate and responsive.
Drilling Down into the Details
If you need to drill down all the way to individual endpoints, you can do so via the Devices report shown below. The Devices report is where you can see each device along with it’s State and other information.
Clicking on the View History link next to a device will bring up the agent log which contains every action that’s been performed on that agent.
Use Case: Monitoring (and Remediating) a Google Chrome Extension
Enough with the background and overview, let’s get down to brass tacks and see what Guaranteed State looks like in action! To demonstrate Guaranteed State, let’s walk through a real-world situation you may find yourself in at some point.
For this scenario, assume you’re an IT pro in charge of managing software on thousands of endpoints. A Google Chrome extension is one of those pieces of software you must ensure is configured correctly at all times. You’ve found that some employees have been disabling it and you’d like to remediate that.
Creating the Chrome Extension Rule
Let’s say you’ve done research and found that to ensure a Google Chrome extension is enabled, you must ensure that the HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Google\Chrome\Extensions registry key has a value of Enabled set to 1.
Now that you know what to change on your endpoints, it’s time to take care of the how with Guaranteed State. To do that, you must create a rule. The rule is the most important component of Guaranteed State.
You aren’t required to always create a rule yourself. If you’re working with an application that has a supported product pack, chances are the rule(s) you need will already be included.
Under the Administration section in Guaranteed State, go to Rules and click on New Rule, as shown below. Clicking on New Rule will bring you to the rule-creation page.
Creating a rules means assigning a name and up to four different behaviors, as mentioned earlier.
- Precondition (optional) – For this use case, I’d like to ensure this registry value is set for all endpoints so I leave it blank.
- Trigger – This option will define the event that must take place before Guaranteed State takes action. For this use case, the trigger will be “When a registry key changes (Windows only)”.
You can create as many triggers as you want for a single rule by clicking on the + in the right corner.
- Check – The Check is the action that Guaranteed State runs when the Trigger is executed. In this instance, I’d like to ensure a specific registry value is set when that happens so I define “Check that registry key %Hive%\%Subkey\%Name% has %ValueType% value of “%Value%”.
You’ll see that each component in a rule is independent of one other. The Check does not know what you defined for the Trigger leading to extra work. It would be nice to use variables in the Check and Fix fields that represent the values that initiated the Trigger.
Now the rule will show non-compliant in the Tachyon Portal if the Enabled registry value ever goes to 0.
Fix (optional) – Since I’d like to take action and actually change something on the endpoint, I will set the Fix behavior to modify the required registry value.
It’d be great if Guaranteed State followed a more declarative model here. If using declarative configuration management, I wouldn’t have to define a Fix. But 1E seems to have followed the endpoint management industry’s lead on this one and decided to go with the imperative approach. A pity from a DevOps guy’s perspective but 1E is always open to feedback so I’ll see what I can do. 🙂
Now when the Check fails, Guaranteed State will label the device as non-compliant and will show up in the Tachyon Portal.
Creating and Assigning the Policy
Now you must create a custom policy and add the rule you just created.
1. Click on New Policy under Administration —> Policies.
2. Now, give the policy and Name, a Description, search for the rule (“chrome” in this case) and click the right arrows to add the rule to the policy. You can see below the actions required to create a policy.
3. Now, assign the policy to a management group. In this case, we’re assigning the policy to the All Devices management group.
4. Finally, click Deploy to deploy the new policy to all endpoints in the All devices management group.
And that’s it! Your endpoints will now begin receiving their new marching orders and will soon start reporting their compliance status against this policy in the Tachyon Portal.
Monitoring Agent Activity
Once each endpoint knows of the policy it’s supposed to apply, you’ll soon see the dashboard begin to populate with data. On the Overview screen, as demonstrated below, you’ll see a breakdown of all compliant and non-compliant devices.
You can then click in each area and, on the Devices page, inspect each endpoint’s log to see if the Chrome extension registry value was enabled or not and what Guaranteed State did to remediate it.
Conclusion
Guaranteed State is a great way to perform checks and retrieve configuration settings against potentially hundreds of thousands of endpoints at once. It would also be useful to not only report on items out of compliance from a particular configuration but also to remediate that same item automatically on those non-compliant devices.
Guaranteed State did not let me down when it came to data visualization. The dashboards provided data in a clear, intuitive fashion similar to other Tachyon applications. It was easy to navigate around and dig deeper into various areas, if necessary.
But, this Tachyon application, along with all others in this space, follows a non-declarative and idempotent model that many configuration management platforms in the DevOps space provide. Endpoint management tools, in general, just aren’t there when it comes to true configuration management.
Guaranteed State doesn’t seem like it was built in a true “configuration management” fashion but more as a way to automatically run a generic action based on an event. It felt more like a script execution engine built with a real-time trigger to know when to execute the script rather than a true configuration management platform.
