This document aims to explain the motivations for, and design of, the Scoutbees Custom Hives.  It should help customers understand how custom hives work, their prerequisites and the way they communicate with internal and external services.

Background & Motivations

2FA

An increasing number of organizations implements various methods of ephemeral 2-factor authentications (one-time pin codes, SMS based token, a mobile app powered step up authentications, etc) on their publicly accessible gateways, all of these methods increase the level of security of enterprise workspace and business applications, but also makes automation and synthetic logins almost impossible (or just ineffectually complex).

Internal networks and services 

Enterprise networks are complex creatures - they are built of various local and wide sub-networks, branches, internal applications and services, testing the published resources only from the outside of the internal network won’t tell the whole story about the business application status.
 

Enrich test results with supplemental data

Understanding of business application status and getting the connection phases tells just part of the story about the application health, in most cases, correlated data from backend and other components of the application will tell a much richer story.

The Solution

Encapsulate the runner capabilities into a distributed executable - Custom Hive - that will allow customers to run tests from any network (cloud VPC, internal network) and test internal (via Citrix StoreFront, Horizon Connection Server, etc) and external (Citrix NetScaler Gateway, VMware UAG, etc) published resources.

Custom Hives will enable customers to -

• Initiate and run scouts from On-Prem locations/networks that will start the connection through the internal StoreFront or NetScaler gateway from custom locations
• Collect relevant session data from On-Prem XD controllers
• Save all scout's credentials On-Prem
• Each scout will just send the metric-based data to our cloud-based DB, for visualization, proactive analytics, and alerts

For example, Custom Hives will be able to enrich the synthetic session data with the following -

Server Name: VDA01 | Session ID: 123 | Logon Duration: 15.501s | ICA RTT: 2ms | Network Latency: 0ms | Logon Scripts Duration: 4s | Profile Load Duration: 47ms | GPO Duration: 1.7s | Authentication Duration: 40ms

Brokered by: ddc01 | Brokering Duration: 70ms | Hosting server: VDA01 | Desktop Group: Windows Server 2012R2 Prod Delivery Group | Catalog Name: Windows Server 2012R2 Prod Catalog  | Pending Update: False

The Custom Hive is a small service installed on one of the servers’ On-Prem (or on the same network/s as the XD Delivery Controllers) and connected to the customer's Scoutbees account.

Visualization, scouts management, custom hives management, reports and scouts creation/deletion will still be done from Scoutbees' cloud-based control pane.
To allow us to read the data from the On-Prem Storefront/XD while keeping the scout creation on the cloud-based web app, we are going to open a secured WebSocket connection from the On-Prem service/s to our cloud-based backend.
All local data to allow the On-Prem runner to run the scouts internally and get the additional data about the sessions are going to be saved encrypted on the same server where the On-Prem runner is running.

Workflow

1. In the Scoutbees Hive tab, create an Hive and copy Hive's key.
2. Download custom hive installation.
3. Run the custom hive installation on a Windows machine and set the API token from step #1.
4. Custom hive will initiate an outgoing WebSocket connecting with Scoutbees cloud backend.
5. In the Scoutbees control plane, go to 'Create Scout', choose the desired custom hive (you will see an indication about its connection status).
   
6. Insert the relevant details about the Scout - such as Storefront Address, Tested Username and Password, and click the Get Resources button.
7. Scoutbees cloud backend will send a request to the selected Custom Hive (on the same WebSocket that opened on step #2) to fetch all the relevant resources for the select User.
8. Choose the tested published resource from the list.
9. Set the schedule and save the Scout.
10. On our cloud jobs DB we are going to save the following (we need this for visualization and alerts engine), Scout ID, Scout Name, Storefront/NetScaler Address, Username, Published resource name, Schedule.
11. In the Custom Hive local DB (the one that running On-Prem) we are going to save the Scout ID, Scout Name, Storefront/NetScaler address, Username, Password, Published resource name, and Schedule.
12. During the run of each scout it will collect data from the server that the session has logged into (with remote WMI query) and from the relevant XD site (discovered automatically. By querying the XD Monitoring Database).
13. Credentials for WMI and XenDesktop queries will be saved in the same local DB, same as the configured jobs. They will be configured with a local configuration wizard (sb-config.exe) together with hive’s API key and proxy (if needed) configuration.
14. At the completion (or failure) of each Scout, it will send the metrics (with Server Name, Delivery Group Name, Catalog and XD Site Name) to our central metrics DB (so we will be able to alert, run analytics and visualize the data).

Architecture and prerequisites

Network connections and prerequisites

Other prerequisites

Architecture

Appendix

Enabling WebSocket Connections on XenDesktop and XenApp via Policies

1. Go to the Group Policy Management Console or Citrix Studio to configure HDX policies.
2. Select the WebSockets connections policy setting, and allow WebSockets connections.
   
3. Assign to the relevant Delivery Group and Enable the policy.