Session Recording Technology Preview Administrator’s Guide
Computer processing capacity
Consider the following specification for the computer on which a Session Recording Server is installed:
x A dual CPU or dual-core CPU is recommended
x 2GB to 4GB of RAM is recommended
Exceeding these specifications does not significantly improve performance.
Deploy multiple Session Recording servers
If a single Session Recording Server does not meet your performance needs, you can install more
Session Recording Servers on different machines. In this type of deployment, each Session Recording
Server has its own dedicated storage, network switches, and database. To distribute the load, point the
Session Recording Agents in your deployment to different Session Recording Servers.
The Session Recording Database requires Microsoft SQL Server 2014, Microsoft SQL Server 2012, or
Microsoft SQL Server 2008 R2. The volume of data sent to the database is very small because the
database stores only metadata about the recorded sessions. The files of the recorded sessions
themselves are written to a separate disk. Typically, each recorded session requires only about 1KB of
space in the database, unless the Session Recording Event API is used to insert searchable events into
The Express Editions of Microsoft SQL Server 2014, Microsoft SQL Server 2012, and Microsoft SQL
Server 2008 R2 impose a database size limitation of 10GB. At 1KB per recording session, the database
can catalog about four million sessions. Other editions of Microsoft SQL Server have no database size
restrictions and are limited only by available disk space. As the number of sessions in the database
increases, performance of the database and speed of searches diminishes only negligibly.
If you are not making customizations through the Session Recording Event API, each recorded session
generates four database transactions: two when recording starts, one when the user logs onto the
session being recorded, and one when recording ends. If you used the Session Recording Event API to
customize sessions, each searchable event recorded generates one transaction. Because even the most
basic database deployment can handle hundreds of transactions per second, the processing load on the
database is unlikely to be stressed. The impact is light enough that the Session Recording Database can
run on the same SQL Server as other databases, including the XenApp or XenDesktop data store
If your Session Recording deployment requires many millions of recorded sessions to be cataloged in the
database, follow Microsoft guidelines for SQL Server scalability.
Important deployment notes
x To enable Session Recording components to communicate with each other, ensure you install them
in the same domain or across trusted domains that have a transitive trust relationship. The system
cannot be installed into a workgroup or across domains that have an external trust relationship.
x Session Recording does not support the clustering of two or more Session Recording Servers in a
x Due to its intense graphical nature and memory usage when playing back large recordings, Citrix
does not recommend installing the Session Recording Player as a published application.
x The Session Recording installation is configured for SSL/HTTPS communication. Ensure that you
install a certificate on the Session Recording Server and that the root certificate authority (CA) is
trusted on the Session Recording components.