Deployment on RDS/Citrix Environment

Kabeen agent deployment guide for RDS and Citrix virtualization environments

The Kabeen agent is compatible with application virtualization environments such as Microsoft Remote Desktop Services (RDS) and Citrix Virtual Apps.

How it works

On a shared server, several users open a session on the same machine. The model is as follows:

  • One installation per server: the MSI package is installed only once on each shared server, for all sessions.
  • One agent instance per session: the agent then runs in the context of every user session opened on that server, under the identity of the user concerned.
  • One configuration per user: each instance reads the configuration of its own user, which makes it possible to attach different users to different teams on the same server.

Prerequisites

  • Administrator access to the RDS/Citrix servers
  • The agent MSI installation package, available from the Kabeen platform
  • Kabeen API key and structure / team UUID
  • Outbound HTTPS (443/TCP) to api.kabeen.io and intake.kabeen.io

Installing the agent on the shared servers

The only requirement is that the agent is installed once on each shared server. The method is entirely up to you, depending on how you manage your servers:

  • adding the MSI to the base image (RDSH gold image, MCS or PVS catalog, Citrix App Layering);
  • or installing directly on each server with your usual tooling: GPO in computer configuration, SCCM, Intune, deployment script, manual installation.

Installation runs silently:

msiexec /i kabeen-agent.msi /qn

Do not bake any user setting (API key, structure, team) into the base image: that configuration is delivered in user context, at session logon (see the next section).

Checking that the agent runs in every session

The best check is to verify, from an administrator session on the server, that a Kabeen.exe process is present for every open user session:

tasklist /FI "IMAGENAME eq Kabeen.exe" /V

You should get one line per active session, each with its own session number and the matching user account. Task Manager gives the same information: Details tab, with the User name and Session ID columns displayed.

If the agent is present for only some sessions, or for none, refer to the RemoteApp special case below.

Configuring the API key and teams

There is no RDS/Citrix specificity at this step: the agent configuration (API key, structure, team) is delivered by GPO, in user configuration, exactly as on a standard workstation. Refer to the Deploy User Agent via GPO article, section Configure Agent Settings: the procedure there is complete and sufficient.

The fact that several users share the same server raises no difficulty. Each session has its own agent instance, which reads the values from the HKEY_CURRENT_USER hive of the logged-on user. Two users from different teams opening a session on the same server therefore receive their settings from their respective GPOs, without conflict: each agent starts with the configuration of its own user.

Special case: RemoteApp sessions and published applications

In RemoteApp mode (Microsoft RDS) or published application in seamless mode (Citrix), the session opened on the server is a lightweight one: Windows does not load the full shell (explorer.exe) in it. Microsoft documents this limitation — in a RemoteApp session, neither the Run registry key, nor the RunOnce key, nor the startup applications are processed (see KB 951048).

As a result, the programs normally started at logon, including the Kabeen agent, do not start in these sessions. Their execution has to be requested explicitly, using one of the two methods documented by Microsoft.

Method 1 — GPO "Run these programs at user logon"

  1. Open the Group Policy Management Editor, then Computer Configuration > Administrative Templates > System > Logon.
  2. Open the Run these programs at user logon setting and enable it.
  3. Click Show, then Add, and enter the full path of the agent executable:
C:\Program Files\Kabeen\Kabeen.exe

The full path is mandatory for any executable located outside %SystemRoot%. This setting also exists under User Configuration, if you prefer to target a user OU rather than the servers.

Method 2 — runonce.exe /AlternateShellStartup logon script

  1. In the Group Policy Management Editor, open User Configuration > Windows Settings > Scripts (Logon/Logoff).
  2. Double-click Logon, then Add.
  3. In Script name, enter runonce.exe.
  4. In Script parameters, enter /AlternateShellStartup.

This method replays the standard startup items of the session, including the Kabeen agent. It avoids hard-coding the path to the executable and covers, in one go, every application affected by the limitation.

Citrix: recent VDA versions start the programs from the Run key in seamless sessions themselves, through their Shell Launcher (ShellAppRuntime.exe). Check first whether the agent already starts in a published application session, and only apply the workaround if it does not.

In these sessions the notification area is not displayed: the agent runs without a visible icon for the user, which changes nothing for collection. Once one of the two methods is applied, open a published application and then check that the Kabeen.exe process is present under the user account, as described above.

Performance Considerations

  • CPU: minimal impact (~1% per session)
  • RAM: ~50 MB per user session
  • Network: data sent every 5 minutes (a few KB)

Troubleshooting

Agent doesn't start in session

Verify that:

  • The agent is indeed installed on the server hosting the session (C:\Program Files\Kabeen)
  • The session is not a RemoteApp session or a published application without startup configuration (see the special case above)
  • No group policy or AppLocker rule blocks the execution of Kabeen.exe
  • The agent is not blocked by your EDR/antivirus (see Allowing the Kabeen agent in your EDR/antivirus)

Data not reported

Verify that:

  • Outbound HTTPS to api.kabeen.io and intake.kabeen.io is allowed
  • The API key is valid and correctly delivered in the user's HKEY_CURRENT_USER hive
  • The firewall doesn't block port 443