In Flexxible|SUITE, the different components use messages to communicate with each other and work together orchestrating the processes and jobs that are running at a given moment.

For example, if an operator in the web console selects the "Restart" option for a  VM, a message of type "Restart VM" is sent by the web console, containing the name of the VM to restart. A running instance of the Flexxible|SUITE desktop operations service will receive the message and create a job "Restart VM" that will be visible in the "Jobs" list.

Another example is the VDIClient service, which periodically sends a "VM status" message with different information about the VM, like memory or CPU usage.

There are many kinds of messages that are continuously being sent and received or answered by the different SUITE components.

Sending and receiving messages is conducted through the message queue as if it was a post service. The different running Flexxible|SUITE Queue service instances take care of receiving the sent messages and process or keep them until someone asks for a message of a given kind. 

Group policy for message queue access

For the Flexxible|SUITE components to know where to send and ask for messages, a Group Policy must be applied to the machines running any Flexxible|SUITE component (workers, web servers, application servers, desktops, VDI appliances...)

This policy should create a REG_SZ key "VDIQueueClient"  in the Windows registry under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Flexxible\VDIClient\Communications containing the list of Queue service instances that are attending message queue requests to send or receive messages.

The value of this key should be a semicolon-separated list of machine names or IP addresses and TCP ports. For example:

SDWorker01.sd.local:1236; SDWorker01.sd.local:1237; SDWorker02.sd.local:1236; SDWorker02.sd.local:1237

Please note that a given machine can appear up to twice with different TCP port numbers. The default TCP port numbers for the Flexxible|SUITE queue are 1236 and 1237.

Group policy for message queue service instances

To configure the TCP ports where Flexxible|SUITE Queue service will listen for queue requests, another Group Policy must be applied to the machines running an instance of this service (usually in the workers).

This policy should create a REG_SZ key "VDIQueueServer" under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Flexxible\VDIWorker\Communications containing two TCP port numbers separated by a semicolon on which the service will listen for queue requests. For example, the default values are:

1236;1237

Settings

Starting from Flexxible|SUITE 4.5, the following settings allow the configuration and control of the message queue behavior:

• QueueMsgForcePersistOverCPUPercent: [an integer from 0 to 100] Percentage of CPU usage over which every queue message received by the Queue service is persisted to the database for deferred processing. The default value is 70. This means that directly processable queue push requests received when the CPU usage is over this value will be deferred. If the CPU usage gets lower, subsequent push requests could be directly processed.
• QueueMsgForcePersistOverRAMPercent: [an integer from 0 to 100] Percentage of RAM usage over which every queue message received by the Queue service is persisted to the database for deferred processing. The default value is 70.
• QueueMsgDirectProcessing: Indicates whether queue messages received by the Queue service are processed without persisting them to the database. The default value is true.
• QueueMsgDirectMaxThreads: [positive integer] The maximum number of threads allowed to the Queue services to process messages in parallel without persisting to the database. Changing this value requires service instances to be restarted. The default value is 20. Please, consider that a higher number of threads could kill performance, so be cautious when changing this value and monitor the Queue service performance after doing so.

Note that all of these settings can be set with a different value for a specific machine by using the "New" button in the settings list and informing the machine NETBIOS name and the particular setting value for that machine:

Message authentication

Also, from version 4.13, the  new setting "QueueMsgAuthentication" allows to digitally sign the queue messages, so they can't be altered or supplanted. Please, consider that you should not set this setting to "true" until the VDIClientService in every machine has auto-updated to the new version, to prevent their queue messages to be discarded for not being digitally signed.

To set up message authentication you should distribute (for example via group policy) two Windows Registry values "SK" and "EK" (REG_SZ) to the key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Flexxible\VDIClient\Communications\Secure in every VM, VDI Appliance, or physical machine where VDIClientService is installed.

To generate and copy to the clipboard a unique value for "SK" in your Flexxible|SUITE installation, you should use this PowerShell script:

$RSA = [System.Security.Cryptography.RSA]::Create()
$byteConverter = [System.Text.UnicodeEncoding]::new()
$xml = $RSA.ToXmlString($true)
$keyPair = [System.Convert]::ToBase64String($byteConverter.GetBytes($xml))
Set-Clipboard $keyPair

To generate and copy to the clipboard a unique value for "EK", use the following script:

$bytes = [System.Byte[]]::CreateInstance([System.Byte],32)
[System.Random]::new().NextBytes($bytes)
$EK = [System.Convert]::ToBase64String($bytes)
Set-Clipboard $EK

For security, the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Flexxible\VDIClient\Communications\Secure should have restricted permissions on all VMs to only the LocalSystem account and the services accounts groups, whose name is specified in the "VDIManagerServicesGroup" setting.

Note: if you securize the registry keys by using a computer GPO, please remember to restart the VCC Worker roles so the changes apply.

Performance counters

Starting from Flexxible|SUITE 4.5, the Flexxible|SUITE Queue service provides the following Windows performance counters to allow for monitoring of its health and status:

• Push requests: Total number of message push requests received by this instance of the Queue service.
• Push requests/second: Number of message push requests received per second.
• Push errors/second: Number of message push requests failed per second. It includes any push request that produced an error while processing it or persisting it for later processing.
• Inline-processable push requests: Total number of message push requests that can be processed without deferral attending to its type. Some or many or these requests might not be directly processed and be deferred depending on the Queue service settings and the status of RAM, CPU, and thread pool occupation.
• Inline-processable push requests/second: Number of message push requests per second that can be processed without deferral.
• Deferred: Total number of messages deferred for later processing. It includes requests that could have been directly processed attending to its type but were deferred for different reasons, indicated by other counters. This number doesn't necessarily have to be the sum of the different deferred counters. A push request could be deferred because of more than one reason, for example, CPU and RAM usage both over the limits.
• Deferred / second: Number of messages per second deferred for later processing.
• Deferred (thread pool overflow): Total number of messages deferred because the thread pool was full. A high value could indicate the need to increase the value of the QueueMsgDirectMaxThreads setting or create new Worker VCC roles.
• Deferred (CPU usage exceeded): Total number of messages deferred because the CPU usage % was exceeded. A high value could indicate that the QueueMsgForcePersistOverCPUPercent setting has a value too low, or that new VCC worker roles are necessary. 
• Deferred (RAM usage exceeded): Total number of messages deferred because the RAM usage % was exceeded. A high value could indicate that the QueueMsgForcePersistOverRAMPercent setting has a value too low, more RAM is needed for the existing VCC worker roles, or new VCC worker roles are necessary.
• Deferred (direct message processing disabled): Total number of messages deferred because direct message processing was disabled. This indicates the number of push requests that could have been directly processed attending to its type but were finally deferred because the QueueMsgDirectProcessing setting indicated that direct processing was disabled whether in general or for this specific VCC worker role.
• Pop requests: Total number of message pop requests received by this instance of the Queue service.
• Pop requests/second: Number of message pop requests received per second. 
• Pop errors/second: Number of message pop requests failed per second. It includes any pop request that produced an error while retrieving the persisted message from the queue. A high value could indicate that there are database access issues.
• Popped messages: Total number of message pop requests that returned a message.
• Popped messages/second: Number of message pop requests per second that returned a message.