Getting the Most Out of Action1 With PSAction1 – Part 2

In part 1 of “Getting the Most Out of Action1 with PSAction1,” we explored how to interact with Action1 via the API and PSAction1. Now, let’s look even further into how much utility this can really bring. Like, why would I want to do this?

Action1 is already so easy and versatile as it is; why would I want to complicate that? And that is why we are here: to show that working with the API can be just as simple as any other Action1 experience you are used to. If you are starting with this article and are new to PSAction1, please check out part one of “Getting the Most Out of Action1 with PSAction1.”

Let’s look at some practical use cases to highlight the simplicity and the power of PSAction1 when working with the Action1 API. They are not more complex than the queries we started with in part 1, but these can change things on the server side.

How Do I Discover and Remove Stale Endpoints in Action1?

The answer to this question is quite simple—with PSAction1!

This would be a simple and logical request, as a regular maintenance task, perhaps even automated externally. For your convenience, we have created a step-by-step guide to follow:

Step 1. Head over to your Action1 instance, ensure you have your module ready to go, and let’s get started.

In Part 1, we went over basic querying on all endpoints. Well, there are a lot of properties per endpoint. So first let’s look at this a little more closely and specifically restrict it to the properties of a single endpoint.

Step 2. Run the following command:

So now we see only the properties that are accessible from one endpoint, and that should look far less daunting. As we look over them, first notice that every object has an ID, which is globally unique; where two endpoints may share a common name, they will always have a separate ID.

Step 3. Next, notice there are properties for the name and the one that looks like what we need, “last seen.”. Using that, let’s make this a little easier to read through by executing this command:

Now, depending on how many endpoints you have, you likely saw a lot more scroll by, but it should make much more sense now as there is a cleanly formatted list of names, the time each was last seen, and the ID associated with each named system.

Much more manageable! And from that we should be able to see quickly how this task is shaping up, take that list, and compare “last_seen” to a predefined date, reporting back what matches our criteria.

Step 4. Proceed by running this command:

Woah! What just happened? You said simple! And really, it is; it just looks complicated. Let’s break it down.

Using “pseudocode,” which is an easy-to-understand representation of a code’s intent, this reads, “Get all the endpoints, convert the date/time format that Action1 stores to one that can be directly compared to one that PowerShell will produce.

Then compare each endpoint’s last seen date to a threshold of 60 days in the past, and for each one that matches that criteria, output an object that displays the name and date. Send that to a grid view for simple reading, and voila!”

This is a safe approach, as it does not change anything; it only displays. So, if we skip the display and go straight for the delete… wait, stop right there, and let’s discuss something important!

In PSAction1, the “Get/Set” verbs do not change anything on the server side; “Set” changes local options in the script; on the other hand, “Get” retrieves data. Verbs such as “new/update/start,” however, send data to the server for processing, not just retrieval instructions; as such, they have the potential to modify your system.

It is always a good idea that until you get more familiar with PSAction1, you always start with queries and make sure the data that you are working with is correct. PSAction1 by design will let you change many things very fast; that is an upside, unless you accidentally change the wrong things, and that can be a massive downside. Disclaimer: There is no undo button or command. So always keep that in mind when using “New/Update/Start.” If you execute a command that causes mass data change in an unexpected manner, support cannot undo those changes.

Step 5. With that acknowledged, and assuming you have reviewed everything… we can proceed by executing the following command that will delete all the endpoints that have not been active for over 60 days:

In “pseudocode” that reads the same as above, we skip the display and replace it with “Delete everyone you find and do not confirm one by one.”

That’s it; simply put, you just cleaned every system out of Action1 that has not been seen in the last 60 days. That said, did you learn along the way how it works? I hope so because let’s look at how easily what you just learned can be adapted to another task.

How to Delete a Group of Inactive Endpoints in Action1?

Let’s say the task had been, “A group of endpoints belonging to a test lab is still in the system, named Lab-01 through Lab-50; and we would like to remove them.”

You can accomplish this task with a single command:

This is exactly what we did above; we just changed the selection criteria to read, “If the name of this system starts with ‘Lab-’ followed by at least 2 digits and then ends, delete it. Now that we know how to delete things, let’s make something new!

How to Create a Group That Represents Systems That Have Not Rebooted in the Last Five Days?

You can do it with PSAction1, of course; why else would you be here? To do so, just follow our step-by-step guide:

Step 1. Run the following command:

This retrieves an endpoint group settings template from Action1 and stores it in the variable $grp. The above procedure creates a blank configuration object that you will customize in the following steps.

Step 2. Name your group of endpoints:

This assigns a name to your group that includes the current date. The group name will indicate its purpose—identifying systems that haven’t been rebooted recently (in our case for 5 days).

Step 3. Add endpoints to the group:

This command retrieves all endpoints, filters for those with a last boot time older than 5 days ago and adds each matching endpoint to the group’s include filter by name.

Step 4. Create the group in Action1:

This finalizes the process by creating the actual endpoint group in Action1 using your configured template.

Now it is important to realize that when doing things like this, the code/logic did not get included in this group creation. The logic was processed at runtime, so for instance, this will not work in the future for detecting endpoints with reboot times older than 5 days. The group will remain defined until manually removed to have the endpoints it decided were applicable at the time this command sequence was executed.

In part 3 of Getting the Most Out of Action1 with PSAction1, we will go over more object creation and more powerful scripts to take what you have learned this far and use them in increasingly complex use cases. We will really start flexing our PSAction1 skills and bringing new levels of system integration potential.