This post will detail how to utilize Powershell in conjunction with various administrative tasks of the Quest KACE SMA. (Or, if you've been around long enough, the artist formerly known as the KACE K1000).


Why was the project even necessary?

I've been a KACE user since 2013, and it's certainly come a long way in the past 6 years. Early on in the product's lifecycle, the development team added a public API for intrepid users to dabble with more advanced use of the appliance, as well as make changes to its database, which is typically read-only.

The API was not without it's share of usability problems- namely its...usability. If you knew what to look for, or the structure of the POST request you were sending, it was great! In other words, the technical backend functioned perfectly as intended, but finding or discovering what you were after was limited to a single API documentation pdf tucked away in a support portal. Written in a somewhat cryptic style, this precious API document contained more than a few errors ranging from syntax to incorrect endpoints, and I really think it turned quite a few users off from wanting to use the public API. This in turn could easily create a chicken-and-egg scenario of "Why develop something nobody uses?" vs. "Why use something they barely document?".

I decided to bite the bullet, and since i have the luxury of a non-production VM of our SMA appliance, I felt much more comfortable developing a Powershell wrapper for KACE's API in that environment.

Let me just stop right here and give a huge shoutout to the amazing community over at the community-focused Slack channel, which is frequented by several awesome Quest employees and KACE developers, including some from the API team. Without their help, the Powershell project would not be where it is today.

Writing the Powershell bits

The project is structured in typical API-wrapper fashion. Front-end requests (/public) are sent to a structured backend (/private) where the magic happens. What you the user sees are all the available commands in /public/{endpoint}, which send their instructions to the appropriate HTTP request in /private.

Authorization is then performed to the appliance by way of HTTP headers, and a CSRF Token is obtained. This token is then appended to the header hashtable, and will allow future requests to be presented until the session is closed.

Thanks to Powershell's Invoke-RestMethod, the final, authorized request is returned as a bona-fide serialized PSObject, which is what you see in the console output after a successful request is returned:


Using it from Powershell

Available on the Powershell Gallery, installation of the module is a single command away, provided you're using Powershell v5.1 or higher:

Install-Module KaceSMA

You can explore the commands available to you by using Get-Command on the module.

Get-Command -Module KaceSMA

The usage of each function is documented through Powershell's unique Get-Help system, so if you want to look for parameter documentation, or get an example of how a command is executed, simply query it's help like so:

Get-Help Get-SmaServiceDeskTicket -Full

or to return only the examples:

Get-Help Get-SmaServiceDeskTicket -Examples

There is much more thorough documentation, including many examples, located at the project's GitHub wiki.

For installation, please use the Powershell Gallery

This project itself is open-source and available on GitHub.

For reporting issues, please use the issue tracker here