Introduction

In any company that has adopted digital workspaces use, there are two situations:

1. The use of legacy tools or applications with compatibility problems and the impossibility of changing their code to adapt it to recent OSs.
2. There are different groups with several level access to provide operations and support tasks to the users. This scenario generates that the T1 agents cannot resolve the user problem because the necessary action cannot be taken to achieve it (e.g. running a script with administrative changes, modifying the registry of the VM, etc.). The resulting ticket must be scaled and resolution times are extended.

Flexxible|SUITE helps to manage the infrastructure by providing fast and automated tools. The corrective fragments can be used to eliminate this type of tasks at the level of support and administrative access to the VMs. 

The corrective snippets functionality provides the administrators with a tool able to execute high-privileged actions remotely in the virtual machines monitored by Flexxible|SUITE. 

E.g. When an application fails and its solution passes through, for example, deleting a pair of registry keys or executing a script, the corrective snippets allow us to "package" that script in a button of the console and to select what type of machine will allow its execution, what type of users can run it and within which tenants. Each execution will audit the actions performed in the form of a record with day, time and user that executed it.

This article explains the possibility of packaging and publishing a script in custom operation format in Flexxible|SUITE.

Custom Operations

This functionality is based in PowerShell scripts. These scripts are executed as the Local System in the VM. For this reason, it is not necessary to grant high-privileges to the user who will execute them.

The Corrective snippets are scripts that can be published in Flexxible|SUITE, this action allows you to:

• Publish a standard script, to avoid unexpected errors or syntax on its execution.
• By managing roles and accesses limit users who will have the ability to create and publish.
• The possibility of giving access to the execution of these scripts in a controlled way to teams of level 1.
• Store the history of executions with hours, the user who has executed, and the result of the operation.

These tasks can be performed massively, by selecting multiple VMs or specifically, selecting just one. Their execution and results will be managed in the web console.

Creating custom operations

To create a new custom operation, we must go to the "Suite management" section of the side menu, "Custom operations" option or simply search the option in the menu browser:

From here, and once inside the section, we must select the "New" option:

The creation form will be launched to fill in the required information:

• A display name and a description of what the custom operation does
• A scope: to which kind of VMs the operation applies to, and which user roles will see the operation or for which tenants or partner operators will be the operation available.
• A PowerShell script to perform the operation. The script can also be uploaded from a local .ps1 file by pressing the "Upload a script file" button:

Please, note that the selected file must be a .ps1 with UTF-8 encoding.

Use the "Browse..." button to select the .ps1 file and load it by closing the dialog pop up with the "Ok" button.

Note: support for custom operations on application template definitions, application servers and VCC roles was introduced in Flexxible|SUITE 4.12. The setting "AllowVCCRoleCustomOperations" controls whether is is possible to execute custom operations on VCC role VMs. This setting can be set to false to reduce the risk of a malicious use on infrastructure VMs, like the VCC role VMs.

Finally, save the new custom operation so it becomes available for the selected scope.

Obtain extended information on the execution

There is the possibility of having the jobs show additional information in the execution of the custom operation in such a way that you have visibility of the output of the command or the result, for example, for a custom operation that restarts the printing services we will have the following details In the detail view of the generated job:

To achieve this, inside the script, we must assign to a variable $Result the error message or correct execution message and at the end of the script, add this line:

Write-Output $Result.ToString()

Execution of custom operations

For any user with a role or level of access that allows it, the custom operation can be executed in two ways:

From the details page of the resource:

1. Display the menu.
2. Select the "Custom operation" submenu.
3. Select the desired operation.
4. A popup window will appear asking us to confirm the operation:

From a listing view:

1. Select all VMs.
2. Select only a few.
3. Display the menu.
4. Select the "Custom operation" submenu.
5. Launch the desired operation.
6. Confirm the operation:

From that moment on, from the jobs view we can check the execution progress of the custom operation:

In addition, with the filtering options, we can generate a list of execution of one or more Custom operations to know its index of use, success in the operation, etc.

Example

$Result = "lodctr /r: `n"
$Result += lodctr /r | Out-String
$Result += "`nRestarting service `n"
$Result += Restart-Service -DisplayName 'Citrix Desktop Service' | Out-String
$Result += "`nService Restarted `n"
Write-Output $Result.ToString()

As we can see in the example above, this script executes a command and restarts a service, the explanation of what happens in each step is:

$Result = "lodctr /r: `n" <-- Message that will appear in the detail of the console job
$Result += lodctr /r | Out-String <-- First execution, a command is run
$Result += "`nRestarting service `n" <-- Message that will appear in the detail of the console job
$Result += Restart-Service -DisplayName 'Citrix Desktop Service' | Out-String <-- Second execution, a service is searched and restarted
$Result += "`nService Restarted `n" <-- Message that will appear in the detail of the console job
Write-Output $Result.ToString() <-- Final message of the job showing the result of the operation

The message within the job details:

Custom Operations Scheduling

You can perform custom operations in two modes: scheduled or automated. Next, it will be explained for each mode.

Scheduling a custom operation

Flexxible|SUITE allows schedule jobs on a specified date and time.

When you click in the desired custom operation, it will display a window where you can schedule the job. 

You must specify the start job from and to fields. Finally, clicking the ok button will save the changes.

Automatic Custom Operations

For version 4.1 or higher Flexxible|SUITE allows creating triggers in the custom operations. 

To create a new Custom Operation trigger you must click in the new button in the triggers tab.

When you create a new trigger you should set:

• The trigger source (at the moment only Eventlog and we will leave the field in read-only)
• The EventLog ID
• EventLog source
• EventLog keyword
• Enabled (true by default)

Note: The EventLog refer to Windows Events. Please, refer to the Windows Events article in Microsoft Windows Dev center for more information.

Every 10 minutes Flexxible|SUITE searches for new events that match with the configured triggers. If there is a match, the trigger will launch the custom operation in the VM that originated the event.

The search for events will be done with the same criteria that are currently used in the alerts activation. 

The custom operation could have some predefined tenants. This makes that the trigger will be only activated by events in the VMs of the linked tenants.

Flexxible|SUITE keeps an audit of all the triggers launched. This will also allow us to know which events should generate a new custom operation or which ones have already generated it. 

This information is shown in the Triggered Events tab.