Custom Hive Overview

You can use Custom Hives to initiate tests from custom locations, and to test internal resources that a Cloud Hive is not able to access. This article explains the purpose and design of Custom Hives, including their prerequisites and network details

What is a Custom Hive?

A Custom Hive is a distributed executable that is installed on a server on-premises, or on the same network as an XD Delivery Controller. The Custom Hive connects to a Scoutbees organization and sends test data to the cloud-based Scoutbees database for proactive monitoring and alerting. You use the Scoutbees web app to create and manage Scouts that are initiated from the Custom Hive.

To allow Scoutbees backend to communicate with Scouts running from Custom Hives, you need to open a secured WebSocket connection from the on-premises service to the Scoutbees cloud-based backend.

The data that allows the Custom Hive to initiate Scouts internally, and gather additional information about the resources, are saved encrypted on the same location where the Custom Hive is installed.

Custom Hives can now be installed and updated using automation tools, without requiring user interaction. See Upgrade Custom Hives, Silent Install for Synthetic Monitoring Custom Hives.

Motivations for using a Custom Hive

Cloud-based Hives can face the following challenges when accessing and testing resources:

• 2FA. Increasingly, various methods of 2FA (one-time pin codes, SMS based tokens, mobile push notifications, etc.) are implemented on publicly accessible gateways. These security measures make automated synthetic logins difficult.
• Internal Networks and Services. Enterprise networks are complex, consisting of various local and wide sub-networks, branches, and internal applications and services. Testing published resources only from outside the internal network might not sufficiently inform you about the entire business application status.
• Additional data. Collecting data on a resources status and the connection phases from an external source is useful, but you might need to correlate it with additional data from the backend and additional components to more closely monitor your business application.

These challenges can be addressed by using a Custom Hive, which allows you to:

• Initiate and run Scouts from on-premises locations/networks to start the test connection through the internal StoreFront or NetScaler Gateway from custom locations.
• Collect session data from on-premises XD controllers.
• Save Scout credentials on-premises.

For example, with a Custom Hive, you can enrich the synthetic session data with the following data:

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 2022 Prod Delivery Group | Catalog Name: Windows Server 2022 Prod Catalog  | Pending Update: False

Network Connections and Prerequisites

Prerequisite for Citrix Storefront Scouts

You will need to allow WebSocket based sessions on the relevant delivery groups in the Citrix Virtual Desktops (formerly XenDesktop) policy to allow the headless runner to connect to the published resources. To do so, perform the following:

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.