The information in this article is the intellectual property of xMatters and is intended only for use with xMatters products by xMatters customers and their employees. Further, this intellectual property is proprietary and must not be reused or resold.
Kaseya provides IT management software that helps MSPs and mid-sized enterprises better manage IT to drive the success of their businesses. Kaseya Virtual System Administrator (VSA) is an IT Systems Management platform that can be leveraged seamlessly across IT disciplines to streamline and automate IT services. By integrating with xMatters, Kaseya gets the power of intelligent multi-channel delivery, management and action to reducs time to resolution and customer impact.
- Installing the Integration
- Configuring xMatters
- Adding the Procedure to Kaseya
- Configure Procedure Variables
- Deploy Shell Script
- Troubleshooting the Integration
Installation and Configuration
|Kaseya VSA Service Desk||
Note: This integration was designed and built for Kaseya's on premise product.
Installing the Integration
|Kaseya.zip||The REB Communication Plan to import into xMatters|
|The procedure to import into Kaseya|
|The PowerShell script and Function library to generate the REST request to xMatters|
|The command definition file that serves to map the parameters from the procedure to the shell script|
Create an integration user
This integration requires a user who can authenticate REST web service calls when working with events – these permissions are provided by the "REST Web Service User" role in xMatters.
For Free and Trial customers, your system has an "Integration User" already configured with the REST Web Service User role, so you don't need to burn up an extra user from your limited supply. Make sure you've changed this user's password from the default, then you're good to go.
For everyone else, we recommend you create a user specifically for this integration because this user appears as the initiator or submitter of events from the integration (in messages, the Communication Center, event reports, etc.). Give this user the "REST Web Service User" role and a profile that lets you easily identify the user as specific to the integration – for example:
- User ID: kaseya
- First name: Kaseya
- Last name: Integration
Note: Make sure you keep the user ID and password of this user handy. You'll need them when configuring other parts of this integration.
Import the communication plan
Next, navigate to the Developer tab and click Import Plan.
Select the components\xmatters/Kaseya.zip file and click Import Plan:
By default, the plan is disabled when imported. Click the checkbox to enable it:
Then enable the Web Service operation for each form by clicking Edit > Forms and selecting Create Event Web Service for each:
Then click the Permissions item for each and enter the integration user created above and click Save Changes. This allows that user to make REST calls to these forms.
Adding the Procedure to Kaseya
First, copy the integration\components\kaseya\shellcommanddef\xMCommandDef.xml to the C:\Kaseya\xml\SDProcShellCommand\0 folder. This contains the script name and parameters and makes them available to the Procedure. For on demand instances, contact Kaseya to have this file copied to the environment.
Login to the Kaseya application: http://servername/vsapres/web20/core/login.aspx where "servername" is the host name of the Kaseya 7.0 server. Navigate to the Service Desk > Procedures Definition > Stage Entry or Exit. Click on the appropriate folder and click Import Folder/Procedure:
Either navigate to the xMProcedure.xml file, or paste in the contents and click Save.
By default, this will fire for tickets with an Urgent priority. Update the procedure to match the business needs.
Next, go to Service Desk > Desk Configuration > Desk Definition and select the appropriate Desk. Click on the Processing tab and then the Stage sub tab:
Click on the New stage and click edit to bring up the Edit Stage dialog. On the Procedures tab in the Stage Entry box, select the newly created procedure and click Save:
Configure Procedure Variables
Navigate to the Service Desk > Common Configuration > Procedure Variables and add variables for each item with the corresponding value below:
|xM_Default_Group||The default group to notify if the Ticket does not have a Pool nor an Assignee||All||
Kaseya Service Desk
The hostname including https of the xMatters system
Password for authenticating to the REB endpoint
|All||passwordhere||The password can also be stored on the Kaseya server in the xM_Script_Path folder in a file called xMPassword.txt.|
The path to the xMatters script file
|All||C:\xMScripts||See the section below on granting privileges to this folder|
|xM_User||The user name used to authenticate to the xMatters REB endpoint||All||kaseya||The user created above.|
Deploy Shell Script
The Windows Powershell script facilitates the communication between Kaseya and xMatters through the REST Web Service calls and consequently, this script must reside on the Kaseya server.
For on premise installations, copy all the ps1 files in components\kaseya\shell_script to a folder on the Kaseya server. Note the install directory and update the xM_Script_Path appropriately. The xM.log file will be created automatically.
For on demand instances, contact Kaseya for help with this step.
Important: The permissions on this folder must be updated to allow Kaseya to read and write to the folder. Right click on the folder and click properties to display the folder properties dialog. Click the Security tab:
Click the Edit.. button to display the Permissions dialog and click Add...
Enter IIS_IUSRS and click Check Names:
Click Ok, and the Permissions dialog is re-displayed with the IIS_IUSRS added. Make sure the Write permission has a check under Allow:
Troubleshooting the Integration
The xMatters.ps1 file contains a $debug variable that will print detailed information about the REST request to the xM_Script_Path\xM.log file. Inspect this file for any errors.
JDN-4824 Originally created by Travis Depuy