CONTOSO - Citrix Xenapp Implementation Document - V1.0

Implementation document
Citrix XenApp Upgrade
CONTOSO
Information in this document, including URL and other Internet Web site references, is subject to
change without notice.
Without limiting the rights under copyright, no part of this document may be reproduced, stored in or
introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording or otherwise), or for any purpose, without the express written
permission of ACME.
© 2023 ACME, all rights reserved.

3 of 128
-
Document history
Revisions
Version Date Author(s)/Editor(s) Notes
1.0 30/10/2015 Joeri Kumbruck Initial version
Reviews
Version Date Reviewer(s) Notes
1.1 04/11/2015 Joeri Kumbruck Changed info regarding RAM
memory configuration of Citrix
Xenapp servers & after feedback
from CONTOSO ICT team
members.
Related documents
Document Version Date Description
CONTOSO -new Citrix 1.0 18/06/2015 Excel sheet with overview of infrastructure
Xenapp Infrastructure items such as VM’s, service accounts,
detailed overview - databases.
v1.0.xlsx
CONTOSO - 1.0 18/06/2015 Sheet with all printer queues and printer
Printer_inventory_list drivers that need to be provided on the new
- v1.0.xlsx Xenapp environment
CONTOSO - 1.0 18/06/2015 Sheet with an overview of all the applications
Application_Inventory that will be available in the new XenApp
_list - v1.0.xlsx environment. A distinction is being made
between which application will be packaged
by ACME and which application will be
packaged by the customer.
CONTOSO Netscaler- 1.0 01/09/2015 Implementation document describing the
Implementation- technical setup of the Netscaler VPX
Document- v1.0.docx appliances.
CONTOSO - Design 1.1 07/09/2015 Design document used to be able to properly
Document Citrix build up the Citrix Xenapp environment
XenApp Upgrade -
v1.1.docx
Section: Document history www.ACME.be

Table of Contents
Document history...........................................................................................................3
Revisions...................................................................................................................................3
Reviews.....................................................................................................................................3
Related documents...................................................................................................................3
1 Introduction.............................................................................................................7
1.1 Scope............................................................................................................................7
2 Architectural Overview...........................................................................................8
2.1 Design Structure...........................................................................................................8
2.2 Infrastructure server Virtual Machines Overview.......................................................10
2.2.1 New Virtual machines.........................................................................................10
2.2.2 Existing Virtual machines....................................................................................11
2.3 XenApp Virtual Machines Overview...........................................................................11
3 User Layer............................................................................................................13
3.1.1 Layer Overview....................................................................................................13
3.1.2 Key Design Decisions...........................................................................................13
3.1.3 Design.................................................................................................................14
4 Access Layer.........................................................................................................20
4.1.1 Layer Overview....................................................................................................20
4.1.3 Design.................................................................................................................23
5 Resource Layer.....................................................................................................29
5.1 Layer Overview...........................................................................................................29
5.2 Key Design Decisions..................................................................................................29
5.3 Design.........................................................................................................................35
5.3.1 XenApp version...................................................................................................35
5.3.2 Flexcast Delivery model.......................................................................................35
5.3.3 XenApp Image Design.........................................................................................36
5.3.4 XenApp Sizing......................................................................................................38
5.3.5 User Profile Management...................................................................................40
5.3.6 User Home folder................................................................................................41
5.3.7 Folder Redirection...............................................................................................41
5.3.8 Citrix Policies.......................................................................................................43
5.3.9 User Environment Configuration.........................................................................44
5.3.10 Server Deployment..............................................................................................46
5.3.11 Server Configuration...........................................................................................46
5.3.12 Printing Environment..........................................................................................49
5.3.13 Applications........................................................................................................51
6 Control Layer........................................................................................................57
6.1 Layer Overview...........................................................................................................57
6.2 Citrix XenApp Controllers............................................................................................57
6.2.1 Overview.............................................................................................................57
Section: Table of www.ACME.

6.2.3 VM Specifications................................................................................................59
6.2.4 Configuration......................................................................................................59
6.2.5 High Availability..................................................................................................62
6.3 Citrix Provisioning Services.........................................................................................63
6.3.1 Overview.............................................................................................................63
6.3.4 Configuration......................................................................................................67
6.3.5 Special Considerations when using PVS..............................................................73
6.3.6 High Availability..................................................................................................74
6.4 App-V Servers.............................................................................................................74
6.4.1 Overview.............................................................................................................74
6.4.4 Configuration......................................................................................................77
6.5 Active Directory Integration........................................................................................79
6.5.1 Overview.............................................................................................................79
6.5.3 Configuration......................................................................................................81
6.6 Print Servers...............................................................................................................93
6.7 IGEL UMS server.........................................................................................................94
6.7.1 Overview.............................................................................................................94
6.7.4 Configuration......................................................................................................95
6.8 File Servers..................................................................................................................98
6.8.1 Overview.............................................................................................................98
6.8.4 Configuration......................................................................................................99
6.9 License Servers...........................................................................................................99
6.9.1 Overview.............................................................................................................99
6.9.3 VM Specifications..............................................................................................101
6.9.4 Configuration....................................................................................................101
6.9.5 High Availability................................................................................................102
7 Hardware Layer..................................................................................................103
7.1.1 Layer Overview..................................................................................................103
7.1.2 Key Design Decisions.........................................................................................103
7.1.3 Design...............................................................................................................104
8 Monitoring..........................................................................................................109
8.1 Performance monitor metrics..................................................................................109
8.1.1 Generic performance monitor metrics..............................................................110
8.1.2 Citrix Delivery controller performance monitor metrics....................................112
8.1.3 Citrix Storefront performance monitor metrics.................................................112
8.1.4 Citrix License server performance monitor metrics...........................................112
8.2 Windows services monitoring...................................................................................113

8.2.1 Citrix Xenapp 7.6 servers services......................................................................113
8.2.2 Citrix Delivery controller servers services..........................................................114
8.2.3 Citrix Provisioning servers services....................................................................114
8.2.4 Citrix Storefront servers services.......................................................................115
8.2.5 Citrix License servers services............................................................................115
8.3 Windows events monitoring.....................................................................................115
8.4 Citrix director............................................................................................................116
9 High availability, disaster recovery and backup & recovery strategy................118
9.1 High availability & disaster recovery.........................................................................118
9.2 Backup & recovery....................................................................................................125

7 of
-
1 Introduction
1.1 Scope
This document contains actual information about the implemented new Citrix XenApp
environment at CONTOSO.
This document is based on the design document and contains all changes that have been
done during the actual implementation of the Citrix Xenapp environment. In other words,
this document describes exactly how the Citrix Xenapp environment look like on the date
that operational management of the new Citrix Xenapp environment has been transferred to
CONTOSO (this is done on Friday 06/11 after knowledge transfer session)
Section: www.ACME.
8 of
-
2 Architectural Overview
2.1 Design Structure
Designing a desktop virtualization solution is simply a matter of following a proven process
and aligning technical decisions with organizational and user requirements. Without the
standardized and proven process, architects tend to randomly jump from topic to topic,
which leads to confusion and mistakes. The difficulty with creating an application delivery
solution is in trying to focus on everything at once, which leads to an overwhelming amount
of data points to design around. However, when focusing on the common use cases, which
typically accounts for the largest percentage of users, many of the decisions simply follow
best practices, which are based on years of real-world implementations. Once a foundation
is created, the complex use cases can be integrated as needed.
At a high-level, the solution is based on a unified and standardized 5-layer model.
1. User Layer – Defines the unique user groups, endpoints and locations.
2. Access Layer – Defines how a user group gains access to their resources. Focuses on
secure access policies and desktop/application stores.
3. Resource Layer – Defines the applications and data provided to each user group
4. Control Layer – Defines the underlying infrastructure required to support the users
accessing their resources
5. Hardware Layer – Defines the physical implementation of the overall solution The
recommended approach focuses on working through five distinct layers:
The following diagram shows an overview of how all these layers interact with each other:
Section: Architectural www.ACME.

9 of 128
-

10 of
-
2.2 Infrastructure server Virtual Machines Overview

The following table is a global overview of all the virtual machines that will be required for
infrastructure components and that will be hosted on the shared VMWare environment.
2.2.1 New Virtual machines

Hostname Role IP Address Xenserver vCPU RAM Disk 1 Disk 2 Xenserver SR
host
vsfcon-1200  Citrix storefront 192.168.1.200 SXCON- 1 4 GB 60 N/A ISCSI-XENLUN-
1018 R620POOL1-SAS
vsfcon-1201  Citrix storefront 192.168.1.201 SXCON- 1 4 GB 60 N/A ISCSI-XENLUN-
1019 R620POOL2-SAS
vddcon-1202  Citrix Delivery 192.168.1.202 SXCON- 2 8 GB 60 N/A ISCSI-XENLUN-
Controller 1018 R620POOL1-SAS
 Citrix Director
vddcon-1203  Citrix Delivery 192.168.1.203 SXCON- 2 8 GB 60 N/A ISCSI-XENLUN-
Controller 1019 R620POOL2-SAS
 Citrix Director
vpvcon-1204  Citrix PVS (incl. TFTP LAN: 192.168.1.204 SXCON- 2 16 GB 60 500 (direct ISCSI-XENLUN-
+ PXE) Iscsi: 1018 attached R620POOL1-SAS
 MS DHCP 192.168.100.204 iscsi disk
within
server OS)
vpvcon-1205  Citrix PVS (incl. TFTP LAN:192.168.1.205 SXCON- 2 16 GB 60 500 ISCSI-XENLUN-
+ PXE) Iscsi: 1021 (direct R620POOL2-SAS
 MS DHCP 192.168.100.205 attached
iscsi disk
within
server OS)
vavcon-1206  MS APP-V 5.0 SP3 LAN: 192.168.1.206 SXCON- 1 4 GB 60 100 ISCSI-XENLUN-
management + Iscsi: 1018 (direct R620POOL1-SAS
publishing + 192.168.100.206 attached
streaming server iscsi disk
within
server OS)
vfscon-1208  MS 2012 R2 File services LAN: 192.168.1.208 SXCON- 2 12 GB 60 300 ISCSI-XENLUN-
 ACME Taskflow Iscsi: 1022 (direct R620POOL1-SAS
deployment 192.168.100.208 attached
framework iscsi disk
 User Configuration within
(User Profiles + server OS)
folder redirection)
vlscon-1209  MS RDS licensing server 192.168.1.209 SXCON- 1 4 GB 60 N/A ISCSI-XENLUN-
 MS KMS host 1021 R620POOL2-SAS
 Citrix license server
vsqcon-1210  MS App-V sequencer 192.168.1.210 SXCON- 2 4 GB 60 N/A ISCSI-XENLUN-
1019 R620POOL2-SAS
vnscon-1211  Citrix Netscaler VPX NSIP: 192.168.1.211 SXCON- 2 2 GB 20 N/A ISCSI-XENLUN-
SNIP1: 1021 R620POOL1-SAS
192.168.1.213
SNIP2:
192.168.1.245
VIP1: 192.168.1.215
VIP2: 192.168.1.216
VIP3: 192.168.1.217
VIP4: 192.168.1.247
vnscon-1212  Citrix Netscaler VPX NSIP: 192.168.1.212 SXCON- 2 2 GB 20 N/A ISCSI-XENLUN-
SNIP1: (failover) 1022 R620POOL2-SAS
SNIP2: (failover)

11 of
-
2.2.2 Existing Virtual machines

Hostname Role IP Address Xenserver vCPU RAM Disk 1 Disk 2 Xenserver SR
host
vpscon-1009  MS print server 192.168.1.9 SXCON- 4 4 GB 48 GB N/A ISCSI-XENLUN-R620POOL4-SAS2
1019
vfscon-1004  MS 2008 R2 File LAN: SXCON- 2 12GB 50 GB Multiple ISCSI-XENLUN-R620POOL2-SAS2
services 192.168.1.4 1021 Iscsi disks
 User Home folder Iscsi: are
(incl. desktop 192.168.100.104 configured
folder redirection) within VM
vmgcon-1077  IGEL UMS 192.168.1.77 SXCON- 2 4 GB 50 GB N/A ISCSI-XENLUN-R620POOL1-SAS2
1021
vdbcon-1082  MS SQL 2014 LAN: SXCON- 2 32 GB 80 GB Multiple ISCSI-XENLUN-R620POOL3-SAS2
192.168.1.82 1022 Iscsi disks
Iscsi: are
192.168.100.82 configured
within VM
2.3 XenApp Virtual Machines Overview

The following table is a global overview of all the new XenApp servers located on the new
XenServer hosts.
Environment Hostname Role IP Address Xenserver vCPU RAM Disk Xenserver SR
host
MASTER vxmcon-1218 Master Citrix xenapp 192.168.1.218 SXCON- 4 4 GB 80 ISCSI-XENLUN-R620POOL1-SAS
server for PVS image 1018
DEVELOPMENT vxdcon-1219 Development Citrix 192.168.1.219 SXCON- 4 25 GB 10 ISCSI-XENLUN-R620POOL2-SAS
Xenapp 1019
TEST vxtcon-1220 Test Citrix Xenapp 192.168.1.220 SXCON- 4 25 GB 10 ISCSI-XENLUN-R620POOL1-SAS
1021
ACCEPTANCE vxacon-1221 Acceptance Citrix 192.168.1.221 SXCON- 4 25 GB 10 ISCSI-XENLUN-R620POOL2-SAS
Xenapp 1022
PRODUCTION vxpcon-1222 Production Citrix Xenapp 192.168.1.222 SXCON- 4 25 GB 10 ISCSI-XENLUN-R620POOL1-SAS
1020
1020
1020
1020
1020
1020
1020
1023
1023
1023
1023
1023

12 of
-

1023
1023

13 of
-
3 User Layer
3.1.1 Layer Overview
The user layer represents the end-users. This layer describes the different groups of users
and their requirements. Users are often grouped based on their network connectivity to the
data center, endpoint devices, data storage needs and any special requirements or concerns
(e.g. security, performance, mobility, personalization).
3.1.2 Key Design Decisions

The user groups are identified as follows:
User group Network Location # Users Client type # Client OS
devices
Employees Internal Brussels +/- 50 Company laptops +/- 80 Windows 7 64-
LAN headquarter CCU bit
s
Internal Brussels +/- 80 Igel Thin Clients +/- 110  Windows 7
LAN headquarter CCU embedded
s  Linux
Internal Brussels +/- 5 Company desktops +/- 10  Windows 7
LAN headquarter CCU 64-bit
s
Internal Gent +/- 6  5 thin clients 6  Linux
WAN CCU  1 company  Windows 7
laptop 64-bit
Internal Hasselt +/- 8 Company desktops 8  Windows 7
WAN CCU 64-bit
Section: User www.ACME.

14 of
-
Internal Libramont +/- 2  2 thin clients 3  Linux

desktop 64-bit
Internal Namen +/- 2 thin clients 4 Linux
WAN CCU
Internal La Louviere +/- 1 Company desktops 1 Windows 7 64-
WAN CCU bit
Internal Antwerpen +/- 2  1 thin client 2  Linux

desktop 64-bit
External  Home +/- 40  Company N/A  Windows
WAN  Remote CCU laptops OS
 Personal  MAC OS
laptops &  Linux OS
desktops
3.1.3 Design
3.1.3.1 User Groups
From a high level perspective, one user group can be defined: Zenito employees.
3.1.3.1.1 Locations
This user group can access the environment from internal as well as external locations.
Internal Locations are:

 Brussels headquarters
 Gent
 Hasselt
 Libramont
 Namen
 La Louviere
 Antwerpen
External locations are:

 Home location
 Any other remote location (e.g. hotel, kiosk,…)
The following picture shows a high-level overview of the different locations that will connect
to the new Citrix Xenapp environment:

15 of
-
3.1.3.1.2 Client devices

The user group will access the environment with the following client devices:
 Windows 7 64-bit company laptops (+/- 80)
 Windows 7 64-bit company desktops (+/- 10)
 Windows 7 embedded Igel thin clients (+/- 10)
 Linux Igel thin clients (+/- 100)
 Windows & Mac personally owned laptops & desktops
The environment will be prepared to enable access for the above mentioned client devices.
MAC DEVICES AS WELL AS MOBILE DEVICES (TABLETS AND SMARTPHONES) WILL BE ABLE TO CONNECT
TO THE NEW XENAPP ENVIRONMENT BUT THEY WILL NOT BE OFFICIALLY SUPPORTED BY THE ICT
CONTOSO TEAM.

16 of
-
3.1.3.2 Connection method & Citrix Receiver version + usage

We make a distinction between fat clients and thin clients:
 Fat clients are full blown laptops or desktops that mainly run on Windows OS. The user
will use locally installed applications and will also use desktop and/or applications
running on the Citrix Xenapp platform. Fat clients are:
 Windows 7 64-bit company laptops
 Windows 7 64-bit company desktops
 Windows & Mac personally owned laptops & desktops
 Thin clients are very light, small devices that only contain robust components and in case
of CONTOSO is only used to access a virtual desktop on the Citrix Xenapp platform. Thin
clients are:
 Windows 7 embedded Igel thin clients
 Linux Igel thin clients
3.1.3.2.1 Fat clients

With fat clients, a further distinction is being made between company owned and personally
owned fat clients.
3.1.3.2.1.1 Company owned fat clients

Company owned fat clients are managed by CONTOSO. This means that Citrix receiver
software will be managed and installed by ICT CONTOSO. It is important that the correct
Citrix receiver version is distributed and installed on all company owned fat clients. Using
the correct Citrix receiver version enables users to use advanced features of Citrix Xenapp
7.6 such as taking advantage of the H.264 supercodec functionality.
Citrix receiver version 4.3.0 (14.3.0) is used and deployed and installed on all company
owned fat clients.
Users will connect to 1 URL, https://access.CONTOSO.be, no matter if they are working from
an internal or external location.
Only Receiver for web will be used, thus end users will always connect to the Citrix access
webportal with their preferred web browser.
3.1.3.2.1.2 Personally owned fat clients

Personally owned fat clients are not managed by CONTOSO but by the user/owner. The user
is responsible to install the required Citrix receiver software themselves. This can be done by
surfing to the following URL: http://receiver.citrix.com.
However, when the user is connecting from an external location, the user will be offered to
autoinstall the Citrix receiver when they connect for the first time to Receiver for web
website (https://access.CONTOSO.be). This is because auto detection and deployment of
Citrix receiver will be enabled when users connect via the Netscaler gateway from external
locations. Citrix receiver version 4.3.0 (14.3.0) will be used for auto-detection and
deployment via the Receiver for Web website.

17 of
-
Users will connect to 1 URL, https://access.CONTOSO.be, no matter if they are working from
an internal or external location.
Only Receiver for web will be used, thus end users will always connect to the Citrix access
webportal with their preferred web browser.
3.1.3.2.2 Thin clients

Most of the end users are connecting to XenApp using an Igel Thin Client device.
CONTOSO is mainly using Linux Igel thin clients but they are also using some Windows
Embedded 7 thin clients.
No matter which Igel OS is being used, the thin clients will connect using the embedded
browser to the Citrix Receiver for Web website.
The Igel built-in Citrix receiver will be used:
 For Linux thin clients this is Citrix receiver version 12.1.8.250715 (included in Igel LX
firmware version 4.14.100).
 For certain Linux thin clients (latest models) this is Citrix receiver version 13.1.4.322630
(included in Igel LX firmware version 5.07.100).
 For Windows 7 Embedded thin clients this is Citrix receiver version 4.2 (14.2.100.14)
(included in Igel W7 firmware version 3.10.120).
Users working on Igel thin clients will autoconnect to 1 URL:

https://storefront.CONTOSO.be/Citrix/Internalweb
All Igel thin clients will be installed with the latest publicly available Firmware version:
 Old Linux thin clients: Igel LX firmware version 4.14.100
 New Linux thin clients: Igel LX firmware version 5.07.100
 W7 thin clients: Igel W7 firmware version 3.10.120
Igel thin client will be configured with an Igel configuration profile that will contain a
minimum of configuration:
 Screen resolution config (1280 x 1024 dual screen)
 Keyboard layout (Dutch-Belgium)
 Autolaunch of IE web browser to URL
https://storefront.CONTOSO.be/Citrix/Internalweb for Windows embedded Igel thin
clients
 Appliance mode for Igel Linux thin clients. Appliance mode has been configured to
connect to Citrix storefront site https://storefront.CONTOSO.be/Citrix/Internalweb
 Local printer configuration (HP4350) for certain Igel linux thin clients
Deployment (firmware)+ configuration (profiles) will always be done in a fully automated

fashion via Igel UMS.

18 of
-
3.1.3.3 Citrix Receiver Deployment

In the current environment, Citrix Receiver for Web is used. When connecting to the Citrix
Web Interface website from an external location using Netscaler Gateway, the web interface
will perform client detection to detect the installed Citrix Receiver version.
3.1.3.3.1 Connecting from internal network

When connected to the Web Interface site internally, the client detection mechanism is
turned off as the Citrix Receiver is already installed on the thin clients and is managed by IT
on internal company owned fat clients.
3.1.3.3.1.1 Igel thin clients

The Igel thin clients have Citrix Receiver for Web embedded in their firmware. The latest
publicly available Igel firmware versions will be used that contain the following Citrix
receiver versions:
 For Linux thin clients this will be Citrix receiver version 12.1.8.250715 (included in Igel LX
firmware version 4.14.100).
 For Windows 7 Embedded thin clients this will be Citrix receiver version 4.2
(14.2.100.14) (included in Igel W7 firmware version 3.10.120).
3.1.3.3.1.2 Managed Windows fat clients

As auto-detection and installation has been turned off for Windows fat clients connecting
from internal locations (as we want to fully manage Citrix receiver installation by ourselves)
another managed way of Citrix receiver distribution will be used to get the Citrix receiver
software installed on managed Windows fat clients.
This can be done in 2 ways:
 Add AD computer object of the managed Windows fat client to AD security group
“SGL_GPO_CONTOSO_FATCLIENTS_COMPUTER_INSTALL_CITRIX_RECEIVER”. The
Correct Citrix Receiver software will be installed during startup of the managed Windows
fat client when it is connecting from an internal location.
Note: As Citrix receiver software will be installed during startup, it can take some time
before the CTRL+ALT+DEL logon screen appears.
 Distribute Citrix Receiver software via Kaspersky network agent: Within Kaspersky
Security Center choose to “Install application” “INSTALL_CITRIX_RECEIVER_4_3” on the
computer object within the Kaspersky Security center console.
3.1.3.3.1.3 Unmanaged Windows fat clients

Unmanaged Windows fat clients will use the existing installed Citrix receiver software that is
already present on the computer.
If there is no Citrix receiver software available on the unmanaged Windows fat client, than
this software can be downloaded and installed via URL http://receiver.citrix.com
3.1.3.3.1.4 Unmanaged Mac fat clients

Unmanaged Mac fat clients will use the existing installed Citrix receiver software that is
already present on the computer.
If there is no Citrix receiver software available on the unmanaged Mac fat client, than this
software can be downloaded and installed via URL http://receiver.citrix.com

19 of
-
Note: Mac fat clients are not officially supported within the CONTOSO environment, services
will be delivered best effort.
3.1.3.3.2 Connecting from external network

3.1.3.3.2.1 Managed Windows fat client
Managed Windows fat clients should already have the correct Citrix receiver on board by
executing the installation procedure explained in paragraph 3.1.3.3.1.2 of this document.
However, if the correct Citrix receiver (Citrix receiver version 4.3.0 or newer) is not installed
on the managed Windows fat client and the user is connecting from an external location
with his managed Windows fat client, the auto-detection and installation functionality of the
Citrix storefront web portal will kick in. this means that the correct Citrix receiver can be
installed on a managed Windows fat client via the auto-detection & installation procedure of
Citrix storefront when connecting from external location. There is a user manual available
that explains these installation steps.
3.1.3.3.2.2 Unmanaged Windows fat client

If the correct Citrix receiver (Citrix receiver version 4.3.0 or newer) is not installed on the
unmanaged Windows fat client and the user is connecting from an external location with his
unmanaged Windows fat client, the auto-detection and installation functionality of the Citrix
storefront web portal will kick in. this means that the correct Citrix receiver can be installed
on a unmanaged Windows fat client via the auto-detection & installation procedure of Citrix
storefront when connecting from external location. There is a user manual available that
explains these installation steps.
3.1.3.3.2.3 Unmanaged Mac fat client

If the correct Citrix receiver (Citrix receiver version 4.3.0 or newer) is not installed on the
unmanaged Mac fat client and the user is connecting from an external location with his
unmanaged Mac fat client, the auto-detection and installation functionality of the Citrix
storefront web portal will kick in. this means that the correct Citrix receiver can be installed
on a unmanaged Mac fat client via the auto-detection & installation procedure of Citrix
storefront when connecting from external location.
Note: Mac fat clients are not officially supported within the CONTOSO environment, services
will be delivered best effort.
3.1.3.4 Citrix Receiver Configuration

As the Receiver for Web will be used, no specific configuration is required at client-side.

20 of
-
4 Access Layer
The Access Layer is responsible for making the resources available to end-users.
Users will utilize the access layer in order to connect to their resources based. Based on the
location, connectivity and security requirements the access layer defines how users should
authenticate and connect to their virtual desktop or applications.
Decision Point Decision Justification

Internal Access
Internal Access  Citrix StoreFront 2.6 Citrix StoreFront is the successor
method  Receiver for Web only of Citrix Web Interface and
should be used whenever
possible.
Number of 2 (vsfcon-1200 and vsfcon- Redundancy on component level
Storefront 1201) as this is a crucial component.
servers
Store Names  DEFAULT_STORE One internal storefront store will
be used as this should be
sufficient for this environment
Receiver for  INTERNALWEB One Receiver for web website will
Web be created to service all client
devices connecting from internal
locations
Delivery  vddcon-  2 delivery controllers will be
Section: Access www.ACME.

21 of
-
Controllers 1202.CONTOSO.be, used for redundancy puposes

https,443  https will be used as this is
 vddcon- citrix recommendation
1203.CONTOSO.be,
https,443
Remote Access None No remote access required for
internal store
Internal Access Hypervisor HA A combination of the Hypervisor
High + HA functionality and load
Availability Netscaler Load Balancing balancing functionality of Citrix
Netscaler will be used to provide
adequate HA on this component.
StoreFront https://storefront.CONTOSO.b Agreed naming convention
Base URL e
Storefront  https://storefront.CONTOS A dedicated Receiver for web site
Receiver for O.be/citrix/INTERNALWEB will be used for internal access.
Web URLs (will be the default
webpage for
https://storefront.CONTOS
O.be and
https://access.CONTOSO.b
e)
StoreFront HTTPS HTTPS is recommended by Citrix
Protocol
Certificate Wildcard certificate Adequate certificate is required

*.CONTOSO.be will be used to use HTTPS/SSL on Netscaler
from GlobalSign CA. gateway.
Authentication  User Name and password One uniformal way of
 Trusted + default domain: authentication: device and
CONTOSO.BE location independent.
 Allow users to change
password: when expired
Deploy Citrix No Auto-deployment will be disabled
Receiver? for internal store as Citrix
receiver installation will be
managed by ICT CONTOSO.
Internal Access https://access.CONTOSO.be The same URL will be used for
URL internal and external access. This
eases access to the environment
for the end users.

22 of
-
External Access
External Access Netscaler VPX 200 Netscaler Gateway is preferred
method way to enable secure remote
access to Citrix Xenapp
environment.
Netscaler 11.0 build 62.10 Latest stable version available
Version
Netscaler Enterprise edition Customer choice. Enterprise
edition edition gives ability to enable
AAA feature which is very useful
in combination with reverse
proxy functionality.
Netscaler Two-arm topology Recommended topology by Citrix
network and ACME
topology
Number of 2 (vnscon-1212 and vnscon- Redundancy on component level
Netscaler 1213) as this is a crucial component.
appliances
Number of 2 (vsfcon-1200 and vsfcon- Redundancy on component level
Storefront 1201) as this is a crucial component.
servers
Store Name DEFAULT_STORE Same DEFAULT STORE can be
used
Storefront  https://storefront.CONTOS A dedicated Receiver for web site
Receiver for O.be/citrix/EXTERNALWEB will be used for external access.
Web URLs
Delivery  vddcon-1202, https,443  2 delivery controllers will be
Controllers  vddcon-1203, https,443 used for redundancy puposes
 https will be used as this is
citrix recommendation
Remote Access  No VPN tunnel  VPN tunnel is not required for
 1 Netscaler gateway ICA proxy functionality
appliance  At least 1 Netscaler gateway
 STAs: need to be added if Remote
 https://vddcon- access is required
1202.CONTOSO.be  2 STAs need to be provided
 https://vddcon- for redundancy
1203.CONTOSO.be
Authentication  Pass-through from This authentication method is
Netscaler Gateway required when working with

23 of
-
 Trusted + default domain: Netscaler Gateway

CONTOSO.BE
Deploy Citrix Yes Auto-deployment will be enabled
Receiver? for external store to ease
distribution of Citrix receiver
software to personally owned
laptops and desktops
Certificate Wildcard certificate Adequate certificate is required
*.CONTOSO.be will be used to use HTTPS/SSL on Netscaler
from GlobalSign CA. gateway.
External Access Hypervisor HA A combination of the Hypervisor
High + HA functionality and Netscaler
Availability failover
Netscaler failover
External Access https://access.CONTOSO.be The same URL will be used for
URL internal and external access. This
eases access to the environment
for the end users.
2-factor No No 2-factor authentication is
authentication? required by customer
4.1.3 Design
4.1.3.1 Access Strategy
Desktops and Applications published by Citrix XenDesktop and XenApp need to be accessed
by users. Users can access the published resources using different methods.
Citrix Web Interface

Citrix Web Interface is the legacy component used for connecting to a Citrix Environment.
Web Interface is based on IIS and Java and is a frontend web site that can be configured to
provide access to resources from multiple Citrix XenApp or XenDesktop farms. Citrix Web
Interface supports normal web sites that users can view in a web browser and XML based
Services web sites. These services sites are used for connecting using the now legacy Citrix
PNAgent.
Citrix Web Interface development is discontinued but is still a supported access method for
use with Citrix XenDesktop 7.6.
Citrix StoreFront
Citrix StoreFront is the successor of Citrix Web Interface and has the same goal as to provide
users with access to their applications. Citrix Storefront uses subscriptions: users can add
their personal favorite application if configured, and are always presented with their
personal list of applications on each client device with a Citrix Receiver for Storefront.

24 of
-
Citrix Netscaler Gateway

Citrix Netscaler Gateway is the successor of Access Gateway and Secure Gateway. Netscaler
Gateway is a Citrix Netscaler appliance with the functionality to tunnel ICA traffic in a secure
SSL connection to the client. In order to secure Citrix traffic to external devices, Netscaler
Gateway must be used.
The Netscaler Gateway is typically deployed in a DMZ and secures all outside traffic with SSL.
Internally, the Netscaler Gateway still connects to an existing Citrix Web Interface or Citrix
StoreFront deployment to display resources to the users.
4.1.3.2 Internal Access

4.1.3.2.1 Diagram
4.1.3.2.2 Access Method

Citrix StoreFront will be used as the internal access method. Citrix StoreFront is future-ready
and supports all required functionality for CONTOSO.
StoreFront VM Specifications:
Name IP Address # vCPU RAM Disk

25 of
-
Vsfcon-1200 192.168.1.200 1 4 GB 60 GB
Vsfcon-1201 192.168.1.201 1 4 GB 60 GB
4.1.3.2.3 Authentication
Authentication is performed on the StoreFront servers. Users will access the StoreFront web
site by logging on with their user name password.
4.1.3.2.4 StoreFront Configuration

Citrix StoreFront will be configured with one store. This store is connecting to the two
delivery controllers from the XenApp 7.6 environment.
A Citrix StoreFront Store determines the XenApp and or XenDesktop environments that can
be accessed. A “Receiver for web” website is a web based front-end for a specific store.
Multiple StoreFront Web sites can be created that provide access to the same or different
Stores.
The following StoreFront web sites will be created for internal web access:
URL Store Description
/Citrix/INTERNALWEB DEFAULT_STORE Default website used by
(default) internal browsers and thin
clients. Citrix Receiver auto-
detection & deployment will
be disabled.
Receiver auto detect and deployment will be disabled on this “Receiver for Web” website as
Citrix receiver software will be deployed and managed in a controlled way on corporate
owned fat clients and thin clients that connect from internal locations.
4.1.3.2.5 High Availability

In order to provide for high availability, 2 Citrix StoreFront servers will be setup. Each
Storefront server will be hosted on a different Xenserver host to ensure 99,999% availability.
The two StoreFront servers will be load balanced using the existing Citrix Netscaler load
balancer.
Citrix StoreFront does not use a central database. The storefront configuration is replicated
using a built-in StoreFront specific mechanism.
The internal load balanced StoreFront URL will be: https://storefront.CONTOSO.be and
https://access.CONTOSO.be. Two DNS A records, access.CONTOSO.be and
storefront.CONTOSO.be will be created within CONTOSO.BE DNS zone that will point to IP
address 192.168.1.217 to redirect https://access.CONTOSO.be to
https://storefront.CONTOSO.be to the LB ipaddress of the Citrix Storefront servers when
end users are connecting from internal locations.

26 of
-
4.1.3.3 External Access

4.1.3.3.1 Diagram
4.1.3.3.2 Access Method

CONTOSO will use Citrix Netscaler appliances to enable remote secure access. Netscaler
Gateway is securing external traffic using an SSL certificate. A wildcard certificate,
*.CONTOSO.be, will be provided and used. The Netscaler Gateway will connect the users to
the internal load balanced StoreFront URL.
Citrix Netscaler appliances specifications:

Vnscon-1211 192.168.1.211 2 2 GB 20 GB
Vnscon-1212 192.168.1.212 2 2 GB 20 GB
4.1.3.3.3 Authentication
For external users, authentication is performed on the Netscaler Gateway appliance. The NS
Gateway appliance validates user credentials using an LDAP connection to Active Directory.
To avoid unencrypted LDAP traffic from the DMZ into the trusted LAN, the LDAP traffic will
be encrypted using SSL to the domain controllers over port 636 (LDAPS). The Netscaler will
load balance all Secure-LDAP traffic between the domain controllers 192.168.1.1 and
192.168.1.3 to provide high availability and failover of the LDAP traffic. Only after successful

27 of
-
authentication on the Netscaler, a backend connection to one of the StoreFront servers is

initiated.
The Netscaler gateway works together with Citrix storefront. The default store will be used,
however a separate “Receiver for web” website will be used, EXTERNALWEB, that works
together with the Netscaler Gateway. “Pass-Through from NS Gateway” will be enabled as
authentication for external users is performed on the Netscaler Gateway and credentials are
then forwarded automatically to Citrix StoreFront.
4.1.3.3.4 StoreFront Configuration

The “DEFAULT_STORE” Citrix StoreFront store will be re-used, however a separate “Receiver
for Web” website will be used: EXTERNALWEB.
The following StoreFront web sites will be created for external web access:
URL Store Description
/Citrix/EXTERNALWEB DEFAULT_STORE Web site used by external
clients connecting via the
Netscaler Gateway. This web
site will be configured for
auto-detect & deployment of
Citrix Receiver.
Receiver auto detect and deployment will be enabled on this “Receiver for Web” website to
make sure that correct Citrix receiver software will be deployed and installed on non-
corporate client devices that are connecting from remote locations.
Some advanced “out-of-the-box” Storefront configuration has been done:

 Customization of the Look’n’feel according to Citrix blog post
https://www.citrix.com/blogs/2014/10/14/customizing-receiver-for-web-2-6/
 Customization when connecting with Chrome web browser:
https://www.citrix.com/blogs/2015/03/09/preparing-for-npapi-being-disabled-by-
google-chrome/
 Customization of client name (to distinct users connecting from internal or external
location): https://www.citrix.com/blogs/2015/07/01/rewriting-the-session-
clientname-from-storefront/
 Enabling Citrix receiver distribution via Storefront web site:
http://www.carlstalhood.com/storefront-basic-configuration/#receivers and
http://docs.citrix.com/en-us/storefront/2-6/dws-manage/dws-configure-wr-conf-
file/dws-configure-wr-receiver.html
 Customization of default.ica file to disable hot keys:
http://support.citrix.com/article/CTX140219
 Auto-redirect at session time out to Storefront logon page:
http://www.czerno.com/blog/post/2014/10/03/redirect-citrix-storefront-to-a-
different-page-at-log-off

28 of
-
4.1.3.3.5 Netscaler Gateway configuration

A Netscaler Gateway virtual server will be configured on IP address 192.168.1.247. The
firewall will be configured to forward all external https://access.CONTOSO.be traffic to this
IP Address. The NS Gateway Virtual Server will be configured with the *.CONTOSO.be
wildcard certificate.
4.1.3.3.5.1 Authorization
The Netscaler Gateway first performs authentication (via secure LDAP) and afterwards
authorization. Authorization determines where a succesfully logged on user has access to. In
this setup authorization is used to define an AD Group that controls the users who are
allowed to access the Netscaler gateway.
The NS Gateway is configured with a default authorization action of DENY.
An AAA Group is added with the name SGU_XA_CAG-USERS and this group has an
authorization policy bound that ALLOWs authorization.
4.1.3.3.5.2 Session Policies

For a NS Gateway Virtual Server, session policies are used to control the functionality of the
NS Gateway, including the backend web interface / storefront servers to connect to, the
type of client plugin’s used, the clientless VPN functionality etc..
For CONTOSO, there will be two session policies defined linked to a specific session profile.
The different profiles are required to differentiate between a web receiver (user’s browsing
to the access.CONTOSO.be website) and a native receiver (Citrix Receiver installed on the
end user’s workstation). The different policies are applied based on the User-Agent string
from the endpoint.
4.1.3.3.6 High Availability

Two Netscaler appliances will be deployed to have required active-passive full redundancy
on this component. Next to this Netscaler failover setup, the underlying Xenserver
hypervisor will take care of an additional layer of high availability on this component. With
Netscaler High Availability, the two Netscaler appliances are configured as a Primary and
Secondary node. All configuration changes must be performed on the primary node and are
then synchronised automatically to the secondary appliance. It is the primary appliance that
owns and responds to the virtual IP addresses used by the virtual servers and the SNIP
addresses used for backend connections. In case the primary appliance fails, these IP
addresses will failover instantly to the secondary appliance.
Note: for more detailed information about the installation and configuration of Citrix
Netscaler infrastructure, please read document “CONTOSO - Netscaler Implementation
Document - v1.0.docx”.

29 of
-
5 Resource Layer
5.1 Layer Overview
The resource layer of a solution focuses on personalization, applications, and image design.
The resource layer is where users will interact with desktops and applications and is most
visible to the end users. The user requirements obtained during the Assess phase and
refined during the user layer design phase are used as the basis for the desktop design
recommendations.
5.2 Key Design Decisions
Decision Decision Justification

Point
XenApp
XenApp Citrix Xenapp 7.6 Platinum edition Latest XenApp version
Version available.
Customer has platinum
edition licenses.
FlexCast Delivery Model
Flexcast  Hosted Shared Desktop Customer requirement to
Model  Optionally: Apps offer Hosted Shared Desktop
(aka published desktop).
Optionally, apps (published
applications) can be offered
but this is initially not
planned.
Section: Resource www.ACME.

30 of
-
Xenapp Citrix Provisioning Services (PVS) Citrix PVS is an enterprise

server level provisioning
deployment technology and can utilize
strategy Cache to RAM technology to
create a high performing
experience.
Image Build
Number of  Only 1 silo type will be It is important to keep the
silo’s implemented that contains all environment KISS. This
the required applications means keeping the amount
 A silo will be created for each of silo’s to a minimum. It is
DTAP environment: recommended to have all
o XA_W2012R2_DESKTOPS apps within 1 silo.
_APPS-PRODUCTION
o XA_W2012R2_DESKTOPS
_APPS-ACCEPTANCE
_APPS-TEST
_APPS-DEVELOPMENT
Number of  XA_W2012R2_DESKTOPS_APPS- A separate vDisk is used for
different PRODUCTION_Vx.x each (D)TAP environment to
images  XA_W2012R2_DESKTOPS_APPS- enable proper change &
ACCEPTANCE_Vx.x release management
 XA_W2012R2_DESKTOPS_APPS-
TEST_Vx.x
 XA_W2012R2_DESKTOPS_APPS-
DEVELOPMENT_Vx.x
Base Windows Server 2012 R2 standard Mainstream support for
Operating edition 2008 R2 already ended and
System Server 2012 R2 is currently
the latest platform.
OS language French and Dutch OS language Customer preference
packs packs will be installed
User Environment Management
User Profile Citrix User Profile Management Free build-in User profile
Management management from Citrix.
Delivers a stable and fast
user profile without
additional costs.
User home  Each user has a home drive that Customer preference

31 of
-
drive is configured on AD account

level
 Drive letter is H:
User  AD Group Policy Policies Recommended user
Environment  AD Group Policy Preferences environment configuration
configuration  VBS logon and logoff scripts methods that are already
available at no additional
cost.
Folder Following user shell folders will be Folder redirection is
Redirection redirected: required to keep user data
 Favorites outside of the user profile.
 Desktop And ensure stable and fast
 Downloads user logons.
 Documents
 Appdata (Roaming)
 Pictures
 Music
 Videos
 Links
 Start menu
Citrix Policies  The new Citrix policies will be In order to avoid confusion
based on the current Citrix with multiple policy
policies locations policies will only
 Citrix Policies will be configured be configured using GPMC in
via AD Group Policy Active Directory. There is no
Management. difference in the available
policies or filters when using
Citrix Studio or AD GPO’s.
AD USER 12 GPO’s will be configured for It is important to have good
GPO’s each DTAP environment: balance between having
 SGL_GPO_CONTOSO_XA_<dtap sufficient and not too much
>_USER_DEFAULT_USERS_CON AD GPO’s.
FIG Having 8 AD GPO’s for each
 SGL_GPO_CONTOSO_XA_<dtap DTAP environment should
>_ be sufficient and enables
_USER_DEFAULT_ADMINS_CON having proper change &
FIG release management in
 SGL_GPO_CONTOSO_XA_<dtap place
>_USER_IE
 SGL_GPO_CONTOSO_XA_<dtap
>_USER_OFFICE_2010

32 of
-
>_USER_CITRIX_POLICIES
>_USER_DUTCH_UI
>_USER_FRENCH_UI
 SGL_GPO_CONTOSO_<dtap>_X
P_USER_VISUALLY_IMPAIRED_
USERS_CONFIG
VBS Each DTAP environment will have User Logon & logoff scripts
logon/logoff its own user logon and logoff will contain user
scripts scripts: environment configuration
 Logon: actions that need to be
 ADMINS: executed during log on or
\\CONTOSO\netlogon\Citrix log off (mainly general user
\<DTAPenv>\adminlogon.vb environment config +
s application config actions)
 USERS:
\\CONTOSO\netlogon\Citrix
\<DTAPenv>\\userlogon.vbs
 Logoff:
 ADMINS:
\<DTAPenv>\\adminlogoff.v
bs
 USERS:
\<DTAPenv>\\userlogoff.vbs
Start Menu  Shortcuts of locally installed Easiest and most flexible and
shortcuts apps as well as App-V apps will consistent way to present
be managed by ACME Taskflow application shortcuts within
framework. desktop.
 AD Security groups will be used
to make sure that end users
only see the required app
shortcuts.
 End users are not allwed to add
shortcuts to start menu
Desktop  Shortcuts of locally installed Easiest and most flexible
Shortcuts apps as well as App-V apps will way to present application
be managed by ACME Taskflow shortcuts within desktop.
framework..

33 of
-
only see the required app

shortcuts.
 End users are only allowed add
shortcuts to their desktop.
Start  Shortcuts (tiles) on start page Easiest and most flexible
shortcuts will be managed via GPO way to present application
SGL_GPO_CONTOSO_XA_<dtap shortcuts within start page.
>_USER_DEFAULT_USERS_CON
FIG
Published  Initially, no published
applications applications will be used, only
desktops.
only see the required published
applications.
 Each DTAP environment will
have its own published
applications to enable proper
change & release management.
Computer Environment Management
Server  AD GPO A combination of AD GPO’s
Configuratio  ACME Taskflow Framework and ACME Taskflow
n framework is most efficient
and manageable.
Server Golden master image will be built The initial Server 2012 R2
Deployment by using: image will be built by having
 Clean VM with Windows server clean VM and manual install
2012 R2 OS manually installed via ISO image. Further
via ISO image configuration will be done
 ACME Taskflow framework by using ACME Taskflow
framework.
Golden image build will be Real life experiences teaches
deployed to Citrix Xenapp servers that this is the best and
by using Citrix PVS. most optimal build method.
Security &  AD GPO AD GPO’s will be used to

Lockdown  MS AppLocker limit the motion space of the
 Kaspersky Antivirus 8.0 end users.
enterprise edition AppLocker policies and
Kaspersky AV will be used to
further lock down and

34 of
-
secure the Citrix Xenapp

environment.
AD GPO’s  SGL_GPO_CONTOSO_XA_<dtap It is important to have good
>_COMPUTER_IE balance between having
 SGL_GPO_CONTOSO_XA_<dtap sufficient and not too much
>_COMPUTER_DEFAULT_SERVE AD GPO’s.
R_CONFIG Having 4 AD GPO’s for each
 SGL_GPO_CONTOSO_XA_<dtap DTAP environment should
>_COMPUTER_CITRIX_POLICIES be sufficient and enables
 SGL_GPO_CONTOSO_XA_<dtap having proper change &
>_COMPUTER_APPLOCKER release management in
place
DTAP DEVELOPMENT, TEST, ACCEPTANCE Having proper change &
strategy and PRODUCTION environments release management by
will be implemented. using a DEVELOPMENT,
TEST, ACCEPTANCE and
PRODUCTION environment.
Printing Environment Management
Printing  Mapped network print queues One network print queue
strategy  Auto-created default client must be available for all
printer mapping users, this is best done via
mapped network print
queue. All other print
queues are arranged by
using auto-created client
printer mappings.
Citrix Printer  Use Citrix Universal Driver if General best practice
Driver requested driver is not available
strategy
Printer  Vbs Logon script for network Only a few network print
Mapping print queues queues will be mapped,
 Citrix policy for auto-created Easiest way is using vbs
client printer mappings logon script.
For auto-created client
printer mappings Citrix
policies will be defined.
Print Driver ACME Taskflow framework Drivers are deployed as part
deployment of server deployment.
Application Environment Management
Application  Primary delivery method Easisest and most
 Local installed apps performant way is installing

35 of
-
Deployment application locally within the

 Secondary delivery method image. Only apps that have
 MS App-V conflicts and multiple
versions will be virtualized
by using MS App-V.
Application MS App-V 5.0 SP3 HF2 Licenses included within RDS
Virtualization CAL’s + market leader
regarding app virtualization
technology
Application  Application configuration on Most efficient way of
configuration machine level will be done via working
Taskflow for local installed
apps.
 Application configuration on
user level will be done via GPO
preferences and/or logon
scripts for local installed apps.
 App-V application configuration
will be done within the App-V
package
Application  Primary presentation method Users will use a published
presentation  Application shortcuts within desktop and app shortcuts in
Citrix desktop start menu + desktop will be
 Optionally: Secondary used to present apps to end
presentation method users.
 Published applications If required, published
applications can be
optionally defined for
certain use cases.
5.3 Design
5.3.1 XenApp version
For the new XenApp environment the latest XenApp 7.6 version platinum edition will be
used.
The XenApp components will be updated with the latest available public hotfixes.
5.3.2 Flexcast Delivery model

Flexcast is the new management architecture used by Citrix XenDesktop/XenApp. Flexcast
allows the use of several types of virtual desktop technologies by using a single integrated
management architecture and integrated tools.

36 of
-
Within Flexcast, several delivery technologies exist and can be combined. The following
delivery technologies are available. Each delivery technology has its own benefits if used for
the correct groups of users.
Server-Side Compute Client-Side compute
Hoste
- Shared - Personal - Runs locally - Secure - Mobile, online
- Best TCO Streame
d Services
- Terminal Hosted
- Desktop OS VDI - Boots from - SingleApps
Instance Local VM
or offline
- VMs or blades network d App management - Synchronisation
Share Services
VHD
The current XenApp environment is based on the Hosted Shared Desktop model and this is
still the best Flexcast model for this environment with the lowest CTO.
The user groups that have been defined can be mapped to the following Flexcast models:
User group Flexcast Model

Employees Hosted Shared Desktop
5.3.3 XenApp Image Design

5.3.3.1 Base operating system
All XenApp servers will be based on Windows server 2012 R2 as the operating system.
Mainstream support for Windows Server 2008 R2 already ended and Windows Server 2012
R2 is the latest available OS.
MS Windows Server 2012 R2 standard edition will be used as OS.
French and Dutch language packs will be installed.
5.3.3.2 XenApp Silos

All applications will be installed within the same silo, however each DTAP environment will
have its own silo.
User type Silo DTAP

environment
PRODUCTION XA_W2012R2_DESKTOPS_APPS_PRODUCTION PRODUCTION
employees
TEST employees XA_W2012R2_DESKTOPS_APPS_TEST TEST

37 of
-
ACCEPTANCE XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE ACCEPTANCE

employees
DEVELOPMENT XA_W2012R2_DESKTOPS_DEVELOPMENT DEVELOPMENT
employees
5.3.3.3 XenApp Server Provisioning

XenApp servers can be provisioned in several ways:
- Standalone servers installed in an automated way: Each server is a typical VM or
physical server that is deployed using an automated deployment tool or an
installation script.
- Citrix Provisioning Services: XenApp servers have a virtual hard drive that is
streamed from Citrix Provisioning Services. All the write actions are redirected to a
write cache. Citrix PVS is an enterprise-grade provisioning method where it becomes
easy to provision many XenApp servers based on the same disk.
- Citrix Machine Creation Services: XenApp servers have a virtual hard drive that is
based on a master disk located on the same storage LUN. The master disk is read by
all servers and all the writes are redirected to a difference disk specific for each
server. Citrix MCS is an easy to use method to provision XenApp servers but comes
with an impact to the underlying storage: all reads are performed on the same
virtual disk and the underlying shared storage solution must be able to handle all the
load.
Citrix Provisioning Services will be used to provision the new XenApp servers. Using PVS will
also guarantee all XenApp servers are exactly the same. The write cache will be located in
RAM with overflow to disk. This ensures optimal performance of the XenApp servers even
though they are streamed from the same base vDisk. The read actions are cached in RAM
by the XenApp server and the PVS server. The write actions are cached in RAM by the PVS
Cache To Ram mechanism on each XenApp server.

38 of
-
5.3.3.4 vDisks
A separate vDisk will be used for each silo.
Additionally a separate vDisk will be used for the different DTAP environments of the
CONTOSO silo. Separate vDisks for each environment ensure changes can be tested
completely independent from the production vDisk.
This results in the following vDisks:

DTAP PVS Vdisk name
PRODUCTION XA_W2012R2_DESKTOPS_APPS_PRODUCTION_Vx.x
ACCEPTANCE XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_Vx.x
TEST XA_W2012R2_DESKTOPS_APPS_TEST_Vx.x
DEVELOPMENT XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_Vx.x
Each Xenapp server is sized for a disk capacity of around 60 GB. To include a safety margin
the vDisks will be created with a size of 80GB. The vDisks used will be Dynamic vDisks where
the size on disk is the same as the actual contents of the vDisk. The vDisk files will not be
pre-allocated.
5.3.4 XenApp Sizing

5.3.4.1 PRODUCTION Xenapp workload
A current best practice when virtualizing Citrix XenApp servers with Citrix PVS with cache
type “Cache to device RAM with overflow on hard disk” is to size each VM to 4 vCPUs and 25
GB RAM. Each XenApp VM with these specifications should be able to handle at least 10-25
concurrent user sessions depending on the workload and applications.
Assuming each VM supports 15 users, a total of 12 production XenApp VM’s will be required
to support the current number of concurrent users. We will add 2 production Xenapp VM’s
to have some margin when certain Xenapp VM’s are not available for some reason.
The XenApp virtual machines will be distributed across 2 Xenserver hosts based on the
following best practices and guidelines:
- No physical host CPU over commitment: the total amount of vCPUs of the running
VM’s on each host should not exceed the number of logical cores.
- No physical host memory over commitment: the total amount of RAM assigned to
all VM’s on one host should not exceed the amount of physical memory in the host.
- On each host at least 16 GB RAM is reserved for the hypervisor itself.
- Physical servers are dedicated for a XenApp workload only. No other VM’s such as
SQL servers or XenApp controllers will be located on the same hosts.

39 of
-
The following diagram will show the distribution of the XenApp Servers across the different
physical hosts:
The production XenApp servers are located on 2 physical hosts. Each physical host contains
7 virtual production XenApp servers. Each virtual XenApp server has the following
specifications:
Specification Virtual XenApp server
# vCPU 4
RAM 25 GB (17 GB RAM + 8 GB PVS RAM Cache)
Local Disk 10 GB
This results in 14 XenApp servers for the main production silo.

For each physical host this totals 28 vCPUs and 179GB RAM, leaving 4 vCPUs and 17GB ram
for the hypervisor itself.
The DEVELOPMENT Xenapp server will be located on Xenserver host SXSCON-1019. The
DEVELOPMENT Xenapp server will share system resources with other types of VM’s on this
Xenserver host.
The TEST Xenapp server will be located on Xenserver host SXSCON-1021. The TEST Xenapp
server will share system resources with other types of VM’s on this Xenserver host.
The ACCEPTANCE Xenapp server will be located on Xenserver host SXSCON-1022. The
ACCEPTANCE Xenapp server will share system resources with other types of VM’s on this
Xenserver host.
5.3.4.2 ACCEPTANCE Xenapp workload

The ACCEPTANCE Xenapp server will have the following specs:
# vCPU 4

40 of
-
Local Disk 10 GB
5.3.4.3 TEST Xenapp workload

The TEST Xenapp server will have the following specs:
# vCPU 4
Local Disk 10 GB
5.3.4.4 DEVELOPMENT Xenapp workload

The DEVELOPMENT Xenapp server will have the following specs:
# vCPU 4
Local Disk 10 GB
5.3.5 User Profile Management

In order to maintain and control the user environment it is important to have a clear user
profile strategy in place.
In Windows, different profile types exist:
 A local profile only exists on an individual machine. As a result the user will have a
different profile on each server and settings are not roamed between different servers.
 A roaming profile is stored on a central file server for each user. When the user logs on
to a machine, the profile is copied from the file server to the local machine. During
logoff, the profile including any changes is copied back to the file server. Once logged
on, the profile behaves as is it is a local user profile. As a result, the user settings will
roam to different machines. There is a problem however, when the user is logged on to
multiple servers at the same time, in which case the last write wins or the profile can
become corrupted.
 A mandatory profile is a roaming profile that is not synced back to the file server. All the
changes are lost when the user logs off. This is used in situations where profile changes
do not need to be retained and the user must always log on with a clean profile. The
benefits of a mandatory profile are faster logon and logoff times because no changes
need to be saved.
 A hybrid profile tries to combine the benefits of a mandatory profile and a roaming
profile. It is in fact the combination of a robust mandatory profile and additional
technology to capture only the required profile settings that need to roam. Multiple
flavors exist of hybrid profiles : The combination of a mandatory profile with folder

41 of
-
redirection or more advanced 3rd party profile solutions such as AppSense Environment
Manager.
For the new XenApp environment at CONTOSO, a hybrid profile solution based on Citrix User
Profile Management is chosen as the user profile solution.
A template profile will be used to supply a properly configured user profile to end users who
connect to the Xenapp environment for the first time. The template profile will be located
on the central file server:
\\Vfscon-1208\userconfig$\template
The Citrix profiles will be stored on the new Windows server 2012 R2 File server:
\\vfscon-1208\USERCONFIG$\UPM\%USERNAME%\
(-> e:\USERCONFIG\UPM\%USERNAME% on File server itself)
The Citrix Profile management configuration will be done via AD GPO:

Development environment
 SGL_GPO_CONTOSO_XA_XD_COMPUTER_CITRIX_POLICIES
Test environment
 SGL_GPO_CONTOSO_XA_XT_COMPUTER_CITRIX_POLICIES
Acceptance environment
 SGL_GPO_CONTOSO_XA_XA_COMPUTER_CITRIX_POLICIES
Production environment
 SGL_GPO_CONTOSO_XA_XP_COMPUTER_CITRIX_POLICIES
5.3.6 User Home folder

No changes will be introduced regarding user home folder.
The home folder location is configured within the AD account and is pointing to:
\\vfscon-1004\home\%username%
The Home drive letter is H:
5.3.7 Folder Redirection

By default, a windows user profile also contains user data (For example the ‘My Documents’
folder). Because this data can potentially get quite big, it is not recommended to store user
data inside the user profile. In order to keep user data outside of the user profile, folder
redirection must be used to redirect the user’s special folders such as My documents, My
Pictures,.. to a network share.

42 of
-
The following folders will be redirected:

Folder Target
Documents %HOMESHARE%%HOMEPATH%
Pictures \\vfscon-1004\Home\%USERNAME%\Pictures
Music \\vfscon-1004\Home\%USERNAME%\Music
Videos \\vfscon-1004\Home\%USERNAME%\Videos
Downloads \\vfscon-1004\Home\%USERNAME%\Downloads
Links \\vfscon-1208\userconfig$\FOLDER_REDIRECTION\LINKS\%username%
Favorites \\vfscon-1208\userconfig$\FOLDER_REDIRECTION\FAVORITES\%username%
Desktop \\vfscon-1208\userconfig$\FOLDER_REDIRECTION\DESKTOP\%username%
Appdata \\vfscon-1208\userconfig$\FOLDER_REDIRECTION\APPDATA\%username%
(Roaming)
Start menu Redirect to local user profile path
The documents folder will be redirected to the existing location because it contains
documents. This is to ensure all documents are accessed from one place when users are still
testing the new XenApp environment. The documents folder will be assigned the H: drive
letter and named “Personal data”. Not changing the My Documents redirection means there
is no impact for users accessing their documents when they access both the current XenApp
environment and the new XenApp environment during a period of user testing. If required,
the documents shares can be moved to a new file server after the new XenApp
implementation.
The Pictures, Music, Videos and downloads folder will also be redirect to the user home
drive, like it is already the case within the current Citrix Xenapp environment.
Folders that are containing just hyperlinks, such as the Favorites and Links folders are
redirected to a new location on the new file server. A one-time import will be done from
the existing Favorites to the new location when the user first logs on to the new
environment.
The Appdata (roaming) folder will be redirected to the new file server.
The desktop folder will be redirected to the new file server and it is only allowed to save
shortcuts on the desktop. This will be forced by using the file screening feature on the new
File server.
The Start menu folder will still be located within the user profile and thus will not roam.

43 of
-
IMPORTANT!: THE USERS WILL RECEIVE A DESKTOP WITH ONLY THEIR EXISTING DESKTOP SHORTCUTS
(THUS E.G. NO OFFICE 2010 OR PDF DOCS WILL BE AVAILABLE ON THE USER’S DESKTOP) WHEN THEY
LOG ON TO THE NEW XENAPP ENVIRONMENT FOR THE FIRST TIME (DESKTOP SHORTCUTS WILL BE
MIGRATED FROM THE OLD CITRIX XENAPP ENVIRONMENT TO THE NEW CITRIX XENAPP ENVIRONMENT).
IT MUST BE COMMUNICATED TO END USERS THAT ONLY SHORTCUTS ARE ALLOWED ON THE DESKTOP.
5.3.8 Citrix Policies

Citrix XenApp policies are used to configure Citrix settings in the user session based on
conditions such as AD user groups or Citrix Specific conditions such as the connection
method.
Citrix policies can be used to configure the following settings:
- Graphics settings for the ICA protocol
- Access to client devices such as client drives, audio, microphone...
- Clipboard Access
- …
With XenApp 7.6, administrators have the option to configure Citrix policies via Citrix Studio
or using Active Directory group policies using Citrix ADMX files that extend group policy and
provide advanced filtering mechanisms. Using AD group policy allows organizations to
manage both Windows policies and Citrix policies in the same location and minimizes the
administrative tools required for policy managed. Citrix Studio console can be used if Citrix
administrators do not have access to AD policies. In order to avoid confusion with multiple
Citrix policy locations it is recommended the AD policies are chosen and used consistently.
The following Citrix policies will be created (similar to the current Citrix Policies):
 Unfiltered Computer Configuration policy: this CTX policy contains baseline computer
Citrix policy settings that will be applied to all Citrix Xenapp servers.
 Unfiltered User Configuration Policy: this CTX policy contains baseline user Citrix policy
settings that will be applied to all users.
 OPTICAL_REMOVABLE_CLIENT_DRIVE_MAPPING_ALLOWED (filtered on AD security
group): this CTX policy will allow client CD-Rom and USB storage drive mappings for
users that are member of AD security group
“SGU_XA_CTX_OPTICAL_REMOVABLE_CLIENT_DRIVE_MAPPING_ALLOWED”.
 ALL_CLIENT_DRIVE_MAPPING_ALLOWED (filtered on AD security group): this CTX
policy will allow all client drive mappings for users that are member of AD security group
“SGU_XA_CTX_ALL_CLIENT_DRIVE_MAPPING_ALLOWED”.
 DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (NOT DEFAULT) (filtered on AD
security group): this CTX policy will map the default client printer but will not make it
the default printer within the Citrix session for users that are member of AD security
group “SGU_XA_CTX_DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (NOT
DEFAULT)”.
 DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (DEFAULT) filtered on AD security
group): this CTX policy will map the default client printer and will make it the default
printer within the Citrix session for users that are member of AD security group
“SGU_XA_CTX_DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (DEFAULT)”.
 DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED_VIA_NS (DEFAULT) (filtered on
Client name): this CTX policy will map the default client printer and will make it the
default printer within the Citrix session for users connecting with client name “E_*.

44 of
-
Users connecting from external locations (via Citrix Netscaler Gateway) will always get
client name (E_*). This means that users who are connecting from external locations will
always have their default client printer within their Citrix session.
5.3.9 User Environment Configuration

5.3.9.1 Group policy policies & policy preferences
Active Directory GPO’s with user configuration (group policy settings as well as group policy
preferences) will be used to configure the user environment. Each DTAP environment will
have its own GPOs:
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_ADMINS_CONFIG: this GPO
contains default user configuration for admin users who logon to a Citrix Xenapp server.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_USERS_CONFIG: this GPO
contains default user configuration for normal end users who logon to a Citrix Xenapp
server.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_CITRIX_POLICIES: this GPO contains Citrix
policies for normal end users who logon to a Citrix Xenapp server.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_IE: this GPO contains Internet Explorer user
configuration for normal end users who logon to a Citrix Xenapp.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_USERS_OFFICE2010: this GPO
contains Office 2010 user configuration for normal end users who logon to a Citrix
Xenapp. This GPO will apply only to AD security group “SGU_XA_GEN-XA-USERS”.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DUTCH_UI: this GPO contains Dutch
language user configuration for users who need to have Dutch language user interface.
This GPO will only be applied to users who are member of AD security group
“SGU_XA_LAN-DUTCH”.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_FRENCH_UI: this GPO contains Dutch
language user configuration for users who need to have Dutch language user interface.
This GPO will only be applied to users who are member of AD security group
“SGU_XA_LAN-FRENCH”.
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_VISUALLY_IMPAIRED_USERS_CONFIG : this
GPO contains user configuration to allow user that are visually impaired to change DPI
settings. This GPO will only be applied to users who are member of AD security group
“SGU_XA_GEN-XA-VISUALLY_IMPAIRED_USERS”.
Group policy loopback processing will be enabled to be able to assign GPO’s with user
configuration to the Citrix Xenapp AD computer objects. Group policy loopback processing
mode is set to “replace” this will ensure that GPO’s applied on user object level are ignored
for the Citrix Xenapp environment.
Also GPO inheritance is blocked on the Citrix root OU, this prevents that GPO’s applied at
higher OU level will also apply to the Citrix environment.
5.3.9.2 User logon & logoff scripts

5.3.9.2.1 Logon scripts
If required, vbs user logon scripts will be defined for the Citrix Xenapp servers.

45 of
-
The location of the logon script is:

Logon:
 ADMINS: \\CONTOSO\netlogon\Citrix\<DTAPenv>\adminlogon.vbs
 USERS: \\CONTOSO\netlogon\Citrix\<DTAPenv>\userlogon.vbs
The logon script can perform the following configuration actions:

 User environment configuration (user registry modifications + user file/folder
modification) that will always be executed when a user logs on.
 User environment configuration (user registry modifications + user file/folder
modification) that will only execute once, the first time an end user logs on.
 …
Execution of the logon script will be done via AD GPO:

 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_ADMINS_CONFIG
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_USERS_CONFIG
5.3.9.2.2 Logoff scripts

If required, vbs user logoff scripts will be defined for the Citrix Xenapp servers.
The location of the logoff script is:
 ADMINS: \\CONTOSO\netlogon\Citrix\<DTAPenv>\adminlogoff.vbs
 USERS: \\CONTOSO\netlogon\Citrix\<DTAPenv>\userlogoff.vbs
Execution of the logoff script will be done via AD GPO:

 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_ADMINS_CONFIG
 SGL_GPO_CONTOSO_XA_<DTAPenv>_USER_DEFAULT_USERS_CONFIG
5.3.9.3 Start Menu Shortcuts

5.3.9.3.1 Locally installed & App-V apps
The start menu will be created using Taskflow for applications that are installed into the
image. Application AD security group membership will determine if the application shortcut
will be shown in the user’s start menu or not.
5.3.9.4 Desktop Shortcuts

5.3.9.4.1 Locally installed & App-V apps
Desktop Shortcuts will be managed using Taskflow. The desktop will be redirected to the
new file server.
Only shortcuts will be allowed on the desktop.
IMPORTANT!: THE USERS WILL RECEIVE A DESKTOP WITH ONLY THEIR EXISTING DESKTOP SHORTCUTS
(THUS E.G. NO OFFICE 2010 OR PDF DOCS WILL BE AVAILABLE ON THE USER’S DESKTOP) WHEN THEY
LOG ON TO THE NEW XENAPP ENVIRONMENT FOR THE FIRST TIME (DESKTOP SHORTCUTS WILL BE
MIGRATED FROM THE OLD CITRIX XENAPP ENVIRONMENT TO THE NEW CITRIX XENAPP ENVIRONMENT).
IT MUST BE COMMUNICATED TO END USERS THAT ONLY SHORTCUTS ARE ALLOWED ON THE DESKTOP.

46 of
-
5.3.9.5 Published applications

The published desktop is used as primary resource delivery mechanism for end users.
However, optionally certain end users can be given access to published applications if
required. This will not be implemented initially.
5.3.10 Server Deployment

Each XenApp server is streamed from a central vDisk. As such, deploying additional XenApp
server VM’s is an easy task. However, the vDisk itself must also be built. It is important that
this vDisk is created as much as possible in an automated way, allowing the vDisk to be
recreated at any time and avoid human errors when building the vdisk. Automating the
initial server deployment helps in the following scenarios:
- Having a consistent process in place to create new vDisks.
- Implement DTAP by testing changes first on a Test vDisk.
- When the Citrix PVS Target Software needs to be updated, a rebuild of the vDisk
might be required. This is because updating the target software might upgrade the
PVS drivers that are in use when the vDisk is active.
In order to automate the Windows Server 2012 R2 build, the following tools will be used:
 Clean VM installed by using Windows server 2012 R2 ISO: manual deployment of the
base operating system + operating system security patches / hotfixes.
 Taskflow: Deployment of additional software, such as XenApp components, physically
installed applications …
5.3.11 Server Configuration

After a server has been deployed it is also required to configure various server-wide settings.
This can include settings for the Windows Page file, performance tuning, server-wide
application settings…
The required settings will be configured using a combination of AD GPO and Taskflow. The
actions configured in Taskflow will be executed during every startup of a server.
5.3.11.1 Windows Firewall

Windows Firewall is a stateful firewall included by default in Windows. By default, Windows
Firewall blocks incoming traffic that is not allowed by one of the configured rules.
ACME recommends the windows firewall component to be turned off (The service must not
be disabled) and implement network security at another level. If Windows Firewall must be
used for security reasons, configuration has to be done using GPO settings.
5.3.11.2 Server Maintenance & Reboot window

Taskflow will be used to control the maintenance window of the XenApp servers. Because
Citrix Provisioning Services is used, a reboot of the XenApp servers takes care of a lot of
maintenance tasks. Taskflow will setup a daily reboot schedule for the production servers.
The following schedule will be used:
 EVEN Xenapp servers
 Even Xenapp servers will reboot on Monday, Wednesday, Friday
 00h00 disable logons to even Xenapp servers + Send first message to logged on
users to log off

47 of
-
 01h00 Send second message to logged on users to log off

 02h00 Send third message to logged on users to log off
 03h00 Send fourth message to logged on users to log off
 03h45 Send fifth message to logged on users to log off
 04h00 – 05h00 reboot even Xenapp servers
 ODD Xenapp servers

 Odd Xenapp servers will reboot on Tuesday, Thursday, Saturday
 00h00 disable logons to even Xenapp servers + Send first message to logged on
users to log off
 01h00 Send second message to logged on users to log off
 02h00 Send third message to logged on users to log off
 03h00 Send fourth message to logged on users to log off
 03h45 Send fifth message to logged on users to log off
 04h00 – 05h00 reboot odd Xenapp servers
5.3.11.3 DTAP
DTAP is standing for development, testing, acceptance and production.
Development environment
A development environment is used to make modifications and adjustments. This includes
development regarding installations and configurations. Actually it’s a sort of playground
where developers and system engineers can test and modify stuff as much as they like.
Therefore this environment needs to be separated completely from the production
environment to make sure the production environment cannot be influenced by
modifications made to the development environment.
The development environment doesn’t need to be exactly the same as the production
environment, it’s only used for development regarding installation and configuration of OS,
Citrix and applications.
A lot of customers choose to use the test environment if they want to make modifications
and adjustments. Although it is ideal to have a separation between development
environment (a real sandbox) and test environment (more controlled and used for technical
validation of changes), but maybe the required system resources are not available to have 2
separate environments and it is also 1 extra environment to manage and maintain.
Therefore, a lot of customers would like to keep it simple and have 1 test environment
instead of also having an extra development environment.
Test environment
A test environment is used to test the modifications and adjustments which were made in
the development environment. The test environment also needs to be separated completely
from the production environment to make sure the production environment cannot be
influenced by modifications made to the test environment. The test environment needs to
be integrated in a separate test environment infrastructure (test Active directory infra, test
SQL infra, test file and print servicing,…), The Citrix Xenapp infrastructure will be shared by
the development environment if a development environment is also present.

48 of
-
A test environment needs to be as similar as possible to the production environment,

especially regarding the installation and configuration of OS and applications. The
environment is used by system engineers to test the installation/configuration developed in
the development environment, to make sure there are no conflicts, problems or errors with
existing installations and configurations. Technical validation of change will be done during
this stage.
Acceptance environment
An acceptance environment is used to accept the implemented solution that has been
introduced in the test environment. An acceptance environment needs to be integrated into
the production environment infrastructure, but the Citrix Xenapp infrastructure can be
separated or can be the same as the production Citrix Xenapp environment, depending if the
customer decides to also have a pre-production environment or not.
If the customer decides to separate the acceptance Citrix Xenapp environment, then
acceptance environment normally does not accept end users during day-to-day operations,
but only accepts end users if functional validation of a change is required.
If the customer decides to integrate the acceptance Citrix Xenapp environment within the
production Citrix Xenapp environment, then the acceptance Citrix Xenapp environment will
actually operate as a pre-production Citrix Xenapp environment (see next paragraph for
more details regarding pre-production Citrix Xenapp environment).
An acceptance environment will be used by system engineers and key end users. The role of
key end users is crucial here, as they know the applications best and they can give valuable
feedback regarding the installation and configuration of the applications. They will supply us
information if applications are ready for production or not. Functional validation and
optionally performance validation will be done during this stage.
Production environment
A change can be implemented within the production environment when proper technical,
functional and performance validation has been done by ICT system engineers and key end
users.
The production environment is used by all end users. Changes that need to be implemented
to the production first need to go through all phases mentioned previously, to make sure
that these changes will not have a negative impact to the production environment.
Optionally, the production Citrix Xenapp environment can also contain a pre-production
Citrix Xenapp environment. A change that has been validated in acceptance phase will first
be implemented on the pre-production environment where also production end users are
connected to. Actually, there is no real difference between a pre-production Citrix Xenapp
server and a production Citrix Xenapp server, the only difference is the way how a change
will be implemented: first it will be installed on the pre-production Citrix Xenapp servers and
if this works fine then the change will be implemented on the other production Citrix Xenapp
servers.
CONTOSO has decided to have a DEVELOPMENT, TEST, ACCEPTANCE and PRODUCTION in

place.
CONTOSO has indicated that a DEVELOPMENT environment might be useful when they want
to test a huge-impact change for a longer time such as e.g. a MS office version upgrade.

49 of
-
However, it is very important to keep the 4 environment in sync as much as possible and at
least have the TEST – ACCEPTANCE – PRODUCTION environment fully in sync. This enables
you to have proper change & release management related to the Citrix Xenapp servers (and
its apps).
5.3.11.4 Security and lockdown

In order to prevent unauthorized usage of applications, a security mechanism needs to be
used to control access to executable software.
5.3.11.4.1 MS Applocker
End users can only launch executables from allowed locations. This security measure will be
configured by using Applocker that can be configured via AD GPO:
 SGL_GPO_CONTOSO_XA_<dtapenv>_COMPUTER_APPLOCKER
MS AppLocker, configured using Group Policies, will be used to control access to

applications. For each packaged application, an AppLocker rule will be created that grants
access for that application to the application AD security group in Active Directory.
5.3.11.4.2 Anti Virus

For general Antivirus scanning, Kaspersky Anti-Virus 8.0 for Windows Servers Enterprise
Edition will be installed into the XenApp image. The Antivirus Configuration will be
specifically adjusted for XenApp based on the Citrix Antivirus Best Practices:
http://support.citrix.com/article/ctx124185
https://support.citrix.com/article/CTX127030
5.3.11.4.3 Lock down via AD Group Policy policies

Further lock down of the Citrix Xenapp environment will be done via AD GPO
SGL_GPO_CONTOSO_XA_<DTAP env>_USER_DEFAULT_USERS_CONFIG.
5.3.12 Printing Environment

5.3.12.1 Printing strategy
A combination of network printing and Citrix auto-created client printing will be used in the
new Citrix Xenapp environment.
5.3.12.2 Printer mapping

5.3.12.2.1 End users connecting from Internal locations
5.3.12.2.1.1 Network print queues
The following network print queue will be required for end users:
Print queue AD security group

50 of
-
PRN-CON-Secure_PCL SGL_PS_VPSCON-1009_PRN-CON-Secure_PCL
PRN-ANT-1-1_PCL SGL_PS_VPSCON-1009_PRN-ANT-1-1_PCL
PRN-CIN-1-1_PCL SGL_PS_VPSCON-1009_PRN-CIN-1-1_PCL
PRN-GEN-1-1_PCL SGL_PS_VPSCON-1009_PRN-GEN-1-1_PCL
PRN-LIB-1-1_PCL SGL_PS_VPSCON-1009_PRN-LIB-1-1_PCL
PRN-LOU-1-1_PCL SGL_PS_VPSCON-1009_PRN-LOU-1-1_PCL
This will be done by using a vbs logon script.
5.3.12.2.1.2 Local client print queues

Users who require the mapping of the local client printer within the Citrix session can be
added to one of the following two AD security groups:
 SGU_XA_CTX_DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (NOT DEFAULT): add
AD user account to this group when the default client printer needs the be mapped
within Citrix session and this printer does not need to be the default printer within the
Citrix session.
 SGU_XA_CTX_DEFAULT_CLIENT_PRINTER_MAPPING_ALLOWED (DEFAULT): add AD
user account to this group when the default client printer needs the be mapped within
Citrix session and this printer also needs to be the default printer within the Citrix
session.
5.3.12.2.2 End users connecting from external locations (via Netscaler Gateway)
The auto-creation of client printers is managed using Citrix policies.
Mapping of the default client printer is enabled for all users who are connecting via the
Netscaler Gateway, thus from an external location. The default client printer will also be the
default printer within the Citrix session.
The Citrix universal print driver will be used when the manufacturer driver is not available on
the Citrix Xenapp servers for auto-created client printers.
5.3.12.3 Print Driver deployment

Print Drivers will be deployed using Taskflow during the automated XenApp server build
process.
The following printer drivers will be installed on the Xenapp servers:

Printer driver name
Konica Minolta C754SeriesPCL
Konica Minolta C360SeriesPCL
Konica Minolta bizhub C35 PCL6
Konica Minolta Universal PCL

51 of
-
Konica Minolta bizhub C35 PS

Konica Minolta c554SeriesPCL
Konica Minolta c554SeriesPS
Konica Minolta C754SeriesPS
HP Color LaserJet 2800 Series PS
HP Color LaserJet 4500 PCL 5
HP LaserJet Series II
Citrix Client printers that are auto-created will only use the Citrix Universal driver if
manfucturer driver is not available.
5.3.13 Applications
5.3.13.1 Application List
The following table lists the applications that will be installed on the new Citrix Xenapp
environment. The table also lists whether or not the application will be delivered as a local
installed application in the XenApp image or as an App-V application.
Application Delivery Mechanism

7-Zip Local install
CMD beheer Local install
Simloon Local install
First Local install
Agfa ALD4000 (Microfilm) App-V
Alacatel Contact center Supervisor Local install
PL/SQL developer Local install
Adobe Shockwave player Local install
Adobe flash player Local install
Adobe Reader Local install
Borland BDE Local install
Cafforun Local install
CONTOSO fonts Local install
Exact Local install
F5Networks-BIG-IPEdgeClientComponents Local install

52 of
-
Oracle Java Runtime 8 Local install

Gemalto middleware Local install
Google chrome Local install
Mozilla Firefox Local install
Isabel Local install
Powergrep Local install
Kaspersky AV 8 enterprise edition Local install
MS Native SQL client Local install
MS Silverlight Local install
MS Skype for Business 2015 (incl. dutch + french language Local install
pack)
MS XMLnotepad 2007 Local install
Notepad++ Local install
Oracle client 11g R2 Local install
Oracle Desktop Integration Suite Local install
Oracle Jinitiator Local install
PDF creator Local install
Simple PDF merger Local install
Printkey 2000 Local install
VLC player Local install
SAP crystal reports Local install
Scansys imagecapture Local install
Sugar CRM outlook plugin Local install
Xnview Local install
Belcotax Local install
Filezilla Local install
Oxygen Local install
Telnet Local install
MS Office 2010 Pro Plus (incl. dutch + french language Local install
pack)
MS 2010 Visio standard (incl. dutch + french language Local install
pack)

53 of
-
Winscp Local install

Zephyr Passporttohost Local install
Zenito ControleCommissie Local install
Zenito Kapitaalstand Local install
Zenito Openboek Local install
Zenito Socias Local install
Zenito Socias Preproductie Local install
Zenito Telefoonafrekening Local install
Zenito Vapenzo Local install
Zentio Vapenzo Preproductie Local install
Zenito Tussenstap Local install
Zenito Tussenstap preproductie Local install
Be-ID Local install
Rasplus Local install
TweetDeck Local install
Zenito Correspondenten Local install
Zenito Kwaliteitsregistraties Local install
Zenito Metingen Local install
Zenitor HernieuwdOndernemersschap Local install
Zenitor HernieuwdOndernemersschap preprod Local install
Zenitor Loopbaancoaching Prod Local install
Zenitor Loopbaancoaching ProProd Local install
5.3.13.2 Application delivery

The approach used to deliver the application to the XenApp server has a significant impact
towards sustainability.
The Xenapp solution provides two inherent options towards application integration:
 Locally installed: Applications installed locally into the operating system are part of the
system. This installation method is the way that it has always been.
 Virtualized (App-V): Virtualized applications are only available to users who are granted
rights. When the application is selected, the application bits are sent across the network
to the target device, Xenapp server, and executed within the isolation environment.
virtualized applications are maintained centrally. A virtualized application can continue
to function in situations where the network connectivity is disrupted.
Each delivery solution has its advantages and disadvantages. In general, we use the following
rule of thumb:

54 of
-
 Locally installed applications

 Commonly used applications used by almost all users. E.g. MS Office
 Business-critical applications where performance is also important. E.g. SAP GUI
 Dependency applications: applications frequently used by other applications. E.g.
oracle client, java runtime.
 Applications that cannot be virtualized or that tightly integrate with OS: E.g. internet
explorer, anti-virus, .net framework.
 Streamed/virtualized applications (App-V)

 Applications that conflict with another (locally installed) application. E.g. dll conflicts
 Multiple versions of the same application is required on the same xenapp server.
E.g. MS office 2010 and MS office 2007
 Application that need frequent updates. E.g. application that need weekly updates
In general, ACME recommends installing applications locally on each Citrix Xenapp server if
possible. Locally installed applications still perform better and when using an enterprise
application deployment solution then maintenance of applications ( installation,
uninstallation and upgrades) is still easy. We recommend using application virtualization
when application conflict, when multiple versions of the same app is required or maybe
when an app is update frequently.
In general, ACME recommends using MS App-V when application virtualization is solely used
within a Citrix Xenapp server environment, as MS App-V licenses are included within RDS
CAL’s.
For CONTOSO, ACME recommends installing as much applications as possible locally in the
vDisk. These applications will be installed during the initial deployment of a new XenApp
server (creating a new vDisk) or during the regular vDisk update schedule. The applications
will be installed in a controlled way by using ACME Taskflow.
ACME advises to use MS App-V application virtualization only when there are application
conflicts or when you want to install multiple versions of the same application side-by-side
on the same Citrix Xenapp server (e.g. MS office 2010 and MS office 2013)
When working with Citrix Provisioning Services, Citrix servers are streamed on the fly using
the same operating system image as a common base. Any changes to the disk are
intercepted by the PVS software and redirected to the write cache. When a Citrix XenApp
server is rebooted, these changes are purged and the server will boot from the same original
image.
When using App-V applications in combination with non-persistent images, it is important
how App-V applications are deployed to these images. By nature, App-V applications are
also streamed to the local machine, hence by default ending up in the write cache. This is
not a desired situation as the write cache can be quickly filled with virtual application data.
A number of options exist to provision App-V applications to XenApp images:
- Pre-Publish and Pre-Cache App-V applications: Applications are already streamed
and cached inside the base vDisk. Any servers streamed from this vDisk will contain
by default all the applications to prevent them being streamed again. This method
requires the vDisk to be updated regularly to cache any new or updated App-V
applications.

55 of
-
- Use App-V Shared Content Store mode. The App-V client will not stream package
contents to the local machine but instead access them directly from the App-V
Streaming Servers. This can introduce a slight impact to the application performance
but can also be used in combination with pre-caching. This way, most applications
can be pre-cached in the image but new and updated applications can still be
streamed without ending up in the write cache.
In the new XenApp environment, the App-V client will be configured with Shared Content
Store enabled.
In order to speed up the displaying of shortcuts in the user’s start menu, the App-V client’s
publishing data will be saved within the user’s Citrix User Profile Management profile.
5.3.13.3 Application Virtualization

As mentioned before, MS App-V Application Virtualization will only be used at CONTOSO in
case of application conflicts and usage of multiple versions of the same application.
Also, not all applications can be virtualized correctly. The table below gives an overview of
possible limitations when virtualizing applications:
Limitation Description
Applications that start App-V requires a logged-in user to initiate the
services at boot time launch of an application.
Applications that require App-V can only virtualize a limited set of drivers. It
device drivers is possible to install the driver locally and virtualize
the application without the driver.
Applications that are For example a program that will initiate a
required by several command and launch another program. Normally
applications for information both programs would be included in the same
or access suite however if this application launches several
applications it may not be feasible to include all of
the applications in the same suite.
Applications that are a part Such as Internet Explorer
of the OS
Applications that use COM+ COM+ is dynamic and happens at runtime. The
App-V sequences cannot capture this information.
COM DLL virtualization Some DLLs run in the DLLHost.exe process and are
therefore difficult to virtualize.
In the new XenApp environment, the primary goal is the performance of the applications.
When applications are installed locally inside the XenApp image, they are immediately
available for the user and performance is guaranteed. For this reason, applications will be
installed locally in the image. App-V will be used for the following circumstances:
- Applications that have a conflict with another locally installed application
- Multiple versions of an application are required to run side-by-side next to each
other

56 of
-
5.3.13.4 Application configuration

 Application configuration on machine level will be done via Taskflow for local installed
apps.
 Application configuration on user level will be done via logon scripts for local installed
apps.
 App-V application configuration will be done within the App-V package
5.3.13.5 Application Presentation

 Primary presentation method for applications will be application shortcuts within the
published desktop
 Optionally and if required, a secondary presentation method for applications can be use
by using published applications for certain end users who prefer to work with published
applications instead of a published desktop.

57 of
-
6 Control Layer
6.1 Layer Overview
The control layer includes all infrastructure related components supporting the overall
solution. This includes the Citrix controllers, image management through MCS or PVS, and
the creation and publication of hosted resources. Specific Control Layer components and
design decisions are based on the completed design of the above layers (user, access and
desktop).
6.2 Citrix XenApp Controllers

6.2.1 Overview
In a XenDesktop or XenApp environment, Citrix Delivery Controllers serve an important role.
XenApp controllers act as the broker between the user and specific resources such as
XenApp pools.
When a user logs on to Citrix Web Interface or StoreFront, the XenApp controllers are
queried for all assigned resources for the current user. The XenApp controllers are
continuously updated by the VDA agent on each XenApp server and as such know the status
and load of each server. Based on the status of each VDA and any configured policies the
user is brokered to the correct XenApp server.

Sizing
Number of Controllers 2 Having 2 Delivery
controllers provides
redundancy and spread
of load.
Section: Control www.ACME.

58 of
-
Controller Specs  Each controller has: These specs should be

 2vCPU’s sufficient to handle an
 4 GB RAM environment of this size.
 60GB Disk
Site Layout
XenApp Sites 1 site , CONTOSO_XA_76 One central site will be
used as there is no
reason for having
multiple sites.
Machine Catalogs 4 machine catalogs One machine catalog
will be used per DTAP
environment
Delivery Groups 4 Delivery groups One delivery group for
each machine catalog.
Citrix Databases
MS SQL version Microsoft SQL Server 2014 Customer preference &
standard edition 64-bit compatible with Citrix
and App-V databases
Database server name vdbcon-1082.CONTOSO.be Existing MS SQL server
of customer
Database Instance default Only Default instance is
defined
Database server specs  2vCPU’s Customer preference.
 32 GB RAM Sufficient resources are
available
Database Names  CX_XA_SITE_CONFIG_DB Customer standards
= Citrix XenApp Site
Configuration
 CX_XA_MONITORING_DB
= Citrix XenApp
Monitoring DB
 CX_XA_CONFIG_LOG_DB
=Citrix XenApp
Configuration Logging
 CX_PVS_SITE_DB=Citrix
PVS Site database
Citrix Service Accounts  PVS: sysxapvs Service account
according to customer
standards

59 of
-
High Availability Hypervisor HA Customer preference

VDA Configuration
Delivery Controller Via Group Policy setting Robust solution and
assignment central & easy
configuration
6.2.3 VM Specifications

Vddcon-1202 192.168.1.202 2 8 GB 60 GB
Vddcon-1203 192.168.1.203 2 8 GB 60 GB
6.2.4 Configuration
6.2.4.1 XenApp Sites
A XenApp or XenDesktop Site is the boundary of a XenDesktop environment. A XenApp sites
consists of one or more delivery controllers and the site configuration is stored in an SQL
Database.
Additional sites are usually created when two geographically spread data centers are used,
as such keeping all site traffic, configuration and database local to each datacenter.
For the new XenApp environment a single XenApp site; CONTOSO_XA_76, will be used as all
components will be located within the same datacenter.
6.2.4.2 Machine Catalogs

Machine catalogs are collections of virtual or physical machines that you manage as a single
entity. These machines, and the application or virtual desktops on them, are the resources
you want to provide to your users. All the machines in a machine catalog have the same
operating system and the same VDA installed. They also have the same applications or
virtual desktops available on them. Typically, you create a master image and use it to create
identical virtual machines in the catalog.
When you create a machine catalog, you specify the type of machine and provisioning
method for the machines in that catalog.
6.2.4.2.1 Machine types

Windows Server OS machines — Virtual or physical machines based on a Windows server
operating system used for delivering XenApp published apps, also known as server-based
hosted applications, and XenApp published desktops, also known as server-hosted desktops.
These machines allow multiple users to connect to them at one time.
Desktop OS machines — Virtual or physical machines based on a Windows desktop
operating system used for delivering VDI desktops (desktops running Window desktop
operating systems that can be fully personalized, depending on the options you choose), and

60 of
-
VM-hosted apps (applications from desktop operating systems) and hosted physical
desktops. Only one user at a time can connect each of these desktops.
Remote PC Access — User devices that are included on a whitelist, enabling users to access
resources on their office PCs remotely, from any device running Citrix Receiver. Remote PC
Access enables you to manage access to office PCs through you XenDesktop deployment.
6.2.4.2.2 Provisioning methods

Machine Creation Services (MCS) — A collection of services that create virtual servers and
desktops from a master image on demand, optimizing storage utilization and providing a
virtual machine to users every time they log on. Machine Creation Services is fully integrated
and administered in Citrix Studio.
Provisioning Services — Enables computers to be provisioned and reprovisioned in real-time
from a single shared-disk image. Provisioning Services manages target devices as a device
collection. The desktop and applications are delivered from a Provisioning Services vDisk that
is imaged from a master target device, which enables you to leverage the processing power
of physical hardware or virtual machines. Provisioning Services is managed through its own
console.
Existing images — Applies to desktops and applications that you have already migrated to
virtual machines in the data center. You must manage target devices on an individual basis
or collectively using third-party electronic software distribution (ESD) tools.
The following machine catalogs will be created:

Name Machine Type Provisioning
Method
XA_W2012R2_DESKTOPS_APPS_PRODUCTION Server OS Provisioning
Services
XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE Server OS Provisioning
Services
XA_W2012R2_DESKTOPS_APPS_TEST Server OS Provisioning
Services
XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT Server OS Provisioning
Services
6.2.4.3 Delivery Groups

Delivery Groups are collections of machines, and specify who can use a group of desktops or
applications. Create Delivery Groups for specific teams, departments, or types of users. A
delivery group can consist of multiple machine catalogs. Each delivery group also specifies
what is delivered to users: a published desktop, published applications or a combination of
both.
For the new XenApp environment, a delivery group is created for each vDisk and mapped to
the respective machine catalog:
Delivery Group Machine Catalog Delivery

61 of
-
Type
XA_W2012R2_DESKTOPS_APPS_ XA_W2012R2_DESKTOPS_APPS_DEV Desktops
DEVELOPMENT ELOPMENT and
Application
s
XA_W2012R2_DESKTOPS_APPS_ XA_W2012R2_DESKTOPS_APPS_TES Desktops
TEST T and
Application
s
XA_W2012R2_DESKTOPS_APPS_ XA_W2012R2_DESKTOPS_APPS_ACC Desktops
ACCEPTANCE EPTANCE and
Application
s
XA_W2012R2_DESKTOPS_APPS_ XA_W2012R2_DESKTOPS_APPS_PRO Desktops
PRODUCTION DUCTION and
Application
s
6.2.4.4 Database
XenApp delivery controllers require SQL databases to store various configuration and logging
data:
Database Description
Site Configuration Stores the XenApp configuration such as the delivery
groups, machine catalogs, …
Monitoring User’s session data and metrics such as logon speed, to be
used by Director Console and reporting.
Configuration Logging Stores all the administrative changes on the environment
for auditing purposes.
By default, the Configuration Logging and Monitoring databases (the secondary databases)
are located on the same server as the Site Configuration database. Initially, all three
databases have the same name. Citrix recommends that you change the location of the
secondary databases after you create a Site. You can host the Configuration Logging and
Monitoring databases on the same server or on different servers. The backup strategy for
each database may differ.
Database SQL Instance\DB Security Account

Site Configuration CX_XA_SITE_CONFIG_DB CONTOSO\VDDCON-1202$
CONTOSO\VDDCON-1203$

62 of
-
Monitoring CX_XA_MONITORING_DB CONTOSO\VDDCON-1202$

Database CONTOSO\VDDCON-1203$
Configuration CX_XA_CONFIG_LOG_DB CONTOSO\VDDCON-1202$
Logging CONTOSO\VDDCON-1203$
We will rely on Hypervisor high availability in order to make sure the SQL databases are
always online. However network or other issues can still prevent a proper database
connection. In order to prevent an outage, Connection Leasing can be enabled on the
delivery controllers. When Connection Leasing is enabled, each delivery controller cashes
user connections to the recently used applications and desktops during normal operations.
If the database becomes unavailable, the controllers can remember all operations in an
internal cache and replay these when a user connects to a recently used published
application or desktop.
When there is a problem with the Site Configuration database and connection leasing is
active, users will still be able to connect to their resources, but the administrative consoles
will not be available. Also some other features such as workspace control will not be
available. More information can be found on :
http://support.citrix.com/proddocs/topic/xenapp-xendesktop-76/xad-connection-
leasing.html
6.2.4.5 VDA Configuration

The address of each delivery controllers must be specified on the Citrix Virtual Desktop
Agent that is installed on each XenApp server. The VDA will use the list of delivery
controllers for failover in case a delivery controller is unavailable.
The list of controllers can be specified in various ways. They are checked by the VDA in the
following order:
- Policy settings. Delivery controllers can be specified using Citrix Policies or by using
the Group Policy templates.
- The ‘ListOfDDCs’ registry key on each server. The VDA installer populates this key if
controllers are specified during installation.
- OU-Based discovery. This is a legacy method in which information was added to the
Active Directory OU’s in which the servers reside.
A Citrix policy setting will be used to control the list of delivery controllers as it is a robust
solution and all configuration will be in a central place.
6.2.5 High Availability

In a XenApp environment, multiple delivery controllers will automatically load balance to
deliver a high available solution. Each XenApp server is configured with the FQDN of both
delivery controllers.
Also the StoreFront store will be configured to connect to the XML brokers on both
controllers.

63 of
-
The XenApp Site database will be hosted on a standalone MS SQL server with underlying
Hypervisor HA as HA solution. Also Citrix Xenapp connection leasing functionality will be
used to guarantee continuity of the Citrix Xenapp 7.6 environment when the Xenapp SQL
databases are offline for certain amount of time. For more info, see
https://www.citrix.com/blogs/2014/11/11/xendesktop-7-6-connection-leasing-design-
considerations/
Load balancing via Citrix Netscaler will be used to make the Citrix Director console highly
available.
6.3 Citrix Provisioning Services

6.3.1 Overview
The Citrix PVS architecture will consist of two PVS servers. Both PVS servers are a member
of a single PVS site and PVS farm. Each PVS server has an additional local disk containing the
vDisks that are streamed to the XenApp VMs.

64 of
-
General Configuration
Provisioning 7.6 Latest PVS version
Services Version available
License Server Vlscon-1209 Dedicated Citrix license
server
License Type Xenapp platinum Xenapp platinum licenses
entitles to use PVS for
deployment of Xenapp
servers
Database server vdbcon-1082.CONTOSO.be Customer SQL server
Database name CX_PVS_SITE_DB Customer choice
PVS farm name CONTOSO_PVS_76 Name according to
customer naming
conventions
PVS farm SGU_XA_GEN-PVS- One AD security group is
administrator ADMINISTRATORS sufficient for this
group environment
PVS site name Brussels Only 1 site at Brussels DC
Database  MS SQL server that hosts PVS Offline support is
Redundancy database will run on Xenserver disabled by default but
with HA enabled when enabled, it allows
 PVS database Offline support PVS within the farm to
will be enabled. use a snapshot of the
database in the event
that a connection to the
database has been lost.
High availability will be
configured in first
instance using this offline
support.
PVS Farm and Site layout
Number of PVS 1 Farm will be used. 1 Farm simplifies the
farms setup and will contain
TST, ACC and PRD vDisks.
Number of PVS 1 site will be used: CONTOSO All PVS servers and
Sites Xenapp servers will be
located within the same
datacenter. No need to
define multiple sites

65 of
-
Number of PVS 2 Having redundancy in

Servers place + load balancing
PVS Server PVS servers will run as a virtual Recommended config
hardware machine on the shared Xenserver
environment with the following VM
specs:
- 2 vCPU’s
- 16 GB RAM
- C:\ 60GB
- D:\ 500GB
Device Collections 5 Device Collections will be defined: A PVS Device Collection
 XA_W2012R2_DESKTOPS_APPS will be defined per DTAP
_MASTER environment
 XA_W2012R2_DESKTOPS_APPS
_DEVELOPMENT
_TEST
_ACCEPTANCE
_PRODUCTION
PVS Service sysxapvs This account will be used
Account to run the Stream and
Soap services and as the
account connecting to
the database.
vDisks Configuration
vDisk location Local Storage on each PVS Server vDisks will be local to
each PVS server for the
best performance
vDisks  1 vDisk for One vDisk will be used for
XA_W2012R2_DESKTOPS_APPS each silo in each DTAP
_DEVELOPMENT_Vx.x environment.
 1 vDisk for
XA_W2012R2_DESKTOPS_APPS
_TEST_Vx.x
 1 vDisk for
_ACCEPTANCE_Vx.x
 1 vDisk for

66 of
-
_PRODUCTION_Vx.x
PVS Stores 1 PVS store (name: STORE, location: Simplest config, no need
E:\PVS_STORE) will be defined on to have more PVS stores.
each PVS store that contains all PVS
vdisks
vDisk Replication Script / Robocopy Script based on robocopy
will be used as this is the
easiest, simplest and best
way to replicate PVS
vdisks between multiple
PVS servers
vDisk Write Cache Device RAM with overflow to Disk Best performance
Type
vDisk Write Cache 8 GB RAM More than sufficient for
Size this environment
Target Device configuration
Target Device 10 GB Each XenApp server will
persistent disk have a local disk of 10GB
for storing persistent data
and as RAM Cache
failover.
Target Device Network boot with DHCP options 66 Simple and robust
boot and 67 without additional
network config.
Streaming Production LAN A single NIC is sufficient
Network and reduces additional
complexity.
TFTP The PVS servers will also run the This option provides a
TFTP services and deliver the boot TFTP infrastructure for all
files requesting targets and
provides redundancy.
TFTP traffic will reside in
the same vLAN as DHCP
traffic.
DHCP  Each PVS will be configured as Simplest and easiest
TFTP server and DHCP server. configuration
 A DHCP reservation will be All the servers running
created for each XenApp server. DHCP will be configured
 DHCP failover will be configured with options 066 and 067
to have DHCP HA to deliver the boot files to

67 of
-
requesting targets.
PXE services No Boot information is
included by using DHCP
options 066 and 067, PXE
services are not needed
on PVS servers

Bpvcon- LAN: 192.168.1.204 2 16 C:\ 60GB (virtual disk)
1204 Iscsi: 192.168.100.204 GB E:\ 500GB (Iscsi disk)
Bpvcon- LAN: 192.168.1.205 2 16 C:\ 60GB (virtual disk)
1205 Iscsi: 192.168.100.205 GB E:\ 500GB (Iscsi disk)
6.3.4 Configuration
6.3.4.1 General Configuration
The latest Citrix Provisioning Services version available is 7.6.
Citrix PVS needs to be licensed by connecting to a Citrix license server. The PVS servers will
be configured to connect to the license server used by XenApp: vlscon-1209
The Provisioning Services database, CX_PVS_SITE_DB, will be hosted on the standalone MS
SQL 2014 server, vdbcon-1082. In case of database unavailability, the PVS servers will have
offline support enabled allowing the servers to continue to work with a local snapshot of the
database until connectivity is restored.
6.3.4.2 PVS Farm and Site layout

At the root of a PVS infrastructure is a PVS farm. A PVS Farm stores its configuration in a SQL
database. Multiple sites can exist within a single farm. A Citrix PVS farm consists of one or
more PVS Servers located in one or more sites.
Reasons to setup separate PVS farms can be:
- Delegation that is required at the highest level: different administrators can manage
each PVS farm independently.
- A separate database must be used. For example in geographically spread locations
where it is not feasible to use a shared SQL database.
- For licensing reasons a separate license server must be used.
Sites are used within farms to group Provisioning Servers located in a specific region or
datacenter. A site contains device collections and one or more stores where vDisks are
located. Sites can be used to make sure a collection of devices uses a specific list of PVS
servers. High Availability is only available within a PVS site, not cross-site.

68 of
-
Each Site should contain at least one PVS server. However that results in no high availability
for the streamed devices.
The new CONTOSO XenApp environment will use a single farm containing a single site. This
site contains 2 PVS servers: vpscon-1204 and vpscon-1205.
The two PVS servers are high available allowing XenApp servers to failover to the other PVS
server in case of PVS server failure.
The vDisk store on each PVS server will be a local attached disk. The vDisks will be replicated
between the sites by using a robocopy script.
Each PVS server will run as a virtual machine on the shared Xenserver environment within
the same datacenter. Each PVs server will run on a separate Xenserver host.
In the PVS site a Device Collection will be created for each vDisk. This results in the following
device collections:
- XA_W2012R2_DESKTOPS_APPS_MASTER: used for the MASTER Citrix Xenapp
server
- XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT: used for the DEVELOPMENT
Citrix Xenapp server
- XA_W2012R2_DESKTOPS_APPS_TEST: used for the TEST Citrix Xenapp server
- XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE: used for the ACCEPTANCE Citrix
Xenapp server
- XA_W2012R2_DESKTOPS_APPS_PRODUCTION: used for the PRODUCTION Citrix
Xenapp server
Its has been configured that only members of AD security group “SGU_XA_GEN-PVS-
ADMINISTRATORS” are administrators within the PVS console and are able to change PVS
configuration.
6.3.4.3 vDisk Configuration

A vDisk is a virtual disk file that functions as the hard drive of which each XenApp VM will
boot. During the boot process of a XenApp server, one of the PVS servers will setup a
streaming connection streaming the applicable vDisk file to the device based on the settings
defined on the device or device collection.
A vDisk can be in Standard mode or Private mode.
While in private mode, a vDisk is accessible for both reading and writing, however only one
device is allowed to connect. A vDisk is in private mode during the initial creation of the
vDisk and during vDisk updates. After a vDisk is ready for mass provisioning it is changed to
standard mode.
Standard mode vDisks are read-only. Devices booting from a standard mode vDisk will only
read from the vDisk and redirect all write actions to the write cache. That write cache can be
located in different places:
- Write Cache on client hard drive: the writes are redirected to a smaller disk attached
to each VM. The write cache file is wiped during each reboot.
- Write Cache on Server hard drive: the writes are redirected back to the PVS server,
over the network, to a writable location accessible by the PVS server. Due to the

69 of
-
additional translation of write actions across the network this method does not give
the best performance.
- Write Cache in client RAM: The writes are redirected to a portion of the RAM
memory on the device. This is very fast but consumes more RAM memory. If the
assigned RAM cache is full, the device becomes instable.
- Write Cache in client RAM with overflow to disk: This is the best of both worlds
where writes are first redirected to fast RAM memory. If the assigned RAM buffer is
full, writes are redirected to a local attached hard disk.
PVS vDisks can be created with a static or dynamic size. As the vDisks are VHD files they can
be compared to virtual machine disks that can be pre-allocated or set to dynamically grow.
The performance impact of using dynamic disks is negligible. The available free space in the
PVS Stores must be carefully monitored to prevent no more free space being available.
The following vDisks will be used:

Name Size Dynamic Cache RAM
Size Type cache
size
XA_W2012R2_DESKTOPS_APPS- 80GB Yes Cache to 8 GB
DEVELOPMENT_Vx.x RAM
with
overflow
to disk
XA_W2012R2_DESKTOPS_APPS-TEST_Vx.x 80GB Yes Cache to 8 GB
RAM
with
overflow
to disk
XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_Vx.x 80GB Yes Cache to 8 GB
RAM
with
overflow
to disk
XA_W2012R2_DESKTOPS_APPS_PRODUCTION_Vx.x 80GB Yes Cache to 8 GB
RAM
with
overflow
to disk
6.3.4.4 vDisk Stores

vDisks are stored in a PVS Store. A store is nothing more than a location on a file share,
shared storage LUN or local disk on each PVS server.

70 of
-
In order to provide high available, each PVS server in a PVS site must have access to the
same PVS Stores. If a store is used based on local storage, the path to the store must be
identical on all PVS servers.
For the new Provisioning Services environment, a PVS store will be used on each PVS server’s
local storage. Each PVS VM will have an additional disk assigned for storing the vDisks.
The vDisk stores will be replicated by using a robocopy based script scheduled for daily
syncing at 23h00.
Estimated vDisk store usage on a PVS server:
vDisk Store Contents Size

XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT 50GB
XA_W2012R2_DESKTOPS_APPS_TEST 50GB
XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE 50GB
XA_W2012R2_DESKTOPS_APPS_PRODUCTION 50GB
Reserved space for having 2 vDisk versions per DTAP 200 GB
environment
TOTAL 400 GB
Based on the above estimations it is recommended the vDisk store on each PVS server to be
at least 400GB in size. 500 GB is foreseen to have some margin.
6.3.4.5 PVS vdisk update

Initially only one PVS vdisk will beused for each DTAP environment. However when a change
needs to be introduced on the vdisk than we need to create a copy of the vdisk that is
currently in used. When a vDisk must be modified, the vDisk mode will be set to Private
mode. Changes will be written directly to the vDisk when a vdisk is operating in private
mode. A vDisk in Private mode can only be used by one device at a time. Therefore, we
assign this vdisk to the development Citrix Xenapp member server to be able to perform
modifications. Modifications are performed by using TaskFlow. If all modifications are done,
the vDisk will be changed back to Standard mode again and Vdisk version number is
increased by 1.
Next step is assigning this new vdisk in standard mode first to the development Xenapp
server and test of technical functionalities are working properly. If all works well within the
testing environment, we can create 2 copies from this new development vdisk:
 One copy will be renamed to XA_W2012R2_DESKTOPS_APPS_TEST_Vx_x and class and
type of this PVS vdisk are changed to TEST
 One copy will be renamed to XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_Vx_x and
class and type of this PVS vdisk are changed to ACCEPTANCE
We then need to assign this new vdisk version to the PVS target devices within each PVS
device collection:

71 of
-
 Assign PVS vdisk XA_W2012R2_DESKTOPS_APPS_TEST_Vx_x to all PVS target devices of

PVS device collection XA_W2012R2_DESKTOPS_APPS_TEST
 Assign PVS vdisk XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_Vx_x to all PVS target
devices of PVS device collection XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE
We can than test the proper working of the new PVS vdisks within the TEST and
ACCEPTANCE environments. When all works fine within the TEST and ACCEPTANCE
environment, than we can create a copy of the new PVS vdisk for the PRODUCTION
environment:
 Copy of new PVS vdisk will be renamed XA_W2012R2_DESKTOPS_APPS_TEST_Vx_x and
class and type of this PVS vdisk are changed to PRODUCTION
We than can “check for updates…” on each PVS server. At next reboot of the PRODUCTION
Citrix Xenapp server, the new PVS PRODUCTION vdisk will be assigned to the PRODUCTION
Citrix Xenapp server.
If any issues arise with the new vdisk, we can always perform a roll-back to the previous
vdisk version.
By using Citrix Provisioning services, we can perform upgrades and roll-backs in a very easy
and fast way. Upgrading and rolling back process is performed by simply assigning and un-
assigning vdisks to target devices (Xenapp servers).
Each vDisk will have a vDisk version number. This number contains 3 digits:
 Major version number
 Minor version number
 Build number
Every vDisk modification should be reflected in the version number. After a major
modification (e.g. new XenApp version), the major version number should be increased by
one. After a minor modification (e.g. new application version), the minor version number
should be increased by one. When correcting a previous modification, only the build number
should be increased.
Every vDisk also has a Type and Class tag. Both should contain the same value. The Class tag
can also be set on target devices, and is used to attach a class of vDisks to a certain target
device. The class and type values that should be used are:
 DEVELOPMENT: For PVS vdisk that need to be assigned to DEVELOPMENT Xenapp
servers
 TEST: For PVS vdisk that need to be assigned TEST Xenapp servers
 ACCEPTANCE: For PVS vdisk that need to be assigned to ACCEPTANCE Xenapp servers
 PRODUCTION: For PVS vdisk that need to be assigned to PRODUCTION Xenapp servers
When you have added a new PVS vdisk version, you can execute “check for updates…” on
each PVS server. This will assign the new PVS vdisk version to the corresponding PVS target
devices and will result Citrix Xenapp servers to boot from the new PVS vdisk version on the
next reboot/maintenance window.

72 of
-
An operation procedure is available that explains the PVS vdisk update process in more
detail, summarized it contains the following steps:
1. Step 1: Take a copy of the DEVELOPMENT vdisk files (pvp and vhd file) and increase
version number. E.g. take a copy of DEVELOPMENT vdisk
“XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_1” and call this copy
“XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_2”.
2. Step 2:Import PVS vdisk into PVS environment via PVS console
3. Step 3: Change vdisk mode of vdisk
“XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_2” to private mode.
4. Step 4: Shutdown vmware virtual machine VXDCON-1219 and assign DEVELOPMENT
vdisk “XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_2” to target device VXDCON-
1219 within the PVS console.
5. Step 5: Startup vmware virtual machine VXDCON-1219 via Xencenter console
6. Step 6: Introduce necessary changes on server VXDCON-1219 (All changes are applied
via ACME TaskFlow by performing maintenance reboot) + validate changes
7. Step 7: Shutdown vmware virtual machine VXDCON-1219
8. Step 8: Change vdisk mode of vdisk
“XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_2” to standard mode and cache
cache type to “Cache in device RAM with overflow on hard disk” and set Maximum RAM
size to 8192 MB.
9. Step 9: Take a copy of DEVELOPMENT vdisk
“XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT_V1_2” files (pvp and vhd file) and
rename the copy vdisk to “XA_W2012R2_DESKTOPS_APPS_TEST_V1_2”
10. Step 10: Import PVS vdisk into PVS environment via PVS console
11. Step 11: Change the Class and type of vdisk
“XA_W2012R2_DESKTOPS_APPS_TEST_V1_2” from “DEVELOPMENT” to “TEST”
12. Step 12: Shutdown vmware virtual machine VXTCON-1220 and assign TEST vdisk
“XA_W2012R2_DESKTOPS_APPS_TEST_V1_2” to target device VXTCON-1220 within the
PVS console.
13. Step 13: Startup vmware virtual machine VXTCON-1220 via Xencenter console and
validate changes again. If all works well, please continue to next step.
14. Step 14: Take a copy of TEST vdisk “XA_W2012R2_DESKTOPS_APPS_TEST_V1_2” files
(pvp and vhd file) and rename the copy vdisk to
“XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_V1_2”
“XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_V1_2” from “TEST” to “ACCEPTANCE”
17. Step 17: Shutdown vmware virtual machine VXACON-1221 and assign TEST vdisk
“XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_V1_2” to target device VXACON-1221
within the PVS console.
18. Step 18: Startup vmware virtual machine VXACON-1221 via Xencenter console and
validate changes again. If all works well, please continue to next step.
19. Step 19: Take a copy of ACCEPTANCE vdisk
“XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE_V1_2” files (pvp and vhd file) and
rename the copy vdisk to “XA_W2012R2_DESKTOPS_APPS_PRODUCTION_V1_2”
“XA_W2012R2_DESKTOPS_APPS_PRODUCTION_V1_2” from “ACCEPTANCE” to
“PRODUCTION”

73 of
-
22. Step 22: Perform “Check for automatic Updates…” via PVS console on PVS server
VPVCON-1204
23. Step 23: The new PVS vdisk “XA_W2012R2_DESKTOPS_APPS_PRODUCTION_V1_2” will
be automatically assigned at next reboot of PRODUCTION Citrix Xenapp server.
6.3.4.6 Startup vmware virtual machine VXDCON-1219 and validate

changes again. If all works well, please continue to next step.Target
Device Configuration
When a Citrix PVS Target Device (XenApp server) boots, it needs to connect to the PVS
servers in order to initiate a streaming session. As the streaming session needs to be setup
before the target VM is able to boot some kind of boot loader must be used.
Citrix PVS allows for several different boot methods:
 Network Boot with PXE: The target VM initiates a PXE broadcast in order to download a
bootstrap file from the PVS servers using TFTP. In order for PXE to work, the PVS targets
and PVS servers must be in the same broadcast domain and no other PXE
advertisements can be active on that broadcast domain.
 Network boot with DHCP options 66 and 67: Using DHCP options the bootstrap file and
TFTP server can be specified where the target VM’s can download the bootstrap file.
 Citrix Boot Device Manager: the PVS bootstrap can be configured as a bootable ISO file
including the information about the different PVS servers inside the ISO image. This ISO
file is then configured as the virtual CD-ROM drive for each VM.
The Network boot with DHCP options 66 and 67 is simple to implement and reduces a lot of
the required configuration on the network side.
Because the target devices all boot from the same vDisk, they will need to get a unique IP
address using DHCP. Each PVS server will also function as DHCP server. To prevent any DNS
dynamic update issues, a reservation will be created for each XenApp VM to make sure it is
always assigned the same IP address and the DHCP server only assigns DHCP IP addresses to
the Citrix Xenapp servers and no other servers within the same ip range.
DHCP failover between the two DHCP servers that will run on the PVS servers will be
configured to enable HA on DHCP level.
6.3.5 Special Considerations when using PVS

XenApp VM’s that are provisioned using Citrix Provisioning Services are non-persistent. Each
XenApp machine boots from the same vDisk in read-only mode. All writes and modifications
to this disk are redirected to the Write Cache in RAM. When a XenApp server reboots, the
write cache is purged and any changes to the disk are gone.
Due to the non-persistent architecture, information and settings that must persist multiple
reboots has to be located on the persistent drive (D:\ ) of each XenApp VM. This includes:
- Event Logs: By using Group Policy settings, the event logs will be redirected to the D:
drive in order to persistent event logs after a reboot.
- Print spooler: performance and manageability of the print spooler is better when
located on a persistent disk
- Antivirus Definitions: Often required to redirect the Antivirus client to the persistent
drive for storing its virus definitions and configuration. Otherwise the client will have
to apply all updates again after every reboot.
- Management Agents using a unique identifier: Some agent software such as the
AppSense Client Communications Agent store unique identifiers in the registry. This

74 of
-
means that by default each XenApp VM would boot up with the same identifier as
was in use by the Master VM and that might give a problem. It is sometimes
required to perform sysprep-like actions before sealing each vDisk to make sure
each XenApp VM is unique.
For CONTOSO only the event logs and print spooler will be located on the persistent disk.
Each Xenapp server will have its own dedicated persistent disk with size of 10 GB.
Antivirus products installed on the PVS Streamed XenApp servers require specific exclusions
to be added to the antivirus engine configuration. This to ensure optimal performance and
stability. For more information refer to CTX124185 – Provisioning Servers Antivirus Best
Practices

Two PVS servers will be setup within the same datacenter. The XenApp VM’s can connect to
both PVS servers if required. When one PVS server goes down, streaming will immediately
continue from the other PVS server.
In order for HA to work correctly, each PVS server must have access to the same vDisks. As
the vDisk stores will be local to each PVS server, a nightly robocopy based replication
scheduled task will replicate the vDisks between the datacenters.
6.4 App-V Servers

6.4.1 Overview
App-V 5.0 enables administrators to deploy, update, and support applications as services in
real time, on an as-needed basis. Individual applications are transformed from locally
installed products into centrally managed services and are available wherever you need,
without the need to preconfigure computers or to change operating system settings.
An App-V environment consists of the following components:
- App-V Management Server

o Central location for managing the App-V infrastructure.
o Uses SQL for its data store.
o Performs authentication requests/ metering / monitoring
- App-V Publishing Server
o Provides the App-V clients with entitled applications for that specific user.
o Hosts the virtual applications for streaming.
- App-V Desktop Client
o Retrieves virtual applications
o Publishes the applications for the users (shortcuts, integration points)
o Responsible for the setup of the virtual environment at runtime for each
package.
- App-V Remote Desktop Services client
o The Desktop Client specifically adjusted for RDS environments.
- App-V Sequencer

75 of
-
o Wizard based tool that captures applications into virtual applications

o Produces the virtual ‘packages’: APPV files.

App-V Version 5.0 SP3 HF2 Latest version available
Publishing User publishing Publishing can be
executed both from a
user perspective (per
user) as well as global
(per computer). Per
user is best solution in
this customer case
Publishing Optimization Pre-added Publishing can be
optimized by pre-
adding (not mounting)
or pre-publishing the
package information of
the application(s) to
the image. Pre-
publishing is only
applicable in global
publishing scenarios.
App-V Infrastructure
Management Servers 1 App-V management server Each App-V server will
for all DTAP environments be a Management
Publishing Servers Same server as management Server and Publishing
servers Server.
Management Servers
SQL server vdbcon-1082 Customer choice
SQL instance default Customer choice
SQL database CX_TST_APP_V_MGT_DB Customer choice
Administrators AD Group SGU_XA_GEN-APPV- Based on the existing
ADMINISTRATORS naming convention
Mgmt Servers port 81 Preferred port for App-
V management
Management server high Hypervisor HA Hypervisor HA is

76 of
-
availability sufficient for this

environment
Publishing Servers
Publishing Servers port 82 Preferred port for App-
V publishing
Streaming Protocol SMB For performance
reasons we
recommend SMB
because it uses less
resources and
therefore will improve
the overall capacity
and publishing times.
Content Location File Share Packages will be
hosted on file share
created on the App-V
server.
Publishing server high Hypervisor HA Hypervisor HA is
availability sufficient for this
environment
App-V RDS Client
Configuration Installation parameters + An ADMX template will
ADMX template be used to configure
the URL’s for the
publishing server.
Shared Content Store Enabled SCS is used on non-
persistent VDI
environments to
prevent image updates
each time a new App-V
application is
deployed.
App-V Sequencer
Package Optimization Fault During the sequencing
process there is the
option to optimize
packages for streaming
(by means of including
a feature block 1).
When the packages
are not optimized

77 of
-
there are two options:

Fault Streaming and
pre-download. In the
pre-download scenario
the package is entirely
downloaded before
launching the
application. In the
Fault Streaming
scenario the
application is launched
as quickly as possible
Package Root PVAD During sequencing you
have the option to
install the packaging
into the Primary
Virtual Application
Directory (PVAD) or
into the Virtual File
System (VFS).
vavcon-1206 LAN: 192.168.1.206 1 4 GB C:\60 GB (virtual disk)
Iscsi: 192.168.100.206 E:\100 GB (Iscsi disk)
6.4.4 Configuration
6.4.4.1 App-V Version
The latest available version of MS App-V is 5.0 SP3 Hotfix 2.
6.4.4.2 App-V Infrastructure

1 App-V server will be used. Each server will have the Management Server and Publishing
Server roles.
1 App-V server will be used for the DEVELOMENT, TEST, ACCEPTANCE and PRODUCTION
environment.
The Management Servers will connect to a SQL database hosted on the MS SQL 2014 server,
vdbcon-1082.

78 of
-
6.4.4.3 Management Servers

The App-V Management Server role requires an SQL database to store its configuration. The
SQL Database will be hosted on MS SQL 2014 server, vdbcon-1082:
SQL server vdbcon-1082
SQL instance SQL Default instance
App-V management database name CX_TST_APP_V_MGT_DB
Each Management Server will be configured on port 81.

The AD group SGU_XA_GEN-APPV-ADMINISTRATORS will be configured as Administrators.
Members of this group will be able to perform administrative tasks in the App-V
infrastructure.
High availability
Only one App-V server will be deployed. This is a SPOF, but we rely on the underlying
Xenserver HA functionality and the App-V environment will host only a very small subset of
applications, thus impact is not high when this service is temporarily unavailable. When
99,99% availability is required on this App-V component, you can easily deploy a second
App-V server and implement network load balancing via the Citrix Netscaler.
6.4.4.4 Publishing Servers

The Publishing Server role will be installed on the management App-V server.
Each publishing server is configured to listen on port 82.
The publishing server will be configured to stream packages using the SMB protocol from
the App-V content file share that will be created on the App-V server.
The share will be:

\\VAVCON-1206.CONTOSO.BE\APPVPACKAGES$
High availability
Only one App-V server will be deployed. This is a SPOF, but we rely on the underlying
Xenserver HA functionality and the App-V environment will host only a very small subset of
applications, thus impact is not high when this service is temporarily unavailable. When
99,99% availability is required on this App-V component, you can easily deploy a second
App-V server and implement network load balancing via the Citrix Netscaler.
6.4.4.5 App-V RDS Client

The App-V client will be configured using the load balanced publishing server addresses.
Basic configuration of the App-V RDS client is done during the installation of the client
software.

79 of
-
The following command line can be used for installing the RDS client on the XenApp servers:
Appv_client_setup.exe
/CEIPOPTIN=0 (Disable customer experience improvement)
/MUOPTIN=0 (Disable Windows Update optin)
/SHAREDCONTENTSTOREMODE=1
/ENABLEPACKAGESCRIPTS=1 (Enable scripts in App-v packages)
/NORESTART
/q
/ACCEPTEULA
Shared Content Store mode will be enabled on the App-V client. This means that packages
are not necessarily cached locally on each XenApp server. Packages that are not in the local
cache will be read directly from the Publishing servers.
The App-V publishing servers will be configured using an ADMX template with GPO
SGL_GPO_CONTOSO_XA_<dtap env>_COMPUTER_DEFAULT_SERVER_CONFIG.
6.5 Active Directory Integration

6.5.1 Overview

AD Sites
AD Site Design No change required. Good AD site
configuration in place.
Organizational Units
Base OU’s  Servers Customer standards
CONTOSO.be/_CONTOSO/Syste
ms/XA Environment
 Security Groups
CONTOSO.be/_CONTOSO/Grou
ps/Security/Resources
 Service accounts
CONTOSO.be/_CONTOSO/Users
/System
AD Group Policies
Naming SGL_GPO_CONTOSO_XA_<server Customer naming
Convention scope>-<gpo settings scope>- convention

80 of
-
<description>
AD Security Groups
Naming  Application groups Customer naming
Convention SGU_XA_APP-<Application convention
name>
 Delivery Group groups

SGU_XA_DDG-<Delivery group
name>
 Desktop Groups
SGU_XA_DES-<Desktop name>
 AD GPO groups
SGL_GPO_CONTOSO_XA_<Citrix
component>_<description>
 Citrix policies groups

SGU_XA_CTX-<Citrix Policy
name>
 Printer groups
SGL_PS_<print server
name>_<print queue name>
 Local administrators groups

SGL_SYS_<server
name>_LocalAdministrators
 Language groups
SGU_XA_LAN-<scope>
 General groups
SGU_XA_GEN-<scope>
AD Groups OU CONTOSO.be/_CONTOSO/Groups/S ACME suggestion

ecurity/Resources
Group types Mix of domain local and universal Customer standards
groups will be used
AD Service Accounts
Naming Sysxa<description> Customer naming
Convention convention
Service Accounts CONTOSO.be/_CONTOSO/Users/Sy Customer standards

81 of
-
OU stem
AD Computer objects
Naming V<server type>CON-<ip range Customer naming
Convention segment><last 3 digits of server ip convention
address>
Computer objects CONTOSO.be/_CONTOSO/Systems/ Customer standards
OU XA Environment
6.5.3 Configuration
6.5.3.1 AD Sites and Services
The current AD Sites and Services design is already configured according to best practices
with a separate AD Site for each datacenter based on the IP Subnet’s of each datacenter.
6.5.3.2 Organizational Unit

6.5.3.2.1 AD computer objects OU
All Citrix –related computer objects will be located in a dedicated OU within the
CONTOSO.be active directory domain: CONTOSO.be/_CONTOSO/Systems/XA Environment
Group policy inheritance will be blocked on this OU to prevent interference of other, on a

higher level defined, AD GPO’s.
Under this “XA Environment” OU, 8 sub OU’s will be created:

 CITRIX DELIVERY CONTROLLER SERVERS: This OU will contain all Citrix Delivery
Controller servers.
 CITRIX STOREFRONT SERVERS: This OU will contain all Citrix Storefront servers.
 CITRIX PROVISIONING SERVICES SERVERS: This OU will contain all Citrix PVS servers.
 LICENSING SERVERS: This OU will contain the license server (Citrix + MS KMS + MS
RDS licensing)
 FILE SERVERS: This OU will contain all Citrix file servers (user profiles + taskflow)
 APP-V MANAGEMENT SERVERS: This OU will contain all App-V
management/publishing servers.
 APP-V SEQUENCER SERVERS: This OU will contain all App-V sequencer servers.
 CITRIX XENAPP SERVERS: This OU will contain all Citrix Xenappp servers.
 The CITRIX XENAPP SERVERS OU will have 5 subOU’s:

 MASTER: This OU will contain the MASTER Citrix Xenapp server that will be used to
ceate the PVS golden image.
 DEVELOPMENT: This OU will contain all DEVELOPMENT Citrix Xenapp servers.
 TEST: This OU will contain all TEST Citrix Xenapp servers.
 ACCEPTANCE: This OU will contain all ACCEPTANCE Citrix Xenapp servers.

82 of
-
 PRODUCTION: This OU will contain all PRODUCTION Citrix Xenapp servers.
6.5.3.2.2 AD service accounts OU

All Citrix –related AD service accounts objects will be located in a dedicated OU within the
CONTOSO.be active directory domain: CONTOSO.be/_CONTOSO/Users/System
6.5.3.2.3 AD security groups OU

9 types of security groups will be created:
 APPLICATION GROUPS: security groups that are related to application access on the
new Citrix Xenapp environment. Will be located under
CONTOSO.be/_CONTOSO/Groups/Security/Resources/Citrix
 DELIVERY GROUPS: security groups that are related to the Desktop Delivery Groups
of the new Citrix Xenapp environment. Will be located under
 DESKTOP GROUPS: security groups that are related to published desktops of the
new Citrix Xenapp environment. Will be located under
 AD GROUP POLICIES GROUPS: This OU will contain all security groups that will be
assigned to its corresponding GPO. Will be located under
CONTOSO.be/_CONTOSO/Groups/Security/Resources/GPO
 CITRIX POLICIES GROUPS: security groups that are related to certain Citrix Policy
Objects. Will be located under
 PRINTER GROUPS: security groups that are related to network print queues that
need to be mapped within the Citrix Xenapp environment. Will be located under
CONTOSO.be/_CONTOSO/Groups/Security/Resources/Printing
 LOCAL ADMINISTRATOR GROUPS: security groups that contain user accounts that
need local administrator permissions on servers. Will be located under
CONTOSO.be/_CONTOSO/Groups/Security/Resources/System
 LANGUAGE GROUP: security groups that are related to language settings. Will be
located under CONTOSO.be/_CONTOSO/Groups/Security/Resources/Citrix
 GENERAL GROUP: security groups that are related to certain Citrix-related
components of the new Citrix Xenapp environment. Will be located under
6.5.3.3 AD Group Policies

6.5.3.3.1 Naming Conventions
The following naming convention will be applied for Group Policies
SGL_GPO_CONTOSO_XA_<server scope>-<gpo settings scope>-<description>
Where:
 SGL = Security Group Local
 GPO = Group Policy Object
 CONTOSO= CONTOSO
 XA = Xenapp environment

83 of
-
 <server scope>=
 XM=Master Xenapp server
 XT=Test Xenapp server
 XA=Acceptance Xenapp server
 XP= Production Xenapp server
 DD= Delivery Controller server
 SF= Storefront server
 PV= Provisioning Services server
 LS= Licensing server
 FS= File server
 AV= App-V management/publishing server
 SQ= App-V senquencer
 <gpo settings scope> =
 USER= GPO contains only user configuration settings
 COMPUTER= GPO contains only computer configuration settings
 <description> = description of content of GPO
Group policy inheritance will be blocked on the “XA Environment” OU.
Initially, the following GPO’s will be created and configured:

1 GPO will be applied on the XA Environment OU:
 SGL_GPO_CONTOSO_XA_ALL_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains computer configuration settings and disables e.g. the Windows update service
on all computer objects that are located under this OU.
1 GPO will be applied on the CITRIX DELIVERY CONTROLLER SERVERS OU:

 SGL_GPO_CONTOSO_XA_DD_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains computer configuration settings and configures membership of the the local
administrators security group on the Citrix Delivery Controller servers.
1 GPO will be applied on the CITRIX STOREFRONT SERVERS OU:

 SGL_GPO_CONTOSO_XA_SF_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
administrators security group on the Citrix Storefront servers.
1 GPO will be applied on the LICENSING SERVERS OU:

 SGL_GPO_CONTOSO_XA_LS_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
administrators security group on the licensing servers.
1 GPO will be applied on the CITRIX PROVISIONING SERVICES SERVERS OU:

 SGL_GPO_CONTOSO_XA_PV_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
administrators security group on the Citrix PVS servers.

84 of
-
1 GPO will be applied on the FILE SERVERS OU:

 SGL_GPO_CONTOSO_XA_FS_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
administrators security group on the file servers.
1 GPO will be applied on the APPV MANAGEMENT SERVERS OU:

 SGL_GPO_CONTOSO_XA_AV_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
administrators security group on the App-V management servers.
12 GPO’s will be applied on the CITRIX XENAPP SERVERS/DEVELOPMENT OU:

 SGL_GPO_CONTOSO_XA_XD_COMPUTER_IE: this GPO contains computer configuration
settings related to Internet Explorer that are applied to all DEVELOPMENT Citrix Xenapp
servers. This GPO takes care of configuring IE settings on computer level.
 SGL_GPO_CONTOSO_XA_XD_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains general computer configuration settings that are applied to all DEVELOPMENT
Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XD_USER_DEFAULT_USERS_CONFIG: this GPO contains
general user configuration settings that are applied to all normal end users who connect
to DEVELOPMENT Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XD_USER_DEFAULT_ADMINS_CONFIG: this GPO contains
user configuration settings that are applied to only admin users who connect to
DEVELOPMENT Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XD_USER_IE: this GPO contains user configuration settings
related to Internet Explorer that are applied to all normal end users who connect to
DEVELOPMENT Citrix Xenapp servers. This GPO takes care of configuring IE settings on
user level.
 SGL_GPO_CONTOSO_XA_XD_USER_OFFICE_2010: this GPO contains user configuration
settings that are applied to end users who have access to Office 2010 applications on
DEVELOPMENT Citrix Xenapp servers. This GPO takes care of configuring office 2010
settings on user level.
 SGL_GPO_CONTOSO_XA_XD_COMPUTER_CITRIX_POLICIES: this GPO contains
computer configuration settings related to Citrix policies that are applied to
 SGL_GPO_CONTOSO_XA_XD_USER_CITRIX_POLICIES: this GPO contains user
configuration settings related to Citrix policies that are applied to DEVELOPMENT Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XD_COMPUTER_APPLOCKER: this GPO contains computer
configuration settings related to Applocker that are applied to DEVELOPMENT Citrix
Xenapp servers. This GPO takes care of lock-down of the user environment as it
manages which executables are allowed to run.
 SGL_GPO_CONTOSO_XA_XD_USER_DUTCH_UI: this GPO contains user configuration
settings that are applied to normal users that require Dutch language interface on

85 of
-
 SGL_GPO_CONTOSO_XA_XD_USER_FRENCH_UI: this GPO contains user configuration

settings that are applied to normal users that require French language interface on
 SGL_GPO_CONTOSO_XA_XD_USER_VISUALLY_IMPAIRED_USERS_CONFIG: this GPO
contains user configuration settings that are applied to visually impaired users who need
to be able to change DPI settings on DEVELOPMENT Citrix Xenapp servers.
12 GPO’s will be applied on the CITRIX XENAPP SERVERS/TEST OU:

 SGL_GPO_CONTOSO_XA_XT_COMPUTER_IE: this GPO contains computer configuration
settings related to Internet Explorer that are applied to all TEST Citrix Xenapp servers.
This GPO takes care of configuring IE settings on computer level.
 SGL_GPO_CONTOSO_XA_XT_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains general computer configuration settings that are applied to all TEST Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XT_USER_DEFAULT_USERS_CONFIG: this GPO contains
to TEST Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XT_USER_DEFAULT_ADMINS_CONFIG: this GPO contains user
configuration settings that are applied to only admin users who connect to TEST Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XT_USER_IE: this GPO contains user configuration settings
TEST Citrix Xenapp servers. This GPO takes care of configuring IE settings on user level.
 SGL_GPO_CONTOSO_XA_XT_USER_OFFICE_2010: this GPO contains user configuration
TEST Citrix Xenapp servers. This GPO takes care of configuring office 2010 settings on
user level.
 SGL_GPO_CONTOSO_XA_XT_COMPUTER_CITRIX_POLICIES: this GPO contains
computer configuration settings related to Citrix policies that are applied to TEST Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XT_USER_CITRIX_POLICIES: this GPO contains user
configuration settings related to Citrix policies that are applied to TEST Citrix Xenapp
servers.
 SGL_GPO_CONTOSO_XA_XT_COMPUTER_APPLOCKER: this GPO contains computer
configuration settings related to Applocker that are applied to TEST Citrix Xenapp
servers. This GPO takes care of lock-down of the user environment as it manages which
executables are allowed to run.
 SGL_GPO_CONTOSO_XA_XT_USER_DUTCH_UI: this GPO contains user configuration
settings that are applied to normal users that require Dutch language interface on TEST
 SGL_GPO_CONTOSO_XA_XT_USER_FRENCH_UI: this GPO contains user configuration
settings that are applied to normal users that require French language interface on TEST
 SGL_GPO_CONTOSO_XA_XT_USER_VISUALLY_IMPAIRED_USERS_CONFIG: this GPO
to be able to change DPI settings on TEST Citrix Xenapp servers.
12 GPO’s will be applied on the CITRIX XENAPP SERVERS/ACCEPTANCE OU:

86 of
-
 SGL_GPO_CONTOSO_XA_XA_COMPUTER_IE: this GPO contains computer configuration

settings related to Internet Explorer that are applied to all ACCEPTANCE Citrix Xenapp
 SGL_GPO_CONTOSO_XA_XA_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains general computer configuration settings that are applied to all ACCEPTANCE
 SGL_GPO_CONTOSO_XA_XA_USER_DEFAULT_USERS_CONFIG: this GPO contains
to ACCEPTANCE Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XA_USER_DEFAULT_ADMINS_CONFIG: this GPO contains
user configuration settings that are applied to only admin users who connect to
ACCEPTANCE Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XA_USER_IE: this GPO contains user configuration settings
ACCEPTANCE Citrix Xenapp servers. This GPO takes care of configuring IE settings on user
level.
 SGL_GPO_CONTOSO_XA_XA_USER_OFFICE_2010: this GPO contains user configuration
ACCEPTANCE Citrix Xenapp servers. This GPO takes care of configuring office 2010
 SGL_GPO_CONTOSO_XA_XA_COMPUTER_CITRIX_POLICIES: this GPO contains
 SGL_GPO_CONTOSO_XA_XA_USER_CITRIX_POLICIES: this GPO contains user
configuration settings related to Citrix policies that are applied to ACCEPTANCE Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XA_COMPUTER_APPLOCKER: this GPO contains computer
configuration settings related to Applocker that are applied to ACCEPTANCE Citrix
 SGL_GPO_CONTOSO_XA_XA_USER_DUTCH_UI: this GPO contains user configuration
 SGL_GPO_CONTOSO_XA_XA_USER_FRENCH_UI: this GPO contains user configuration
 SGL_GPO_CONTOSO_XA_XA_USER_VISUALLY_IMPAIRED_USERS_CONFIG: this GPO
to be able to change DPI settings on ACCEPTANCE Citrix Xenapp servers.
12 GPO’s will be applied on the CITRIX XENAPP SERVERS/PRODUCTION OU:

 SGL_GPO_CONTOSO_XA_XP_COMPUTER_IE: this GPO contains computer configuration
settings related to Internet Explorer that are applied to all PRODUCTION Citrix Xenapp
 SGL_GPO_CONTOSO_XA_XP_COMPUTER_DEFAULT_SERVER_CONFIG: this GPO
contains general computer configuration settings that are applied to all PRODUCTION

87 of
-
 SGL_GPO_CONTOSO_XA_XP_USER_DEFAULT_USERS_CONFIG: this GPO contains

to PRODUCTION Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XP_USER_DEFAULT_ADMINS_CONFIG: this GPO contains user
configuration settings that are applied to only admin users who connect to PRODUCTION
 SGL_GPO_CONTOSO_XA_XP_USER_IE: this GPO contains user configuration settings
PRODUCTION Citrix Xenapp servers. This GPO takes care of configuring IE settings on
user level.
 SGL_GPO_CONTOSO_XA_XP_USER_OFFICE_2010: this GPO contains user configuration
PRODUCTION Citrix Xenapp servers. This GPO takes care of configuring office 2010
 SGL_GPO_CONTOSO_XA_XP_COMPUTER_CITRIX_POLICIES: this GPO contains
PRODUCTION Citrix Xenapp servers.
 SGL_GPO_CONTOSO_XA_XP_USER_CITRIX_POLICIES: this GPO contains user
configuration settings related to Citrix policies that are applied to PRODUCTION Citrix
Xenapp servers.
 SGL_GPO_CONTOSO_XA_XP_COMPUTER_APPLOCKER: this GPO contains computer
configuration settings related to Applocker that are applied to PRODUCTION Citrix
 SGL_GPO_CONTOSO_XA_XP_USER_DUTCH_UI: this GPO contains user configuration
 SGL_GPO_CONTOSO_XA_XP_USER_FRENCH_UI: this GPO contains user configuration
 SGL_GPO_CONTOSO_XA_XP_USER_VISUALLY_IMPAIRED_USERS_CONFIG: this GPO
to be able to change DPI settings on PRODUCTION Citrix Xenapp servers.
6.5.3.4 AD security Groups
Multiple AD security groups will need to be used by various components in the new XenApp
environment. AD Security groups will be used to grant users access to resources such as
applications.
AD global security group, which will contain all user objects and/or other group objects that
have access to the resource and will also be used to grant access to required resources. This
is customer choice.
For the new Citrix Xenapp environment, 8 different security group types will be used:
 APPLICATION GROUPS: security groups that are related to application access on the
new Citrix Xenapp environment.

88 of
-
 DELIVERY GROUPS: security groups that are related to the Desktop Delivery Groups of
the new Citrix Xenapp environment.
 DESKTOP GROUPS: security groups that are related to published desktops of the new
Citrix Xenapp environment.
 AD GROUP POLICIES GROUPS: security groups that will be assigned to its corresponding
AD GPO
 CITRIX POLICIES GROUPS: security groups that are related to certain Citrix Policy
Objects.
 PRINTER GROUPS: security groups that are related to network print queues that need to
be mapped within the Citrix Xenapp environment.
 LOCAL ADMINISTRATOR GROUPS: security groups to give local administrator
permissions on each server.
 LANGUAGE GROUPS: security groups to be able to assign the correct (dutch or French)
language interface to end users.
 GENERAL GROUPS: security groups that are related to certain Citrix-related components
of the new Citrix Xenapp environment.
6.5.3.4.1 Naming convention

6.5.3.4.1.1 Application groups
Purpose: to give users access to only authorized applications.
The following naming convention will be applied for application groups :
SGU_XA_APP-<Application name>
Where:
 SGU= Security Group Universal
 XA= Xenapp environment
 APP = Application
 <Application name> = corresponding application name for the security group
E.g. The security group that contains all user objects that will have access to the Office 2010
applications will get the following naming: SGU_XA_APP-OFFICE2010
6.5.3.4.1.2 Delivery groups

Purpose: to give users access to only authorized Citrix Delivery Groups.
The following naming convention will be applied for Desktop Delivery Groups groups:
SGU_XA_DDG-<Delivery group name>
Where:

89 of
-

 DDG = Desktop Delivery Group
 <Desktop name> = corresponding Desktop name for the security group
There will be 4 desktop delivery groups:

 SGU_XA_DDG_XA_W2012R2_DESKTOPS_APPS_DEVELOPMENT
 SGU_XA_DDG_XA_W2012R2_DESKTOPS_APPS_TEST
 SGU_XA_DDG_XA_W2012R2_DESKTOPS_APPS_ACCEPTANCE
 SGU_XA_DDG_XA_W2012R2_DESKTOPS_APPS_PRODUCTION
6.5.3.4.1.3 Desktop groups

Purpose: to give users access to only authorized published desktops.
The following naming convention will be applied for published desktops groups:
SGU_XA_DES-<Desktop name>
Where:
 DES = Desktop
 <Desktop name> = corresponding Desktop name for the security group
There will be 4 desktop groups:

 SGU_XA_DES-DEVELOPMENT-DESKTOP
 SGU_XA_DES-TEST-DESKTOP
 SGU_XA_DES-ACCEPTANCE-DESKTOP
 SGU_XA_DES-PRODUCTION-DESKTOP
6.5.3.4.1.4 Language groups

Purpose: to give users to correct Language UI within the Windows desktop.
The following naming convention will be applied for language groups:
SGU_XA_L-<language>
Where:
 LAN = Language
 <language> = corresponding laguage

90 of
-
There will be 2 language groups:

 SGU_XA_LAN-FRENCH
 SGU_XA_LAN-DUTCH
Users not belonging to one of the above groups will have English as language UI.
6.5.3.4.1.5 AD Group Policies Groups

Purpose: to give users access to only authorized AD GPO.
The following naming convention will be applied for AD GPO groups:
SGL_GPO_CONTOSO_XA_<Citrix component>_<description>
Where:
 SGL= Security Group Local
 GPO=Group Policy Object
 CONTOSO= CONTOSO
 <Citrix Component>=
 ALL= All Citrix-related servers
 FS= File server
 <Description> = corresponding description of AD GPO
E.g. The security group that contains all AD objects that will have GPO
“SGL_GPO_CONTOSO_XA_XT_USER_DEFAULT_USERS_CONFIG” applied will be named:
SGL_GPO_CONTOSO_XA_XT_USER_DEFAULT_USERS_CONFIG
6.5.3.4.1.6 Citrix Policies Groups

Purpose: to assign certain users to a Citrix policy object.
The following naming convention will be applied for Citrix policy groups:
SGU_XA_CTX-<Citrix Policy name>

91 of
-
Where:
 CTX = Citrix Policy
 <Citrix Policy name> = corresponding Citrix policy name
E.g. The security group that contains all AD objects that will have Citrix Policy
“CLIENT_DRIVE_MAPPING_ALLOWED” applied will be named:
SGU_XA_CTX_CLIENT_DRIVE_MAPPING_ALLOWED
6.5.3.4.1.7 Printer groups
Purpose: to map correct network print queues per user
The following naming convention will be applied for printer groups:
SGL_PS_<print server name>_<print queue name>
Where:
 SGL= Security Group Local
 PS=PrintServer
 <print server name> = print server name
 <print queue name> = corresponding print queue name for the security group
E.g. The security group that contains all user objects that will have print queue “PRN-CON-
Secure_PCL” from print server VPSCON-1009 mapped within the new Citrix Xenapp
environment will get the following naming: SGL_PS_ VPSCON-1009_PRN-CON-Secure_PCL
6.5.3.4.1.8 Local administrators groups

The following naming convention will be applied for general Citrix related groups:
SGL_SYS_<server name>_LocalAdministrators
Where:
 SGL = Security Group Local
 SYS = System
 <server name> = server name
 LocalAdministrators = will be added to local administrator group of the server
E.g. The security group that contains all user objects that will have admin privileges on the
Citrix file servers will get the following naming: SGL_SYS_vfscon-1208_LocalAdministrators

92 of
-
E.g. The security group that contains all user objects that will have admin privileges on the
production Citrix Xenapp servers will get the following naming: SGL_SYS_vxpcon-1221-
1230_LocalAdministrators
6.5.3.4.1.9 General groups

Purpose: to give correct permission level on Citrix Xenapp, PVS and MS APP-V environments.
The following naming convention will be applied for general group:
SGU_XA_GEN-<scope>
Where:
 GEN = General
 <scope> =
 XA-ADMINISTRATORS = administrator permissions on Citrix Xenapp environment
 XA-SERVICEDESK = servicedesk permissions on Citrix Xenapp environment
 XA-USERS= user permissions on Citrix Xenapp environment
 PVS-ADMINISTRATORS= administrator permissions on Citrix PVS environment
 APPV-ADMINISTRATORS= administrator permissions on AppV environment
6.5.3.5 Service Accounts

The following naming convention will be applied for service accounts:
Sysxa<description>
Where:
 Sys= system
 Xa= Xenapp environment
 <description>= description of service account>
The following service accounts will be required:
SA Account Name Domain Description

Admin?
sysxapvs Yes Citrix Provisioning Services: account for database
connection + rights in AD OU for updating computer
objects
sysxataskflow No Taskflow: service account performing the installations

93 of
-
on each XenApp server

sysxanetscaler No Citrix Netscaler service account for LDAPS connection
from Citrix Netscaler appliances
6.5.3.6 Computer objects

All AD computer objects that are related to the new Citrix Xenapp environment will be will
be created in the OU: CONTOSO.be/_CONTOSO/Systems/XA Environment

The following naming convention will be applied for computer objects:
V<server type>CON-<ip range segment><last 3 digits of server ip address>
Where:
 V = Virtual
 <server type>:
 FS= File server
 CON = Brussels datacenter
 <iprange segment>= will be 1
 <last 3 digits of server ip address> = will be in the range of 200 to 235
E.g. The first production Xenapp server will be named vxpcon-1222
6.6 Print Servers

Print servers are an important component within a XenApp environment. Ideally the print
servers used by XenApp servers are based on the same Operating System and processor
architecture as the XenApp servers to prevent print driver conflicts.
For the new XenApp environment, the existing print server, vpscon-1009, will be used, this
has customer preference. The print servers will be based on Windows Server 2008 R2.

94 of
-
6.7 IGEL UMS server

6.7.1 Overview
The Universal Management Suite (UMS) is an easy-to-use yet extremely powerful software
that allows you to remotely manage your IGEL thin and zero clients so that support costs are
kept to a minimum. It is extremely open and network friendly so that it can fit into your
organization’s existing infrastructure.
Typical uses:
 Automatically setting up thin and zero clients with the right profile when they first attach
to the network
 Changing the settings of the device or its local protocols and software tools
 Re-imaging devices mid-life when new firmware becomes available, diagnostics and
support
vmgcon-1071 192.168.1.71 4 4 GB 50 GB

Igel UMS server 1 server, vmgcon-1071 Existing UMS server
Igel UMS version 4.09.110 Latest stable igel UMS
version
Igel UMS HA N/A High availability not
required on UMS level for
this environment
Igel Thin clients  UD3-420 LX Thin clients already
 UD3-421 LX purchased and used by
 UD3-430 LX Customer
 UD3-431 LX
 UD3-W7 40C
Igel firmware versions  LX 4.14.100 Latest stable Igel
 LX 5.07.100 firmware version
 ES 3.10.120 available
Igel LX Multimedia Codec Not used Igel LX multimedia codec
pack pack is not purchased an
used by customer

95 of
-
Igel UMS profiles folder  A folder per thin client ACME best practices
structure firmware version
Igel UMS profiles  Per Thin client ACME best practices
firmware version
 One baseline profile
per thin client version
 A separate profile per
thin client version for
following task areas:
 Firmware Update
 GFX
 Hardware –
printer
 Keyboard
 Mouse
 Sound
Igel UMS thin client folder  A folder per thin client ACME best practices
structure firmware version
 A department folder
per firmware version
folder
6.7.4 Configuration
6.7.4.1 General information
The existing Igel UMS server, vmgcon-1071, will be used to manage the Igel thin clients that
will connect to the new Citrix Xenapp environment.
Igel UMS version 4.09.110 is running on this server.
Igel UMS HA will not be setup as this is not required within this environment.
The following Igel thin clients are currently used within the environment:
 UD3-420 LX
 UD3-421 LX
 UD3-430 LX
 UD3-431 LX
 UD3-W7 40C
The latest stable Igel firmware versions will be used:

 LX 4.14.100
 LX 5.07.100
 ES 3.10.120
The multimedia codec pack is not installed on the Igel LX thin clients.

96 of
-
6.7.4.2 Igel UMS profile information

6.7.4.2.1 Igel UMS profile folder structure
According to ACME best practices and to keep the Igel UMS environment as clean and
simple as possible whilst not giving in on flexibility, a IGEL UMS folder will be created for
each Igel firmware version:
 Universal Desktop ES 3_10_120
 Universal Desktop LX 4_14_100
The following subfolders will be created below each Igel firmware version folder:
6.7.4.2.2 Igel UMS profiles

Regarding Igel UMS profiles:
 A baseline profile will be created for each Igel firmware version with the default settings
that will apply to all thin clients with the same firmware version
 Multiple specific profiles that will contain specific settings and will be applied to specific
thin clients devices and/or thin client folders.
The naming convention for profiles will be:
<folder>_<section>_<description>
Where:
 Folder = the folder to which the profile belongs
 Section = the profile section of the configured settings
 Description = description of the settings that are configured within the profile
Intially the following profiles will be configured for each igel firmware version:
 BASELINE: this profile contains all the default settings that will be applied to all thin
clients that have the same firmware version.
 FIRMWARE_UPDATE: this profile contains settings that are required to perform a
firmware upgrade for thin clients that have the same firmware version.
 GFX_RESOLUTION_1280x1024_1280x1024_DUAL-MONITOR: this profile contains
screen resolution settings for thin clients that have two monitors with 1280x1024
resolution.

97 of
-
 GFX_RESOLUTION_1280x1024_SINGLE-MONITOR: this profile contains screen

resolution settings for thin clients that have one monitor with 1280x1024 resolution.
 PRINTER_USB_HP4350_GENERIC_RAWQUEUE: this profile contains printer settings for
thin clients that have a HP 4350 local USB printer attached.
 KEYBOARD_KEYBOARD-LAYOUT_DUTCH-BELGIUM: this profile contains keyboard
settings for thin clients that keyboard with Belgian keyboard layout.
 MOUSE_SPEED_SLOW: this profile contains mouse settings for thin clients that require
slow mouse speed settings.
 SOUND_ENABLED: this profiles contains sound settings to enable audio for Citrix
sessions.
This results in the following configuration within the IGEL UMS console:
6.7.4.3 Igel UMS thin clients information

6.7.4.3.1 Igel UMS thin clients folder structure
According to ACME best practices and to keep the Igel UMS environment as clean and simple
as possible whilst not giving in on flexibility, a IGEL UMS folder will be created for each Igel
firmware version:
 Universal Desktop ES 3_10_120
The following subfolders will be created below each Igel firmware version folder:

98 of
-
6.8 File Servers

6.8.1 Overview
One new file server based on the 2012 R2 operating system will be used for:
 hosting the file shares for Taskflow
 hosting Citrix user profiles
 hosting certain folder redirections such as desktop, favorites, appdata, and cookies.

Operating System Windows server 2012 R2 Latest Windows server OS
standard edition
High Availability Xenserver hypervisor HA Sufficient HA without
adding any unnecessary
complexity
vfscon-1208 LAN: 192.168.1.208 2 12 GB C:\60 GB (virtual disk)

99 of
-
Iscsi:192.168.100.20 E:\300GB (Iscsi disk)

8
6.8.4 Configuration
The file servers will host the file shares:
 Taskflow$ share hosting the Taskflow console, master share, status share and
installation sources.
 Userconfig$ share hosting:
 Citrix user profile for each user
 Redirected user shell folders for each user:
 Desktop
 Favorites
 Links
 Appdata (Roaming)
Description File Share Physical Path
User config share hosting the Citrix \\vfscon-1208\userconfig$ E:\userconfig

user profiles and redirected user
shell folders
Taskflow share hosting the \\vfscon-1028\taskflow$ E:\taskflow
Taskflow console, master share,
status share and installation
sources
6.9 License Servers

6.9.1 Overview
For the new XenApp environment, one new license server will be installed. The license
servers will be used as Citrix license servers, Microsoft KMS host for Windows server 2012 R2
and Office 2010 licensing and Microsoft RDS license servers.

100
- of

License Server High Hypervisor HA Hypervisor HA should be
Availability sufficient and keeps HA
for this component simple
Citrix License Server

License server  Vlscon-1209
License type  Xenapp Platinum Customer preference
 Xenserver enterprise
per socket
License count  200 Xenapp Platinum Customer preference
CCU
 14 Xenserver
enterprise per socket
License server port 27000 Default & recommended
value
License server HA Hypervisor HA Hypervisor HA is
sufficient for Citrix license
server
MS RDS License Server
License Type Per User Customer preference
License count 200 Customer preference
License server HA Hypervisor HA Hypervisor HA is
sufficient for this
environment
KMS Host
Windows server 2012 R2 V6Q99-VXBQK-9MXK6- KMS licensing is preferred
key HDRP7-RVQY4 licensing method in
combination with Citrix
PVS
Office 2010 key PRR4X-7RVJP-MBHR3- KMS licensing is preferred
D4PX6-R7DXJ licensing method in
combination with Citrix
PVS
office 2013 key (for Lync YM7TR-42BH4-8C8HK- KMS licensing is preferred
2013 / Skype for Business 3WCKF-JPH9X licensing method in
2015) combination with Citrix

101
- of
PVS

vlscon-1209 192.168.1.209 1 4gb 60gb
6.9.4 Configuration
6.9.4.1 Citrix License Server
A Citrix License Server is required to be compliant with Citrix licensing. The License Server is
used by the Xenserver hosts, XenApp Delivery controllers, XenApp servers and Citrix
Provisioning Servers.
When the Citrix license server is unavailable, XenApp servers enter a grace period.
Xenserver, XenApp and PVS have a grace period of 30 days.
The license server component will be installed on server vlscon-1209 using default port
27000.
The Citrix licenses will be installed on the new license server:
- 200 XenApp platinum edition concurrent user licenses
- 12 per socket Xenserver enterprise licenses (covers 6 x 2 socket CPU servers)
AD user account needs to be member of AD security group “SGL_SYS_vlscon-

1209_LocalAdministrators” to be able to manage the Citrix licenses on the Citrix license
server.
Hypervisor HA will be used as HA for this component.
6.9.4.2 MS RDS License Server

Citrix XenApp builds upon Microsoft RDS. In addition to XenApp, also the MS RDS
component needs to be licensed utilizing a RDS License Server.
Each RDS host (XenApp server) requires a functioning RDS License Server to accept
connections.
A Windows 2012 R2 RDS Session host server needs a 2012 R2 RDS licensing server and RDS
CAL’s for 2012.
The license server that is used for Citrix licensing, vlscon-1209, will also be used as RDS
licensing server.
200 Windows server 2012 R2 RDS User licenses are installed.

102
- of
An AD GPO “SGL_GPO_CONTOSO_XA_<dtap env>_COMPUTER_DEFAULT_SERVER_CONFIG”

is used to assign MS RDS licensing server to all Citrix Xenapp servers.
Hypervisor HA will be used as HA for this component.
IMPORTANT: HYPERVISOR HA WILL BE USED TO ENSURE BASIC HA SOLUTION FOR THIS COMPONENT.
HOWEVER, TO ENSURE 99,99% AVAILABILITY ON RDS LICENSING COMPONENT, PLEASE INSTALL AND
CONFIGURE A SECOND RDS LICENSING SERVER WITH NO RDS CAL’S AND ADJUST GPO
“SGL_GPO_CONTOSO_XA_<DTAP ENV>_COMPUTER_DEFAULT_SERVER_CONFIG” TO
INCLUDE THIS EXTRA RDS LICENSING SERVER.
6.9.4.3 MS KMS host

As Citrix Provisioning services will be used and we will take advantage of its single image
management, it is challenging to get MS OS and Office licensing right. There are 2 types of
licensing activation available: MAK and KMS.
MAK activation method within Citrix PVS environments is complex and not easy to manage,
therefore it is highly recommended to use KMS activation method for Windows server OS as
well as Office when working with Citrix PVS.
The new license server will function as MS KMS host for Windows server 2012 R2 as well as
Office 2010.
The following keys will be used:
 MS Windows server 2012 R2: V6Q99-VXBQK-9MXK6-HDRP7-RVQY4
 MS Office 2010: PRR4X-7RVJP-MBHR3-D4PX6-R7DXJ
 MS Office 2013: YM7TR-42BH4-8C8HK-3WCKF-JPH9X

The license servers need to be high available. The HA features of the hypervisor will be used
to provide high availability.
Additionally a snapshot / backup of the license server VM can be created to restore the
license server when required.
In case the primary RDS license server does go offline, it is key to bring it up and running
again as soon as possible. If zero downtime is required, a second RDS license server with no
licenses should be implemented so it can offer temporary RDS licenses when the primary
RDS license server is not available.
For Citrix Licensing, XenApp and PVS will enter a grace period of 30 days when the primary
license server is unavailable. There is no immediate benefit of installing the Citrix License
Server component on the second server other than preparing it already for a future role as
Citrix license server.
KMS activations are valid for 180 days—the activation validity interval. To remain activated,
KMS client computers must renew their activation by connecting to the KMS host at least
once every 180 days. By default, KMS client computers attempt to renew their activation
every seven days. If KMS activation fails , the client will retry every two hours. After a client
computer’s activation is renewed, the activation validity interval begins again.

103
- of
7 Hardware Layer
The hardware layer is responsible for the physical devices required to support the entire
solution including servers, and storage devices. Specific Hardware Layer components and
design decisions are based on the completed design of the above layers (User, Access,
Desktop and Control).

Physical Hardware
# Physical Servers 6 Customer’s choice
Vendor + Model Dell Poweredge R620 Customer’s choice
Physical Specs  2 x Intel Xeon E5-2650v2 8- Customer’s choice
core 2.6 ghz
 4 hosts with 196 GB RAM + 2
hosts with 262 GB RAM
 2 x 124 GB RAID1
 6 x 1Gbps NIC
Hypervisor
Hypervisor Software Citrix XenServer Enterprise Preferred hypervisor
edition of CONTOSO
XenServer version 6.5 SP1 Latest version
available
Xenserver Pools 1 Pool: Xenserver R620 Pool 1 Pool is more than
Section: Hardware www.ACME.

104
- of
sufficient.
Workload separation? No separate Xenserver pool but Important to have
2 dedicated Xenserver hosts dedicated Xenserver
within pool for Xenapp workload hosts for Xenapp
workload to make sure
that Xenapp servers
have sufficient system
resources (no CPU
overcommitment).
Local Storage 124GB RAID1 Local storage only
used for Xenserver
installation.
Shared Storage 2 new SR will be created to host Important to have
VMs of new Citrix Xenapp sufficient and
environment: performant shared
 ISCSI-XENLUN-R620POOL1- storage
SAS
 ISCSI-XENLUN-R620POOL2-
SAS
Network config 4 network configs: Xenserver best
 Bond 0+1 SAN: storage practices, best
 Bond 2+3 LAN: VM traffic configuration in
 Network 5 Mgt: customer’s situation
management
 Network 4: DMZ
7.1.3 Design
7.1.3.1 Physical Hardware
The XenApp servers as well as the related infrastructure servers will be virtual machines
running on a hypervisor environment hosted on 6 physical servers.
4 Physical servers will be used for infrastructure server workload while 2 physical servers will
be used for Xenapp workload. As mentioned before, all physical servers will run Xenserver
hypervisor and all Xenapp and infrastructure servers will run as virtual machines.
Each physical server has the following specs:
Item Specification
Vendor + Model Dell Poweredge R620
CPU 2 x Intel Xeon E5-2650v2 8-core 2.6 ghz

105
- of
RAM  4 hosts with 196 GB RAM

 2 hosts with 262 GB RAM
Local HDD 2 x 124GB RAID1

Network 6 x 1GB NIC
7.1.3.2 Hypervisor
7.1.3.2.1 Hypervisor vendor
In order to fully use the new hardware, a hypervisor will be used to allow multiple XenApp
servers to be used on the same physical box.
The hypervisor to be used is Citrix XenServer Enteprise edition (commercial version)
because:
- This hypervisor is optimized for Citrix Xenapp workload
- CONTOSO is already using XenServer for the current virtual server environment,
including the currently used Citrix Xenapp environment and already has knowledge
about the product.
The XenServer version used will be version 6.5 SP1.
This is the latest version available and should fully support the hardware.
7.1.3.2.2 Xenserver workload separation

As CPU overcommitment should be avoided for Citrix Xenapp servers, it is important to have
dedicated Xenserver hosts available that will host only production Citrix Xenapp workload.
Therefore we will reserve 2 Citrix Xenserver hosts, SXSCON-1020 and SXSCON-1023, for
hosting only the production Citrix Xenapp servers.
The remaining Citrix Xenserver hosts will host the infrastructure workload. CPU
overcommitment is allowed on these Xenserver hosts as Infrastructure workload are in
general ideal candidates to maximize the virtual server consolidation ratio and take
advantage of using the Hypervisor CPU scheduler.
This results in the following VM placement strategy on the Xenserver environment:

106
- of
This also results in the following vCPU and memory assignment per Citrix Xenserver host:
Xenserver host # vCPU Current # total Current Workload
Assigned RAM free
vCPU RAM
SXSCON-1018 32 57 262 GB 140 GB Infra
SXSCON-1020 32 28 196 GB 2 GB Xenapp
SXSCON-1023 32 28 196 GB 2 GB Xenapp
7.1.3.2.3 XenServer Pool configuration

To simplify management and also take advantage of advanced features such as High
availability, all 6 XenServer hosts are member of one XenServer pool called “Xenserver R620
Pool”.
7.1.3.2.4 Xenserver network configuration

4 networks are configured on the Xenserver environment:
Network name NIC VLAN Auto Link status Speed MTU Bond
mode
Bond 0+1 SAN Bond 0+1 - No Connected 2000 9000 Active-
Mbit/s Active
Bond 2+3 LAN Bond 2+3 - Yes Connected 2000 9000 Active-
Mbit/s Active
Network 4 DMZ NIC 4 - No Connected 100 1500 N/A
Mbit/s
Network 5 Mgt NIC 5 - No Connected 1000 1500 N/A
Mbit/s
Currently there is no need for multiple VLAN’s so the ports will be configured as access ports
on the switch.
The Management IP’s of the XenServer hosts will be located in the same subnet as the VM’s.
Management Network Configuration

Xenserver Interface Network NIC IP address Subnet mask Gateway DNS
name
SXSCON-1018 Management Network 5 NIC 5 192.168.1.1 255.255.240.0 192.168.15. 192.168.
Mgt 8 253 1.1
192.168.
1.3

107
- of

Mgt 9 253 1.1
192.168.
1.3
Mgt 0 253 1.1
192.168.
1.3
Mgt 1 253 1.1
192.168.
1.3
Mgt 2 253 1.1
192.168.
1.3
Mgt 3 253 1.1
192.168.
1.3
Storage Network configuration

Xenserver Interface Network NIC IP address Subnet mask Gateway DNS
name
SXSCON-1018 Bond 0+1 SAN Bond 0+1 Bond 192.168.100.180 255.255.255.0 N/A N/A
SAN 0+1
SAN 0+1
SAN 0+1
SAN 0+1
SAN 0+1
SAN 0+1
7.1.3.2.5 Xenserver storage configuration

Local Storage
Each physical host has 2 local disks of 124GB.
The disks will be configured in RAID1 in order to have a redundant, fast, local disk of 124GB.
The local storage will only be used to install the Xenserver software.
Shared storage
Shared storage will be used.

108
- of
2 new Storage repositories of each 1000 GB should be created to host disk of VM’s that are
related to the new Citrix Xenapp environment:
 ISCSI-XENLUN-R620POOL1-SAS
 ISCSI-XENLUN-R620POOL2-SAS
This will result in a total of 10 storage repositories:

SR name Type Total disk Free disk Address HA Workload
space space
ISCSI-XENLUN- LVM 500 MB 240 GB 192.168.100.3 HA Xenserver HA
R620POOL- over Heartbeat
HeartBeat-SAS2 iSCSI SR
ISCSI-XENLUN- LVM 1000 GB 200 GB 192.168.100.3 N/A Non Xenapp related
R620POOL1-SAS2 over infrastructure VMs
iSCSI
iSCSI
iSCSI
iSCSI
iSCSI
R620POOL4-SATA over infrastructure VMs
iSCSI
VFSCON-1004 CIFS ISO 192.168.1.4 N/A ISO repository
ISO Library
ISCSI-XENLUN- LVM 1000 GB 530 GB 192.168.100.1 N/A Xenapp related
R620POOL1-SAS over infrastructure VMs
iSCSI
ISCSI-XENLUN- LVM 1000 GB 550 GB* 192.168.100.1 N/A Xenapp related
R620POOL2-SAS over infrastructure VMs
iSCSI
*Some free disk space is required for App-V Sequencer VM snapshot functionality

109
- of
8 Monitoring
By having an in-depth understanding of current and expected behavior of the Citrix environment and its components, administrators are better equipped to
discover an issue before it impacts the user community. Furthermore the data tracked during normal operations can be used for trending and capacity
planning. This section defines how a Citrix environment should be monitored, as well as some common tools that can be used.
8.1 Performance monitor metrics

Monitoring the performance of the overall environment is crucial towards making sure all components are available and performing effectively to ensure
users have a high quality experience.
Different components within the overall solution require monitoring of unique metrics with appropriately set thresholds. The metrics and thresholds
presented are based on real world experience but may not apply to all environments. Organizations will need to perform their own baselining, validity
testing and validation before implementing within a production environment.
Note: Some hypervisors, such as Citrix Xenserver, VMware vSphere and MS Hyper-V, provide specific performance counters for tracking CPU and Memory
utilization within virtual machines (i.e. “VM Processor \ % Processor Time”). These performance counters should be used in addition to the general counters
listed below.
Section: www.ACME.
119
- of
8.1.1 Generic performance monitor metrics

These performance counters should be used to monitor the key performance metrics of all virtual machines that are related to the Citrix infrastructure.
Metric Description Warning (Yellow) Critical (Red) Troubleshooting/Remediation
Processor - % % Processor Time is the percentage of elapsed time that the processor 80% for 15 minutes 95% for 15 minutes Identify the processes/services consuming processor time
Processor Time spends to execute a non-Idle thread. It is calculated by measuring the using Task Manager or Resource Monitor.
duration of the idle thread is active in the sample interval, and subtracting If all processes/services work within normal parameters and
that time from interval duration. (Each processor has an idle thread that the level of CPU consumption is an expected behavior it
consumes cycles when no other threads are ready to run). This counter is should be considered to add additional CPU resources to this
the primary indicator of processor activity, and displays the average system in the future.
percentage of busy time observed during the sample interval. It is calculated
by monitoring the time that the service is inactive and subtracting that value If a process/service can be identified which works outside
from 100%. normal parameters, the process should be killed. Please note
that killing a process can cause unsaved data to be lost.
System - Processor Processor queue length is the number of threads in the processor queue. 5 (per core) for 10 (per Core) for 10 A long CPU queue is a clear symptom of a CPU bottleneck.
Queue Length Unlike the disk counters, this counter shows ready threads only, not threads 5 minutes minutes Please follow the steps outlined for counter “Processor -
that are running. There is a single queue for processor time even on
computers with multiple processors. Therefore, if a computer has multiple or or % Processor Time”.
processors, you need to divide this value by the number of processors 6 (per core) for 15 12 (per core) for 30
servicing the workload. A sustained processor queue of less than ten minutes minutes
threads per processor is normally acceptable, dependent of the workload.
Memory - Available Available memory indicates the amount of memory that is left after <30% of total RAM <15% of total RAM Identify the processes/services consuming memory using
Bytes nonpaged pool allocations, paged pool allocations, process’ working sets, or or Task Manager or Resource Monitor.
and the file system cache have all taken their piece. If all processes/services work within normal parameters and
20% of physical 5% of physical
memory the level of memory consumption is an expected behavior it
memory over 6 should be considered to add additional memory to this
minutes over 6 minutes system in the future.
If a process/service can be identified which works outside
normal parameters, the process should be killed. Please note
Memory – Pages/sec is the rate at which pages are read from or written to disk to >10 >20 A high value reported for this counter typically indicates a
Pages/sec resolve hard page faults. memory bottleneck, except if “Memory – Available Bytes”
reports a high value at the same time. In this case most likely
an application is sequentially reading a file from memory.
Please refer to KB139609 for furtherinformation.
Paging File - %Usage %Usage This is the percentage amount of the Page File instance in use. >40% >70% Review this value in conjunction with “Memory - Available
Section: www.ACME.
111
- of
or or Bytes” and “Memory - Pages/sec” to understand paging

80% over 60 minutes 95% over 60 minutes activity on the affected system.
LogicalDisk/Physical % Free Space is the percentage of total usable space on the selected logical <10% of physical <5% of physical disk Identify which files or folders consume disk space and delete
Disk - % Free Space disk drive that is free. disk or obsolete files if possible. In case no files can be deleted,
consider increasing the size of the affected partition or add
or 10% reported after 1 additional disks.
10% reported after 2 minute
minutes
LogicalDisk/Physical % Disk Time marks how busy the disk is. >70% consistently >90% consistently Identify the processes / services consuming disk time using
Disk - % Disk Time or or Task Manager or Resource Monitor.
90% over 15 minutes 95% over 15 minutes If all processes/services work within normal parameters and
the level of disk consumption is an expected behavior it
(_Total) (_Total) should be considered to move the affected partition to a
more capable disk subsystem in the future.
If a process/service can be identified which works outside
normal parameters, the process should be killed. Please note
LogicalDisk/ Current disk queue length provides a primary measure of disk congestion. It >=1 (per spindle) >=2 (per spindle) A long disk queue length typically indicated a disk
PhysicalDisk – is an indication of the number of transactions that are waiting to be consistently consistently performance bottleneck. This can be caused by either
processed. or processes/services causing a high number of I/Os or a
Current Disk Queue or shortage of physical memory. Please follow the steps outlined
Length 3 over 15 minutes 10 over 30 minutes for counter “LogicalDisk/PhysicalDisk - % Disk Time” and
(_Total) (_Total) counter “Memory – Available Bytes”
PhysicalDisk – Avg. The Average Disk Second counters show the average time in seconds of a >=15ms consistently >=20ms consistently High disk read or write latency indicates a disk performance
Disk Sec/Read read/write/transfer from or to a disk. bottleneck. Systems affected will become slow, unresponsive
and application or services may fail. Please follow the steps
– Avg. Disk Sec/Write outlined for counter “LogicalDisk/PhysicalDisk - % Disk Time”
– Avg. Disk Sec/
Transfer
Network Interface – Bytes Total/sec shows the rate at which the network adapter is processing < 8 MB/s for 100 70% of NIC speed Identify the processes / services consuming network using
Bytes Total/sec data bytes. This counter includes all application and file data, in addition to Mbit/s adaptor inbound and Task Manager or Resource Monitor.
protocol information, such as packet headers. outbound If all processes/services work within normal parameters and
<80 MB/s for 1000
traffic for 1 min. the level of bandwidth consumption is an expected behavior
Mbit/s adaptor it should be considered to move the respective
or process/service to a dedicated NIC (or team of NICs).
60% of NIC speed If a process/service can be identified which works outside
Section: www.ACME.
112
- of
inbound normal parameters, the process should be killed. Please note

and outbound that killing a process can cause unsaved data to be lost.
traffic for 1 min.
8.1.2 Citrix Delivery controller performance monitor metrics

These specific performance counters should be used (next to the generic performance monitor metrics) to monitor the Delivery Controllers.
Database Connected Indicates whether this service is in contact with its database. (1 is 0 0 for over 30 Both values report connectivity issues of the XenDesktop
connected; 0 is not connected) minutes Broker service with the database. In case issues are reported,
SQL server and network availability needs to be verified.
Database Transaction The rate at which database transactions are failing None >0 Both values report connectivity issues of the XenDesktop
Errors/sec Broker service with the database. In case issues are reported,
SQL server and network availability needs to be verified.
8.1.3 Citrix Storefront performance monitor metrics

These specific performance counters should be used (next to the generic performance monitor metrics) to monitor the Storefront servers.
ASP.NET – Requests The number of requests rejected because the request None >1 When this limit is exceeded, requests will be rejected with a
Rejected queue was full. 503 status code and the message “Server is too busy.” Please
follow the steps outlined for counter “ASP.NET – Request
Queued”
8.1.4 Citrix License server performance monitor metrics

These specific performance counters should be used (next to the generic performance monitor metrics) to monitor the Citrix license servers.
Citrix Licensing – Last Displays the last recorded license check-out response time in milliseconds. >2000 ms >5000 ms If the reported values exceed the 5000 ms response time, a
Section: www.ACME.
113
- of
Recorded License potential performance issue needs to be investigated in the

Check-Out Response Citrix License Server.
Time
Citrix Licensing – isplays the number of minutes that XenDesktop has been > 1 minute > 1440 minutes Both values report connectivity issues with the License
License Server disconnected from the License Server. Server. In case issues are reported, License Server and
network availability needs to be verified.
Connection Failure
8.2 Windows services monitoring

Windows services that are critical to basic server functionality should be automatically monitored to ensure that they are running properly. The following
table provides a list of the common Windows services that should be monitored. When any of these services are restarted or stopped a warning (Yellow) or
critical (Red) alert should be assigned respectively. The recommended recovery actions for the services listed below are as follows:
 First failure: Restart the Service
 Second Failure: Restart the Service
 Subsequent Failures: Put the server in maintenance mode and investigate the root cause
8.2.1 Citrix Xenapp 7.6 servers services

Service Functionality
Citrix Audio Redirection Service Provides audio redirection between the endpoint device and the virtual desktop..
Citrix Desktop Service The Citrix Desktop Service manages communication between the delivery controller and virtual desktops. It handles initial brokering of connections,
settings for connections, and interaction with sessions.
Citrix Device Redirector Service Service to manage Citrix remote devices
Citrix Group Policy Engine Responsible for applying settings configured by Citrix administrators for the computer and users through the Group Policy component.
Citrix HDX MediaStream for Flash Service Provides the HDX MediaStream for Flash feature to published applications and virtual desktops. HDX MediaStream for Flash allows the Adobe Flash
Player to run on the client user device instead of within the server session.
Citrix Print Manager Service This service supports the Citrix Advanced Universal Printing Architecture.
Citrix Profile Management Manages user personalization settings
Section: www.ACME.
114
- of
Citrix PVS device Service Citrix PVS device Service

Citrix Services Manager Citrix Services Manager
Citrix Pvs for VMs agent Pvs for VMs agent machine password update service
8.2.2 Citrix Delivery controller servers services

Citrix AD Identity Service Manages Active Directory Computer Accounts
Citrix Analytics Collects analytical data on Citrix products.
Citrix Broker Service The Citrix Broker service provides configuration and allows brokering of connections to desktops and applications.
Citrix Configuration Logging Service Logs Administrator activity and configuration changes in a XenDesktop deployment
Citrix Configuration Replication Provides access to Delivery Services configuration information
Citrix Configuration Service Stores service configuration information.
Citrix Delegated Administration Service Manages configuration of delegated administration permissions.
Citrix Diagnostic Facility COM Server Manages and controls Citrix diagnostic trace sessions on the system.
Citrix Environment Test Service Manages tests for evaluating the state of a XenDesktop Site
Citrix Host Service Citrix Host Service
Citrix Monitor Service This service monitors the FlexCast system.
8.2.3 Citrix Provisioning servers services

Citrix PVS TFTP Service Provides the TFTP Server functionality.
Citrix PVS Soap Server Provides framework for external or existing solutions to interface with Provisioning services.
Citrix PVS Stream Service Streams contents of the vDisk to the target device on demand.
Section: www.ACME.
115
- of
8.2.4 Citrix Storefront servers services

Citrix Cluster Join Service Provides Server Group join services
Citrix Credential Wallet Provides a secure store of Credentials
Citrix Default Domain Services Provides authentication, change password and other domain services
Citrix Peer Resolution Service Resolves peer names within peer-to-peer meshes
Citrix Storefront Privileged Administration Service Manages privileged operations on Storefront..
Citrix Storefront Service Manages deployment of Storefront.
Citrix Subscriptions Store Provides a store and replication of user subscriptions
World Wide Web Publishing Service Provides web connectivity and administration through the Internet Information Services Manager.
8.2.5 Citrix License servers services

Citrix Licensing Provides licensing services for Citrix products
Citrix Licensing Support Service This account controls reading the license files and updating strings with license trailers ( data dictionary functionality)
8.3 Windows events monitoring

Monitoring the Windows Event Log for unknown or critical events can help to proactively discover issues and allow administrators to understand event
patterns:
 Licensing: Errors in the Event Log dealing with Remote Desktop licensing should be investigated. This might be a result of the installed Citrix product not
being able to contact the Remote Desktop Licensing Server or the Citrix Licensing Server. If errors in the Event Log are not reviewed, users might
eventually be denied access because they cannot acquire a valid license.
Section: www.ACME.
116
- of
 Hardware Failure: Any event notification that relates to a hardware failure should be looked at immediately. Any device that has failed will have an
impact on the performance of the system. At a minimum, a hardware failure will remove the redundancy of the component.
 Security Warnings: Customers should investigate security warnings or audit failure events regarding failed logons in the security log. This could be an
indication that someone is attempting to compromise the servers.
 Disk Capacity: As the drives of a Windows system reach 90% of capacity, an event error message will be generated. To ensure continuous service,
customers should poll these event errors. As the system runs out of hard disk space, the system is put at severe risk. The server might not have enough
space left to service the requests of users for temporary file storage.
 Application / Service errors: Any event notification that relates to application or services errors should be investigated.
 Citrix errors: All Citrix software components will leverage the Windows Event Log for error logging. A list of the known Event Log warnings and errors
issued by Citrix components can be found at the following links:
 Event Codes Generated by PVS
 XenDesktop 7 - Event Log Messages
It is important to periodically check the Event Viewer for Citrix related warnings or errors. Warnings or errors that repeatedly appear in the logs should
be investigated immediately, because it may indicate a problem that could severely impact the Citrix environment if not properly resolved.
In multi-server environments it becomes easier to administer the servers when logs can be collected and reviewed from a central location. Most enterprise
grade monitoring solutions provide this functionality. More sophisticated monitoring solutions enable an administrator to correlate event information with
other data points such as performance metrics or availability statistics. In case the selected monitoring solution does not provide this functionality the
Windows Server 2008 R2 or Windows Server 2012/2012 R2 Event Log subscription feature can be used. This feature allows administrators to receive events
from multiple servers and view them from a designated collector computer. For more information please refer to the Microsoft TechNet article – Manage
Subscriptions.
8.4 Citrix director

Administrators can utilize the Trends view within Citrix Director to track different parameters of the Citrix XenApp/XenDesktop deployment over time.
These parameters can be leveraged for capacity planning of the Citrix environment.
From the Trends view, administrators can see historical data that is broken up into several categories including:
 Sessions: Provides the concurrent session usage over time enabling the ability to size the environment appropriately.
 Connection Failures: Gives an overview of the different types of connection failures that have occurred across different Delivery Groups.
 Failed Desktop OS Machines: Gives an overview of the different problems associated with failures in desktop machines.
 Failed Server OS Machines: Gives an overview of the different problems associated with failures in server machines.
Section: www.ACME.
117
- of
 Logon Performance: Shows how long it takes for users to log on to their applications and desktops.
 Load Evaluator Index: Provides various performance counter-based metrics, including CPU, Memory, and Disk Usage for Server OS machines.
 Hosted Application Usage: Details all applications published in the site and can provide usage information about each individual applications in detail
(concurrent instances, launches, usage duration, and so on).
For more information on Citrix Director Trends, please refer to the following:
 Citrix Blogs – Citrix Director: Trends Explained
 Citrix Support – CTX139382 Best Practices for Citrix Director
Section: www.ACME.
118
- of
9 High availability, disaster recovery and backup

& recovery strategy
9.1 High availability & disaster recovery
Creating a desktop delivery solution requires proper analysis and design around fault
tolerance and business continuity. As a user’s desktop and applications are hosted from an
internal data center location, the failure of a component could have a widespread impact
across the user community. The customer organization should include failover solutions
within a single data center or across multiple data centers.
9.1.1.1 Rebuild process

Having a fast (automated) rebuild process for the servers (Delivery controller servers,
XenApp servers, Storefront servers, Provisioning Servers, etc.) is highly recommended.
ACME recommends having a fully automated deployment of Citrix xenapp servers in place.
ACME also recommends having a well-documented installation procedure in place for Citrix
Delivery controllers, Citrix storefront servers, Citrix license servers, Citrix netscaler
appliances and Citrix provisioning servers.
For CONTOSO, The Citrix Xenapp servers will be deployed in a fully automated way, this also
includes rebuilding. A combination of Citrix provisioning services (for Xenapp machine
deployment), ACME TaskFlow (for server configuration + application deployment) and
Xenserver template (for VM + OS installation) will be used to automate the installation,
configuration and deployment of Citrix Xenapp servers.
The rebuild procedure for the other components will be based on a written installation
procedure.
For CONTOSO, we have the following rebuild strategy in place:
Component rebuild strategy Justification
Citrix Xenapp Installation procedure ACME recommended
that describes: rebuild procedure
 VM template
deployment
 Taskflow deployment
 Deployment of
Xenapp servers via
Citrix PVS
Citrix Delivery controller Installation procedure ACME recommended
rebuild procedure
Citrix Provisioning Services Installation procedure ACME recommended
rebuild procedure
Citrix Storefront Installation procedure ACME recommended
rebuild procedure
Section: High availability, disaster recovery and backup & recovery

119
- of
Citrix licensing Installation procedure ACME recommended

rebuild procedure
Citrix databases (MS SQL) N/A Existing CONTOSO MS
SQL infrastructure will be
used. Existing server
rebuild procedures of
CONTOSO for this
component will be used.
MS App-V management / Installation procedure ACME recommended
publishing rebuild procedure
File servers Installation procedure ACME recommended
rebuild procedure
Print servers N/A Existing CONTOSO MS
CONTOSO for this
Citrix Netscaler Installation procedure ACME recommended
rebuild procedure
Active Directory N/A Existing CONTOSO MS
CONTOSO for this
Igel UMS server N/A Existing CONTOSO MS
CONTOSO for this
Citrix Xenserver N/A Existing CONTOSO MS
CONTOSO for this

120
- of
9.1.1.2 Component fail-over (high availability)

Local site users experience the best performance and responsiveness of their applications
and desktops by utilizing systems that are also local. However, if a local component fails,
users must still be able to utilize their desktops and applications without changing their
endpoint configurations or be required to remember to use a different location’s resources.
Local high availability solutions ensure availability in a single data center deployment. These
solutions guard against process, node, and media failures, as well as human errors. Local
high availability solutions can be further divided into two types: active-passive and active-
active:
 Active-passive solutions deploy an active instance that handles requests and a passive
instance that is on standby. When the active instance fails, the active instance is shut
down and the passive instance is brought online, and resumes application services. At
this point the active-passive roles are switched. This process can be done manually or it
can be handled through vendor-specific clusterware. Active-passive solutions are
generally referred to as cold failover clusters.
 Active-active solutions deploy two or more active system instances at all times. All
instances handle requests concurrently.
Citrix Xenapp has already a built-in fail-over mechanism in place, so no extra technology is
required to have fail-over on this component.
Citrix Provisioning services has built-in fail-over by deploying multiple PVS servers in the
same PVS farm and enable high availability.
Citrix delivery controller servers have built-in high availability by deploying multiple servers
in the same Xenapp/Xendesktop site.
Citrix Storefront, does not have built-in fail-over and we have used a network load balancing
solution, Citrix netscaler, to enable redundancy and load balancing of the citrix storefront
servers.
The Citrix netscaler appliances have built-in fail-over functionality, however a deployment of
2 Citrix netscalers is required to have active-passive HA.
It is recommended to have redundancy on MS SQL infrastructure that hosts the Citrix

Xenapp and Provisioning services databases. The well-known MS SQL HA options such as
failover clustering, mirroring or AlwaysOn availability groups can be used. In the worst case,
you can rely on Hypervisor HA functionality and also have a good backup strategy and well
documented disaster recovery procedure in place to quickly bring the MS SQL environment
back online.

121
- of
In general, the Citrix license server is not business critical and in most cases there is no need
to make them highly available. A good backup strategy and a well-documented disaster
recovery procedure for this component should be sufficient.
Other dependent infrastructure servers such as AD domain controllers, file servers, print
servers should also be made highly available by using their built-in fail-over capacities or by
using technologies such as clustering and network load balancing.
ACME recommends that there is no single point of failure within the citrix xenapp
environment. Citrix delivery controllers, Citrix Xenapp, Citrix PVS, Citrix Netscaler have built-
in fail-over capacity and they should be activated by deploying at least 2 servers/appliances,
however other components such as the Citrix storefront servers do not have built-in fail-
over and should be made highly available. Also make sure that all other dependent
infrastructure servers (such as AD DC’s, database servers, file servers, print servers,…) are
highly available.
For CONTOSO, we have the following high availability strategy in place:

Component High availability strategy Justification
Citrix Xenapp Built-in HA by deploying Easiest and simplest
multiple Xenapp servers solution to supply
sufficient HA level on this
component
Citrix Delivery controller Built-in HA by deploying 2 Easiest and simplest
Citrix Delivery controller solution to supply
servers sufficient HA level on this
component
Citrix Provisioning Services Built-in HA by deploying 2 Easiest and simplest
Citrix PVS servers solution to supply
sufficient HA level on this
component
Citrix Storefront Deploying 2 Storefront Recommended HA
servers in combination solution for Citrix
with network load storefront
balancing functionality via
Citrix Netscaler
Citrix licensing Hypervisor HA Citrix Xenapp
environment can run 30
days without Citrix license
server. Underlying
hypervisor HA
functionality is sufficient.

122
- of
Citrix databases (MS SQL) Hypervisor HA Citrix Xenapp

environment can
continue to function by
using connection leasing
functionality.
Citrix PVS environment
can continue to function
by using PVS offline
database functionality.
Basic HA is provided by
underlying hypervisor HA
functionality.
MS App-V management / Hypervisor HA Only non-business critical
publishing apps and a very limited
application set will use
APP-V. Temporarily
unavailability of this
service is not critical.
Basic HA is provided by
underlying hypervisor HA
functionality.
File servers Hypervisor HA A limited amount of
downtime (<15 minutes)
is allowed for this
services. Basic HA is
provided by underlying
hypervisor HA
functionality.
Print servers Hypervisor HA A limited amount of
downtime (<15 minutes)
is allowed for this
services. Basic HA is
hypervisor HA
functionality.
Citrix Netscaler Built-in HA by deploying 2 Easiest and simplest
Citrix Netscaler solution to supply
appliances sufficient HA level on this
component
Active Directory Multiple AD domain Recommended HA
controllers solution for AD domain

123
- of
controllers
Igel UMS server Hypervisor HA Temporarily unavailability
of this service is not
critical. Basic HA is
hypervisor HA
functionality.
Citrix Xenserver Multiple Xenserver hosts Recommended HA
in HA setup solution for Citrix
Xenserver
9.1.1.3 Site fail-over (disaster recovery)

Providing component-level failover is the initial start for a business continuity solution, but
the design must also take a holistic view of the entire site health. For example, if an entire
data center is unavailable, in a disaster scenario, users must be rerouted to their backup
data center.
In a complete site disaster recovery scenario, users continue to go to the fastest responding
site, which now excludes the failed site. E.g. a user located in Gent, who is normally routed
to the Brussels data center during normal operations, would have their requests directed to
the Amsterdam data center in case the data center in Brussels is not available.
Site-fail over solutions are usually geographically distributed deployments that protect your
applications from disasters such as floods or regional network outages. Disaster recovery
solutions typically set up two homogeneous sites, once active and one passive. Each site is a
self-contained system. The active site is generally called the production site, and the passive
site is called the standby site.
During normal operation, the production site services requests. In the event of a site failover
or switchover, the standby site takes over the production role, and all requests are routed to
that site.
To maintain the standby site for failover, not only must the standby site contain
homogeneous installations and applications, but data and configurations must also be
synchronized constantly from the production site to the standby site.
However, nowadays a lot of environments have active-active sites instead of active-passive

sites. With the active-passive site approach, we always have system resources in the standby
site that are actually not doing anything until a disaster takes place and the systems of the
standby sites are finally being used. To avoid this waste of system resources and to enable
optimal use of all system resources an environment has at its disposal, a lot of companies
are switching to active-active sites: environments have 2 or more data centers available
which are connected through redundant, very high bandwidth connections (dark fiber
connections giving LAN experience) which enables those environments to use system
resources located at all datacenters, If this is combined with server virtualization technology
such as Vmware Vsphere, Citrix Xenserver of MS Hyper-V, you can even organize your
environment so it acts as one big cloud infrastructure.

124
- of
No matter if you choose for the active-passive or active-active approach, always make sure
that you have proper scalability and capacity planning in place, so you can guarantee proper
functioning of the systems in case of a disaster.
ACME highly recommends having site fail-over in place. Depending on environment

requirements, an active-passive or active-active approach can be chosen. Always make sure
that scaling (capacity planning) is properly done, to make sure that operations and
performance are satisfying in case of a disaster occurs and thus a site (datacenter) is not
available.
CONTOSO only has 1 datacenter so no site fail-over strategy can be put in place. However,
CONTOSO has a procedure in place to rebuild their datacenter in case of disaster recovery.
CONTOSO has already a disaster recovery plan in place that is based on having a backup &
restore strategy in place for Virtual machines and reassigning iSCSI disks within the OS if this
is required.
ACME built the disaster recovery strategy for the new Citrix Xenapp environment based on
the disaster recovery strategy that is already in place at CONTOSO for their existing server
infrastructure.
For CONTOSO, we have the following disaster recovery strategy in place:

Component Disaster recovery Justification
strategy
Citrix Xenapp Citrix Provisioning Easiest and simplest DR
services solution for this
component
Citrix Delivery controller Restore of VM backup Easiest and simplest DR
solution for this
component
Citrix Provisioning Services  Restore of VM backup Easiest and simplest
 Reattach iSCSI disk solution to supply
that contains PVS sufficient HA level on this
vdisks component
Citrix Storefront Restore of VM backup Easiest and simplest DR
solution for this
component
Citrix licensing Restore of VM backup Easiest and simplest DR
solution for this
component
Citrix databases (MS SQL)  Restore of VM backup Easiest and simplest DR
 Reattach iSCSI disks solution for this

125
- of
that contain MS SQL component

database info.
MS App-V management /  Restore of VM backup Easiest and simplest
publishing  Reattach iSCSI disk solution to supply
that contains App-V sufficient HA level on this
packages component
File servers  Restore of VM backup Easiest and simplest
 Reattach iSCSI disk solution to supply
that contain user sufficient HA level on this
profiles and Taskflow component
framework
Print servers Restore of VM backup Easiest and simplest DR
solution for this
component
Citrix Netscaler Restore of VM backup Easiest and simplest DR
solution for this
component
Active Directory Restore of VM backup Easiest and simplest DR
solution for this
component
Igel UMS server Restore of VM backup Easiest and simplest DR
solution for this
component
Citrix Xenserver Rebuild procedure
available?
9.1.1.4 Disaster recovery test

A full disaster recovery restore test should be completed at least twice a year to verify the
integrity of the backups and to ensure that the support staff are familiar with the process.
ACME recommends to occasionally do disaster recovery testing to make sure that systems
continue to function correctly in case of a disaster.
9.2 Backup & recovery

Backup and recovery refers to the various strategies and procedures involved in guarding
against hardware failures and data loss, and reconstruction data should a loss occur. There
are failure scenarios that do not involve the catastrophic loss of an entire production
environment. But regardless of the type of failure, once a failure has occurred in your system
it is important to restore the failed component or process as quickly as possible.

126
- of
User errors may cause a system to malfunction. In certain circumstances, a component or

system failure may not be repairable. A backup and recovery facility should be available to
back up the system at certain intervals and restore a backup when an irreparable failure
occurs.
There are several factors to consider including, the different types of backups you can make,
the state of the virtual machines, and the type of storage being used by the virtual machines.
Backups
can occur at two levels on the hypervisor:
 Backup the guest virtual machine itself: This method is preferred because it captures
more data than performing the backup from within the guest operating system
 Backup within the guest virtual machines: A backup application runs within the virtual
machine.
At a minimum, backup the following XenApp components so that it is possible to recover

from a complete failure:
 XenApp database
 Provisioning Services database
 Provisioning Services vDisks
 XenServer VM/Pool metadata (or equivalent for other hypervisors)
 Storefront configuration
 License files
 App-V packages
 Taskflow framework
 User profiles (including folder redirection data) / home folders
ACME recommends having a decent backup and recovery strategy and procedure in place
for at least the citrix-related components. Make sure that at least the above mentioned
components are backed up. Also, occasionally, perform recovery testing to make sure that
you are able to restore proper data.
Note: It is assumed that there is a fast automated rebuild process in place for the servers
supporting the Xenapp infrastructure (Delivery controller, StoreFront server, Provisioning
Server, etc.). If this assumption is not true then all infrastructure servers must also be
backed up. Virtual networks are not included in a full server backup. You will need to
reconfigure the virtual networking by recreating the virtual networks and then reattaching
the virtual network adapters in each virtual machine to the appropriate virtual network.
Make sure the virtual network configuration and all relevant settings are documented as part
of the backup process.
CONTOSO uses a script to frequently create snapshots of VM’s running on the Citrix
Xenserver environment and to store these snapshots as backup to a QNAP NAS storage
device.
Symantec Backup exec is used as backup solution to backup databases and files from within
VM’s.
For CONTOSO, we have the following backup strategy in place:

127
- of
Component backup strategy Justification

Citrix Xenapp N/A No backup strategy
required for this
component
Citrix Delivery controller Backup of guest VM via Easiest and simplest
script backup strategy for this
component
Citrix Provisioning Services  Backup of guest VM Easiest and simplest
via script backup strategy for this
 Backup of PVS vdisks component
via backup exec
Citrix Storefront Backup of guest VM via Easiest and simplest
component
Citrix licensing Backup of guest VM via Easiest and simplest
component
Citrix databases (MS SQL)  Backup of guest VM Easiest and simplest
 Backup of databases component
via backup exec
MS App-V management /  Backup of guest VM Easiest and simplest
publishing via script backup strategy for this
via backup exec
File servers  Backup of guest VM Easiest and simplest
via backup exec
Print servers Backup of guest VM via Easiest and simplest
component
Citrix Netscaler Backup of guest VM via Easiest and simplest
component
Active Directory Backup of guest VM via Easiest and simplest
component

128
- of
Igel UMS server Backup of guest VM via Easiest and simplest

component
Citrix Xenserver N/A No backup strategy
required for this
component

CONTOSO - Citrix Xenapp Implementation Document - V1.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CONTOSO - Citrix Xenapp Implementation Document - V1.0

Uploaded by

Copyright:

Available Formats

Implementation document

Citrix XenApp Upgrade

© 2023 ACME, all rights reserved.

Section: Document history www.ACME.be

Section: Table of www.ACME.

Section: Table of www.ACME.

Section: Table of www.ACME.

Section: Architectural www.ACME.

Section: Architectural www.ACME.

2.2 Infrastructure server Virtual Machines Overview

2.2.1 New Virtual machines

Section: Architectural www.ACME.

2.2.2 Existing Virtual machines

2.3 XenApp Virtual Machines Overview

Section: Architectural www.ACME.

PRODUCTION vxpcon-1234 Production Citrix Xenapp 192.168.1.234 SXCON- 4 25 GB 10 ISCSI-XENLUN-R620POOL1-SAS

Section: Architectural www.ACME.

3.1.2 Key Design Decisions

Section: User www.ACME.

Internal Libramont +/- 2  2 thin clients 3  Linux

Internal Antwerpen +/- 2  1 thin client 2  Linux

Internal Locations are:

External locations are:

Section: User www.ACME.

3.1.3.1.2 Client devices

Section: User www.ACME.

3.1.3.2 Connection method & Citrix Receiver version + usage

3.1.3.2.1 Fat clients

3.1.3.2.1.1 Company owned fat clients

3.1.3.2.1.2 Personally owned fat clients

Section: User www.ACME.

3.1.3.2.2 Thin clients

Users working on Igel thin clients will autoconnect to 1 URL:

Deployment (firmware)+ configuration (profiles) will always be done in a fully automated

Section: User www.ACME.

3.1.3.3 Citrix Receiver Deployment

3.1.3.3.1 Connecting from internal network

3.1.3.3.1.1 Igel thin clients

3.1.3.3.1.2 Managed Windows fat clients

3.1.3.3.1.3 Unmanaged Windows fat clients

3.1.3.3.1.4 Unmanaged Mac fat clients

Section: User www.ACME.

3.1.3.3.2 Connecting from external network

3.1.3.3.2.2 Unmanaged Windows fat client

3.1.3.3.2.3 Unmanaged Mac fat client

3.1.3.4 Citrix Receiver Configuration

Section: User www.ACME.

4.1.2 Key Design Decisions

Decision Point Decision Justification

Section: Access www.ACME.

Controllers 1202.CONTOSO.be, used for redundancy puposes

Certificate Wildcard certificate Adequate certificate is required

Section: Access www.ACME.

Section: Access www.ACME.

 Trusted + default domain: Netscaler Gateway

Citrix Web Interface

Section: Access www.ACME.

Citrix Netscaler Gateway

4.1.3.2 Internal Access

4.1.3.2.2 Access Method

Section: Access www.ACME.

4.1.3.2.4 StoreFront Configuration

4.1.3.2.5 High Availability

Section: Access www.ACME.