CWS 415 2I en StudentManual v02

N
ot
fo
rr
es
al
e
or
di
CWS-415-2I: Citrix Virtual Apps and Desktops 7 Assessment,
s
tri
Design and Advanced Configuration
b
ut
io
n
Table Of Contents
Module 0 - Course Overview.....................................................................................................................................................................2

Module 1 - Methodology & Assessment..................................................................................................................................................34
Citrix Consulting Methodology.....................................................................................................................................................36
N
Business Drivers..........................................................................................................................................................................51
ot
User Segmentation......................................................................................................................................................................61
Application Assessment..............................................................................................................................................................73
fo
Capabilities Assessment.............................................................................................................................................................81
rr
Module 2 - User Layer...........................................................................................................................................................................100
es
Endpoints and Peripherals........................................................................................................................................................103
Citrix Workspace App................................................................................................................................................................126
al
Network Connectivity.................................................................................................................................................................133
e
Module 3 - Access Layer.......................................................................................................................................................................168
or
Access Matrix............................................................................................................................................................................170
Access Layer Architecture Design Considerations....................................................................................................................178
di
StoreFront Store Design............................................................................................................................................................194
s tri
Scalability and Redundancy......................................................................................................................................................205
Module 4 - Resource Layer - Images....................................................................................................................................................263
b ut
FlexCast Model Assignment......................................................................................................................................................265
Virtual Delivery Agent Machine Scalability................................................................................................................................273
io
Virtual Delivery Agent Machine Security...................................................................................................................................294
n
Provisioning Strategy / Image Management..............................................................................................................................309
Module 5 - Resource Layer - Applications and Personalization............................................................................................................370
Application Delivery...................................................................................................................................................................372
Profiles.......................................................................................................................................................................................403
Policies......................................................................................................................................................................................422
Printing......................................................................................................................................................................................437
Module 6 - Control Layer.......................................................................................................................................................................471
Citrix Virtual Apps and Desktops Site Design............................................................................................................................473
Machine Catalogs & Delivery Groups........................................................................................................................................487
Site Management Considerations.............................................................................................................................................498
Control Layer Scalability and High Availability..........................................................................................................................507
Control Layer Security...............................................................................................................................................................525
N
Module 7 - Hardware/Compute Layer...................................................................................................................................................555
ot
Assessment Considerations for Hardware & Hypervisor Selection...........................................................................................558
fo
Cluster / Resource Pool Design................................................................................................................................................571
rr
Hardware/ Compute Layer Sizing..............................................................................................................................................584
Storage......................................................................................................................................................................................596
es
Datacenter Networking..............................................................................................................................................................614
al
Security......................................................................................................................................................................................627
e
Module 8 - Multiple Location Considerations........................................................................................................................................666
Introduction to Multiple Location Considerations.......................................................................................................................670
or
Access.......................................................................................................................................................................................683
di
Image Management...................................................................................................................................................................698
s
Profiles and Data.......................................................................................................................................................................712
tri
Printing......................................................................................................................................................................................731
b
Control Layer.............................................................................................................................................................................739
ut
Module 9 - Disaster Recovery...............................................................................................................................................................753
io
Disaster Recovery Levels..........................................................................................................................................................755
n
Disaster Recovery - Strategy.....................................................................................................................................................766
Disaster Recovery - Process.....................................................................................................................................................780
Citrix Virtual Apps and Desktops
7 Assessment, Design and
Advanced Configuration
N
ot
Course Overview
fo
rr
es
al
e
Module 0
or
di
s
tri
b
ut
io
n
2 © 2021 Citrix Authorized Content

Course Overview
• Review the Citrix methodology and the different
N
assessments used by Citrix.
ot
• Identify the user layer including endpoints,
peripherals and network connectivity.
fo
rr
• Describe the access layer architecture including
double-hop deployment options and StoreFront
es
configurations and review scalability and
al
redundancy configuration options.
e
• Define the image layer including VDA scalability,
or
security and provisioning strategies.
di
s
tri
b
ut
io
n

Course Overview
• Investigate the differences between the available
N
application delivery options, and identify the leading
ot
practices of configuring profiles, folder redirection
and printing.
fo
• Explore the considerations and leading practices for
rr
designing the control layer.
es
• Present the compute layer and the considerations
al
for hypervisors, hardware, networking and storage
e
in the datacenter.
or
• Introduce designing multi-location environments and
di
implementing features such as GSLB, optimal
gateway routing and image replication.
s
tri
• Describe the process of designing a disaster
b
recovery solution.
ut
io
n

Citrix Workspace
Drive digital transformation
N
with an intelligent workspace
ot
platform.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

App Delivery and
Security
Formerly Networking
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Student Introduction
• Introduce yourself to the class.
N
• Include the following information:
ot
• Name and company
• Job title
fo
• Job responsibility
rr
• Networking and virtualization experience
es
• Citrix product experience
• Class expectations
al
e
or
di
s
tri
b
ut
io
n

Facilities
• Parking and transportation information
N
• Class Policies
ot
• Break and lunch schedules
fo
• Emergency contact information
rr
es
al
e
or
di
s
tri
b
ut
io
n

Course Prerequisites
• This course requires extensive experience with

Citrix Virtual Apps and Desktops 7 as well as
experience with Citrix ADC and supporting
infrastructure.
N
ot
• Citrix recommends completion of the following
courses or similar experience prior to attending this
fo
course:
rr
• CWS-215 Citrix Virtual Apps and Desktops 7
es
Administration On-Premises and in Citrix Cloud
• CWS-315 Citrix Virtual Apps and Desktops 7
al
Advanced Administration
e
• CXD-250 Moving to the Citrix Virtual Apps and
Desktops Service on Citrix Cloud
or
• Recommended certifications achieved prior to this
di
course:
s
• CCA-V and CCP-V.
tri
b ut
io
n
Key Notes:
• There are three different learning paths provided by Citrix Education to get to CWS-415:
• Learning Path 1: CWS-215 > CWS-315 > CWS-415
• Learning Path 2: CWS-215 > CWS-313 > CWS-314 > CWS-415
• Learning Path 3: CMB-318 > CWS-313 > CWS-415

Course Outline – Day 1
• Module 0: Course Introduction
N
• Module 1: Methodology & Assessment
ot
• Module 2: User Layer
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Module 3: Access Layer
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Module 4: Resource Layer – Images
N
• Module 5: Resource Layer – Applications &
ot
Personalization
fo
rr
es
al
e
or
di
s
tri
utb
io
n

• Module 6: Control Layer
N
• Module 7: Hardware/Compute Layer
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Module 8: Multiple Location Considerations
N
• Module 9: Disaster Recovery
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Course Materials
• This course has the following material:
N
• Student Manual
• Lab Manual
ot
• Lab Environment
fo
• Watch the Instructor demonstrate how to access the
rr
course materials and connect to the lab
es
environment.
al
e
or
di
s
tri
b
ut
io
n

Lab Exercises
All lab exercises are grouped and performed together
N
per module.
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise Design
N
1 - Review 2 - Design 3 - Implement
ot
fo
Review if design requirements are Update detailed design document Implement the new design in the
met using: to match design requirements. design validation lab.
rr
• Design requirements document
es
• Detailed design document
• Design validation lab
al
e
or
di
s tri
b
ut
© 2021 Citrix Authorized Content
io
n

Student Resources
ZIP archive containing:
N
• Design requirements
ot
documents
• Detailed design documents
fo
• Module-based lab manuals
rr
es
al
e
or
di
s
tri
b
ut
io
n

Lab Exercise
Access
1. Login with your MyCitrix
N
Credentials, specifically
ot
those used to enroll in the
course.
fo
2. When instructed to
rr
provision your labs, click
es
the module you want to
al
complete.
e
or
di
s tri
b ut
io
n
Key Notes:
• The Student Resources is a zip file containing a number of different documents used throughout the class to aid you in
completing the exercises.
• This class contains module-based labs, meaning that you will start a new lab base for each module.

Lab Exercise Access (Continued)
Download the Lab Guide to complete the

exercises.
N
ot
fo
rr
es
al
3. After clicking on a specific module, verify the
e
requirements and click READY TO START.
or
di
s
tri
4. On the next page, select your GEO and click
b
Start Lab.
ut
io
n

Take notice of the Lab Time counter, this

will show you how much time you have left
to complete the exercise.
N
ot
fo
rr
es
al
5. Verify the 5-minute countdown timer starts and
e
wait for the timer to go to zero.
or
6. If you have not done so already, ensure you
have Citrix Workspace app installed.
di
s
7. Click Open Lab in Citrix Workspace app to
tri
connect to the lab.
but
io
n

N
ot
fo
rr
es
al
e
or
8. Once the lab exercises are complete, click END
di
LAB to decommission the lab.
stri
b ut
io
n

Lab Introduction
New York
User Layer Access Layer Control Layer Resource Layer
PVS
StoreFront Delivery Controller Server VDA

Active Directory Server PVS Server
NYC-STF-001 NYC-VDC-001 NYC-SRV-MAN-001
NYC-ADS-001 NYC-PVS-001
192.168.10.31 192.168.10.46 DHCP
192.168.10.11 192.168.10.51
• This diagram represent the
N
lab environment for this
ot
course. NetScaler Database Server File Server Server VDA
NYC-ADC-001 NYC-SQL-001 NYC-FSR-001 NYC-SRV-001
192.168.10.100 192.168.10.21 192.168.10.17 DHCP
• Check connectivity to the lab
fo
environment and report to
rr
User Endpoint
NYC-WRK-001 San Francisco
the Instructor any issues. DHCP
es
Access Layer Control Layer Resource Layer
• All lab environment details
al
are also provided in the lab PVS
e
manual. NetScaler Delivery Controller PVS Server Server VDA
or
SFO-ADC-001 SFO-VDC-001 SFO-PVS-001 SFO-SRV-MAN-001
192.168.11.100 192.168.11.46 192.168.11.51 DHCP
di
s
Database Server File Server Server VDA
tri
StoreFront
SFO-SQL-001 SFO-FSR-001 SFO-SRV-001
SFO-STF-001
192.168.11.21 192.168.11.17 DHCP
192.168.11.31
b ut
io
n
Key Notes:
• The course lab environment is not a production environment.
• Each VM is given enough resources to perform the lab exercises.
• There are enough lab exercises to gain valuable hands-on experience to match the lecture part of this course.
• These lab VM’s are tuned tot eh lab manual tasks, do not deviate unless instructed to by the Instructor.
• Any deviation may result in destabilizing of the lab causing intermittent or long-term failure.
• If a lab fails, it can be reset to the beginning, but it is time consuming and requires a classroom support ticket.

Student Desktop
• Remote Desktop Connection
N
Manager for general
ot
management
• Hyper-V Manager for virtual
fo
machine management and
rr
power operations
es
• System Center Virtual
al
Machine Manager for
e
Hypervisor management
or
di
s
tri
b
ut
io
n

Remote Desktop
Connection
Manager
• Use the Remote Desktop
N
Connection Manager to
ot
connect to the lab virtual
machines (VM).
fo
• The connections are pre-
rr
configured.
es
al
e
or
di
s
tri
b
ut
io
n

Hyper-V Manager
• Manage virtual machines
N
• Power operations
ot
• Install operating system
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

System Center
Virtual Machine
Manager
• Manage Hyper-V clusters
N
• Add Networking features
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Classroom Support
N
ot
fo
rr
es
al
e
or
1. Navigate to training.citrix.com
di
2. Click on the “Contact Us” dropdown.
s
3. Select “Classroom Support”.
tri
utb
io
n

Printing
• You can download, save, and print electronic
N
courseware.
ot
• To print, click Student Resources > Courseware >
Student Manual > Launch.
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Looking Ahead:
End of Course Survey
Your opinion matters!
N
ot
fo
rr
Help shape the next course.
es
al
Tell us what you liked!
e
or
What can we do better?
di
s
tri
utb
io
n

Citrix Measures your Feedback with NPS
How is Net Promoter Score Calculated?
N
Not at all How likely is it you would recommend Citrix Courses to a friend? Extremely
ot
Likely Likely
0 1 2 3 4 5 6 7 8 9 10
fo
rr
es
\/
al
e
or
di
Detractor Passive Promoter
s
tri
but
io
n

Connect with Citrix Education
N
ot
fo
rr
es
al
Facebook Twitter LinkedIn
e
Become a fan of Citrix Services Follow @citrixservices Join the Citrix Education Group
or
di
Visit http://training.citrix.com to find more information on training, certifications, and exams.
s tri
b ut
io
n

Thank You
Special thanks you to all who contributed to the

creation of this course!
N
ot
• Rod Haanappel – Lead Enablement Specialist
fo
• Kelly Vespi – Senior Enablement Specialist
rr
• Chris McMillan – Senior Enablement Specialist
es
• Laura Gough – Senior Instructional Designer
al
• Rahul Mohandas – Education Programs Specialist
e
or
• Tero Laine – Citrix Certified Instructor
• The Citrix Consulting Team
di
s
tri
utb
io
n

N
ot
Methodology & Assessment
fo
rr
es
al
e
Module 1
or
di
s tri
but
io
n
Key Notes:
• Welcome to the Methodology and Assessment module. This is the first module in the Citrix Virtual Apps and Desktops 7
Assessment, Design and Advanced Configuration course.
• Throughout this module, we will define and apply the Citrix Consulting Methodology and understand how it relates to
properly identifying business drivers, user segmentation and application requirements.

Learning Objectives
• Describe the Citrix Methodology and identify
N
challenges designing project plans.
ot
• Identify and prioritize business drivers.
fo
• Describe how to complete the user segmentation
rr
process.
es
• Assess and categorize key applications.
al
• Perform a capabilities assessment.
e
or
di
stri
b ut
io
n
Key Notes:
• Upon completion of this module, you will be able to:
• Describe the Citrix Methodology and identify challenges designing project plans.
• Identify and prioritize business drivers.
• Describe how to complete the user segmentation process.
• Assess and categorize key applications.
• Perform a capabilities assessment.

N
ot
Citrix Consulting Methodology
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Lesson Learning Objectives
• Describe how the Citrix methodology lifecycle is
N
applied to designing a project plan.
ot
• Recognize common challenges when designing a
project plan and describe how to mitigate them.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Upon completion of this lesson, you will be able to:
• Describe how the Citrix methodology lifecycle is applied to designing a project plan.
• Recognize common challenges when designing a project plan and describe how to mitigate them.

Citrix Consulting
Methodology
• Plan
Advise • Strategize
• Define
Citrix works with customers to
N
understand their goals and
ot
challenges to define an
appropriate IT strategy, • Assess
fo
including the required • Design Implement
rr
technologies and the best way • Deploy
es
to optimize them.
al
• Monitor
e
Manage • Mitigate
or
• Optimize
di
stri
b ut
io
n
Key Notes:
• Apply the proven methodology to Citrix projects to maximize end value.
• With years of successful project implementation experience, Citrix Consulting has developed the Citrix Consulting
Methodology, which can be leveraged to achieve the highest levels of efficiency, manageability and agility for all
strategic IT services – from enabling mobile workstyles to delivering cloud services.
• Our tailored methodology and approach to problem solving makes it easier to measure your project’s success and
demonstrate results, while minimizing risk and maximizing effectiveness and value.

• The methodology is an iterative process, meaning that after the completion of each project, or each
phase of a larger project, the same steps of the methodology should be leveraged again to improve the
environment and/or progress to next steps.
• The Citrix Methodology is defined by three distinct phases of engagement: Advise, Implement and Manage.
Each of the three primary phases off the methodology consist of sub-steps to provide more granularity to the
overall Life Cycle process. Complete each phase and obtain signoff from key stakeholders before moving to
next phase.
N
• The first phase is Advise – Citrix will work with the customer to understand their goals and challenges,
ot
then help to define an appropriate IT strategy, including the required technologies and the best way to
fo
optimize them.
• Strategize - At this stage, our goal is to help the customer to conceptualize a vision tied to the desired
rr
business outcomes, while working with them to understand their goals and challenges.
es
• Define - We'll help the customer to define a path forward, including the technologies needed and the
al
best way to optimize them.
• Plan - Leveraging 25+ years of experience, Citrix will work with the customer to plan the short,
e
medium, and long-term steps required to achieve the desired results.
or
di
Additional Resources:
• Citrix Consulting Methodology: https://www.citrix.com/content/dam/citrix/en_us/documents/guide/a-proven-
s tri
approach-to-ensure-success-and-predictable-outcomes.pdf
b ut
io
n

Citrix Consulting
Methodology
• Plan
• Define
Citrix will create, configure,
N
and deploy a new
ot
environment on-premises, in
the cloud or anywhere in • Assess
fo
between, in accordance with • Design Implement
rr
leading designs. This includes • Deploy
es
supporting integration with a
customer’s existing
al
environment and phasing the
• Monitor
e
rollout to align with the
Manage • Mitigate
or
business needs, while
• Optimize
identifying major use cases
di
and project requirements.
s tri
but
io
n
Key Notes:
• The second phase is Implement – Citrix will create, configure, and deploy a new environment on-premises, in the cloud or
anywhere in between, in accordance with leading designs. This includes supporting integration with a customer’s existing
environment and phasing the rollout to align with the business needs, while identifying major use cases and project
requirements.
• Assess - Citrix conducts an assessment to understand the customer's current environment and needs, then develop
a detailed blueprint to guide them in the right direction

• Design - Citrix will design a new IT environment, tailored to the exact specifications, and in accordance
with leading practices by analyzing and designing for scalability, business continuity and security.
• Deploy - Citrix will deploy a new environment in accordance with leading designs. This includes
supporting integration with any existing environment and phasing the roll-out to align with business
needs.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Consulting
Methodology
• Plan
• Define
Citrix directly manages the
N
Citrix environment to exceed
ot
the customer expectations,
with minimal time and effort • Assess
fo
required from the customer’s • Design Implement
rr
IT staff. Citrix experts will • Deploy
es
apply specialized knowledge
and lessons learned from
al
other projects to keep the
• Monitor
e
environment operating at peak
Manage • Mitigate
or
efficiency.
• Optimize
di
stri
b ut
io
n
Key Notes:
• The third phase is Manage – Citrix directly manages the Citrix environment to exceed the customer expectations, with
minimal time and effort required from the customer’s IT staff. Citrix experts will apply specialized knowledge and lessons
learned from other projects to keep the environment operating at peak efficiency.
• Monitor - As a customer’s needs change, we'll adapt and update the environment accordingly, all the while leveraging
leading practices.
• Mitigate - Citrix will recommend solutions based on leading practices in contextual access, networking, analytics, as

well as application data. Then we'll configure the environment to mitigate security risks and prevent future
attacks.
• Optimize - Working with the customer, Citrix will evaluate and address user needs regarding the
customer’s Citrix solution and recommend improvements to minimize issues and maximize adoption.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Identify Key People
N
Business Technical
ot
Roles Architect
fo
Roles
rr
es
• Project sponsor • Applications owners • Citrix desktop • Backup
al
• Project manager • Service desk • Active Directory • Application
manager packaging
e
• Business manager • Virtualization
or
• Training manager • Monitoring
• Business continuity • Network
manager • Communications • Systems
di
• Desktop
manager management
s
• Test manager
• Storage
tri
• Security
but
io
n
Key Notes:
• Desktop virtualization is a fundamental change that requires close collaboration between various business and technical
teams in order to be successful. For example, the virtualization and desktop teams need to work together to ensure that
the virtual desktop image meets user needs while also being optimized for the datacenter.
• Failure to build a cohesive project team that consists of the right roles and skillsets can negatively impact performance,
availability, user experience and supportability while also increasing costs and risk.
• There are various business and technical roles required during an enterprise virtual desktop deployment. Although the

number of roles may seem quite large, many of these roles are only required for a short time and multiple
roles may be performed by a single person.
• For example, the project manager and Citrix architect are considered to be full time roles with other team
members being brought in only when required. The project manager role is key to ensuring that the right
people are involved in the project at the right time.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Create a High-Level Project Plan
Project Plan Overview Gantt Chart
N
ot
fo
rr
es
al
e
or
di
• Provides high-level plan that can be used for • Provides justification for resources.
presentations and discussions.
s
• Breakdown of tasks and target dates helps
tri
align implementation team.
but
io
n
Key Notes:
• Mapping out a high-level project plan can help prepare you to discuss timescales and resource requirements. One
approach is to treat each identified use case as a separate project and order them according to the priorities established
during the roadmap stage of the project.
• This will help to ensure that the business receives the maximum value from their investment as soon as possible.
• For example, a high-priority use case can move through the Advise-Implement-Manage stages more quickly than a
secondary use case.

• To communicate the plan to different audiences, different formats can be used. For example, a visual chart
can provide a high-level overview that is useful for presentations and high-level discussions.
• To complement that, a standard Gantt chart can provide an additional level of detail which can be useful for
justifying resource requirements. A Gantt chart is a type of bar chart that shows the timing and relationship
between different project tasks.
• The pictured portion of the chart accompanies the bar graph and delineates the expected duration and dates
when each project activity will be performed in order to stay on schedule.
N
• There is no hard and fast rule for estimating how long each phase will take as it all comes down to the
ot
complexity of the environment, skillset involved and the scale of the environment.
fo
rr
• Desktop Transformation – High-Level Project Plan: https://www.citrix.com/blogs/2012/03/30/desktop-
es
transformation-high-level-project-plan/
al
e
or
di
s tri
but
io
n

Common Citrix Consulting Methodology Challenges
Challenge Mitigation Steps

• Ensure detailed scope of work is reviewed and agreed to by all
Differences in expectations stakeholders before starting the project.
between stakeholders. • Review key milestones accomplished after each project phase and review
N
the upcoming phase to ensure alignment over time.
ot
fo
• Build buffer time into project timelines at start of project to account for
Difficulty adhering to project unexpected delays and setbacks.
rr
schedule. • Look for opportunities to blend the end of one phase with the beginning of
es
the next phase.
al
Project documentation is not • Include an executive summary section for each major deliverable.
e
reviewed by customer/ • Use a strategic meeting at the end of each phase to communicate key
or
management. takeaways from that phase.
di
Customer/management wants to
• Include discussion of methodology in planning phase of project.
s
accelerate project by skipping
• Provide examples of what occurs when methodology is not followed.
tri
Assess or Design phases.
b ut
io
n
Key Notes:
• There are a few pitfalls that can occur when planning a project using the Citrix Consulting Methodology. However, these
can be mitigated if you are aware of these risks and react accordingly.
• Taking time to plan the project with all stakeholders is key. Even if the time available to implement the project is restricted,
it pays off to plan the project phases and ensure everyone is on the same page with regards to timing, resources needed,
and key milestones.
• This also includes ensuring that everyone understands and buys into the phases of the methodology and their necessity

for the project.
• After each project phase, take some time to review the project’s progress with all stakeholders, discussing the
milestones that have been achieved, and looking forward to the next project phase, including whether any
adjustments are required for the original project plan. These reviews will help stakeholders remain aligned
over time, especially for longer-term projects.
• During these review meetings, focus on the key takeaways that everyone should know. Include
necessary details in the project documentation but include an executive summary in the documentation
N
to highlight the most important items. This makes it more likely that those points will be communicated
ot
throughout the wider project team.
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Lesson Objective Review
You are leading a Citrix Virtual Apps and Desktops full

lifecycle project. The team began building the core
infrastructure components for a new Site this week.
However, the project sponsor insists that the Site must
N
go live to production next week in order to meet key
business goals.
ot
What may have caused this situation?
fo
How should you address this going forward?
rr
es
Possible causes:
al
e
• Project timelines not developed or not shared with sponsor.
or
• Project team did not hold a review meeting after each project phase,
leading to misalignment over time.
di
Going forward, the project manager should communicate the risks
s
associated with trying to accelerate an environment rollout without
tri
going through a technical and user acceptance testing process.
utb
io
n
Key Notes:
• Even if a project scope and timeline was developed and shared initially, for long-term projects, misalignment can occur
over time if review meetings are not held periodically. This can arise because business conditions or objectives change, or
the project encounters delays.

N
ot
Business Drivers
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify the business drivers that are used in the
N
project design process.
ot
• Describe how to prioritize business drivers to make
project design decisions.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Identify the business drivers that are used in the project design process.
• Describe how to prioritize business drivers to make project design decisions.

Why Identify Business Drivers?
• Defines the “Why” of the project.
N
• Clarifies which objectives should be used as project success criteria.
ot
• Drivers serve as a key input into the design process.
fo
rr
es
al
e
or
di
stri
but
io
n
Key Notes:
• Most organizations do not focus on technology; they focus on the needs of the users and of the organization. These needs
can be met with technical solutions, but it is imperative the team understands the “Why” of the project.
• The first step in your virtual desktop project should be to understand and prioritize the strategic business drivers of the
organization. Without clearly identified and prioritized business drivers, nobody really knows what the project should
achieve, how much it should cost or when it should be finished by.
• Lacking a clear definition of what should be achieved is one of the leading causes of project failures.

• At the start of the project, preferably during the kickoff meeting, take time to establish and prioritize the key
drivers behind a project. You should have everything you need to answer that all-important question – “What
needs to be achieved for this project to be a success?”
• The business priorities identified enable the project management team to define success criteria and allows
the design team to create a tailored and optimized architecture.
N
• Desktop Transformation Assessment – Business Priorities: https://www.citrix.com/blogs/2011/06/21/desktop-
ot
transformation-assessment-defining-business-priorities/
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Identify Business Drivers
Improve End
User Experience Reduce
N
Increase Costs
ot
Flexibility
fo
rr
Improve
es
Performance
al
Simplify
Management
e
or
Enable Mobile Increase
di
Workstyles Security
s tri
utb
io
n
Key Notes:
• Core business drivers and requirements can be captured during meetings or by distributing questionnaires. Meetings are
more time consuming, but allow for follow-up questions to be asked and help to simplify the prioritization process.
• It is important that this exercise be completed jointly by both business managers and IT decision makers since both
groups will have significantly different viewpoints.
• To help jumpstart the conversations, it can be helpful to provide examples of common business drivers, such as those
shown here.

• Increase flexibility: Many businesses are looking for a flexible desktop solution that is capable of
accommodating periods of change such as rapid growth, outsourcing, takeovers and downsizing. A
modular high-level design is the best way to achieve this requirement.
• Improve end user experience: This would involve increasing performance or enabling features which
would otherwise not be possible with a geographically dispersed user population.
• Reduce costs: Replacing workstations every three to five years in order to keep up with the requirements
of the operating system or the applications can be very costly. This could be mitigated by extending the
N
life of desktop PCs while still being able to run the latest applications.
ot
• Improve performance: Poor performance is a frequent driver behind desktop virtualization, especially
fo
when users access corporate resources over low-bandwidth and/or high-latency links. Hosting the virtual
desktops near the application servers and corporate data typically helps to improve application
rr
performance.
es
• Increase security: More and more businesses are concerned about data theft and are looking for ways to
al
protect information. In such situations, implementing preventative measures are a top priority.
• Enable mobile workstyles: The business may need to support remote access and/or travelling employees
e
in order to attract and retain top talent. They may also want to support BYOD initiatives or be concerned
or
with the impact from transport disruption and natural disasters.
di
• Simplify management: A lot of businesses are seeking ways to simplify the management of their desktop
infrastructure as they realize that they can’t just keep hiring more resources. These businesses may not
s tri
be as proactive as they would like and are probably spending too much time ‘fighting fires’. A business
b
may also want to improve IT efficiency by focusing on only the aspects driving the business while
ut
offloading remaining functions to 3rd parties through cloud or service providers.
io
n

Prioritize Business
Drivers
Business Drivers
Topic Design Decision
Ranked
Through stakeholder
Authentication Multi-factor authentication
N
discussions, determine which
1 - Increase Security
ot
business drivers are most
Clipboard Use No clipboard redirection
important to the organization.
fo
It is not always possible to
rr
2 - Reduce Costs FlexCast Model Hosted apps and desktops
meet the requirements of all
es
business drivers for every
al
design decision. In these 3 - Improve End User Use Citrix Profile
cases, the most prioritized User Profile
e
Experience Management
business drivers will
or
determine the decision.
di
stri
b
ut
io
n
Key Notes:
• Once you’ve identified your priorities, they should be ranked according to their importance to the business, so that
resources, time and funds can be allocated appropriately.
• The prioritization process should be completed in collaboration with the project team, business managers and IT
managers so that all views are considered.
• Having this list of priorities clearly outlined from the start will help you successfully execute your project.
• Given that certain business drivers may occasionally conflict with each other, the prioritization will help to determine the

design decisions for an environment.
• For example, providing a feature that improves user experience may decrease security or increase costs.
A tradeoff may have to occur; in the example above, security was identified as the top priority, meaning
that in these situations the design decision would be made in alignment with increasing security.
• There is no “correct” prioritization; this will vary based on the industry and individual organization.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

During a project planning meeting, the project

sponsor says the following regarding Workspace
Labs’ business priorities:
“Overall, we want a robust solution that ensures
N
users can access their resources at any time, even
if one of our sites experiences an outage. “
ot
“We have over 10,000 users who will be using this
fo
environment so we need to make sure the
rr
infrastructure can handle the expected usage.”
es
“These users will need to access virtual
al
applications and desktops from both inside and
outside our corporate network, but we need to
e
make sure that we enable this in a secure manner
or
and protect our sensitive data.”
di
“Overall, we want our users to have a seamless
s
experience, and be able to be productive while
tri
using this environment.”
but
io
n
Key Notes:
• Based on the customer statement above, identify some key business drivers, and how those drivers could translate to a
Citrix virtualization environment.

Which business drivers can be

identified in the previous statement?
Robust solution: Redundancy should be implemented for all

infrastructure components.
N
ot
Access resources even during a Site outage: This suggests a
desire for a multi-site architecture and disaster recovery plan.
fo
Over 10,000 users: With this number of users, a pod
rr
architecture with multiple pods in each Site may be required.
es
Virtual applications and desktops: Can lead with Citrix Virtual
Apps and Desktops to meet this requirement.
al
e
Inside and outside our corporate network: Remote access is a
priority; can suggest Citrix Gateway.
or
Secure…protect our sensitive data: Security is a priority,
di
especially for external access.
s
tri
Seamless experience…productive: User experience is a
priority.
utb
io
n
Key Notes:
• Note what was not stated as a priority: common drivers such as reducing cost and simplifying administration were not
mentioned. Although we assume that these would still be considered benefits by most organizations, they have not been
explicitly identified as key business drivers and would be prioritized below the identified drivers.

N
ot
User Segmentation
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Describe how to complete the user segmentation
N
process to assess business and technical needs for
ot
the user population.
fo
rr
es
al
e
or
di
stri
b ut
io
n
Key Notes:
• Describe how to complete the user segmentation process to assess business and technical needs for the user
population.

User Segmentation Overview
Assess user population
• Assess business and technical needs of user
N
population.
ot
• Segment into user groups based on common
requirements:
fo
• End user location
rr
• Mobility
es
• Security Segment into user groups
• Personalization, customization, and ability to install
al
applications
e
• Application set and application usage
or
• Desktop loss criticality
• User groups typically map to a role within a
di
department.
s
User Group 1 User Group 2 User Group 3 User Group 4
tri
b ut
io
n
Key Notes:
• Depending on the size of the department, there might be a subset of users with unique requirements. Each defined user
group should be evaluated against the following criteria to determine if the departmental user group needs to be further
divided into more specialized user groups.
• Some criteria that can be used to segment users includes:
• End user location/Mobility – understand where user is connecting from (are users hosted across multiple data
centers, network speeds, network security, etc.) and how frequently the user is roaming.

• Security – determine the appropriate security level required for each user group and identify specific
lockdown and audit requirements.
• Personalization – assess if user requires additional personalization that cannot be provided by roaming
profiles. Determine if user needs the ability to install apps themselves, or if the admin should install any
additional apps required by user.
• Application set/application usage – common applications required; how resource intensive the application
work is that users are doing.
N
• Have to have an understanding of how users are using applications; not always a clear mapping
ot
between app and workload.
fo
• E.g. Excel for one user may be a light workload but may have another user who is running reports
with thousands of data sets and who therefore is a heavy workload.
rr
• Desktop loss criticality – understand impact to revenue, projects, and product if user is unable to access
es
resources.
al
• Although printing requirements are another factor that often differs between user groups, it is typically not the
factor that defines said groups; usually it is based on another factor such as department, location, and
e
application set. Another example is GPU usage; this will often be provided to specific user groups, but the
or
groups are defined by their occupational role or application set (which require GPU usage).
di
s tri
• Desktop Transformation Assessment – User Segmentation: https://www.citrix.com/blogs/2011/06/28/desktop-
b
transformation-assessment-user-segmentation/
ut
io
n

Importance of User
Segmentation
N
Understanding user requirements and using those requirements to create a
ot
virtualization solution is important to:
fo
• Improve user acceptance and reduce costs.
rr
• Assist in the appropriate assignment of FlexCast models.
es
• Help determine optimal policies and settings for each group.
al
e
or
di
s tri
but
io
n
Key Notes:
• It is important to the success of the deployment to understand the user requirements and tailor the solution to their specific
needs, as this can impact user acceptance and project costs.
• You need to define user groups based on shared common characteristics in order to assign the FlexCast model that
effectively addresses the requirements of the user group.
• User segmentation is also important for understanding policies that may need to be applied.

User Segmentation Process
Step 1: Assess how much data has already been collected.
N
ot
fo
Level of user High data collection, low definition High data collection, high definition
rr
data collection
es
performed
al
e
or
Low data collection, low definition Low data collection, high definition
di
s
Level of role definition and
tri
standardization within departments
utb
io
n
Key Notes:
• When starting the user segmentation process, determine how much data an organization has already collected around its
users’ requirements, workflow, application set, and other details.
• Find out which of the following categories your organization falls into:
• Highly-informed, well-defined organization: This organization regularly records data on its employees’ requirements
for compliance, managerial, or other purposes. Additionally, the organization’s existing role definitions are sufficiently
well defined that all the users within a role share the same requirements.

• Highly informed, less defined organization: This organization regularly records data on its employees’
requirements, but roles within a group or department are highly variable.
• Low informed, well-defined organization: This organization collects minimal or no data on its employees’
requirements, but interviews with departmental representatives reveal that role definitions are fairly
uniform and well-defined within each department.
• Low informed, less defined organization: This organization collects minimal or no data on its employees’
requirements and interviews reveal that roles are highly variable within departments.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Step 2: Design a Data Collection Strategy.
• Analyze existing data.
N
• Confirm groups and identify any sub-groups.
ot
• Confirm user requirements.
fo
• Thoroughly analyze existing data.
rr
• Based on common requirements, segment users into defined groups.
• Identify groups’ requirements.
es
al
• Collect user data.
e
• Confirm groups, identify sub-groups.
• Identify user requirements.
or
di
• Collect user data.
s
• Based on data, identify user groups and requirements.
tri
b ut
io
n
Key Notes:
• Based on the organization’s data collection category, develop a strategy to complete user segmentation:
• Highly-informed, well-defined organization: Existing data and roles can be analyzed to determine the appropriate
FlexCast model for each group or department. Additionally, confirm whether there are any sub-groups within a
department that require a specialized use case.
• Highly informed, less defined organization: A thorough analysis of the existing data should be used to create user
groups that are not departmental based. These could include grouping by location, workload, security needs,

personalization needs, mobility needs, desktop loss criticality, etc.
• Low informed, well-defined organization: User segmentation data will need to be collected, both to
confirm the pre-defined user groups, and to accurately capture group requirements for a desktop
virtualization environment.
• Low informed, less defined organization: Extensive user data collection may be required to define
sufficiently detailed user groups and requirements.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Step 3: Perform Data Collection and Analyze Activities.
N
Interviews & Surveys Active Directory Data Import 3rd Party Data Collection Tools
ot
• Develop interview questions and/or • Leverage the Microsoft CSDVE • Used specialized agents to collect
fo
surveys for representatives from utility to export user details from application and resource usage
rr
target departments. Active Directory into a CSV file. data from user endpoints.
es
• Collect data about users’ roles, • Each user or job role can then be • Typical examples include:
• Lakeside SysTrack
al
devices, application sets, analyzed so that it can be assigned
workflows, and other requirements. to an appropriate user group. • Liquidware Stratusphere UX
e
or
di
s tri
b ut
io
n
Key Notes:
• Each of the displayed data collection methods have benefits and drawbacks. Ideally, multiple data collection methods
should be used to validate and supplement each other.
• Note that these are tools specifically for user segmentation; Citrix monitoring and data collection tools such as Scout and
Director collect valuable information, but do not have much information about user activity unless there is already a pre-
existing Citrix Virtual Apps and Desktops environment that is being actively used by all targeted user groups – and these
groups are accessing all their desktop and application resources from that environment.

• Interviews and surveys:
• Pros: Simple to administer, interviews and surveys are widely understood and can be
distributed/collected by non-technical resources. This qualitative data can capture details that are not
visible with other data collection methods, including whether the current applications and work processes
could be improved from their current state.
• Cons: Efforts must be made to conduct enough interviews or get enough survey responses so that an
acceptable sample size is reached. Otherwise, the anecdotal data collected may not accurately reflect
N
the true state of the organization.
ot
• One big assumption of this method is that the responses are made in good faith; ideally, data collected
fo
with this method would be corroborated by additional data collection methods.
• Active Directory data import:
rr
• Pros: This method can capture many user details that can assist with segmentation, include user
es
location, department, and role. This information can be captured for thousands of users without requiring
al
additional software, accelerating the data collection process.
• Cons: By itself, this method can provide a good starting point for user segmentation, but does not provide
e
key information around required applications, key workflows, or user requirements. As a result, this
or
method should be supplemented with other data collection methods.
di
rd
• 3 party data collection tools:
• Pros: These tools can capture details about users’ required applications and workflows – this is usually
s tri
accomplished by installing an agent on users’ endpoints, then capturing data around application and
b
resource usage. This data tends to be more accurate than users’ own estimates of their workflows and
ut
application usage and can provide a thorough representation of what different users groups currently
io
require for their roles.
• Cons: These tools may require fine tuning prior to the collection phase, as well as additional funding and
n
more implementation effort to put into place. The reach of a user behavior capture can be restricted
based on licensing, project timescales and agent support for devices.
• Additionally, be mindful of the privacy laws and regulations for the locations where the employees are based –
some locations require employees to be notified if such data collection agents are used, while others may
prohibit these methods entirely.

What user segmentation actions should be
N
pursued in organizations that have
ot
collected a high amount of data around
fo
user requirements, but lack well defined
groups of users?
rr
es
Analyze the existing data, segment users
into groups, and identify groups’
al
requirements.
e
or
di
s
tri
b
ut
io
n

N
ot
Application Assessment
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine application categories and characteristics
N
to determine the optimal deployment method for
ot
each required user application.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Examine application categories and characteristics to determine the optimal deployment method for each required
user application.

Why Conduct an
Application
Assessment?
Review the application estate in order to:
• Consolidate the number of applications that must be integrated into the
N
desktop virtualization environment.
ot
• Provide valuable inputs during the Design phase by categorizing and
fo
characterizing the applications.
rr
• Ensure that any application-related challenges are identified early in the
es
project lifecycle.
al
e
or
Application
Application Rationalization
di
Categorization/Characterization
s tri
but
io
n
Key Notes:
• Once the users have been divided up into groups, the next step is to determine which applications they require in order to:
• Consolidate the number of applications that must be integrated into the desktop virtualization environment.
• Provide valuable inputs during the Design phase by categorizing and characterizing the applications.
• Ensure that any application-related challenges are identified early in the project lifecycle.
• Application assessments involve two key stages:
1. Application rationalization: The number of applications identified during the inventory is often surprising, even for

organizations that believe they have a high-level of control over applications. To help reduce complexity
as well as overall time required, it’s important to take the time to consolidate the list of applications. This
could include reducing multiple versions of the same application, identifying and removing non-business
applications, legacy apps that are no longer needed, and management applications that will be re-
designed for the virtualized environment.
2. Application categorization/characterization and assignment: Each application included in the project
should be categorized based on certain criteria, which will help determine the most appropriate way to
N
host and integrate the app. Due to the uniqueness of every application, many large-scale deployments
ot
simultaneously utilize multiple approaches. Then the consolidated, categorized list of apps should be
fo
mapped to the groups identified during the user segmentation process.
rr
es
• Desktop Transformation Assessment – Application Assessment:
al
https://www.citrix.com/blogs/2011/06/27/174163877/
e
or
di
s tri
but
io
n

Categories and Characteristics of Applications
Application Categories Application Characteristics
N
ot
• Common apps: Used by almost every user. • Complexity: Whether an app is technically
challenging due to dependencies or specialized
fo
• Departmental apps: Only relevant for a particular
configurations.
user group.
rr
• Resource requirements: CPU and RAM utilization.
• User apps: Only used by a few individual users.
es
• Mobility requirements: Whether app must be
• Management apps: Includes antivirus, monitoring,
al
available for mobile users or offline.
inventory, maintenance, and backup apps.
e
• Peripheral requirements: Specialized peripherals
or
needed by the app.
• License/security restrictions: Application access
di
may need to be restricted to protect license
s
agreements or sensitive data.
tri
b ut
io
n
Key Notes:
• Categorizing the applications and identifying their characteristics will create key information that will be used during the
Design phase to select the best delivery method for each of the applications.
• For example, common apps are more likely to be included in the base image of a Virtual Delivery Agent, rather than
in an App-V package or App Layer, because all users require access to that application.
• Application characteristics are also important to define. For example, applications with high CPU requirements may
need to be deployed on a single-session OS Virtual Delivery Agent so that it does not impact other users.

Application Assessment Analysis Options
Application Assessment Collect Information from Utilize Application Management
N
Analysis Options Existing App Repository Software
ot
• Application inventory data may • The organization’s application team • Provides analysis on how easily an
fo
have been collected during the user may have application management app can integrate with different
rr
segmentation process. software. operating systems and platforms.
es
• If not, a third party tool can be • Information from these systems • Provides suggested remediation
al
deployed to collect this data. may be used to assist in the steps for challenges it identifies.
assessment.
e
or
di
s tri
but
io
n
Key Notes:
• Various methods exist for collecting the information needed to condense, categorize, and characterize the applications
which will be included in the environment.
• Application inventory data from the user segmentation process can be used as a source of information for the
assessment.
• Additionally, application management software from vendors Lakeside SysTrack, Liquidware Stratusphere UX,
LanDesk/Ivanti, ServiceNow, or BMC Remedy are another potential source of data.

• If the organization lacks an application management utility or repository and does not wish to utilize a third-
party data collection tool, interviewing application owners may be the primary method of performing these
steps.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
fo
Why is it important to categorize applications
during an application assessment?
rr
es
The categories will be used to determine the optimal
deployment method for each application during the
al
environment design.
e
or
di
s
tri
b
ut
io
n

N
ot
Capabilities Assessment
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Describe how to assess the capabilities of an
N
existing environment so that potential risks can be
ot
identified and addressed in the project design.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Describe how to assess the capabilities of an existing environment so that potential risks can be identified and
addressed in the project design.

Why Perform a
Capabilities
Assessment?
N
Gain a solid understanding of the existing IT infrastructure and operations in
ot
order to:
fo
• Inform relevant design decisions.
rr
• Identify potential risks for the design and build.
es
• Identify other planned projects and initiatives that must be integrated with
al
the design and build.
e
or
di
s tri
b ut
io
n
Key Notes:
• In a capabilities assessment, the current state of the environment is evaluated so that the starting point for the Design can
be established. This includes assessing any planned projects and initiatives so that they can be factored into the Design.
• This process also serves to capture and prioritize any potential risks that could affect the success of the eventual
environment build.
• The capabilities assessment evaluates the existing infrastructure by examining the readiness of the following ten key
areas – each of which will form part of the foundation that supports any proposed virtual desktop solution:

• Users and applications
• Client devices and mobility requirements
• Image management processes
• Existing access infrastructure
• Current virtualization and storage solutions
• Windows Server and Active Directory environment
• Network architecture
N
• Existing Citrix Virtual Apps and Desktops environments
ot
• Disaster recovery plan & implementation
fo
• Training and certifications of support staff and end users
rr
es
• Desktop Transformation – Capabilities Assessment: https://www.citrix.com/blogs/2011/06/30/desktop-
al
transformation-capabilities-assessment/
e
or
di
s tri
b
ut
io
n

Examples of Common Capability Risks
Windows Server and AD

Users and applications
N
environment
ot
Client devices and mobility
fo
Network architecture
requirements
rr
es
Image management Existing Citrix Virtual Apps
processes and Desktops environments
al
e
Disaster recovery plan and
or
Existing access infrastructure
implementation
di
s
Current virtualization and Training and certifications of
tri
storage solutions support staff and users
but
io
n
Key Notes:
• All of the displayed topics should be covered during a capabilities assessment. The topics highlighted in gold will be
explored in the following slides to demonstrate some of the potential risks that exist for each area.
• Examples of capability risks in each area:
• Users and applications: Insufficient user segmentation; poorly defined or executed application inventory and
management.
• Client devices and mobility requirements: Outdated or specialized devices and peripherals; challenging mobility

requirements.
• Image management processes: Poorly defined or executed image management processes; lack of
standardized images across the organization.
• Existing access infrastructure: Presence of pre-existing components such as a VPN solution, load
balancers, two-factor authentication, etc.
• Current virtualization and storage solutions: Insufficient capacity on existing hardware, hypervisor, or
storage deployments; poorly maintained or un-optimized infrastructure in these areas.
N
• Windows Server and AD environment: Poorly designed and maintained Active Directory environment;
ot
irregular Windows Server patching schedule.
fo
• Network architecture: Insufficient bandwidth or IP address space available for proposed environment;
lack of Quality of Service (QoS) or network optimization.
rr
• Existing Citrix Virtual Apps and Desktops environments: Poor design or maintenance of existing
es
environments; low utilization of these environments.
al
• Disaster recovery (DR) plan and implementation: Lack of a DR plan; no formal testing of DR plan.
• Training and certifications of support staff and users: Support staff unqualified to support existing or
e
proposed environment; high number of user-generated support tickets due to lack of communication or
or
training on end-user software.
di
s tri
b ut
io
n

Client Devices and Mobility Requirements
Example Potential Risks
Endpoints Use a Legacy Specialized Peripherals are Users Require Mobile Devices
N
Operating System Needed for Required Apps with Limited Network Access
ot
• May not support modern versions • Peripheral communicates with • May include traveling or outdoor-
fo
of Citrix Workspace App. application to import/export data. based employees.
rr
• Could become a security weak- • Verify whether peripheral can be • Mobile device use a key part of
es
point in the environment. redirected into an HDX session. current workflow.
al
• Address by updating OS, updating • May need to consider alternative • Determine whether to provide
e
device, converting to thin client, etc. deployment method for the app. network connectivity, change the
workflow, or consider other
or
deployment methods.
di
s tri
b ut
io
n
Key Notes:
• When reviewing client devices and mobility requirements, you must consider the client devices and peripherals in use so
that an appropriate FlexCast model and HDX technology can be selected for each use case. There are a number of
different vendors offering desktop inventory software that can assist with the required data collection.
• Citrix Ready can be a useful resource in situations where the organization does not have pre-existing endpoints or
peripherals and would like to ensure that new equipment will work well in a Citrix Virtual Apps and Desktops environment.
The products within Citrix Ready specify which versions of Citrix Virtual Apps and Desktops they have been tested with for

compatibility.
• The current strategy for supporting mobile workers should also be evaluated. Some user groups may require
the ability to work while mobile, sometimes when offline.
• If so, it is important that the design can determine which applications will work without a network connection
and which ones will not. Applications that require backend infrastructure such as web and database servers
are not typically available offline.
N
ot
• Citrix Ready Marketplace: https://citrixready.citrix.com/
fo
rr
es
al
e
or
di
s
tri
b ut
io
n

Network Architecture
• Insufficient bandwidth or excessive latency to some user locations.
N
• Insufficient IP address space for proposed virtualization solution.
ot
• Single points of failure or bottlenecks among critical network infrastructure components.
fo
• No Quality of Service or network optimization present.
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• To assess the capabilities of the network infrastructure:
• Map the location of the users against the existing network topology.
• Review existing monitoring solutions for periods of latency, lost packets and insufficient bandwidth
• Check that there are a sufficient number of IP addresses available to support the proposed virtual desktop solution.
• Examine the topology for single points of failure and potential bottlenecks.
• Determine whether Quality of Service (QoS) and network optimization devices are available.

Current Virtualization and Storage Solutions
Virtualization Storage
N
ot
• Existing hardware/hypervisor deployment does not • Existing storage lacks capacity for proposed
have enough resources to support the proposed environment.
fo
environment.
• Performance of available storage sub-optimal for
rr
• Hypervisor high-availability features not used or not proposed new workloads.
es
available.
• Storage lacks regular backups.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• When assessing this area, perform a thorough review of the virtualization and storage solutions currently in use. Establish
their resilience, scalability, performance and redundancy so that the most appropriate solution can be selected for an
environment design.
• A major decision coming from this section is whether new hardware and storage will be needed for the project.
Procurement times can vary widely among organizations, so assessing this need early on will reduce of the risk of project
delays.

Windows Server and Active Directory Environment
Windows Server Active Directory
N
ot
• Target OS version image not developed or available. • Organizational Unit structure not optimized for
virtualization.
fo
• Available images not optimized for virtualized
environments. • Local profiles currently in use.
rr
• Servers not patched on a regular schedule. • Siloed desktop and server administrative teams.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Since the Windows Server environment will impact the infrastructure servers and potentially the Virtual Delivery Agents
within a Citrix Virtual Apps and Desktops environment, it is important to assess capability risks in this area:
• Review the build process for Windows Servers to determine the different configurations available, for example
operating system version, system architecture, processor/memory specification, disk space, etc.
• Determine whether the organization has performed any OS-level optimizations for virtualized environments. For
example, Citrix has released an OS Optimizer tool to apply optimizations to the various supported Windows

operating systems that can host a Virtual Delivery Agent.
• Regular security patching is a mundane, yet critically important practice that should be in place for any
organization and presents a clear red flag if this is not the case.
• The Active Directory environment should be reviewed to determine whether the OU structure, group policies,
user profiles, logon scripts and delegated rights are ready to support desktop virtualization.
• The Organizational Unit (OU) structures used by organizations are often as diverse as the organizations
themselves. However, there needs to be a way to easily apply and identify policies which are specific to
N
the Citrix Virtual Apps and Desktops infrastructure hosts and VDAs.
ot
• Local profiles are available by default in a Windows environment, but present several drawbacks in a
fo
virtualized environment, such as lack of ability to roam and using up excessive storage space in multi-
user environments.
rr
• On the organizational side, siloed desktop and server administrative teams can cause delays in a
es
virtualization project. It is important to have good coordination and clear-cut responsibilities for these
al
teams, particularly when implementing multi-session OS Virtual Delivery Agents, which could fall into a
contested gray area if the teams are siloed.
e
or
di
• Citrix Optimizer: https://support.citrix.com/article/CTX224676
s tri
utb
io
n

Disaster Recovery Plan and Implementation
• No disaster recovery location exists.
N
• Disaster recovery plan exists but has never been tested.
ot
• Supporting infrastructure for proposed virtualization environment not included in DR implementation.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• It’s important to check that the supporting infrastructure offers a similar level of redundancy to the virtual desktop solution.
Also, verify that the business has a suitable disaster recovery plan in place and that it has been adequately tested.

You are conducting a capabilities assessment for

an organization that wants to create a new Citrix
Virtual Apps and Desktops environment. One of
the organization’s core business drivers is to
N
ensure that key applications are always available
ot
to users. What capabilities must be verified to
fo
assess whether this is feasible with the current
infrastructure?
rr
es
• Verify disaster recovery plan and implementation.
al
• Verify whether supporting infrastructure is configured
e
for high availability.
or
• Verify whether the key applications support high
availability.
di
s tri
but
io
n
Key Notes:
• Depending on the organization, certain capabilities may be paramount, while others are less critical. During any
capabilities assessment, put extra focus on the capabilities that will be most critical for achieving the organization’s core
business goals.

Lab Exercise
• Ex 1-1: Conduct an Application Assessment
N
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Lab Exercise 1-1: Conduct an
Application Assessment
A. Review App Usage and Application Reports.

B. Update Application Analysis Document.
N
ot
Overview: Workspace Lab has collected application usage
data for its current environment, and has identified several
fo
candidates for packaging and deployment via App-V. Using
rr
the provided usage data and App-V reports captured from
3rd party software, determine the appropriate app category,
es
App-V compatibility, and next steps for each app.
al
Navigate to \Module 1\Exercise 1-1
e
or
Task: Using the information from the application usage and
di
Application reports, update the Application Analysis
s
document with the app category, App-V compatibility, and
tri
recommended next steps for each application.
b
ut
io
n

Application Assessment –Answer Key
Application Application
Description App-V Candidate? Next Steps
Name & Version Category
Validate whether shell integration is a desired feature.

7-Zip 16.04 (x64 Maybe; remediation work may be
File archiver Common App Since this is a common app, it can be installed on the
edition) required (shell extensions)
base VDA images.
N
Citrix Content
ot
Cloud storage No; as a boot-time app, this app cannot Since this is a common app, it can be installed on the
Collaboration Drive Common App
connector be deployed via App-V base VDA images.
Mapper 3.9.105.0
fo
rr
Validate that auto-update functionality is not required. If
Maybe; Mozilla Maintenance Service
Mozilla Firefox 57.0.2 so, manually disable service during App-V packaging
es
Web browser Departmental App (auto-update functionality) is a kernel
(x86 en-US) and validate other functionality with user acceptance
mode service that runs at boot time.
testing.
al
e
Due to limited usage currently, validate business case
Notepad ++ (64-bit Maybe; remediation work may be
Text editing tool Individual App for the application, as well as whether the shell
or
x64) required (shell extensions)
extensions are part of the workflow.
di
Probably, as long as file type App-V packages should follow suggested remediation
s
PuTTY release 0.70 IT Administration
Departmental App association and environment variable steps listed in the 3rd party application reports during
tri
(64-bit) tool
items are addressed. the packaging process.
b ut
io
n

Key Takeaways
• Use the Citrix methodology to facilitate project
N
planning and execution.
ot
• Before starting any virtualization project, identify
and prioritize the key business drivers of the
fo
organization to ensure that the design will align with
rr
them.
es
• Segmenting users allows for the identification of the
al
core use cases and requirements, which are the
e
foundation of any virtualization design.
or
di
s tri
b ut
io
n
Key Notes:
• Let’s review the key takeaways of this module:
• Use the Citrix Consulting Methodology to facilitate project planning and execution.
• Before starting any virtualization project, identify and prioritize the key business drivers of the organization to ensure
that the design will align with them.
• Segmenting users allows for the identification of the core use cases and requirements, which are the foundation of
any virtualization design.

Key Takeaways
• An application assessment creates an inventory of
N
applications, which could be included in an
ot
environment, and enables necessary app
remediation efforts to begin.
fo
rr
• A capabilities assessment validates that an
organization’s supporting infrastructure and
es
operations are ready for a new virtualization
al
environment.
e
or
di
s tri
but
io
n
Key Notes:
• An application assessment creates an inventory of applications, which could be included in an environment, and enables
necessary app remediation efforts to begin.
• A capabilities assessment validates that an organization’s supporting infrastructure and operations are ready for a new
virtualization environment.

N
ot
User Layer
fo
rr
es
al
e
Module 2
or
di
s tri
but
io
n
Key Notes:
• Welcome to the User Layer module. This is the second module in the Citrix Virtual Apps and Desktops 7 Assessment,
Design and Advanced Configuration course.
• Throughout this module, we will explore the considerations for endpoints and peripherals from a deployment,
management and a lifecycle perspective, review challenges with multiple versions of Citrix Workspace app in an
environment and discuss network connectivity between endpoints and VDAs and the impact it has on the user experience,
including connection links, re-connect options and peripherals connected over different bandwidths.

Learning Objectives
• Identify the considerations for incorporating
N
endpoints and peripherals.
ot
• Examine the considerations and challenges when
deploying Citrix Workspace app.
fo
rr
• Determine the network connectivity and graphics
requirements in order to implement a high-quality
es
user experience.
al
e
or
di
s tri
but
io
n
Key Notes:
• Identify the considerations for incorporating endpoints and peripherals.
• Examine the considerations and challenges when deploying Citrix Workspace app.
• Determine the network connectivity and graphics requirements in order to implement a high-quality user experience.

• What’s new with the HDX in the 1912 LTSR: https://www.citrix.com/blogs/2019/12/18/whats-new-with-hdx-in-
the-1912-ltsr/
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
ot
Endpoints and Peripherals
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify the considerations for incorporating
N
endpoints and peripherals into an environment’s
ot
design.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Identify the considerations for incorporating endpoints and peripherals into an environment’s design.

Endpoint Considerations
Endpoint Selection
N
ot
Desktop Laptop/Notebook Thin Client Phone Tablet Workstations
fo
Knowledge Knowledge Knowledge
Typical user
rr
Task Worker Task Worker Power Worker
Worker Worker Worker
es
Typical location Internal Any Internal Any Any Internal
al
e
Linux / Win /
or
Typical OS Win Win / Mac Chrome OS / iOS / Android iOS / Android Win
Vendor specific
di
s
Peripheral support Extensive Extensive Vendor specific Limited Limited Extensive
tri
b ut
io
n
Key Notes:
• The user’s primary endpoint device must align with the overall business objectives as well as each user’s role and
associated requirements that were identified during the user segmentation phase. In many circumstances, multiple
endpoints may be suitable, each offering differing capabilities.
• First, let’s discuss the most commonly used endpoint devices:
• Desktops typically include a full-sized case containing the CPU(s), memory, power supply etc. and which would
typically sit underneath, beside or on top of a desk.

• Laptop/notebooks are a smaller, portable version of a desktop, which can be folded shut during
transportation. Because the components must fit into a smaller physical space, laptops are typically less
powerful than a desktop of the same cost.
• Thin clients are relatively low-cost and lightweight computers designed to connect to remote servers, and
as such, is ideal as managed endpoints for Citrix Virtual Apps and Desktops environments. They do not
have as much local processing power as “fat clients” (e.g. desktops and laptops). However, the
capabilities of endpoints have grown along with efficiencies offered in thin client form factors. Even mid-
N
range thin clients now have graphics capabilities that allow utilization of HDX features such as multi-
ot
monitor support while offering management and power efficiency benefits. A variant of the thin client is
fo
the “zero client”, which does not have a local operating system, but instead uses firmware to connect to a
remote machine over a specific protocol. The Citrix Ready marketplace offers low-cost zero clients such
rr
as the Citrix Workspace Hub (a Raspberry Pi-based zero client) to meet this use case for a Citrix Virtual
es
Apps and Desktops environment.
al
• Mobile phones and smart phones have proliferated rapidly over the last decade, and smart phones now
have the capability of running multiple sophisticated applications. The primary challenge with mobile
e
devices is adapting desktop-based applications for the smaller screens and limited peripheral capabilities
or
of these devices.
di
• Tablets are very similar to smart phones, except that they typically have larger screen sizes. Tablets are
popular among a number of industries, including education and health care.
s tri
• Workstations are high-powered desktops, often connected to multiple monitors. They often include high-
b
end CPUs and GPUs designed to support resource-intensive graphics, engineering, scientific, and
ut
financial applications.
io
• Now that the endpoint devices have been identified, let’s match them with each user’s role to provide the best
user experience:
n
• Task workers are typically employees who must perform highly defined, structured, and repetitive tasks
within an organization. Examples include customer support agents, billing processors, and factory
workers.
• Knowledge workers are typically employees with less well-defined and structured job responsibilities that
may require a variety of applications and specialized knowledge. Examples include business managers,

and IT systems administrators.
• Power workers run resource-intensive applications and require a high quality graphics user experience.
Examples include graphic designers and CAD/CAM technicians.
• Finding VDI Thin Clients Just Got Easier: https://www.citrix.com/blogs/2016/01/04/finding-vdi-thin-clients-just-
got-easier/
N
• Citrix Ready Workspace Hub: https://citrixready.citrix.com/program/workspace-hub.html
ot
• Secure virtual desktop with Samsung DeX and Citrix: https://www.citrix.com/global-partners/samsung/secure-
fo
desktop-experience.html
• Samsung DeX(Samsung Galaxy S8/S8+ with DeX Station): https://citrixready.citrix.com/samsung-electronics-
rr
co-ltd/samsung-dex-samsung-galaxy-s8-s8-with-dex-station.html
es
• Citrix Ready Marketplace: https://citrixready.citrix.com/info/endpoints.html
al
e
or
di
s tri
but
io
n

Endpoint Ownership
N
ot
fo
Corporate / Corporate / Corporate /
Typical Ownership
rr
Corporate Corporate Corporate
BYOD BYOD BYOD
es
al
Corporate
YES YES YES YES
e
Device
or
High
Streamed Remote
di
Security Local VM
Start User FlexCast?
VHD PC BOYD
s
FlexCast? FlexCast?
Group?
tri
NO NO NO NO
b ut
io
n
Key Notes:
• In many organizations, endpoint devices are corporate owned and managed. However, more and more organizations are
now introducing bring your own device (BYOD) programs to improve employee satisfaction, reduce costs and to simplify
device management.
• Even if BYOD is a business priority, it does not mean that every user should be allowed to use a personal device in the
corporate environment.
• Certain user requirements can greatly impact the suitability of personal devices:

• Security – Users requiring a high-level of security might not be able to bring a personal device into the
secured environment for risk of data theft.
• Mobility – Users operating in a disconnected mode might not be able to use a personal device, as the
local VM desktop VDI model associated with this type of requirement can have specific hardware
requirements, or special maintenance requirements.
• Desktop loss criticality – Users with a high desktop loss criticality rating might require redundant
endpoints in the event of failure. This would require the user to have an alternative means for connecting
N
in the event their personal device fails, likely making these users poor candidates for a BYOD program.
ot
• VDI models – A personal device should not be recommended for user groups utilizing a local VDI model
fo
like a local streamed desktop (Streamed VHD), local VM desktop or Remote PC Access. These VDI
models typically require a specific hardware configuration or installation that will restrict device selection.
rr
es
al
e
or
di
s tri
b ut
io
n

Endpoint Lifecycle
N
ot
fo
Typical Lifecycle
rr
3-4 years 2-3 years 3-8 years 1-3 years 1-3 years 2-3 years
es
Wear and Peripheral and Wear and Application and
Refresh reasons Age Wear and battery
al
battery graphics battery graphics
e
or
Total Cost of Ownership Medium Medium / High Low Medium Low / Medium High
di
s tri
b ut
io
n
Key Notes:
• Endpoint lifecycles can play a significant role in the endpoint selection process; organizations must balance the cost of
refreshing their managed devices vs. the other business objectives met by a refresh (new features, better specifications,
less support costs, etc.).
• Organizations may choose to repurpose devices in order to extend refresh cycles or to provide overflow capacity for
contract workers. Endpoints now offer more capabilities allowing them to have longer useful lifespans.
• In many cases, these hardware capabilities vastly exceed the needs of a typical user.

• When coupled with the ability to virtualize application and desktop workloads, this provides new options to
administrators such as repurposing existing workstations. These options go well beyond the simple three-year
PC refresh cycle.
• However, the benefits of repurposing or reallocating a workstation should be balanced against the following
considerations:
• Minimum standards: While cost factors of repurposing existing workstations may be compelling, certain
minimum standards should be met to guarantee a good user experience. At a minimum, it is
N
recommended that repurposed workstations have a 1GHz processor, 1GB of RAM, 16GB of free disk
ot
space and a GPU that is capable of supporting HDX features.
fo
• Business drivers: Priorities underpin the success of any major project. Those organizations that have
prioritized reducing capital expenditure by means of prolonging the hardware refresh cycle can benefit
rr
from repurposing hardware. Conversely, if an organization’s business drivers include reducing power
es
consumption as part of an overall green initiative, purchasing newer endpoints may be beneficial in order
al
to take advantage of the latest generation of power management capabilities available in the most
modern devices.
e
• Workload: The type of work and VDI model for an end user can determine whether they are a good
or
candidate for a repurposed endpoint or may be better served with a new device. If the work performed by
di
the individual involves locally installed applications, the individual may be best served by a new endpoint
that offers the most powerful and recently updated processor and graphics architecture. However, if a
s tri
user is largely performing tasks associated with virtualized applications that do not involve the latest
b
multimedia capabilities such as webcams, VoIP and media redirection, then a repurposed workstation
ut
should be a viable alternative.
io
n

Citrix Ready Thin Clients
N
Features HDX Ready HDX Premium HDX 3D Pro
ot
HDX Plug n Play – USB
fo
HDD Video Playback – Server Rendered
rr
Windows Media
es
Print using Citrix Universal Printer Driver
al
HDX Real Time Audio (VOIP)
e
HDX Smartcard Support
or
HDX Rich Graphics – 3D Pro
di
HDX Pixel Perfect Lossless Support
s tri
b ut
io
n
Key Notes:
• Another important consideration is that not all thin clients are alike. Citrix has created three categories of thin clients
available in the Citrix Ready marketplace to assist organizations in choosing the model that best fits their use cases:
• HDX Ready: HDX Ready Thin Clients serve the daily task workers who need access to basic business productivity
applications like office suites and various enterprise resource planning (ERP) related software for business
management.
• HDX Premium: In addition to the basic functionalities offered by HDX Ready Thin Clients, these devices enable

unified communication solutions such as Skype for Business (formerly Lync) for better communication
and collaboration by leveraging Citrix HDX Real-time Optimization Pack.
• HDX 3D Pro: HDX 3D Pro Thin Clients cater to the power users who need high-end capabilities to
access centrally delivered 3D graphics-intensive apps with powerful performance.
• Field experience has shown that some customers have had to replace “HDX Ready” Thin Clients within 3-4yrs
as the device or firmware would not support newer HDX capabilities such as HDX RealTime Optimizations
and newer webcams or other devices (USB 3.0). Also, multi-monitor support may require a Thin Client refresh
N
as newer monitors may only support HDMI, DP or DVI connections, removing VGA support.
ot
fo
• Find Your Thin Client Devices: https://citrixready.citrix.com/content/dam/ready/assets/thin-clients/thin-clients-
rr
features.pdf
es
al
e
or
di
s tri
b ut
io
n

Endpoint Management
N
ot
fo
BYOD N/A User or MDM N/A User or MDM User or MDM N/A
rr
SCCM / Altiris SCCM / Altiris / SCCM / Altiris /
es
Corporate owned / Etc. Etc.
Vendor system User or MDM User or MDM
Etc.
al
Maintenance cost High High Low Medium Medium High
e
or
Potential risk Medium High Low High High High
di
Hardware
Hardware Lost / Damaged Hardware failure
s
Typical reason for risk failure / virus / Virus
failure / port Lost / Damaged Lost / Damaged
/ virus
tri
failure
b ut
io
n
Key Notes:
• The breakdown risk noted for phones and tablets are due to users dropping and losing them.
• Consider implementing a Mobile Application Management (MDM) system such as Citrix Endpoint Management to manage
phones and tablets. New MDM solutions can even manage Windows 10 and Mac laptops.
• Citrix Workspace Environment Management (WEM) can be used to manage thin clients and converted desktops by using
the WEM Transformer feature. This includes actions such as process launcher mode, auto-logon mode, and basic power
management settings.

• Workspace Environment Management Settings – Advanced: https://docs.citrix.com/en-us/workspace-
environment-management/current-release/user-interface-description/transformer-settings/advanced.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Endpoint to User Mapping
N
ot
fo
Remote
User Location Office workers Office / remote Office workers Remote workers Office workers
rr
workers
es
User Mobility None High None High High None
al
GPO / NTFS / Vendor specific
GPO / NTFS / GPO / NTFS /
e
User Security Lockdown / lockdown by MDM MDM
Lockdown Lockdown
Or MDM default
or
Roaming Local profile & Limited & Citrix Limited & Citrix
Roaming profile
profile & Citrix Content Mandatory or Content Content
di
User Personalization & Folder
Folder Collaboration none Collaboration for Collaboration
s
redirection
redirection for data data for data
tri
b
User Workload Low to high Low to high Low to high Low Low to medium High
ut
io
n
Key Notes:
• Ultimately, endpoints should be assigned to users based on their location, as well as their mobility, security,
personalization, and workload requirements.
• If all the needs of a particular user group are not met by a single device, consider whether an additional device type is
warranted. For example, office workers could utilize a thin client while in the office but require a tablet or smartphone to
perform certain tasks remotely.
• Certain vendors have developed solutions for these use cases. For example, Samsung Dex, which is a Citrix Ready

device, allows users to insert their Samsung Galaxy mobile device into a dock which is connected to a
monitor, keyboard and mouse. Citrix Virtual Apps and Desktops can be used to provide access to the
necessary resources while using this “thin client” mode.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Peripherals
Type Characteristics HDX Channel
Keyboard and mouse These devices are used both in the endpoint and in the session. TWI
Audio Can be available on the endpoint as well as in session. ClientAudio
N
ot
Citrix Workspace App captures the webcam images on the physical endpoint device,
Webcams Multimedia
optimizes them and sends them to be displayed in session.
fo
Endpoint data storage devices (USB memory sticks, DVDs & endpoint drives) can be
rr
Endpoint drives made available in the session using Client Drive Mapping. USB mapping not ClientDrive
recommended.
es
Typically smart card needs to be available on the endpoint and in session and removal
al
Smart Cards SmartCard
of the smartcard is used for automatic lock or logoff.
e
Printers defined on the endpoint can be mapped through to the session using OEM
Printers Print
or
drivers or Citrix Universal drivers.
Scanners can be made available in the session using TWAIN redirection. USB mapping
di
Scanners / TWAIN TwainRdr
not recommended.
s
Typically only used for: Devices without a virtual channel, Specialty pointer devices,
tri
USB GenericUSB
Non-compliant peripheral devices.
b ut
io
n
Key Notes:
• The next step is to determine the types of peripherals that will be required in the environment.
• If needed, you can create your own Virtual Channel using the Virtual Channel SDK.
• Creating a virtual channel using the Virtual Channel SDK requires intermediate programming knowledge.
• The Citrix Virtual Channel Software Development Kit (VCSDK) allows you to write and develop both host-side
applications and Workspace app-side drivers to support additional virtual channels using the Citrix HDX protocol.
• It is best to use this method when it is necessary to provide a major communication path between the client and the

server.
• For example, if you are implementing usage of a device on the client side, such as a scanner, to be
used with a process in the session.
• The Virtual Channel SDK requires the WFAPI SDK to write the server side of the virtual channel; you can
reference: https://www.citrix.com/community/citrix-developer/xenapp-xendesktop/wfapi-sdk.html
• To download and use the Citrix Virtual Channel Software Development Kit, go to: Virtual Channel SDKs:
https://www.citrix.com/downloads/workspace-app/virtual-channel-sdks/virtual-channel-sdk.html
N
• Then, select “Download File” to get the latest Windows version available.
ot
• The development documentation for writing these Windows virtual channels, is under: https://developer-
fo
docs.citrix.com/projects/workspace-app-for-windows-virtual-channel-sdk/en/latest/
• The development docs includes information on System Requirements, Build Process, steps on using
rr
the Virtual Channel SDK, and Programming Guide for reference.
es
• There are also development information for Linux and Chrome.
al
e
• Peripheral Devices in XenDesktop: https://www.citrix.com/blogs/2014/02/03/peripheral-devices-in-xendesktop/
or
• USB Support in XA/XD Environment: https://support.citrix.com/article/CTX816193
di
• Generic USB Redirection Deployment Guide: https://support.citrix.com/article/CTX137939
• Citrix ICA Virtual Channels Overview: https://support.citrix.com/article/CTX116890
s tri
b ut
io
n

Peripherals
Impact on Workflows
1. Determine all peripherals needed in the organization.

2. Determine full functionality with Citrix Workspace app version, endpoint type and OS.
N
3. Determine application behavior with redirected peripheral.
ot
4. For unsupported peripherals, consider upgrading or investigate workaround.
fo
rr
es
al
e
or
di
s tri
1 2 3 4
b
ut
io
n
Key Notes:
• When designing a Citrix Virtual Apps and Desktops environment, it is important to identify the impact peripherals have on
user workflows.
• If a required peripheral is unsupported in a virtual environment, consider upgrading, is possible or investigate a
workarounds to consider:
• Deploy the app locally on one PC for integration purposes, exporting to a file on the endpoint and importing inside the
VDA or develop a custom virtual channel to extend support.

• Local app access allows an administrator to deploy the app locally on the user's device and use the Citrix
stack to display the local app within the virtual desktop.
• Local App Access and URL Redirection: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/general-content-redirection/laa-url-redirect.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Peripherals
Scalability Considerations
Identify Requirements Assign HDX Channel Optimize for Networks
N
ot
fo
• Identify drivers and software • Consider deploying peripherals • Identify bandwidth needed to
needed on endpoint and VDA. on HDX virtual channels rather redirect peripherals.
rr
than USB redirection.
• Identify peripheral usage
es
• Consider limiting peripheral
pattern. mapping to well performing
al
networks.
e
• Consider controlling HDX
or
channel bandwidth when using
di
peripherals over WAN links.
s tri
but
io
n
Key Notes:
• USB redirection may be required in cases where the peripheral doesn’t have an HDX-optimized virtual channel –
examples include gaming controllers, specialty keyboards, space mice, developer access to mobile devices, legacy
peripherals, and others. However, this comes at a scalability cost, because using USB redirection requires more network
bandwidth than if the same device communicated via an HDX virtual channel.
• For example, mapping a printer through the USB channel will consume much more bandwidth than mapping that
same printer through the print virtual channel.

• Additionally, when using USB redirection, the local device loses access to the peripheral until the HDX session
is disconnected or ended.
• The Peripherals Easy Test Tool can be used to verify that a specialty device is functioning as expected inside
a simulated HDX session.
• Peripherals Easy Test Tool: https://support.citrix.com/article/CTX214040
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Peripherals
Security Considerations
N
Type Risk Solution
ot
Client Drives Data leaks or virus imports Unidirectional mapping or disable feature
fo
rr
Clipboard Data leaks Unidirectional mapping or disable feature
es
Client Print Data leaks Disable feature for external users
al
e
USB Data leaks, virus imports and AutoPlay Limit device categories or disable feature
or
Webcams Privacy concerns, data leaks Limit device categories
di
s
Disable any virtual channels not required.
General All virtual channels are open by default
tri
Granulated policy configurations
b ut
io
n
Key Notes:
• Data theft or malicious activity launched from malware is a big risk and preventive measures are a top priority.
• Allowing peripherals increases the chances of data leaks, virus attacks and privacy concerns.
• When considering the peripherals allowed in a Citrix Virtual Apps and Desktops environment, leading practice is to
implement policies that limits peripheral usage for all users, then create override policies to allow usage of certain
peripherals only for certain user groups.

N
ot
fo
Which corporate-owned endpoint typically has the
lowest Total Cost of Ownership?
rr
es
Thin Clients typically have the lowest TCO, because
the devices require less maintenance, use less power
al
and typically have a longer lifetime.
e
or
di
s
tri
b
ut
io
n

N
ot
Citrix Workspace App
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine the considerations and challenges when
N
deploying Citrix Workspace app.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Examine the considerations and challenges when deploying Citrix Workspace app.

Citrix Workspace
App Version
Considerations Operating
System
N
Access Workspace
ot
Method App Type
fo
Features
Performance
rr
Look & Feel
es
al
e
or
Workspace
Device
App
di
Type
Version
s tri
b ut
io
n
Key Notes:
• While most organizations should simply deploy the latest Citrix Workspace app compatible with their endpoint, it is
important to recognize that there are certain differences between editions.
• Citrix provides a feature matrix to assist in determining the most appropriate edition of Citrix Workspace app for each user
group.

• Citrix Workspace App Feature Matrix: https://www.citrix.com/content/dam/citrix/en_us/documents/data-
sheet/citrix-workspace-app-feature-matrix.pdf
• Citrix Workspace app for Windows: https://docs.citrix.com/en-us/citrix-workspace-app-for-windows.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Challenges with Implementing Multiple Versions of Citrix
Workspace App
N
ot
fo
rr
es
Citrix Content Collaboration
al
e
or
di
s tri
Citrix Workspace App 4.9 LTSR Citrix Workspace App 1912 LTSR
but
io
n
Key Notes:
• Running multiple versions of Citrix Workspace app or legacy Citrix Receiver within an organization may lead to additional
troubleshooting efforts on application behavior and peripheral mappings.
• Citrix Workspace app has additional capabilities over legacy Receiver, which may prevent some users running Receiver
from having certain security capabilities, or direct access to specific SaaS applications.
• Citrix Workspace app aggregates and incorporates the full capabilities of Citrix Workspace app as well as other Citrix
client technologies - including the Citrix Gateway plug-ins, and Citrix Endpoint Management Secure Hub.

• Citrix Workspace app for Windows 1912 LTSR: https://docs.citrix.com/en-us/citrix-workspace-app-for-
windows/1912-ltsr/
• Citrix Workspace app for Windows 2009.5 Current Release: https://docs.citrix.com/en-us/citrix-workspace-
app-for-windows/about.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

A company maintains the latest Citrix Virtual Apps

and Desktop environment and has users running
legacy Receiver, and some other users running
Citrix Workspace app.
N
What challenges might the company have with
ot
this deployment?
fo
rr
• Potential conflicts with application behavior and
peripheral mappings for users.
es
• Legacy Receiver users lack new features, such as
al
data loss prevention, secure internet browsing
e
capabilities and secure access to SaaS apps.
or
• If Citrix Cloud is being used, only users running Citrix
di
Workspace app will be able to utilize Citrix
s
Workspace services.
tri
utb
io
n

N
ot
Network Connectivity
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the network connectivity and graphics
N
requirements in order to implement a high-quality
ot
user experience.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the network connectivity and graphics requirements in order to implement a high-quality user experience.

Network Connectivity and the User Experience
N
The network and related hardware can be
ot
a big factor in the end user experience Satellite
and its connection to the VDA resource.
fo
rr
es
Wifi
Challenges may include:
al
External Citrix Gateway
• Latency Switch Network VDA
e
Users Router Hardware
• Packet loss
or
Internet
• Bandwidth limitations
di
s
Internal
tri
Users
b
Cell tower
ut
io
n
Key Notes:
• One of the biggest factors in the user experience is the network between the user's endpoint and the VDA resources being
accessed.
• Understand which networks the users are hosted on, and the capabilities on these networks, then select the best transport
protocol, policy optimizations and peripheral limitations to enable the best possible user experience.
• Examples of challenging use cases:
• High latency due to distance (many customers want to reduce the number of data centers)

• Public Internet connections with jitter and packet loss
• Wi-Fi and 4G/LTE connections with intermittent spectral interference and multipath
• Limited bandwidth MPLS connections to widely distributed offices (e.g. bank branches)
• Satellite (VSAT) links with low bandwidth and very high latency
• Overcoming latency to serve a global user population: https://www.citrix.com/blogs/2016/12/14/overcoming-
N
latency-to-serve-a-global-user-population/
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Throughput and Latency Considerations
Standard HDX Guidelines

Latency Bandwidth per user
(No Multimedia or HDX3D)
Great User Experience 0 to 150ms >100kbps
N
ot
Good/Acceptable User Experience 150ms to 300ms 50kbps to 100kbps
fo
rr
Degraded User Experience Over 300ms <50kbps
es
al
Bandwidth and latency impact on user experience depends on:
e
• VDA, Operating System and Citrix Workspace app versions
or
• HDX Protocol (Thinwire, HDX 3D Pro)
• Virtual Channels and Peripherals
di
• Application characteristics
• Multimedia redirection
s tri
• Multi-monitor and high-resolution environments
utb
io
n
Key Notes:
• Different use cases, and even groups within the same use cases, may require different settings based on what type of
activities they need to perform within their session, how far they are from Virtual Delivery Agents hosting their sessions,
and the characteristics of their network connection. Therefore, make sure to select the appropriate graphics mode for each
scenario (more on this in an upcoming slide).
• In addition to the graphics mode, HDX offers an array of options that can help further optimize the performance and
experience of multimedia content. There are also settings that should be applied or changed in Windows itself to optimize

the operating system for a virtual workload.
• Assuming the environment has been tuned properly, the figures in the chart reflect what Citrix Consulting sees
on average in regards to latency when using Thinwire.
• How Network Latency Impacts User Experience: https://www.citrix.com/blogs/2017/09/25/how-network-
latency-impacts-user-experience/
N
• HDX Graphics Overview: https://docs.citrix.com/en-us/tech-zone/design/design-decisions/hdx-graphics.html
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Estimating User
Bandwidth Bandwidth (kbps) = 90H + 30D + 170X + Z
Requirements
To estimate requirements for
N
users accessing the Citrix
ot
Virtual Apps and Desktops Number of Number of Number of Additional
environment, a formula can be concurrent concurrent concurrent 1000 to 2000
fo
used to provide a good knowledge task workers. power kbps minimum
workers. workers. capacity to
rr
estimate of bandwidth that will support peaks
es
be needed. in smaller
environments
al
(<10 users).
e
or
di
Example:
s
4,300 kbps = 90(10) + 30(85) + 170(5) + 0
tri
b ut
io
n
Key Notes:
• With the release of Citrix Virtual Apps and Desktops 1912 LTSR, the protocol has gone through many improvements that
directly impact the user experience and bandwidth utilization.
• Keep in mind that it is Citrix leading practice to implement a standard optimization policy to have the best user experience.
• This formula can be used to provide an estimate of the bandwidth requirements for users accessing a Citrix Virtual Apps
and Desktops environment.
• Sample lab tests show the task worker would require around 30 kbps, knowledge worker requires 90 kbps, and a power

worker requires 170 kbps.
• The formula is based on 60 minute LoginVSI 4.1.39 testing using the baseline HDX graphics policy settings.
The Citrix Optimizer Tool was also ran on the test VDAs. This example is not meant as a substitute for
environment-specific testing.
• 3D applications tend to be harder to forecast in terms of bandwidth usage; the figure provided in the formula is
intended as a baseline only.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Graphics Modes Design Considerations
Graphics Mode Use Case Performance Policy Configuration Codecs
Balanced: optimized for

Use video codec for
Default Mode: bandwidth and scalability, JPEG = Still images (quality
compression
(Optimized for majority of use delivers good image quality 80)
Thinwire
N
Use when preferred (default)
cases) Uses hardware and frame rate for video H.264 / H.265 = Video
or
acceleration if available content RLE = Text
ot
For actively changing regions
fo
H.264 YUV 4:2:0 (default)
Optimal for 3D graphics/design
or
type applications requiring Optimized for performance
rr
H.264 YUV 4:4:4
hardware acceleration (frame rate) at the expense of Optimize for 3D graphics
HDX 3D Pro image quality and bandwidth workload = Enabled
or
es
H.265
*To be used only with GPU-
(requires supported GPU on
enabled VDAs
al
VDA and client)
e
Visual quality = build to
High FPS at the expense of lossless
Recommended for users who H.264 + RLE
or
image quality for moving Use video codec for
Build to Lossless need performance and image
images. Pixel perfect image compression = enabled or
or
quality JPEG + RLE
quality for final image. disabled to switch between
di
H.264 and JPEG
s
Use video codec for
tri
Default Mode: May vary based on screen compression RLE = Still images
Lossless (optimized for majority of use contents Use when preferred (default) RLE = Video
b
cases) or RLE = Text
ut
© 2021 Citrix Authorized Content For actively changing regions
io
n
Key Notes:
• General performance and scalability considerations:
• In the context of display remoting the size of a user session can vary significantly based on display resolution and the
number of monitors alone. As the session grows in size more server and client resources are required, for rendering
and encoding/decoding of the graphics, and more data needs to be sent from the server to the client via the network.
This has a direct impact to session performance and server scalability.
• Bandwidth constraints could limit frame rates and reduce image quality affecting session interactivity and user

experience as a result.
• The endpoint device must have adequate hardware resources available to support the desired display
configuration. This could mean having enough CPU resources and in some cases a GPU that can handle
the graphics workload.
• Performance limitations of Thin Clients may become apparent at high resolutions such as 4K, for
example.
• Selecting the correct display protocol determines the quality of static images, video and text within the user’s
N
session as well as determining the impact on single server scalability. These protocols were introduced at
ot
different times, and in many cases to address specific needs or use cases.
fo
• Understanding the background of each protocol will aid in selecting appropriate protocols, particularly in a
Citrix Virtual Apps and Desktops 1912 LSTR environment, where all of them are available.
rr
• To select the appropriate protocol for a particular use case, it is important to understand how each protocol
es
rates in terms of bandwidth consumption, CPU consumption, overall Virtual Delivery Agent machine scalability,
al
and the overall user experience.
• For user experience, the rating is subjective based on the perception of an average user. Protocols that
e
can support higher framerates are also considered to contribute to an overall higher user experience.
or
• H.264 Video Codec is the development of Citrix’s “Deep Compression” or “SuperCodec” around 10 years ago
di
when HDX 3D Pro was developed for large aerospace customers. It’s essentially the Deep Compression
version 2.0 codec but modified to leverage a CPU instead of requiring a GPU.
s tri
• This protocol provides the highest frame rate but uses a lot of CPU resources and bandwidth, and will
b
impact Single Server Scalability.
ut
• Thinwire is basically the name of the virtual channel for display/remoting and is derived from Citrix’ original
io
patents from 20-25 years ago on how to thinly transfer data over a wire. It was rebuilt from the ground-up for
“modern” operating systems when Microsoft deprecated GDI/GDI+ and forced DWM in Win8/2012.
n
• Overall, it is a very balanced protocol generator in terms of CPU, bandwidth, frame rate and single server
scalability.
• Video playback would typically be the most expensive operation from a CPU and bandwidth perspective,
but no worse than the “Deep Compression V2” codec.
• Thinwire can detect and encode video regions with H.264 (or H.265 if supported), using hardware if a

GPU is available. This reduces CPU usage by encoding just the video regions of the screen, leaving the
static content to be encoded in the normal way. This feature is known as “Selective H.264”.
• Thinwire with Selective H.264 should now be used for a majority of use cases in new environments. It is
the default setting and requires no extra configuration or policies to be set (also referred to as Adaptive
Display 2.0).
• HDX 3D Pro:
• Optimized for performance (frame rate) at the expense of image quality and bandwidth.
N
• Image quality can be improved by using H.264 YUV 4:4:4 or H.265 options (Windows clients only)
ot
• Optional Policy Configuration: H.264 YUV 4:4:4 = (Allow visually lossless compression = enabled) +
fo
(Visual quality = always lossless) or H.265 = H.265 Decoding for graphic (Windows client policy)
• Build to Lossless:
rr
• Generally for 3D Pro users who need high frame rates when things are moving and pixel perfect images
es
when contents are static.
al
• The changes to image quality may be too distracting for some users.
• Improved to only change quality when needed. Dynamic image analysis is performed to determine
e
whether changing quality is required. For example, on wireframe imagery, it is better to stay lossless.
or
• Lossless:
di
• To be used as last resort for improving image quality. Ex. Medical imaging.
s tri
b
• Citrix Virtual Apps and Desktops 1912 Product Docs: Graphics - https://docs.citrix.com/en-us/citrix-virtual-
ut
apps-desktops/graphics.html
io
• HDX Graphics Overview - https://docs.citrix.com/en-us/tech-zone/design/design-decisions/hdx-graphics.html
• Improving the Citrix User Experience: https://www.citrix.com/blogs/2018/01/02/improving-the-citrix-user-
n
experience/
• Citrix Virtual Apps and Desktops 1912 LTSR Graphics: https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops/1912-ltsr/graphics.html

Transport Protocols
Adaptive Transport Application

Layer
Citrix Virtual Apps and
N
Desktops environments will
ot
use EDT unless the
appropriate firewall ports are
fo
not open, the Citrix Gateway
rr
is not configured properly, or
EDT
es
Adaptive Transport is
disabled. If any of these
al
conditions are true, then TCP TCP Transport Layer
e
is used.
or
di
UDP
s tri
b ut
io
n
Key Notes:
• Adaptive Transport is a feature that allows Virtual Apps and Desktops to use Enlightened Data Transport (EDT) or TCP for
transporting ICA over the network. It prioritizes EDT and will fall back to TCP if EDT cannot be used. This could be
because the firewall is blocking the required ports or the Gateway does not have DTLS enabled.
• Enlightened Data Transport is a network transport protocol for Citrix Virtual Apps and Desktops. It can be faster, more can
scalable, and can improve application/desktop interactivity, specially on challenging long-haul WAN and internet
connections.

• EDT maintains high server scalability and efficient use of bandwidth. By using EDT, ICA virtual channels can
respond more rapidly to changing network conditions.
• When the policy setting for HDX Adaptive Transport is set to Preferred, data transport over EDT is used as
primary and fallback to TCP.
• There are two ways to transport the HDX protocol across the network:
• TCP
• Uses the industry standard TCP transport protocol.
N
• Common transport protocol over LAN and low-latency WAN connections, but suffers when connection
ot
distances increases, thus increasing latency and incurring more retransmissions.
fo
• Less transport overhead than UDP
• EDT
rr
• The Enlightened Data Protocol (EDT) is based on UDP.
es
• It is meant for high latency and/or high-packet loss networks, which used to be most common on
al
long-distance WAN links.
• Migration of workloads to the cloud and increase in work-from-home have resulted in network
e
challenging conditions to become more common, and also unpredictable.
or
• In terms of transport protocols, most environments should be using EDT if they are using Citrix Virtual Apps
di
and Desktops 1912 LTSR.
• The main design considerations here are validating that the environment will support the prerequisites:
s tri
• The Common Gateway Protocol (CGP) and by extension, Session Reliability must be enabled for any
b
reverse proxy HDX connections going through a Citrix Gateway. This is also required for MTU Discovery
ut
to work. Currently, this is enabled by default. Port 2598 must also be allowed to pass through the
io
applicable firewalls.
• Citrix Gateway must also have DTLS enabled on the front-end VPN vServer.
n
• Preferably, use build 12.1.56.22+ or 13.0.52.24+ since those builds contain important DTLS fixes as
well as MTU Discovery support.
• DTLS is enabled by default on Gateway vServers when created.

• Enlightened Data Transport is getting even smarter and more robust!:
https://www.citrix.com/blogs/2020/06/18/enlightened-data-transport-is-getting-even-smarter-and-more-robust/
• Adaptive transport: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/technical-overview/hdx/adaptive-
transport.html
• Configure Citrix Gateway to support Enlightened Data Transport and HDX Insight: https://docs.citrix.com/en-
us/citrix-gateway/13/hdx-enlightened-data-transport-support/configuring-citrix-gateway.html
• The following resources are a little dated and may contain some information that is no longer accurate, but
N
they do provide a good background on why EDT and Adaptive Transport were created:
ot
• HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part 1):
fo
https://www.citrix.com/blogs/2017/11/17/hdx-adaptive-transport-and-edt-icas-new-default-transport-protocol-
part-i/
rr
• HDX Adaptive Transport and EDT: ICA’s New Default Transport Protocol (Part 2):
es
https://www.citrix.com/blogs/2017/11/20/hdx-adaptive-transport-and-edt-icas-new-default-transport-protocol-
al
part-ii/
e
or
di
s tri
but
io
n

Media Content Redirection
During User Layer design: During Resource Layer design: During Control Layer design: During Hardware Layer design:
N
• Determine what types of content the • Adjust Virtual Delivery Agent resource • Configure redirection policies as • Verify that network bandwidth is
ot
endpoints can support. specifications based on amount of needed to achieve the desired sufficient to support content transfer to
server-side rendering that must be settings. the VDAs/endpoints.
• Determine whether endpoints can and
performed.
should have direct access to the
fo
• Verify that internal media file servers • Perform hardware sizing to
content. are accessible from intended accommodate the VDA resource
rr
endpoints/VDAs, and have sufficient allocations determined in the
• Verify that endpoints have or can
resources to handle the expected Resource Layer.
receive the prerequisites needed to
load.
es
access the desired content types.
al
e
HTML5 Multimedia Redirection Browser Content Redirection Windows Media Redirection
or
di
s tri
b ut
io
n
Key Notes:
• Use content redirection to offload resource consumption away from the VDA and to optimize the user experience on slow
links.
• This will require several design decisions across multiple layers, but starts at the User Layer, where user requirements
and endpoints are identified.
• During the Resource Layer design, it’s a good idea to test the resources on the Virtual Delivery Agents to ensure it can
handle the amount of server-side rendering that must be performed.

• When designing the Control Layer, identify all the redirection policies that should be implemented to achieve
the desired settings. It is also important to verify that internal media file servers are accessible from the
intended endpoints and Virtual Delivery Agents.
• And finally, during the Hardware Layer design phase, verify that the network bandwidth is sufficient to support
transferring the content between the endpoint devices and Virtual Delivery Agents. Be sure to factor in
hardware sizing to accommodate the Virtual Delivery Agent resource allocations determined in the Resources
Layer.
N
• There are three types of media content redirection to consider:
ot
• HTML5 Multimedia Redirection:
fo
• This is effectively the successor to Flash content going forward; as a result the need for HTML5
multimedia redirection is expected to grow. HTML5 multimedia redirection extends the multimedia
rr
redirection features of HDX MediaStream to include HTML5 audio and video.
es
• Flash has been the standard until recently, however, it requires a plug-in, doesn’t work on all devices
al
and has higher battery usage in mobile devices.
• The HTML5 video redirection feature is available for controlled webpages only as it requires the
e
injection of the HdxVideo.js JavaScript into to the webpages where the HTML5 multimedia content is
or
provided from.
di
• Currently, this form of redirection is supported for progressive downloads in mp4 format. This means
a single file is played back as it is downloaded from a media or web server, is encoded at only one
s tri
quality.
b
• Browser Content Redirection:
ut
• Browser content redirection controls and optimizes the way Citrix Virtual Apps and Desktops deliver
io
any web browser content (for example, HTML5) to users. Only the visible area of the browser where
content is displayed is redirected.
n
• HTML5 video redirection and browser content redirection are independent features. The HTML5
video redirection policies are not needed for this feature to work, but the Citrix HDX HTML5 Video
Redirection Service is used for browser content redirection.
• By default, Citrix Workspace app tries client fetch and client render. If client fetch client and render
fails, server-side rendering is tried. If you also enable the browser content redirection proxy

configuration policy, Citrix Workspace app tries only server fetch and client render.
• Windows Media Redirection:
• Windows Media redirection controls and optimizes the way servers deliver streaming audio and video
to users. The client device is utilized for playing the media run-time file as opposed to the server.
Thus, reducing bandwidth requirements for playing multimedia files within the environment.
• Windows Media redirection is supported by most versions of Citrix Workspace app.
• As with other redirection types, consider where the content and endpoints are located, and whether
N
endpoints should be able to directly access the content from a network security and bandwidth
ot
standpoint.
fo
rr
• Multimedia: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/multimedia.html
es
• HTML5 Multimedia Redirection: State of the Union: https://www.citrix.com/blogs/2017/11/06/html5-multimedia-
al
redirection-state-of-the-union/
• HTML5 Multimedia Redirection: State of the Union Part II: https://www.citrix.com/blogs/2018/01/03/html5-
e
multimedia-redirection-state-of-the-union-part-ii/
or
di
s tri
b ut
io
n

Endpoint
Media Content
Web Server
Redirection HDX Session
Strategies 1 Public or
private
network Media content
Endpoint
N
1. Server Fetch & Server Web Server
ot
Render HDX Session
fo
2. Server Fetch & Client Public or
rr
Render private Media content
network
es
3. Client Fetch & Client
Render Endpoint
al
Web Server
e
HDX Session
or
3 Public or
private
di
network Media content
s tri
b ut
io
n
Key Notes:
• There are three available strategies to deliver multimedia applications.
• Each strategy provides the ability for customer’s to ensure they can deliver a full range of multimedia formats, with a great
user experience, while maximizing server scalability to reduce the cost-per-user.
• Strategy 1: Server Fetch and Server Rendering
1. The server fetches the media file from its source, decodes, and then presents the content to an audio device or
display device.

2. The server extracts the presented image or sound from the display device or audio device respectively.
3. The server optionally compresses it, and then transmits it to the client.
• This approach incurs a high CPU cost, high bandwidth cost (if the extracted image/sound isn’t
compressed efficiently), and has low server scalability.
• Thinwire and Audio virtual channels handle this approach. The advantage of this approach is that it
reduces the hardware and software requirements for the clients. Using this approach the decoding
happens on the server and it works for a wider variety of devices and formats.
N
• Strategy 2: Server Fetch and Client Render
ot
• This approach relies on being able to intercept the media content before it is decoded and presented to
fo
the audio or display device. The compressed audio/video content is instead sent to the client where it is
then decoded and presented locally. The advantage of this approach is that the are offloaded to the client
rr
devices, saving CPU cycles on the server.
es
• However, it also introduces some additional hardware and software requirements for the client. The client
al
must be able to decode each format that it might receive.
• Strategy 3: Client Fetching and Client Rendering
e
• This approach relies on being able to intercept the media content URL before it’s fetched from the
or
source. The URL is sent to the client where the media content is fetched, decoded, and presented locally.
di
This approach is conceptually simple. Its advantage is that it saves both CPU cycles on the server and
bandwidth because the server sends only control commands. However, the media content is not always
s tri
accessible to the clients.
b
• If you don’t configure redirection, Server-Side Rendering will be used by default. If you configure redirection,
ut
HDX uses either Server Fetch and Client Render or Client Fetch and Client Render. If those methods fail,
io
HDX falls back to Server-Side Rendering as needed and is subject to the Fallback Prevention Policy.
n
• Multimedia Policy Settings: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/policies/reference/ica-policy-settings/multimedia-policy-settings.html

Session
Interruption
Management Feature Benefits Considerations
• Useful for mobile, wireless • No logging.

connections. • May hide network issue.
Session • No re-authentication required • No re-authentication required
Reliability (enhances UX). (so, potential security concern).
N
• Required on Citrix Gateway for
ot
Adaptive Transport to be used.
• Choose the appropriate
fo
• Allows for reconnection • If re-authentication cookies
feature based on the use attempts without user doing it expire, users must manually
rr
case present in the manually. re-authenticate.
environment. Auto-Client • Allows for logging of reconnect • Session will be closed until
es
Reconnect attempts via HDX policy. reconnection is successful.
• Regardless of which method
al
• Uses authentication mechanism
is used, end-user training based on encrypted user
e
credentials.
and education will increase
or
the manageability of the • Prevents broken sessions from • Only active when Auto-Client
ICA Keep- being disconnected by Terminal Reconnect is being used.
environment long-term.
di
Alive Services. • Does not function when Session
s
Reliability is in use.
tri
b ut
io
n
Key Notes:
• As these features directly impact the end user experience, end users should be educated on the expected session
behavior when a network interruption occurs. This will allow them to distinguish between a session handling the
interruption as designed, and other types of issues that require a support ticket to be opened.
• Session Reliability (CGP):
• Session reliability keeps sessions active and on the user’s screen when network connectivity is interrupted.
• Ideal for 3G/4G or Wi-Fi connections where disconnects are likely to occur.

• Freezes the session screen while trying to re-connect.
• May hide network issues.
• Keep in mind that Session Reliability must be enabled for connections going through the Citrix Gateway
in order to support Adaptive Transport.
• Auto Client Reconnect:
• Auto client reconnect allows or prevents automatic reconnection by the same client after a connection
has been interrupted.
N
• Ideal for reconnecting to disconnected sessions where Session Reliability is not enabled, or a Session
ot
Reliability timeout has occurred
fo
• Logging reconnects is possible, unlike Session Reliability.
• Auto-client Reconnect is enabled by default.
rr
• ICA Keep-Alive:
es
• The server sends keep-alive packets every few seconds to detect if the session is active. If the session is
al
no longer active, the server marks the session as disconnected.
• ICA Keep-Alive works only if you are not using Session Reliability.
e
• ICA Keep-Alive settings override keep-alive settings that are configured in Microsoft Windows Group
or
Policy.
di
• Default interval is 60 seconds (can be modified between 1-3600 seconds).
s tri
b
• Sessions: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-deployment/sessions
ut
• Session reliability policy settings: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
io
ltsr/policies/reference/ica-policy-settings/session-reliability-policy-settings.html
n
• Auto client reconnect policy settings: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/policies/reference/ica-policy-settings/auto-client-reconnect-policy-settings.html
• Keep alive policy settings: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/policies/reference/ica-policy-settings/keep-alive-policy-settings.html
• Is Session Reliability Good or Bad?: https://www.citrix.com/blogs/2013/10/16/is-session-reliability-good-or-bad/

A company maintains a Citrix Virtual Apps and

Desktops environment with Auto-client reconnect
enabled for the local network users to help with
N
any random network interrupts that may take
ot
place. More recently, the company has an
increasing number of remote users that run
fo
various devices connecting to the Citrix
rr
environment. These remote users sometimes
complain of connection interrupt issues.
es
What action can be taken to assist the remote
al
users, while maintaining the current configuration
e
for the local users?
or
Enable Session Reliability
di
s
tri
utb
io
n

Exercise 2-1: User Layer Design
and Verification
Workspace Labs wants to use Workspace
N
Environment Management (WEM) to manage its thin
ot
client endpoints. Your team completed the User Layer
design based on requirements provided by the
fo
business. However, design verification testing shows
rr
several requirements not achieved.
es
al
e
or
di
s
tri
b
ut
io
n

Module 2 Lab
New York
• Connect to lab through HDX StoreFront

NYC-STF-001
N
connection over port 443. 192.168.10.31
User Endpoint
ot
NYC-WRK-001
• Do not launch lab before you DHCP File Server
NYC-FSR-001
Active Directory Server
NYC-ADS-001
Database Server
NYC-SQL-001
Desktop VDA
NYC-DTP-001
Desktop VDA
NYC-DTP-002
192.168.10.17 192.168.10.11 192.168.10.21
need it.
fo
DHCP DHCP
StoreFront
NYC-STF-002
rr
192.168.10.32
• Labs are per module and
decommission after the
es
User Endpoint Delivery Controller Delivery Controller Vendor Active
Desktop VDA Server VDA
NYC-VDC-001 NYC-VDC-002 Directory
allotted time expires. NYC-WRK-002
DHCP 192.168.10.46 192.168.10.45 VDR-ADS-001
NYC-DTP-MAN- NYC-SRV-MAN-
al
001 001
Citrix Gateway 192.168.12.1
DHCP 192.168.10.48
NYC-VNS-001
• Labs cannot be launched
e
192.168.10.100
PVS PVS ELM
multiple times.
or
Provisioning Server Provisioning Server ELM Server
Server VDA Server VDA
NYC-PVS-001 NYC-PVS-002 NYC-ELM-001
User Endpoint NYC-SRV-001 NYC-SRV-002
192.168.10.51 192.168.10.512 192.168.10.76
di
NYC-WRK-003 Citrix Gateway DHCP DHCP
DHCP NYC-VNS-002
192.168.10.101
s tri
b ut
io
n

Exercise 2-1A: Update Design
Requirements Document [15 min]
Task:
N
• Review Design Requirement document.
ot
• Review Detailed Design document.
fo
• Use Design Verification lab to check requirements
rr
met:
es
• Endpoints: NYC-WRK-001 (corporate laptop) and
NYC-WRK-002 (thin client)
al
• Accounts: hr1/Password1, engineer1/Password1 and
e
administrator/Password1
or
• Copy and update Design Requirements document
di
to show which requirements met by design. Focus
on the yellow highlighted fields.
s
tri
b
ut
io
n

Exercise 2-1A
Use Design Verification lab to check design meets

requirements.
• Corporate laptop users unable to access control
N
panel, registry editor, network connections, command
ot
prompt and Windows PowerShell.
fo
• Thin client users restricted to a locked down browser,
which can only access published applications and
rr
desktops. Disable access to taskbar and start menu.
es
• Thin client users automatically logged off when Citrix
session ends.
al
• Thin client users can restart but not shut down
e
endpoint.
or
• Thin client users can manage local printers.
• Thin client endpoints should support multi-language
di
configuration.
s
tri
b
ut
io
n

Exercise 2-1B: Update Detailed
Design Document [20 min]
Task:
N
• Copy and update Detailed Design document
so all requirements met.
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Exercise 2-1C: Update Design
Verification Lab [35 min]
Task:
N
• Update Design Verification lab to match design.
• Endpoints: NYC-WRK-001 (corporate laptop) and NYC-
ot
WRK-002 (thin client)
fo
rr
• Verify all design requirements met.
es
al
e
or
di
s
tri
b
ut
io
n
Key Notes:
• When verifying the new Workspace Environment Management (WEM) settings, be aware that the agent refresh may take
a few minutes to apply the blacklist settings.

Design Requirements – Answer Key
Requirement Met in Requirement Met in Lab

Number Priority Design Requirement
Design Yes/No Yes/No
Yes
The following endpoint types will be managed:
• Sales: corporate laptops WEM Console shows two
User-1 High Yes
• HR: corporate laptops configuration sets.
N
• Engineers: thin clients CorporateLaptopSite and
ot
ThinClientSite.
fo
Centralized management of thin clients and corporate
rr
User-2 High Yes Yes
laptops.
es
No
al
Corporate laptop users unable to access control panel, No
e
registry editor, network connections, command prompt, Hr1 able to access command
User-3 High
Windows PowerShell, and Network section of Windows Some lock down settings prompt, Windows PowerShell,
or
Explorer. missing from restrictions and Network section of Windows
Explorer.
di
No
s
Thin client users restricted to a locked down browser, which
tri
User-4 High can only access published applications and desktops. Yes
Start menu visible when running
Disable access to taskbar and start menu.
b
virtual desktop
ut
io
n

Design Requirements – Answer Key (Continued)
Requirement Met in Requirement Met in Lab

Design Yes/No Yes/No
No
No
Thin client users automatically logged off when
User-5 Medium ThinClientSite should be
Citrix session ends. Session on NYC-WRK-002 not logged off
N
configured to logoff user when
after virtual desktop session logged off.
the Citrix session ends.
ot
No
fo
No
Thin client users can restart but not shut down The power management icon in the top-
rr
User-6 Medium
endpoint. ThinClientSite right most corner of the locked down web
should prevent shutdown. browser allows engineer 1 to restart and
es
shut down the endpoint.
al
No
No
e
User-7 High Thin client users can manage local printers. The settings icon in the top-right corner of
ThinClientSite should allow
or
the locked down web browser does not
viewing printers
include a Printers option.
di
No
s
Thin client endpoints should support multi-
tri
User-8 Medium Yes The setting in the top right corner of the
language configuration.
locked down web browser does not
b
include the language option.
ut
io
n

Detailed Design Requirements – Answer Key
Citrix Workspace App
Category Design Decision Justification
Endpoints managed by WorkspaceLab.
Design requirement User-1: The following endpoint types will be managed:
N
• Sales: corporate laptops
• Corporate laptop • HR: corporate laptops
ot
Endpoint Devices
• Thin client • Engineers: thin clients
fo
Design Verification: Two test endpoints:
• NYC-WRK-001 (corporate laptop)
rr
• NYC-WRK-002 (thin client)
es
Workspace app
1912 or later Version approved by WorkspaceLab.
al
version
e
or
• Corporate laptop: Installed in base image.
Workspace app Install Prevent corporate laptop and thin client users from needing to install and configure
• Thin client: Installed in base image.
Strategy Workspace app.
• Personal device: StoreFront
di
s tri
• Corporate laptop: ESD
Workspace app
• Thin client: ESD New versions of Workspace app automatically deployed to managed endpoints.
Update Strategy
b
• Personal device: StoreFront
ut
io
n

Detailed Design Requirements – Answer Key
Citrix Workspace Environment Manager (WEM)
WEM Version 2005 or later Version approved by WorkspaceLab.
N
ot
fo
WEM SQL Server NYC-SQL-001.workspacelab.com SQL Server dedicated to support Citrix infrastructure.
rr
es
Citrix License Server.
WEM License Server NYC-LIC-001.workspacelab.com
al
Design verification: Using NYC-FSR-001.workspacelab.com.
e
or
Allows different configurations applied to corporate laptops and thin client devices.
Personal devices not managed by WEM.
1. CorporateLaptopSite
WEM Sites
di
2. ThinClientSite
Design Verification: NYC-WRK-001 added to CorporateLaptopSite. NYC-WRK-002
s
added to ThinClientSite.
tri
b ut
io
n

Detailed Design Requirements – Answer Key (Continued)
Citrix Workspace Environment Manager (WEM)
CorporateLaptopSite:
• Hide Control Panel
• Prevent Access to Registry Editing Tools Lock down corporate laptop and thin client devices according to business
N
• Hide Network Connections requirements.
• Hide Administrative Tools • Design requirement User-3: Corporate laptop users unable to access control
ot
• Hide Network Icon in Explorer panel, registry editor, network connections, command prompt and Windows
• Disable command prompt PowerShell.
fo
• Disable PowerShell • Design Requirement User-4: Thin client users restricted to Internet Explorer,
Restrictions ThinClientSite which can only access published applications and desktops. Disable access to
rr
• Enable Transformer: taskbar and start menu.
https://storefront.workspacelab.com/Citrix/ • Design Requirement User-5: Thin client users automatically logged off when
es
EmployeeStoreWeb Citrix session ends.
• Hide printer settings • Design Requirement User-6: Thin client users can restart but not shut down
al
• Hide Shutdown option endpoint.
e
• Hide Taskbar & Start Button • Design Requirement User-7: Thin client users can manage local printers.
• Lock Alt-Tab
or
• Users logged off when session ends
di
Allow Language Enable transformer to support multiple Design Requirement user-8: Thin client endpoints should support multi-language
Selection language support. configuration.
s tri
b ut
io
n

Key Takeaways
• Peripheral support is dependent on the combination
N
of the endpoint, network, operating system, and
ot
Citrix Workspace app version used.
• The lifecycle and hardware cost for endpoint
fo
devices will directly impact the total cost of
rr
ownership for each device type.
es
• Maintaining an environment with multiple versions
al
of Citrix Workspace app can create challenges with
e
troubleshooting, security and application support.
or
di
s tri
but
io
n
Key Notes:
Let’s review the key takeaways of this module:
• Peripheral support is dependent on the combination of the endpoint, network, operating system, and Citrix Workspace app
version used.
• The lifecycle and hardware cost for endpoint devices will directly impact the total cost of ownership for each device type.
• Maintaining an environment with multiple versions of Citrix Workspace app can create challenges with troubleshooting,
security and application support.

Key Takeaways
• Various methods of content redirection exist to
N
reduce resource and bandwidth demands on the
ot
VDA.
• An organization should weigh all the benefits and
fo
considerations for each session interruption
rr
management feature prior to implementation, as
es
each infrastructure will represent a unique use case.
al
e
or
di
s tri
but
io
n
Key Notes:
• Various methods of content redirection exist to reduce resource and bandwidth demands on the VDA.
• An organization should weigh all the benefits and considerations for each session interruption management feature prior
to implementation, as each infrastructure will represent a unique use case.

N
ot
Access Layer
fo
rr
es
al
e
Module 3
or
di
s tri
b ut
io
n
Key Notes:
• Welcome to the Access Layer module. This is the third module in the Citrix Virtual Apps and Desktops 7 Assessment,
• Throughout this module, we will discuss the concept of an access matrix, briefly review the Citrix Gateway and StoreFront
Access Layer components, then dive into some of the key high-level architecture considerations for them and finally
examine the use cases and considerations for a multi-store StoreFront deployment.

Learning Objectives
• Create an access matrix to align User, Access, and
N
Resource Layer design decisions.
ot
• Integrate high-level access architecture
considerations into a virtualization design.
fo
rr
• Determine the architectural needs of an
environment when designing StoreFront stores.
es
• Examine scalability and redundancy options for
al
Access Layer components.
e
or
di
s tri
but
io
n
Key Notes:
• Create an access matrix to align User, Access, and Resource Layer design decisions.
• Integrate high-level access architecture considerations into a virtualization design.
• Determine the architectural needs of an environment when designing StoreFront stores.
• Examine scalability and redundancy options for Access Layer components.

N
ot
Access Matrix
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Create an access matrix to align User, Access, and
N
Resource Layer design decisions.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Create an access matrix to align User, Access, and Resource Layer design decisions.

Is an Access Design Equal to
Defining Users & Groups?
Users and Groups are not the only parameters to
N
determine a secure access strategy.
ot
=/
fo
rr
Users & Access
es
Groups design
al
e
or
di
s tri
but
io
n
Key Notes:
• Users and Groups are important when you define the access strategy and create the access design, however there are a
lot of other variables that can impact the final design.
• While it is easy to define a set of groups and allow them to connect internally and externally to some predefined
resources, but what happens when one of these users start using a new device type or needs access to a new type of
peripheral?

Defining an Access Design
A successful access design takes all the business requirements into account.
N
ot
Device Type Location
fo
=
rr
es
FlexCast Users Peripherals
al
Access Design
e
or
Security Criticality
di
s tri
Business
b
requirements
ut
io
n
Key Notes:
• Several additional factors should be considered when defining an access design.
• The business requirements listed on this slide are just examples, you may identify additional business requirements as
you start new projects. You may also complete projects where there are fewer business drivers to consider.

Access Matrix
Introduction
A matrix that maps all the Sample access assessment data to collect:
N
required access scenarios per • User / Groups
ot
user group to meet business • Location / Network
requirements. • FlexCast model
fo
• Peripheral mappings
rr
• Device type / Citrix Workspace app version
• Delivery groups / Application groups
es
• Authentication type
al
• SmartAccess / SmartControl
e
• StoreFront timeouts
• Printer mappings
or
• Hidden applications
di
• Workspace Control
s tri
b ut
io
n
Key Notes:
• This list identifies some of the data you can collect and assess prior to defining a new access matrix.
• The key purpose of an access matrix is to consolidate the long list of requirements shown into a clear and simple format
that can be referenced during the rest of the design and build.

Access Matrix Example
Delivery /
User Device FlexCast Hidden Authentication Timeouts Client Printer SmartControl SmartControl
Location Application
Group Type Model Resources type (minutes) Redirection Mapping Policies Action
Groups
Local Drives,
Printing,
Passthrough No Session
Corporate Hosted HR Apps Clipboard,
HR Internal None Username and 30 Idle Enabled None None
Laptop Apps Office Audio, COM
Password 30 Disconnect
Port, USB,
TWAIN, LPT
N
No Session
Corporate Hosted HR Apps Two Factor Domain- Joined
HR External HR App 30 Idle Disabled Disabled Deny logon
ot
Laptop Apps Office Authentication Antivirus
30 Disconnect
fo
Call Hosted CallCenter Username and
Internal ThinClient None 5 Windows Lock Disabled None None None
Center Desktop Desktop Password
rr
No Session TWAIN
Corporate Hosted Finance Apps
Finance Internal None SmartCard 30 Idle Clipboard Enabled None None
es
Desktop Apps Office
30 Disconnect USB
No Session
al
Hosted Finance Apps Two Factor
Finance External BYOD Payroll 30 Idle Disabled None Antivirus Deny Clipboard
Apps Office Authentication
30 Disconnect
e
Local Drives,
or
Printing,
No Session
Hosted SalesTools Clipboard,
Sales Internal Laptop None Passthrough 30 Idle Enabled None None
Apps Office Apps Audio, COM
30 Disconnect
di
Port, USB,
TWAIN, LPT
s
No Session
tri
Hosted SalesTools Username and
Sales External iPad All Office 30 Idle Disabled None Certificate Hide SalesTools
Apps Office Apps Password
30 Disconnect
but
io
n
Key Notes:
• This access matrix example can be used as a reference for creating your own access matrix. Each customer may have a
different set of business requirements and therefor each customer may also have varying data in their access matrix.
• Location: Can be Internal and External to define whether they connect through a gateway or not but can also include other
variables such as WAN links, Satellite offices and less secure networks. In some cases you may even want to label the
physical locations of users.
• Device Type: Can be corporate owned or BYOD, laptops, desktops, thin clients, tablets or phones.

• FlexCast model: Can be Hosted shared, Hosted VDI, Remote PC, Streamed VHD, Local VM and On-demand
Apps. Flexcast can also include details about persistency settings.
• Delivery Groups / Application Groups: Defines how users are mapped to resources and where the sessions
will be directed. The names defined here will vary by customer.
• Hidden resources: Defines whether a set of users will have access to all resources in the above Delivery /
Application Groups or if certain resources are hidden away from the resource set.
• Authentication types: Can be all the options available in StoreFront but can also use the authentication options
N
provided in Citrix Gateway for external users. Options include: Username / Password, Passthrough, SAML,
ot
SmartCard, Passthrough from Citrix ADC, RADIUS / Tokens solutions and Certificate based authentication.
fo
• Timeouts: Can include StoreFront and Citrix ADC disconnection settings but can also be used to define
session disconnect and logoff policy settings.
rr
• Client Redirection: Can contain a wide variety of the device mappings controlled by policies, such as client
es
drives, USB, clipboard etc.
al
• Printer Mapping: Can refer to client printer redirection and reference the policy settings related to client print.
Alternatively it can be used to reflect printer mapping lists in Citrix Policies.
e
• SmartControl policy and action: Can be used to scan endpoints connecting through a gateway and control the
or
session based on the outcome of the scan. For example; if antivirus is not present on the endpoint, we will
di
deny client drive mapping.
s tri
b ut
io
n

A company is designing the required access scenarios
for a new Citrix Virtual Apps and Desktops deployment.
They expect to have thousands of end users from
various locations around the world. Many departments
will need to access scanners, printers and webcams. The
CTO has expressed a big concern for ensuring their data
N
is kept secure.
ot
fo
Identify which business requirements could be a
determining factor in the access design.
rr
es
• Device type
al
• Location
e
• Peripherals
or
• Security
di
s
tri
utb
io
n

N
Access Layer Architecture
ot
Design Considerations
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Integrate high-level access architecture
N
considerations into a virtualization design.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Integrate high-level access architecture considerations into a virtualization design.

Citrix Gateway and
StoreFront 2598/443
HDX 80/443
HTTP(S)
80/443
XML/STA
Delivery 27000 VDAs

Controller Lic
80/443 389/636
HTTP(S) LDAP
StoreFront
N
Internal Users
Server OS Assigned Desktop OS
Component Review Domain
ot
80/443 Controller
HTTP(S)
1433/
fo
443
SQL
rr
Databases
Firewall Citrix Random Desktop OS Remote PC
es
External Users Gateway
License
al
389/636 Server
LDAP
e
or
Hardware Layer
di
stri
Network Storage Processor Memory Graphics Hypervisor
b ut
io
n
Key Notes:
• StoreFront is the interface that authenticates users, manages applications and desktops, and hosts the application store.
StoreFront communicates with the Delivery Controller using XML.
• Stores are the main configuration unit of StoreFront servers, and aggregate resources from multiple Farms / Sites, as
well as StoreFront mobile access management (MAM) deployments.
• Users can connect to access the published resources through Citrix Workspace app for Windows, iOS, Android, or
the StoreFront web site.

• StoreFront can host multiple Stores with different settings (this will be a focus of the next lesson).
• Citrix Gateway is a security hardened appliance (virtual or physical) which communicates with internal
resources on behalf of external users to perform authentication, allow secured external connections to
StoreFront (reverse web proxy), and allow secured access to internal hosted applications and desktops (HDX
proxy).
• A proxy server is typically hosted internally to allow users to browse externally-hosted websites without
actually having a TCP session to the web servers.
N
• Reverse web proxy uses the same idea; however, instead it allows external users to browse internal
ot
resources without enabling TCP access to the web servers themselves (many customers may be familiar
fo
with Microsoft ISA or TMG servers, which have similar functionalities).
• HDX proxy is similar to reverse web proxy; however, instead of protecting webservers, it protects the
rr
internal VDAs and converts port 1494/2598 data to encrypted SSL/TLS data in real time.
es
• The security appliance can be a Citrix Gateway or a Citrix ADC with the Gateway Feature, depending on
al
how it is licensed. If you License it to be a Citrix ADC and use the Gateway Feature it is a Citrix ADC
containing the Gateway feature. If you only License it to be a Citrix ADC Gateway, then it is just that.
e
• Customer-managed Citrix Gateway and StoreFront hosted in a public cloud like Azure or AWS falls in this
or
category.
di
s tri
but
io
n

Double-Hop Access Architecture
Introduction
DMZ 1 DMZ 2 Internal Network
Citrix Citrix
Gateway 1
N
Gateway 2
Delivery Controller VDA
ot
Endpoint Devices Firewall 1 Firewall 2 Firewall 3
fo
Internet
rr
RADIUS StoreFront Other Internal
Active Directory
Server Servers
es
al
e
or
Citrix Gateway 1: Citrix Gateway 2:
• Can authenticate user • Proxies STA communications from
di
• Communicates with StoreFront Gateway 1 to STA service
s
• Proxies HDX traffic between endpoint • Proxies traffic from Gateway 1 to
tri
device and Citrix Gateway 2 VDA in the secure zone
b ut
io
n
Key Notes:
• Some organizations implement a double-hop DMZ architecture using multiple Citrix ADCs, where three firewalls divide the
DMZ into two stages to provide an extra layer of security for the internal network.
• In this setup, the first Citrix Gateway encrypts user connections, determines how the users are authenticated, and controls
access to the servers in the internal network.
• The second Citrix Gateway enables the ICA traffic to traverse the second DMZ to complete user connections to the server
farm. Communications between Citrix Gateway in the first DMZ and the Secure Ticket Authority (STA) in the internal

network are also proxied through Citrix Gateway in the second DMZ.
• Leading practice is a single-hop architecture unless double-hop architecture is required by the security team.
Double-hop is more expensive, complicated, and time consuming to setup.
• Deploying in a Double-Hop DMZ: https://docs.citrix.com/en-us/netscaler-gateway/12/double-hop-dmz.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Double-Hop Access Architecture
Key design considerations
N
Required Components Required Ports Certificates Load Balancing
ot
• Minimum two Citrix • Firewall 1: Port 443 open • NSG1: SSL Cert for GW • Determine where Load
fo
Gateway appliances. to DMZ1 Balancer should be
• NSG2: SSL Cert for GW
rr
placed.
• StoreFront installed • Firewall 2: Port 443 and and StoreFront LB
es
second DMZ. 389/636 to DMZ2. • Consider deploying
• LAN: Additional SSL Certs
internal Load Balancer
al
• Remaining infrastructure • Firewall 3: Port 443, 1494, for XML, STA, LDAPS etc.
separately.
e
deployed on internal 2598 and 389/636 to LAN.
network.
or
di
stri
but
io
n
Key Notes:
• What components are needed before deployment?
• At minimum, two Citrix Gateway appliances must be available (one for each DMZ).
• StoreFront must be installed in the second DMZ and configured to operate with the Citrix Virtual Apps and Desktops
site in the internal network.
• The remaining Citrix Virtual Apps and Desktops Site infrastructure should be fully deployed in the internal network.
• What ports must be opened on the firewalls?

• Firewall 1 (between external network and DMZ 1):
• TCP port 443 for TLS
• Firewall 2 (between DMZ 1 and 2):
• TCP port 80 or 443 between NSG1 and the StoreFront server(s)
• TCP Port 443 between NSG1 and NSG2 (secure SOCKS connection)
• TCP Port 1812 (RADIUS) or 389/636 (for LDAP/LDAPS) if authentication is enabled on the Citrix
Gateway
N
• Firewall 3 (between DMZ 2 and 3)
ot
• TCP Port 80 or 443 between NSG2/StoreFront and the XML/STA services
fo
• TCP Port 1494 or 2598 between NSG2 and VDAs (depending on whether standard HDX or Session
Reliability is used)
rr
• TCP Port 1812 (RADIUS) or 389/636 (for LDAP/LDAPS) if authentication is enabled on the Citrix
es
Gateway and authentication servers reside in the same network as the Citrix Virtual Apps and
al
Desktops Site.
• How many SSL certificates are needed?
e
• One SSL server certificate must be installed on Citrix Gateway in the first DMZ. This certificate ensures
or
that the web browser and user connections to Citrix Gateway are encrypted.
di
• Additional certificates to encrypt connections that occur among the other components in a double-hop
DMZ deployment. There is no end-to-end SSL encryption of these connections. However, each
s tri
connection can be encrypted individually.
b
• Does load balancing need to be supported?
ut
• If either of the Citrix ADCs also provide server load balancing, ensure that the required ports are opened
io
between the Citrix ADC and the load balanced components (in addition to the ports specified above).
• Other considerations:
n
• If Citrix Gateway is deployed in a double-hop DMZ with StoreFront, email-based auto-discovery for
Receiver does not work because it would keep looping the Receiver / user back to the first hop.
• Citrix Secure Hub and the Citrix Gateway Plug-in are not supported in a double-hop DMZ deployment.
Only Citrix Receiver is used for user connections.
• Citrix Gateway supports IPv4 and IPv6 connections. Use the configuration utility to configure IPv6.

• System Hardening Guidance for XenApp and XenDesktop (pages :
https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/system-hardening-for-xenapp-
and-xendesktop.pdf
• Deploying in a Double-Hop DMZ: https://docs.citrix.com/en-us/netscaler-gateway/12/double-hop-dmz.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Workspace vs. Citrix StoreFront
Architecture
Feature Citrix Workspace Citrix StoreFront
Zero Effort  X
Automatic Updates  X
N
Citrix Managed  X
ot
UI Customization (Branding)  
fo
Citrix Workspace App Deployment X 
rr
Multiple Stores X 
es
Support for Two-factor Authentication  
Local Password Processing X 
al
e
Supports Session Reliability  
or
Anonymous Access X 
Federated Authentication  
di
Thin Client Support (PNAgent) X 
stri
Support for Single Sign On X 
but
io
n
Key Notes:
• When using a Citrix Cloud deployment, administrators have the option to deploy StoreFront on-premises or enable Citrix
Workspace in the Cloud to allow users can authenticate and access published resources. In each case, the flow of
communication and the key benefits are unique.
• Advantages of Citrix Workspace in Citrix Cloud:
• Zero Effort: Using Citrix Workspace eliminates the need to manage this component while retaining high availability.
• Automatic Updates: Citrix manages updates to Citrix Workspace for the customer.

• Citrix Managed: Citrix Workspace is always available over the internet through a unique URL for each
customer. (https://<customername>.cloud.com/Citrix/StoreWeb/)
• With the release of Citrix Workspace, it is now possible to customize the URL, but it will still be in the
format https://<custom>.cloud.com.
• Limitations of Citrix Workspace in Citrix Cloud:
• Citrix Workspace does not support several advanced features, including Citrix Workspace app
deployment to endpoints, multiple stores, and local password processing.
N
• If Citrix Gateway is not used, the launch.ica file will use an internal IP which cannot be resolved by
ot
remote clients. Citrix Workspace without Citrix ADC provides access to internal users only.
fo
• Citrix Workspace does not support direct authentication, where StoreFront communicates directly with
Active Directory, instead Citrix Workspace will authenticate via the Cloud Connectors hosted by the
rr
customer.
es
• On-premises StoreFront offers greater security configuration options and flexibility for deployment
al
architecture, including the ability to keep user credentials on-premises.
• For a Citrix Cloud deployment, deploying StoreFront on-premises does not support delegated
e
authentication, since StoreFront cannot communicate with the Delivery Controllers directly and the
or
Delivery Controllers are not members of the customers Active Directory.
di
• PNAgent site is not available when using Citrix Workspace.
s tri
b
• Virtual Apps and Desktops Service: https://docs.citrix.com/en-us/tech-zone/learn/downloads/diagrams-
ut
posters_virtual-apps-and-desktops-service_poster.png
io
n

Citrix Cloud Citrix Cloud
Considerations for
License Server Studio Director
Citrix ADC
Citrix Gateway Workspace Delivery Controller Databases
service
Architecture
N
• Option to use Citrix Cloud
ot
hosted Citrix Gateway as a User Layer Access Layer Control Layer Resource Layer
fo
Service.
rr
Cloud
• Option to deploy BYO Citrix StoreFront Connector Server OS Assigned Desktop OS
es
ADC or Gateway in resource
On-premises
location.
al
Users Firewall
e
or
Domain Random Desktop OS Remote PC
Firewall Citrix Gateway
Controller
di
Compute Layer
s tri
b ut
io
n
Key Notes:
• Several options are available for Citrix Cloud customers when creating an access design:
• One is to use to Citrix Gateway as a Service in Citrix Cloud, this is included with the Citrix Cloud Virtual Apps and
Desktops subscription.
• You can also Bring Your Own (BYO) Citrix ADC licenses and use these if you need more features than the Citrix
Gateway service provides.
• Features will vary based on which approach you take; see the Additional Resources for the latest features available

with the Citrix Gateway service.
• Citrix Gateway service: https://docs.citrix.com/en-us/citrix-gateway-service.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Cloud Access Layer Design Considerations
Design Options
1 2 3
No Citrix Gateway Gateway Service Citrix Gateway
N
on-premises
ot
fo
rr
es
al
Citrix Workspace Citrix StoreFront Citrix Workspace Citrix Workspace Citrix StoreFront
e
or
di
s
A B A A B
tri
b
ut
io
n
Key Notes:
• The options for Citrix ADC ICA Proxy are the same as those for the Citrix ADC.
• Design Options:
• 1A: No Citrix Gateway, Workspace in Citrix Cloud
• Pros: No management needed, automatic updates and upgrades.
• Cons: Lacks numerous customization and advanced configuration options; supports internal users only;
credentials parsed in cloud.

• 1B: No Citrix Gateway, StoreFront on-premises
• Pros: Able to use StoreFront customization and many advanced features. supports internal users
only.
• Cons: StoreFront must be managed by the organization.
• 2A: Citrix Gateway in Citrix Cloud, Workspace in Citrix Cloud.
• Pros: Able to support both internal and external users with lowest management overhead.
• Cons: Lacks support for customization, two-factor authentication, server load balancing, and other
N
features. Unable to use on-premises StoreFront. Credentials parsed in cloud, HDX traffic routed
ot
through Cloud Connectors.
fo
• 3A: Citrix ADC on-premises, Workspace in Citrix Cloud.
• Pros: Possible to use full Citrix ADC feature set. Able to communicate to StoreFront in Cloud or on-
rr
premises.
es
• Cons: Requires network experience and training to manage, more licensing and deployment costs to
al
achieve an HA configuration.
e
or
di
s tri
but
io
n

N
ot
fo
If you want to use Citrix Cloud, do you lose the
ability to manage environment access?
rr
es
No. Citrix Cloud supports on-premises Citrix ADC(s)
and StoreFront(s) so that credentials do not need to be
al
processed in the cloud.
e
or
di
s
tri
utb
io
n

N
ot
StoreFront Store Design
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the architectural needs of an
N
environment when designing StoreFront stores.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the architectural needs of an environment when designing StoreFront stores.

Use Cases for Multiple Stores
1
N
Authentication Resource Filtering Optimal Gateway Routing
ot
fo
• Different authentication methods • Differing enumeration and/or • Multiple Optimal Gateway
required. resource filtering configurations Routing addresses requires
rr
required. multiple Stores.
es
• Example: a separate Store for
contractors who require Multi- • Example: an HDX double-hop • Typically required for special
al
Factor Authentication. scenario where external clients use cases.
e
access desktops only; internal
• Anonymous Stores.
or
and mobile clients can access
apps and desktops.
di
s
tri
b ut
io
n
Key Notes:
• Authentication requirements are one of the primary reasons for multiple Stores.
• User groups that have different authentication requirements may necessitate a separate store.
• A separate unauthenticated Store may also be required for kiosk or shared device use cases.
• Consider whether the authentication requirements could be better served by adding a Citrix Gateway or Gateways to
handle special access use cases.
• HDX double-hop scenarios are one of the most common reasons for differing resource filtering requirements. (HDX

double-hop should not be confused with DMZ double-hop covered previously.)
• The same user may need to access a published desktop from their external endpoint, and then launch a
published application from Citrix Workspace app installed on the virtual desktop.
• In this case, multiple Stores may be desired in order to provide this user with the most seamless
experience.
• There are several challenges to configuring multiple Stores, including:
• More complex user experience due to having to choose between multiple Stores. To mitigate the multiple
N
Store issue, you can toggle the Advertise/Hide Store option in the Store settings so that users only
ot
access Stores intended for their use.
fo
• Multiple authentication prompts as users switch between Stores. This can be mitigated by using shared a
authentication service between Stores. However, these Stores must use the same authentication
rr
methods.
es
• More administrative overhead.
al
• Alternative methods are available for accomplishing goals that previously needed multiple Web Interface sites.
Multiple Receiver for Web sites can be configured for a single Store, so any setting that is specific to a
e
Receiver for Web does not require multiple Stores. Examples include:
or
• StoreFront Receiver for Web branding
di
• Timeout settings
• Citrix Workspace app deployment, including Citrix Workspace app for HTML5 usage
s tri
b
ut
• Configure and manage stores: https://docs.citrix.com/en-us/storefront/1912-ltsr/configure-manage-stores.html
io
n

Designing Store Access Types
Access Paths User Device StoreFront Server
• Determine which access

Web browser Receiver for Web site
type will be used by different
user groups.
N
Email based discovery
ot
• Based on the access types Provisioning file for Citrix Workspace app
in use, determine required
fo
Group Policy
Citrix Workspace app
access path per group:
rr
• URL-based Domain-joined managed device (e.g. thin client)
es
• Services URLs StoreFront
• Email based account Store
al
Citrix Virtual Apps Services URL
discovery
Legacy Citrix Receiver
e
• Provisioning file for Citrix or Desktop Lock
Workspace app
or
• Group Policy Non-domain-joined managed device (e.g. kiosk) Desktop Appliance Site
di
s tri
Citrix Workspace app
with Desktop Lock
b ut
io
n
Key Notes:
• Refer to the access matrix created earlier to confirm the access paths and authentication types required for each user
group. Also determine whether the group will primarily use native Citrix Workspace app or Receiver for Web, whether they
will connect directly to StoreFront or go through Citrix Gateway, and how native Citrix Workspace app will connect to the
designated Store(s).
• URL-based (CG, Receiver for Web): URLs and web browsers are familiar to most users and can be bookmarked for
easy future access. Additionally, if Citrix Workspace app for HTML5 is leveraged, users do not need to install

anything on the endpoint. However, users lose some of the desktop integration and single-sign on
features available with Citrix Workspace app.
• Services URLs: Domain joined desktop appliances (i.e. thin clients or repurposed PCs running Citrix
Workspace app with Desktop Lock) can use the Services URL for a Store, which is enabled by default.
Non-domain joined desktop appliances can use a Desktop Appliance site.
• Email-based account discovery: When native Citrix Workspace app is used, this method makes it easy
for end users to configure access to their assigned Store(s) because they can use a readily-available
N
piece of information to identify themselves. However, this method does require a DNS SRV record, and
ot
the email namespace must be the same as the DNS namespace.
fo
• Provisioning file for Citrix Workspace app and Group Policy: These are two additional ways to allows
users to connect native Citrix Workspace app to the Store with little to no effort. Group Policy takes the
rr
least end-user effort, but is only available for internal endpoints, while provisioning files can be used for
es
all endpoints, and can include Citrix Gateway and beacon information.
al
e
• Gateway Integration with StoreFront Lessons Learned: https://www.citrix.com/blogs/2014/10/15/gateway-
or
integration-with-storefront-lessons-learned/
di
• Connecting to StoreFront by Using Email-Based Discovery: https://docs.citrix.com/en-us/netscaler-
gateway/12/storefront-integration/ng-clg-session-policies-overview-con/ng-clg-storefront-policies-con/ng-clg-
s tri
storefront-email-discovery-tsk.html
b
• User Access Options: https://docs.citrix.com/en-us/storefront/1912-ltsr/plan/user-access-options.html
ut
• Citrix Workspace app Desktop Lock: https://docs.citrix.com/en-us/storefront/1912-ltsr/configure-manage-
io
stores.html

Designing Store Access Paths
Determine number of URLs required
Different URLs for Multiple URLs for

Single-URL for
Internal and External Internal Access
Internal/External
N
Access
Access internal.workspacelab.net/
ot
Citrix/StoreWeb
Access Layer Access Layer
fo
User Layer User Layer User Layer Access Layer
rr
es
StoreFront StoreFront StoreFront
Internal Users Internal Users Internal Employees
al
internal.workspac
e
access.workspacelab.com internal.workspacelab.net elab.net
/Citrix/Store2Web
or
Firewall Firewall Firewall
Internal Contractors
di
Firewall Firewall Citrix Gateway Firewall Citrix Gateway
Citrix Gateway
s
External Users External Users
External Users
tri
access.workspacelab.com
b
access.workspacelab.com
ut
io
n
Key Notes:
• With StoreFront:
• It is possible to define multiple Citrix Gateways per Store (IIS site). Gateways are defined and listed independently of
the Store configuration. StoreFront identifies the source Gateway for requests via HTTP headers.
• Multiple Gateways per Store can be used for defining a particular gateway for authentication and others for HDX
routing.
• By default, StoreFront requires that authentication occur at the Gateway for ICA traffic to be proxied by the Gateway.

When you define a Citrix Gateway in the StoreFront console, “Passthrough from Citrix Gateway”
authentication is automatically enabled.
N
ot
fo
rr
es
al
e
or
di
stri
b ut
io
n

Designing Store Access Paths
Determine configurations and prerequisites required for access paths
Citrix ADC / StoreFront / Citrix

Public URLs and Certificates
Workspace App Settings
N
ot
fo
rr
es
al
e
Network Settings (Ports, Topology) DNS Settings
or
di
DNS
s
tri
b ut
io
n
Key Notes:
• Once the access methods and paths have been determined, identify the configurations and prerequisites that would be
needed to implement them.
• There are multiple ways to configure single URL access for internal and external endpoints. The most common way is to
use StoreFront beacons, but it can also be accomplished via SAN certificates and DNS CNAME records.
• The major areas for consideration as the Citrix ADC / Storefront / Citrix Workspace app settings, Network settings, Public
URLs and Certificates and the DNS settings.

• Citrix ADC / StoreFront / Citrix Workspace App Settings:
• Determine how many Stores are needed and identify if each Store should have a unique access point
and name. If not a Citrix ADC content switch or Citrix Gateway can be used to access different Stores
using a single URL.
• Knowing the number of stores and the way they are setup helps in designing the StoreFront servers
allowing to decide on whether there is a need to do the resource aggregation or implement subscription
replication etc.
N
• Network Settings:
ot
• Identify the networks, firewalls, DMZs and VLANs that be used in the design. Make a detailed plan for
fo
which ports must be opened between the different networks.
• The Network settings are very crucial as network issues or other problems can occur between a
rr
StoreFront store and the servers that it contacts, causing delays or failures for users.
es
• Public URLs and Certificates:
al
• Determine all the URL/FQDNs that will be used in the design and ensure that you have matching SSL
certificates needed.
e
• Being aware of all the URLs allow securing the communication between StoreFront and users’ devices.
or
There are multiple ways and Citrix leading practices are to use Citrix Gateway and HTTPS.
di
• DNS Settings:
• Ensure your DNS structure is compatible with the access and Store design, if your design is to have the
s tri
same FQDN both internally and externally, you might need a split-brain DNS configuration.
b ut
io
• A Different Approach to a Single FQDN for StoreFront and NetScaler Gateway:
https://www.citrix.com/blogs/2015/06/02/a-different-approach-to-a-single-fqdn-for-storefront-and-netscaler-
n
gateway/
• Securing Storefront: https://docs.citrix.com/en-us/storefront/1912-ltsr/secure.html

You are designing a new Citrix Virtual Apps and

Desktops access infrastructure for an
organization. Some users will use Citrix
N
Workspace app for HTML5 via Receiver for Web,
ot
while other users should be prohibited from using
fo
Citrix Workspace app for HTML5. How many
Stores would be needed to accomplish this?
rr
es
This can be accomplished with one Store. Since Citrix
Workspace app for HTML5 usage is a Receiver for
al
Web setting, two RfW sites would be created and
e
attached to the same Store.
or
di
s
tri
utb
io
n

N
ot
Scalability and Redundancy
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine Access Layer scalability and high
N
availability options for Citrix Gateway, Citrix ADC
ot
and StoreFront.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Examine Access Layer scalability and high availability options for Citrix Gateway, Citrix ADC and StoreFront.

Citrix ADC
Scalability Citrix ADC VPX
• SSL throughput is the most
N
significant factor in
ot
identifying the appropriate
Citrix Gateway.
fo
• Each Citrix ADC platform Citrix ADC MPX
rr
has multiple models with
es
increasing throughput
al
capabilities.
e
or
di
Citrix ADC SDX
s tri
b ut
io
n
Key Notes:
• In order to identify an appropriate Citrix ADC platform to meet project requirements, the key resource constraints must be
identified. Since all remote access traffic will be secured using the secure sockets layer (SSL), transported by Hypertext
Transfer Protocol (HTTP) in the form of HTTPs, there are two resource metrics that should be targeted:
• SSL throughput – The SSL throughput is the gigabits of SSL traffic that may be processed per second (Gbps).
• SSL transactions per second (TPS) – The TPS metric identifies how many times per second an Application Delivery
Controller (ADC) may execute an SSL transaction. The capacity varies primarily by the key length required. While

TPS is an important metric to monitor, field experience has shown that SSL throughput is the most
significant factor in identifying the appropriate Citrix Gateway.
• To determine the SSL throughput required by a Citrix ADC platform, multiply the maximum concurrent
bandwidth for a datacenter by 1.02:
• SSL Throughput = Maximum Concurrent Bandwidth * 1.02
• We are adding 2% to the max concurrent bandwidth to as a rule of thumb to account for SSL bandwidth
overhead. This is often considered negligible relative to the volume of HDX traffic and is not typically
N
accounted for as part of required SSL throughput. However, making provisions for SSL bandwidth will
ot
help ensure the total throughput estimated is sufficient.
fo
• Ideally, the overhead should be measured during a proof of concept or pilot.
rr
es
• Citrix ADC MPX/SDX data sheet: https://www.citrix.com/products/netscaler-adc/netscaler-data-sheet.html
al
• Citrix ADC VPX data sheet: https://www.citrix.com/products/citrix-adc/resources/citrix-adc-vpx.html
e
or
di
s tri
but
io
n

Citrix ADC
High Availability Options
HA Pair/AWS (Active/Passive) Cluster (Active/Active) Azure (Active/Active)
N
ot
Users Users Users
fo
rr
Azure Load Balancing
es
al
Citrix ADC Citrix ADC Citrix ADC Citrix ADC Citrix ADC VPX Citrix ADC VPX
e
or
di
s tri
Server Server Server Server Server Server
b ut
io
n
Key Notes:
• Customers historically always deployed HA Pairs when integrating with Citrix Virtual Apps and Desktops products.
• In current releases, we support most of the important features in Cluster mode and thus we see more and more
customers deploying Clusters.
• When deploying any type of High Availability, scale the individual Citrix ADCs to handle the user load even in the event
that one Citrix ADC is down.
• A Citrix ADC HA pair is active/passive, so while paying for two Citrix ADCs, you are only getting 1x on performance and

throughput.
• You can configure two Citrix ADC VPX instances on AWS as a high availability (HA) active-passive pair. When
you configure one instance as the primary node and the other as the secondary node, the primary node
accepts connections and manages servers. The secondary node monitors the primary. If for any reason, the
primary node is unable to accept connections, the secondary node takes over.
• A Citrix ADC cluster is a group of nCore appliances working together as a single system image. Each
appliance of the cluster is called a node. The cluster can have one appliance or as many as 32 Citrix ADC
N
nCore hardware or virtual appliances as nodes.
ot
• In a Microsoft Azure deployment, a high availability configuration of two Citrix ADC virtual machines is
fo
achieved by using the Azure Load Balancer, which distributes the client traffic across the virtual servers
configured on both the Citrix ADC instances.
rr
• The Basic edition of the Azure Load Balancer uses a hash-based distribution algorithm. By default, it
es
uses a 5-tuple hash composed of source IP, source port, destination IP, destination port, and protocol
al
type to map traffic to available servers.
• It provides stickiness only within a transport session. Packets in the same TCP or UDP session will be
e
directed to the same instance behind the load-balanced endpoint. When the client closes and reopens
or
the connection or starts a new session from the same source IP, the source port changes. This may
di
cause the traffic to go to a different endpoint in a different datacenter.
s tri
b
• High Availability: https://docs.citrix.com/en-us/citrix-adc/current-release/system/high-availability-
ut
introduction.html
io
• Clustering: https://docs.citrix.com/en-us/citrix-adc/current-release/clustering.html
n
• How high availability on AWS works: https://docs.citrix.com/en-us/citrix-adc/current-release/deploying-
vpx/deploy-aws/how-aws-ha-works.html
• Azure Load Balancer overview: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

Citrix ADC
High availability considerations
N
HA Pair/AWS (Active/Passive) Clustering (Active/Active) Azure
ot
• Both nodes of the HA pair • Clustering may limit certain • High Availability in public clouds
fo
should be the same model, features. is handled by the cloud platform
rr
version, and release. rather than Citrix ADC.
• Check the feature list and
es
• In AWS, the following release version during a design. • A number of low-level
al
deployment types are supported networking features are not
• All cluster nodes should be the
e
for VPX instances: available in Azure.
same model, platform, type,
or
• High availability within same
zone version, and release. • High Availability in Azure can be
di
• High availability across different Active/Active or Active/Passive.
s
zones
tri
but
io
n
Key Notes:
• HA Pair using Active/Passive are historically the most common deployment model. Both nodes of the HA pair should be
the same model, version and release.
• Clustering using Active/Active may limit certain features. Check the feature list and release version for verification during
the design phase. All cluster nodes should be the same model, platform, type, version and release.
• With Azure, high availability can be configured for Active/Active or Active/Passive. High availability in public clouds is
handled by the cloud platform rather than Citrix ADX; however, a number of low-level networking features are not available

in Azure.
• The following features are not available in Azure: Clustering, IPv6, Gratuitous ARP (GARP), L2 Mode, Tagged
VLAN, Dynamic Routing, Virtual MAC (VMAC), USIP, Jumbo Frames.
• Points to Consider for a High Availability Setup: https://docs.citrix.com/en-us/citrix-adc/current-
release/system/high-availability-introduction/points-to-consider-high-availability-setup.html
N
• Supportability matrix for Citrix ADC Cluster: https://docs.citrix.com/en-us/citrix-adc/current-
ot
release/clustering/cluster-features-supported.html
fo
• Prerequisites for Cluster Nodes: https://docs.citrix.com/en-us/citrix-adc/current-release/clustering/cluster-
prerequisites.html
rr
• Deploying Citrix NetScaler VPX on Microsoft Azure – Limitations: https://docs.citrix.com/en-us/citrix-
es
adc/current-release/deploying-vpx/deploy-vpx-on-azure.html#limitations
al
e
or
di
s tri
b ut
io
n

StoreFront Server
Scalability Native Citrix Workspace app
Host 2 CPU / 4 GB RAM 4 CPU / 4 GB RAM 8 CPU / 4 GB RAM

Single Server
User connections per
30,000 55,000 80,000
hour
N
ot
Receiver for Web
fo
Host 2 CPU 4 CPU 8 CPU
rr
User connections per
25, 500 46,750 68,000
es
hour
RAM usage MB (100
al
4096 + 1702 4096 + 3120 4096 + 4539
resources)
e
or
• RAM usage for Receiver for Web: 4GB + (700 byes * Resources * Users)
di
• Receiver for Web has a 15% CPU overhead compared to native Citrix
s
Workspace app
tri
b
• Workspace Control can reduce scalability by 50%
ut
io
n
Key Notes:
• The number of Citrix Workspace app users supported by a StoreFront server group depends on the hardware you use
and on the level of user activity. Based on simulated activity where users log on, enumerate 100 published applications,
and start one resource, expect a single StoreFront server with the minimum recommended specification of two virtual
CPUs running on an underlying dual Intel Xeon L5520 2.27Ghz processor server.
• The minimum recommended memory allocation for each server is 4GB. When using Receiver for Web, assign an
additional 700 bytes per resource, per user in addition to the base memory allocation.

• As with using Receiver for Web, when using Citrix Workspace app, design environments to allow an extra 700
bytes per resource, per user on top of the base 4 GB memory requirements for this version of StoreFront.
• Plan your StoreFront deployment: https://docs.citrix.com/en-us/storefront/1912-ltsr/plan.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

StoreFront Server
Scalability
Server Group
• Minimum 2 StoreFront servers for redundancy.
N
• Scale up not out.
ot
• Scale up: Increase specifications per StoreFront server.
• Scale out: Add more StoreFront servers to the server group.
fo
• There are diminishing scalability increases above 4-5 StoreFront servers in a
rr
Server Group. At that point, scale up the existing servers.
es
• Keep server group on same LAN.
al
• Latency + large server groups = replication issues.
e
or
di
s tri
b ut
io
n
Key Notes:
• To scale StoreFront servers, Citrix leading practices to implement a minimum of two servers to account for HA, each with
4 CPU & 8 GB RAM. Sizing does not work like controllers, where there is an estimate # of users per controller.
• Measurement is in the login rate (how many logins simultaneously) i.e. how many simultaneous requests can be handled.
In most environments, two servers would suffice.
• If there is a need to be able to handle 100% of the production load if one server fails, then add a 3rd server.
• CCS recommends 4 vCPU x 8 GB RAM VMs for deployments with many logins per hour.

StoreFront Component High Availability
Load Balancing StoreFront
Hardware Load Balancing DNS Round Robin Microsoft Software Load Balancer
N
ot
Users Users Users
fo
rr
es
DNS Server Cluster
Citrix ADC
al
e
Cluster Virtual IP
or
di
s
StoreFront 1 StoreFront 2 StoreFront 1 StoreFront 2 StoreFront 1 StoreFront 2
tri
b ut
io
n
Key Notes:
• If the server hosting StoreFront is unavailable, users will not be able to launch new virtual desktops, published applications
or manage their subscriptions. Therefore at least two StoreFront servers should be deployed to prevent this component
from becoming a single point of failure. By implementing a load balancing solution, users will not experience an
interruption in their service.
• A hardware load balancer is an intelligent appliance that can verify the availability of the StoreFront service and actively
load balance user requests appropriately. Citrix ADC is a great example of a hardware load balancer.

• Citrix ADC is an ideal load balancer, coming pre-configured with StoreFront health checks.
• DNS round robin provides rudimentary load balancing across multiple servers without performing any checks
on availability. If a StoreFront server becomes unavailable, DNS round robin would still route users to the
failed server.
• Because of this, DNS round robin is not recommended by Citrix.
• A Microsoft software load balancer (SLB) is a Windows service capable of performing rudimentary checks to
verify the server is available but cannot determine the status of individual services. This can cause users to be
N
forwarded to StoreFront servers which are not able to process new requests. The user would then not be able
ot
to access applications or desktops.
fo
• Overall, a majority of medium to large, production Citrix Virtual Apps and Desktops environments use a Citrix
ADC or other hardware load balancer to achieve high availability for the StoreFront component. In situations
rr
where the environment is small, funding is limited, or multiple non-production environments will be used, one
es
of the other methods can be considered.
al
• Even in smaller environments, virtual appliances such as the Citrix ADC VPX can still be used to provide
intelligent load balancing without requiring the purchase of a dedicated piece of hardware.
e
• If using Citrix Workspace hosted in Citrix Cloud:
or
• Citrix monitors, maintains and scales Citrix Workspace as necessary.
di
• The Citrix goal is that in any 30 calendar day period 99.5% of the time users can access their app or
desktop session through the Service.
s tri
• Performance against this goal can be monitored on an ongoing basis at https://status.cloud.com.
b ut
io
• Service Level Agreement: https://docs.citrix.com/en-us/citrix-cloud/overview/service-level-agreement.html

You are designing an environment for a large

consumer goods company. The company requires
a highly available StoreFront design for 30,000
users, each user logs on once per hour and the
average user has 50 resources available. The
N
customer only has one datacenter.
ot
fo
1. Which additional question(s) should you ask
rr
before sizing the servers?
es
2. How many StoreFront servers would you
al
recommend and how would you size them?
e
or
di
s
tri
b
ut
io
n

Questions to ask:
• Will the users be accessing the environment through
native Citrix Workspace app or Receiver for Web?
• Will Workspace Control be used?
N
ot
Answer:
fo
• If all connections are through native Citrix Workspace
app, each of two StoreFront servers with 2 vCPU and 4
rr
GB RAM can handle the load.
es
• If all connections are through Receiver for Web, each
of two StoreFront servers with 4 vCPU and 6 GB RAM
al
can handle the load.
e
• If Workspace Control is used, an additional StoreFront
or
server would be added to the above configurations to
account for the reduction in scalability while
di
maintaining N+1 redundancy.
s
tri
utb
io
n

Exercise 3-1: Create an
Access Matrix
An Access Matrix was created for the user groups
N
taking part in the Proof of Concept. During the design
ot
phase, this matrix must be extended to include all
groups identified during the user segmentation
fo
process.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 3-1: Create an
Access Matrix [15 minutes]
Task:
N
• Use the Design Requirements document to
ot
complete the Access Matrix document. All green
cells must be completed.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Access Matrix – Answer Key
SmartAccess
Delivery / SmartAccess/
User Device FlexCast Hidden Authentication Timeouts Client Printer /Smart
Location Application Smart Control
Group Type Model Resources Type (minutes) Redirection Mapping Control
Groups Action
Policies
20 StoreFront Local drives
[Access-1] Printing
No session Clipboard All fixed drives
[Access-2] Audio [Access-17]
Corporate Passthrough
HR Internal TBD TBD None 20 idle COM port None None
laptop [Access-10]
[Access-3] USB All client printers
180 TWAIN [Access-18]
N
disconnect LPT
[Access-6] [Access-17]
ot
10 StoreFront
[Access-7]
Domain-joined
No session
fo
[Access-12]
Username & [Access-2]
Corporate HR Data Disabled Disabled Deny logon
HR External TBD TBD password 10 idle
rr
laptop [Access-14] [Access-9] [Access-19] Up-to-date [Access-12]
antivirus
180
[Access-12]
es
disconnect
[Access-6]
Local drives
al
20 StoreFront
Printing
[Access-1]
Clipboard All fixed drives
e
No session
Audio [Access-17]
Thin client Passthrough [Access-2]
Engineering Internal TBD TBD None COM port None None
or
(WEM) [Access-10] 20 idle
USB All client printers
[Access-3]
TWAIN [Access-18]
No disconnect
LPT
di
[Access-6]
[Access-17]
10 StoreFront
s
All published
[Access-7 User is member Hide all published
tri
resources
No session of Engineering resources except
except for Username & Printing All local (non-
Personal [Access-2] group on an for Microsoft
b
Engineering External TBD TBD Microsoft password Clipboard network) printers
device 10 idle external Office hosted
Office hosted [Access-11] [Access-16] [Access-20]
ut
[Access-4] connection apps
apps
© 2021 Citrix Authorized Content No disconnect [Access-15] [Access-15]
[Access-15]
io
[Access-6]

Access Matrix – Answer Key
Delivery / SmartAccess/S SmartAccess/
Device FlexCast Hidden Authentication Timeouts Client Printer
User Group Location Application mart Control Smart Control
Type Model Resources Type (minutes) Redirection Mapping
Groups Policies Action
20 StoreFront Local drives
[Access-1] Printing
No session Clipboard All fixed drives
[Access-2] Audio [Access-17]
Corporate Passthrough
Sales Internal TBD TBD None 20 idle COM port None None
N
laptop [Access-10]
[Access-3] USB All client printers
ot
180 TWAIN [Access-18]
disconnect LPT
fo
10 StoreFront
rr
Sales Data Access-7
Domain-joined
hosted app No session
Access-13
es
only visible Username & Access-2 Hide Sales Data
Corporate Disabled Disabled
Sales External TBD TBD from password 10 idle published app
laptop Access-9 Access-19 Up-to-date
corporate Access-11 Access-4 Access-13
al
antivirus
laptop 180
Access-13
e
Access-13 disconnect
Access-6
or
5 StoreFront
Access-8
No session
di
Username & Access-2 All local (non-
Partner Printing
s
Partners External TBD TBD None password 5 idle network) printers None None
owned Access-19
tri
Access-11 Access-5 Access-20
180
b
disconnect
ut
Access-6
io
n

Exercise 3-2: Access Layer Design
and Verification
Your team completed the Access Layer design based
N
on design requirements provided by the business.
ot
However, design verification testing shows several
requirements not achieved.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 3-2A:
Update Design Requirements
Document [15 minutes]
Task:
N
• Review Design Requirement and Access Matrix
ot
documents.
fo
rr
es
met:
• Internal/ External users/Partners
al
• StoreFront and Citrix ADC
e
or
di
s
tri
b
ut
io
n

Exercise 3-2A
Use Design Verification lab to check design

meets requirements.
N
• StoreFront timeouts implemented based on
ot
access matrix.
• Favorite resources should be retained whether
fo
accessed from endpoint device or published
rr
desktop.
• Unable to start published desktop from another
es
published desktop.
al
• Published resources started on endpoint device
e
are not disconnected and reconnected within
published desktop.
or
di
s
tri
b
ut
io
n

Design Document [15 minutes]
Task:
N
• Copy and update Detailed Design document so
ot
all requirements met.
• Add new stores if necessary.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Verification Lab [45 minutes]
Task:
N
• Update Design Verification lab to match design
ot
• Internal/ External users/Partners
• StoreFront and Citrix ADC
fo
rr
es
al
e
or
di
s
tri
utb
io
n

General
Requirement Met in Design Requirement Met in Lab

Yes/No Yes/No
Access-50 High Standardize on Microsoft Windows Server 2016. Yes Yes
N
ot
Access-51 Medium StoreFront 1912 or newer. Yes Yes
fo
rr
Access-52 Medium Citrix ADC 13.0 or newer. Yes Yes
es
Access-53 High No single points of failure. Yes Yes
al
e
Access-54 Medium Stores customized with corporate branding. Yes Yes
or
Access-55 Medium Comply with Workspacelab naming standard. Yes Yes
di
All connections to StoreFront and Citrix Gateway
s
Access-56 High encrypted. Unsecure connections automatically Yes Not yet configured
tri
redirected to encrypted connection.
but
io
n

General (Continued)

Yes/No Yes/No
No
N
StoreFront timeouts implemented based on access
Access-57 High No Internal users should be logged
matrix.
ot
off StoreFront after 20 minutes
and not 10 minutes.
fo
No
Favorite resources retained whether accessed from
rr
Access-58 Medium endpoint device, published desktop, internally or No Favorite resources not retained
es
externally. Partners excluded. between internal and external
Stores.
al
e
or
di
s tri
b
ut
io
n

Internal
Yes/No Yes/No
No
Unable to start published desktop from another HR1 able to start published
Access-59 High No
published desktop. desktops from a published
N
desktop.
ot
Internal users authenticated to domain-joined
Access-60 High corporate desktop can start published resources Yes Yes
fo
without re-authenticating.
rr
No
Published desktop users can start published Hr1 user cannot start published
es
Access-61 High Yes
applications without re-authenticating. application without re
authenticating
al
No
e
Hr1 user cannot authenticate
Internal employees authenticate without entering a
Access-62 Low Yes without entering
or
domain -WORKSPACELAB.COM used by default.
WORKSPACELAB.COM
domain.
di
No
s
Published resources started on endpoint device not Published resources started on
tri
Access-63 Medium disconnected and reconnected within published No NYC-WRK-001 by HR1
b
desktop. disconnected and reconnected
ut
within published desktop.
io
n

External & Partners

Yes/No Yes/No
All external employee and partner traffic secured using

Access-64 High Yes Not yet configured
Citrix Gateway.
N
ot
External employees and partners use
WORKSPACELAB.COM domain credentials to
fo
authenticate. No requirement for two-factor
authentication.
rr
External employees and partners must specify
es
Access-66 Low No Not yet configured
WORKSPACELAB.COM domain when authenticating.
al
External users and employees prompted with
corporate access policy before log on – “This computer
e
system is for authorized users only. Users have no
or
explicit or implicit expectation of privacy.”
di
s tri
b
ut
io
n

Detailed Design – Answer Key
Citrix Gateway
2
Number of Citrix • No single points of failure.
NYC-ADC-001
Gateway Appliances • Design Requirement Access-53: No single points of failure in Access Layer.
NYC-ADC-002
N
• Workspace Lab standard.
ot
Citrix Gateway Version 13.0
• Design Requirement Access-52: Citrix ADC 13.0 or newer.
fo
• Citrix Gateway appliances configured as Active/Passive.
rr
NYC-NSG-CNG (tcp:443) • Design Risk: “Stay Primary” is currently configured on NYC-VNS-001. Although this
Gateway High
NYC-ADC-001 (active) can be used during testing, the configuration must be removed prior to putting the
Availability
es
NYC-ADC-002 (Passive) environment into production to enable failover to occur when necessary.
• Design Requirement Access-53: No single points of failure in Access Layer .
al
Gateway FQDN storefront.workspacelab.com • FQDN agreed with business.
e
Encrypted using TLS with public certificate. Non- • Design Requirement Access-56: All connections to StoreFront and Access Gateway
or
encrypted connections redirected to encrypted encrypted. Unsecure connections automatically redirected to encrypted connection.
Gateway Encryption
site. • Design Verification: Private certificate used for storefront.workspacelab.com. Public
di
certificate used for production.
s
https://NYC-VDC-
• Enable round robin load balancing from StoreFront. No single points of failure.
tri
001.workspacelab.com/Scripts/CtxSta.dll (active)
Secure Ticket Authority • Design Requirement Access-53: No single points of failure in Access Layer.
https://NYC-VDC-
b
• Hardware load balancer not recommended.
002.workspacelab.com/Scripts/CtxSta.dll (active)
ut
io
n

StoreFront
2
Number of StoreFront • No single points of failure.
NYC-STF-001
Servers • Design Requirement Access-53: No single points of failure in Access Layer.
NYC-STF-002
N
StoreFront Server • Workspace Lab standard.
ot
Microsoft Windows Server 2016
Operating System • Design Requirement Access-50: Standardize on Microsoft Windows Server 2016.
fo
rr
Citrix StoreFront • Workspace Lab standard.
1912
Version • Design Requirement Access-51: StoreFront 1912 or newer.
es
al
Base URL • storefront.workspacelab.com • FQDN agreed with business.
e
or
sf_vsrv (tcp:443)
Base URL High • Base URL load balanced using Citrix ADC.
• https://NYC-STF-001 (active)
Availability • Design Requirement Access-53: No single points of failure in Access Layer.
di
• https://NYC-STF-002 (active)
s
Encrypted using TLS with private certificate. Non-
tri
• Design Requirement Access-56: All connections to StoreFront and Citrix Gateway
Base URL Encryption encrypted connections redirected to encrypted
encrypted. Unsecure connections automatically redirected to encrypted connection.
b
site.
ut
io
n

StoreFront (Continued)
2
• InternalStore used by internal employees, including published desktop users.
4
• PartnerStore used by external employees and partners.
• InternalStore
Number of Stores • DesktopStore used by published desktop users. Desktops filtered out.
N
• PartnerStore
• ExternalStore used by external employees.
• DesktopStore
ot
• InternalStore, PartnerStore and ExternalStore have different timeouts.
• ExternalStore
fo
• Design Requirement Access-60: Internal users authenticated to domain-joined
Username and password corporate desktop can start published resources without re-authenticating.
rr
Authentication
Domain Pass-through • Design Requirement Access-61: Published desktop users can start published
applications without re-authenticating.
es
al
• Design Requirement Access-62: Internal employees authenticate without entering a
Trusted Domains Default domain: workspacelab.com
domain -WORKSPACELAB.COM used by default.
e
or
• Used by internal employees, including published desktop users.
• Microsoft GPO (Citrix Worker Desktops) used to configure Citrix Receiver on
di
Store 1 Name InternalStore
published desktops to use InternalStore.
s
• Configured as default site.
tri
b ut
io
n

https://storefront.workspacelab/
Store 1 URL • URL agreed with business.
Citrix/InternalStore
• Two Controllers for redundancy.
N
• Design Requirement Access-53: No single points of failure.
NYC-NLB-XML (tcp:443)
ot
• Allow StoreFront to enumerate resources from site.
• https://NYC-VDC-001.workspacelab.com
Store 1 Delivery • Design Risk: Certain supporting infrastructure services such as LDAP and DNS are
(active)
fo
Controller(s) NOT load balanced or highly available in the current configuration. Although these
• https://NYC-VDC- 002.workspacelab.com
configurations are not explicitly mentioned in the Design, Workspace Lab should
rr
(active)
implement load balancing vServers for these services to eliminate single points of
failure.
es
Store 1 Citrix Gateway
None • Not Required.
al
Integration
e
• Internal users authenticate using pass-through authentication or manually by entering
Store 1 RfW Username and password username/password combination.
or
Authentication Domain Pass-through • Design Requirement Access-60: Internal users authenticated to domain-joined
corporate desktop can start published resources without re-authenticating.
di
s
• Requirement from Access Matrix.
Store 1 Session 10 minutes
tri
• Design Requirement Access-57: StoreFront timeouts implemented based on access
Timeout 20 minutes
matrix.
b ut
io
n

Customize colors and logos based on corporate branding.

• Logon Branding: \\NYC-FSR-001\Resources\StoreFront
Design\LogonBranding.png
N
• Header Branding: \\NYC-FSR-001\Resources\StoreFront • Design Requirement Access-54: Stores customized with corporate
Store 1 Customizations
Design\HeaderBranding.png branding.
ot
• Background Color: R:0, G:174, B:239
• Text and Icon Color: R:255, G:255, B:255
fo
• Link Color: R:28, G:117, B:188
rr
Store 2 Name PartnerStore • PartnerStore used by external employees and partners.
es
Store 2 URL https://storefront.workspacelab/ Citrix/PartnerStore • URL agreed with business.
al
NYC-NLB-XML (tcp:443) • Two Controllers for redundancy.
Store 2 Delivery
• https://NYC-XDC-001.workspacelab.com (active) • Design Requirement Access-53: No single points of failure.
e
Controller(s)
• https://NYC-XDC-002.workspacelab.com (active) • Allow StoreFront to enumerate resources from site.
or
Store 2 Citrix Gateway • Design Requirement Access-64: All external and partner traffic
Remote access enabled with Citrix Gateway integration.
di
Integration secured using Citrix Gateway.
s
tri
• Design Requirement Access-65: External employees and partners
Store 2 RfW
b
Username and password use WORKSPACELAB.COM domain credentials to authenticate.
Authentication
ut
No requirement for two-factor authentication.
io
n


Store 2 Session
5 minutes • Design Requirement Access-57: StoreFront timeouts implemented
N
Timeout
based on access matrix.
ot
fo
rr
• Header Branding: \\NYC-FSR-001\Resources\StoreFront • Design Requirements Access-54: Stores customized with
es
Design\HeaderBranding.png corporate branding.
• Background Color: R:0, G:174, B:239 • Design Requirement Access-67: External users and partners
• Text and Icon Color: R:255, G:255, B:255 prompted with corporate access policy before log on – “This
al
• Link Color: R:28, G:117, B:188 computer system is for authorized users only. Users have no
e
Users prompted with access policy before log on – “This computer
or
system is for authorized use only. Users have no explicit or implicit
expectation of privacy.”
di
s tri
b ut
io
n

• DesktopStore used by published desktop users. Desktops filtered

out.
N
• Microsoft GPO (Citrix Worker Desktops) used to configure Citrix
ot
Receiver on published desktops to use DesktopStore.
• Workspace Control only works with resources accessed by the
Store 3 Name DesktopStore same Store. Creating a separate store for resources accessed
fo
from published desktop will prevent resources started on endpoint
rr
device from being disconnected and reconnected within published
desktop.
es
• Design Requirement Access-59: Unable to start published desktop
from another published desktop.
al
e
Store 3 URL https://storefront.workspacelab/Citrix/DesktopStore • URL agreed with business.
or
Store 3 Delivery
di
Controller(s)
s
tri
Store 3 Citrix Gateway
None • Not required.
b
Integration
ut
io
n

• Internal users authenticate using pass-through authentication or

Store 3 RfW Username and password manually by entering username/password combination.
N
Authentication Domain Pass-through • Design Requirement Access-61: Published desktop users can
ot
start published applications without re-authenticating.
fo
Store 3 Session
20 minutes • Design Requirement Access-57: StoreFront timeouts implemented
Timeout
based on access matrix.
rr
es
al
• Header Branding: \\NYC-FSR-001\Resources\StoreFront • Design Requirement Access-54: Stores customized with corporate
e
Design\HeaderBranding.png branding.
• Background Color: R:0, G:174, B:239 • Configuring DesktopStore to use the InternalStore subscription
or
• Text and Icon Color: R:255, G:255, B:255 database ensures users see the same favorites from their
• Link Color: R:28, G:117, B:188 published desktop.
di
• Design Requirement Access-58: Favorite resources retained
Use Filter resources by type setting within store settings to filter out whether accessed from endpoint device, published desktop,
s
desktops. Only applications and documents will be shown. internally or externally. Partners excluded.
tri
b
DesktopStore subscription database redirected to InternalStore
ut
subscription database.
io
n

Store 4 Name ExternalStore • ExternalStore used by external employees.
N
ot
Store 4 URL https://adc.workspacelab.com/Citrix/ExternalStore • URL agreed with business.
fo
rr
Store 4 Delivery
es
Controller(s)
al
e
Store 4 Citrix Gateway • Design Requirement Access-64: All external employee and partner
Remote access enabled with Citrix Gateway integration.
Integration traffic secured using Citrix Gateway.
or
di
s
tri
b ut
io
n

• No requirement for two-factor authentication.

Store 4 RfW • Design Requirement Access-65: External employees and
Username and password
N
Authentication partners use WorkspaceLab.com domain credentials to
authenticate. No requirement for two-factor authentication.
ot
Store 4 Session Timeout 10 minutes • Design Requirement Access-57: StoreFront timeouts
fo
implemented based on access matrix.
rr
• Logon Branding: \\NYC-FSR-001\Resources\StoreFront Design\LogonBranding.png
es
• Header Branding: \\NYC-FSR-001\Resources\StoreFront • Configuring ExternalStore to use the InternalStore subscription
Design\HeaderBranding.png database ensures users see the same favorites when connecting
al
• Background Color: R:0, G:174, B:239 externally.
e
• Text and Icon Color: R:255, G:255, B:255 • Design Requirements Access-54: Stores customized with
Store 4 Customizations • Link Color: R:28, G:117, B:188 corporate branding.
or
• Design Requirement Access-67: External users and partners
Users prompted with access policy before log on – “This computer system is for prompted with corporate access policy before log on – “This
di
authorized use only. Users have no explicit or implicit expectation of privacy.” computer system is for authorized users only. Users have no
s
Configuring ExternalStore to use the InternalStore subscription database ensures
tri
users see the same favorites from their published desktop.
b ut
io
n

Exercise 3-3: Implement Single
URL Access for Internal and
External Users
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 3-3: Implement Single
URL Access for Internal and
External Users [15 minutes]
Following a demonstration to the key project

stakeholders you are asked to redesign the solution
N
so employees only need to remember a single
ot
FQDN regardless of whether they are internal or
fo
external.
rr
es
al
Task:
e
• Update Design Verification lab to use single
or
URL for internal and external employee
di
access to Receiver for Web.
s
tri
• Follow instructions in 3-3 Exercise Workbook.
b
ut
io
n

Exercise 3-4: Configure Traffic to
Route via Citrix Gateway
Your team completed the Access Layer design based
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 3-4A:
Task:
N
ot
fo
rr
met:
es
• Endpoints: NYC-WRK-003
• Accounts: hr1/Password1, partner1/Password1,
al
e
or
di
s
tri
utb
io
n

Exercise 3-4A

meets requirements.
N
• Performance monitoring for all internal and
ot
external Citrix HDX connections, including HDX
double-hop. Principle of least security privilege
fo
followed.
rr
• Employees connecting from an internal or external
unmanaged endpoint authenticate using two-factor
es
authentication.
al
• Partners authenticate using two-factor
e
authentication
or
di
s
tri
utb
io
n

Task:
N
• Copy and update Detailed Design document so all
ot
requirements met.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Task:
N
• Update Design Verification lab to match design:
ot
• Endpoints: NYC-WRK-001
• Accounts: hr1/Password1, partner1/Password1,
fo
rr
es
al
e
or
di
s
tri
utb
io
n

General

Yes/No Yes/No
Access-1 Medium Citrix ADC version 13.0 or newer. Yes Yes
N
ot
Access-2 High No single points of failure. Yes Yes
fo
rr
No
Performance monitoring for all internal and external
es
Access-3 Medium Not yet configured
Citrix HDX connections, including HDX double-hop. Internal HDX traffic not routed
through Citrix Gateway.
al
e
Same URL (storefront.workspacelab.com) can be used
by internal users, external users and partners to
or
access the Citrix Virtual Apps and Desktops
environment.
di
s tri
but
io
n

Security

Yes/No Yes/No
Access-5 High Partner responsible for maintaining user accounts Yes Yes
N
Access-6 High All certificates SHA 256. Yes Yes
ot
Access-7 High RC4 ciphers disabled. Yes Yes
fo
rr
Access-8 High SSL v2.0 and SSL v3.0 disabled. Yes Yes
es
Management access restricted to management
Access-9 High Yes Yes
network.
al
Citrix ADC configured as relying party for the partner No
e
Access-10 High domains, no Windows domain trust required between Relying party trust has not Not yet configured
or
WorkspacaceLab and partner domains. been designed.
di
Access-11 High Partner traffic to WorkspaceLab restricted to HDX only. Yes Yes
s
NYC-RAD-001 RADIUS server used for two-factor
tri
authentication.
b
ut
io
n

Employees

Yes/No Yes/No
2048-bit machine certificate (PKCS12) used to
determine if employees connecting from managed
N
endpoint.
ot
Employees connecting from an internal or external
No
fo
managed endpoint authenticate using LDAP.
Access-14 High LDAP + RADIUS designed for Not yet configured
rr
authentication.
es
Employees connecting from an internal or external
No
unmanaged endpoint authenticate using two-factor
al
Access-15 High LDAP designed for Not yet configured
authentication.
authentication.
e
HDX Double-hop connections authenticate using pass-
or
through authentication.
Access-16 Medium Yes Yes
di
s tri
b
ut
io
n

Partners

Yes/No Yes/No
N
Access-17 High Partners authenticate using two-factor authentication. Yes Not yet configured
ot
fo
Access-18 High Partners do not authenticate using workspacelab.com. Yes Yes
rr
es
Partner responsible for maintaining user accounts
al
Access-19 High authorized to access WorkspaceLab partner Yes Yes
resources.
e
or
No
Partners limited to accessing FireFox published
Access-20 High Yes Partners have access to more
di
application only.
resources.
s tri
b
ut
io
n

General
• ACL configured to restrict the access to NSIP using port 22 and

ACL configured
Restrict the 443
1. Permit the users from subnet 192.168.10.0/24 to NSIP.
management Access Design Requirement Access-9: Management access restricted to
2. Deny traffic from any other subnet to NSIP.
N
management network.
• The version SSLv2, SSLv3 are considered insecure due multiple
ot
• All the Virtual Servers on the Citrix ADC have SSLv2, SSLv3
vulnerabilities.
Disabled.
SSL Settings and • Default configuration of the Citrix ADC includes several non-
• All the Virtual Servers on the Citrix ADC have been configured with
fo
secure cipher suites secure ciphers and protocols.
custom cipher group to preference Elliptic Curve Diffie–Hellman
Design Requirement Access-7: RC4 ciphers disabled.
rr
Exchange (ECDHE).
• Design Requirement Access-8: SSL v2.0 and SSL v3.0 disabled.
storefront.workspacelab.com
es
• All HDX traffic routed through the active Citrix Gateway.
NYC-NSG-STF (TCP:443) • Encrypted using TLS with public certificate. Non-encrypted
al
• NYC-STF-001 (active) connections redirected to encrypted site.
e
• NYC-STF-002 (passive) • Design Requirement Access-2: No single points of failure.
• Design Requirement Access-3: Performance monitoring for all
or
Internal HDX Routing
Internal DNS host record for storefront.workspacelab.com changed internal and external Citrix HDX connections, including HDX
from NYC-NSG-STF VIP to NYC-NSG-CNG VIP. double-hop.
di
• Design Requirement Access-4: Same URL
NYC-NSG-CNG (TCP:443) (storefront.workspacelab.com) can be used by internal users,
s
• NYC-ADC-001 (active) external users and partners.
tri
• NYC-ADC-002 (passive)
b ut
io
n

General (Continued)
• FQDN agreed with business.

• Encrypted using TLS with public certificate. Non-encrypted
connections redirected to encrypted site.
storefront.workspacelab.com
N
ot
• Design Requirement Access-3: Performance monitoring for all
External HDX Routing NYC-NSG-CNG (TCP:443)
internal and external Citrix HDX connections, including HDX
• NYC-ADC-001 (active)
double-hop.
fo
• NYC-ADC-002 (passive)
• Design Requirement Access-4: Same URL
rr
(storefront.workspacelab.com) can be used by internal users,
external users and partners.
es
• All managed endpoints have 2048-bit PKCS12 machine
• Design Requirement Access-13: 2048-bit machine certificate
al
Managed Endpoint certificates.
(PKCS12) used to determine if employees connecting from
Identification • nFactor authentication used to determine if users connecting from
e
managed endpoint.
managed or unmanaged endpoint.
or
Session policies bound to the Citrix Gateway configured in ICA Proxy Design Requirement Access-11: Partner traffic to workspacelab
Session Policies
mode. restricted to HDX only.
di
s tri
b ut
io
n

Authentication
• Internal and external managed endpoints are differentiated based

• LDAP
Managed Endpoint - on client IP.
• Upon successful authentication, Citrix Gateway will direct internal
Internal • Design Requirement Access-14: Employees connecting from an
employees with managed endpoint to InternalStore.
N
internal or external managed endpoint authenticate using LDAP.
ot
• Internal and external managed endpoints are differentiated based
• LDAP
Managed Endpoint - on client IP.
fo
• Upon successful authentication, Citrix Gateway will direct external
External • Design Requirement Access-14: Employees connecting from an
employees with managed endpoint to ExternalStore.
internal or external managed endpoint authenticate using LDAP.
rr
• Drop down menu prompting user to select workspacelab or vendor
es
domain. • Design Requirement Access-15: Employees connecting from an
Unmanaged Endpoint –
• LDAP + RADIUS internal or external unmanaged endpoint authenticate using two-
al
Internal
• Upon successful authentication, Citrix Gateway will direct internal factor authentication.
e
employees with managed domain to InternalStore.
or
• Drop down menu prompting user to select workspacelab or vendor • Partners will not be able to logon to workspacelab domain as they
domain. do not have credentials.
di
• LDAP + RADIUS • Design Requirement Access-15: Employees connecting from an
Unmanaged Endpoint -
• Upon successful authentication: internal or external unmanaged endpoint authenticate using two-
s
External
• Citrix Gateway will direct external employees with unmanaged factor authentication.
tri
endpoints to ExternalStore. • Design Requirement Access-17: Partners authenticate using two-
b
• Citrix Gateway will direct partners to PartnerStore. factor authentication.
ut
io
n

Authentication (Continued)
• Citrix Workspace app installed on published desktop allowing

• Pass-through authentication.
employees to start published applications from published desktop.
HDX Double-hop • Double-hop Receiver configured with URL of DesktopStore –
• Design Requirement Access-16: HDX Double-hope connections
https://storefront.workspacelab.com/Citrix/Store/DesktopStore
N
authenticate using pass-through authentication.
ot
• Use existing RADIUS server for two-factor authentication.
NYC-NSG-RDS (UDP:1812)
fo
• Design Requirement Access-12: NYC-RAD-001 RADIUS server
RADIUS Server • NYC-RAD-001 (active)
used for two-factor authentication.
rr
• NYC-RAD-002 (passive)
• Design Verification: Only one RADIUS server deployed for Design
Verification – NYC-RAD-001.
es
• Shadow accounts created within Workspacelab.com\Citrix\New
• Design Requirement Access-10: No trust created between
al
Shadow Accounts York\Partner for each partner user authorized to access
Workspacacelab and partner domains.
workspacelab resources.
e
or
• Partners restricted to FireFox application.
• Partner shadow accounts added to Partners user group.
Partner Access • Design Requirement Access-20: Partners limited to accessing
di
• FireFox application published to Partners user group.
FireFox published application only.
s tri
b
ut
io
n

• NYC-FAS-001
N
• NYC-FAS-002
• FAS Settings GPO – enable FAS and
ot
specify FAS server
• StoreFront reads the FAS GPO to get a list of all the FAS servers available to it. For a
• Design Requirement Access-10: No trust
given user UPN, FAS applies a hashing algorithm to decide the primary, secondary,
created between Workspacacelab and
fo
FAS Server tertiary (and so on) FAS server for the user. The primary FAS server is the preferred
partner domains
server for a user, followed by the secondary if the primary is not available, and so on.
rr
• Design Verification: FAS server installed on
Because a hashing algorithm is used, the FAS server for different users will be evenly
file server – NYC-FSR-001. No high
distributed amongst all the available FAS servers, but for a particular user the selected
es
availability.
FAS server will be consistent (unless failover is required). This maximizes the chance that
a user will be directed to a FAS server, which already has a certificate for the user.
al
e
or
• StoreFront selects the primary FAS server for the user and attempts to contact that
server. If the server cannot be contacted, or if the server reports it is in "maintenance
di
mode", StoreFront will select the secondary server and so on. • Design Requirement Access-2: No single
FAS Server HA
StoreFront does not maintain a "blacklist" of recently failed FAS servers. When probing to points of failure.
s
determine if a FAS server is available, StoreFront applies a hard-coded timeout of 5
tri
seconds.
b ut
io
n


FAS Settings GPO applied to: Workspacacelab and partner domains.
• Design Verification: FAS server installed on file server – NYC-
N
FAS Policy • Workspacelab\Citrix\New York\Servers\FAS FSR-001. FAS Settings GPO applied to Workspacelab\Citrix\New
ot
• Workspacelab\Citrix\New York\Servers\STF York\Servers\FSR rather than Workspacelab\Citrix\New
• Workspacelab\Citrix\New York\VDA York\Servers\FAS.
fo
rr
Authentication Policy and Profile Binding
es
1. LDAP authentication for the users from Workspacelab Domain
from the managed endpoint. • Authentication policies required to support different authentication
al
Authentication Policy
2. LDAP + Radius authentication for the users from Workspacelab scenarios.
e
Domain from the unmanaged endpoint.
3. ADFS for the users from Partnerlab Domain from the unmanaged
or
endpoint.
di
s tri
b ut
io
n

Authentication policies bound to policy labels.
1. Policy Label: OnlyLDAP
N
Policy: LDAP
Login Schema: OnlyPassword
ot
• Policy Label created to invoke the appropriate set of policies and
Policy Label 2. Policy Label: RADIUS corresponding login schema depending on the type of the user
fo
Policy: Radius access to achieve the nfactor requirement.
LoginSchema: noschema
rr
3. Policy Label: LDAP_RADIUS
es
Policy: LDAP Authentication Policy
LoginSchema: LDAP+Radius
al
e
or
• Not required.
None.
• No trust between workspacelab.com and abcventures.com.
Relying Party Trust
di
Citrix ADC configured to trust abcventures.com domain.
Workspacelab and partner domains.
s
tri
b
ut
io
n

Key Takeaways
• Use an access matrix to align User, Access, and
N
Resource layer requirements.
ot
• Begin an Access Layer design by determining which
Access Layer components will be used – Citrix
fo
Gateway/Citrix ADC or Citrix Gateway Service,
rr
StoreFront or Workspace.
es
• Key StoreFront design considerations include the
al
number of Stores, the access paths required for the
e
environment, and how subscriptions will be handled
or
in a multi-store environment.
di
s tri
but
io
n
Key Notes:
• Use an access matrix to align User, Access, and Resource layer requirements.
• Begin an Access Layer design by determining which Access Layer components will be used – Citrix Gateway/Citrix ADC
or Citrix Gateway Service, StoreFront or Workspace.
• Key StoreFront design considerations include the number of Stores, the access paths required for the environment, and
how subscriptions will be handled in a multi-store environment.

Key Takeaways
• Citrix ADCs can be configured as HA pairs or
N
clusters on-premises.
ot
• Use Citrix ADC to strengthen security for external
users using RADIUS, certificate-based
fo
authentication, or SmartAccess.
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Citrix ADCs can be configured as HA pairs or clusters on-premises.
• Use Citrix ADC to strengthen security for external users using RADIUS, certificate-based authentication, or SmartAccess.

Citrix Virtual Apps and Desktops 7
Assessment, Design and
N
ot
Resource Layer - Images
fo
rr
es
al
e
Module 4
or
di
s tri
but
io
n
Key Notes:
• Welcome to the Resource Layer - Images module. This is the fourth module in the Citrix Virtual Apps and Desktops 7
• Throughout this module, we will look at how the FlexCast models can be strategically assigned to user groups to meet
user requirements while maximizing scalability. Next, we will review some of the factors that can impact the scalability and
sizing of the images and review a few key areas that should be addressed to secure Virtual Delivery Agent machines. And
finally, we will review the key considerations when selecting an appropriate image provisioning method in a Citrix Virtual
Apps and Desktops environment.
Learning Objectives
• Apply the pyramid approach to assign FlexCast
N
models to user groups.
ot
• Design and validate Virtual Delivery Agent machine
sizing and scalability.
fo
rr
• Integrate security considerations into an image
design.
es
• Design an appropriate image provisioning and
al
management strategy.
e
or
di
s tri
b ut
io
n
Key Notes:
• Apply the pyramid approach to assign FlexCast models to user groups.
• Design and validate Virtual Delivery Agent machine sizing and scalability.
• Integrate security considerations into an image design.
• Design an appropriate image provisioning and management strategy.

N
ot
FlexCast Model Assignment
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Apply the pyramid approach to assign FlexCast
N
models to user groups based upon business
ot
requirements.
fo
rr
es
al
e
or
di
stri
but
io
n
Key Notes:
• Apply the pyramid approach to assign FlexCast models to user groups based upon business requirements.

FlexCast Models Review
Image Delivery User installed Virtual/

Resource Types OS Type
N
Technology apps? Physical
ot
On-Demand Applications Multi-Session OS Any No Virtual
fo
rr
Hosted Shared Desktops Multi-Session OS Any No Virtual
es
Hosted VDI
Single-Session OS Citrix Provisioning/MCS No Virtual
al
(Random/Non-persistent)
e
Hosted VDI
Single-Session OS MCS Yes Virtual
(Static/Persistent)
or
VM Hosted Applications Single-Session OS MCS No Virtual
di
s tri
Remote PC Single-Session OS Manual Yes Physical
b ut
io
n
Key Notes:
• FlexCast Management Architecture, or FMA, is the platform Citrix Virtual Apps and Desktops uses to provide the ability to
deliver published applications or desktops to users.
• FMA is made up of workloads, or FlexCast models, which are classified into two categories – Multi-Session OS workloads
and Single-Session OS workloads.
• These workloads can be further broken down into resource types. Although the table is not a comprehensive list, the
resource types displayed in the table are the most common.

• For example, it is technically possible to deliver static, non-persistent Hosted VDI. However, this option is
not commonly used, since it lacks the flexibility of random, non-persistent Hosted VDI, and lacks the
usability benefits of static, persistent Hosted VDI.
• Server VDI is also a lesser-known option. In this case, a Multi-Session OS VDA machine delivers a virtual
desktop to a single user. This is typically utilized by service providers who cannot provide Hosted VDI
desktops due to Microsoft licensing limitations.
• Desktop Player is a Type II hypervisor that supports Windows or Mac. It can be used to take a provisioned
N
Windows virtual desktop offline allowing users to access apps and desktops without network connectivity.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

FlexCast Model
4
Assignment
Strategy Executives
3
• Use a pyramid approach to
N
assign models to user Developers, Engineers
ot
groups.
2
• Tier 1: On-Demand Apps
fo
rr
• Tier 2: Hosted VDI
(random, non-persistent)
es
• Tier 3 & 4: Hosted VDI Contractors, Task Workers
al
(static, persistent)
e
1
or
di
s
General Apps (All Employees)
tri
b ut
io
n
Key Notes:
• The pyramid model ensures that user groups can receive a FlexCast model that meets their requirements while also
increasing scalability and minimizing cost where feasible. Overall, highly scalable models (On-Demand Apps, Random
Hosted VDI) should form the lower levels of the pyramid, while less scalable models (Static Hosted VDI, Remote Desktop,
VM Hosted Applications) should form the upper levels.
• Beyond user requirements, also consider the endpoints that will be used when assigning FlexCast models, since certain
endpoint devices are more appropriate when used in combination with certain FlexCast models. For example, mobile

devices would typically be assigned published apps instead of a full desktop.
• Although numbered “tiers” are used in the example shown, alternative designations could be used instead; for
example, “Gold-Silver-Bronze” classifications could be used if three categories are desired.
• You could also consider further dividing layers based on other factors, such as whether certain VDA machines
will make use of graphics cards.
• This structure should fit most organizations; however, there will be exceptions. For example, a satellite
imaging company many need a majority of its employees to use one of the Hosted VDI models due to the
N
resource requirements of the imaging applications.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

1
You are designing an environment for a large consumer goods company. The company has identified the following
N
user groups and requirements. Which FlexCast model(s) would you assign to each group? What (if any) follow up
ot
questions would you ask?
fo
rr
Product Managers
• Typically work in company network but can work from home.
es
• Need to use a variety of standard productivity and web-based SaaS apps.
al
Field Sales Managers
e
• Frequently work with mobile devices; tend to access the environment externally.
or
• Need access to sales tools and customer database frontend.
di
Graphic Designers
• Internal and remote workers using specialized hardware with graphics card to handle resource-intensive apps.
s
tri
• Management interested in centralizing resources in the datacenter to lower hardware replacement costs.
but
io
n

1
Based on the initial use cases identified here, the expected responses are to:
N
• Place the Product Managers in Tier 1 (Hosted Shared Desktops).
ot
• Place the Sales Managers in Tier 2 (On-Demand Apps).
fo
• Place the Graphic Designers in Tier 3 (Static Hosted VDI) with a vGPU enhancement.
rr
es
However, based on additional details that are constructed via the discussion,
al
those responses could potentially change.
e
or
di
s
tri
but
io
n

N
Virtual Delivery Agent
ot
Machine Scalability
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine how to appropriately scale the
N
infrastructure for Virtual Delivery Agent Machines.
ot
• Validate and adjust Virtual Delivery Agent machine
sizing and scalability during the design or initial
fo
build phase.
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Determine how to appropriately scale the infrastructure for Virtual Delivery Agent Machines.
• Validate and adjust Virtual Delivery Agent machine sizing and scalability during the design or initial build phase.

Virtual Delivery Agent Machine Scalability
Overview
Rule of 5
• The scalability and sizing of Virtual Delivery Agent 32 5 160
N
Machines will depend on multiple factors.
ot
2x16 Physical Single- 160 Single-Session
• Beyond hardware and other environmental factors,
Cores Session OS OS VMs
the FlexCast model being deployed will greatly
fo
affect users per host.
rr
• Scalability “rules of thumb” can be used as a quick
es
initial estimate before testing and monitoring can be
Rule of 10
al
performed.
e
• For example, the “Rule of 5 and 10” is a simple way 32 10 320
or
to estimate the single server scalability of a physical
di
server. 2x16 Physical Multi- 320 Multi-Session
Cores Session OS OS Sessions
s tri
b ut
io
n
Key Notes:
• Factors such as user workload, hardware, activity ratio, CPU over-subscription ratio, microprocessors, graphics codec,
operating system, and optimizations can all influence the actual number in a specific environment. That is why fine-tuning
the scalability numbers for a specific environment is also important.
• In a vast majority of deployments, CPU has been the scalability bottleneck for VDA machines. That is why most of the
recommended baselines typically only mention sizing based on CPUs available.
• With the Rule of 5 and 10, use 5 if you’re looking for the number of Citrix Virtual Desktops VMs you can host on a box and

use 10 if you’re looking for the number of Citrix Virtual Apps user sessions you can host on a box. However,
this is only intended to be used for a basic initial estimate.
• A few examples of the Rule of 5 and 10 in practice:
• Rule of 5 (Single-session OS VDAs)
• 2x16 physical cores: 32 x 5 = 160 sessions (example from slide)
• 2x14 physical cores: 28 x 5 = 140 sessions
N
• Rule of 10 (Multi-session OS Sessions)
ot
• 2x16 physical cores: 32 x 10 = 320 sessions (example from slide)
fo
rr
es
al
• Citrix Scalability — The Rule of 5 and 10: https://www.citrix.com/blogs/2017/03/20/citrix-scalability-the-rule-of-
5-and-10/
e
or
di
s tri
b ut
io
n

Single-Server Sizing Recommendation (assuming 2x oversubscription ratio):
Scalability Eight 6-vCPU VMs, Sixteen 3-vCPU VMs, or Twenty-four 2-vCPU VMs
Socket 0 Socket 1
Local NUMA Node 0 NUMA Node 2 Local

Memory Memory
Ring-Based Architecture node 0 node 2
1 2 1 2
N
(NUMA)
ot
3 4 3 4
fo
5 6 5 6
rr
es
Local Local
Local memory
NUMA Node 1 NUMA Node 3 Local
memory
Memory Memory
al
access access
node 1 node 3
1 2 1 2
e
or
3 4 3 4
di
5 6 5 6
s
tri
Intersocket Connections
b ut
io
n
Key Notes:
• The underlying chip and memory architecture can also play an important role in SSS. And Intel has recently made
significant improvements in the underlying microprocessor architecture design which means it’s important to understand
the specific chip that is being used in the hardware you purchase and how the underlying microprocessor architecture is
designed and constructed. The resources allocated should be based on the workload characteristic of each user group,
identified during the assess phase.
• Ring-Based Architecture

• Ring-based Architecture, referred to as Non-Uniform Memory Access (NUMA), was used on older chips,
such as Broadwell and Haswell, Intel connected processors.
• This invisible split was something that needed to be factored into CVAD SSS to provide optimal results.
• At the time, the leading guidance was to ensure that you are sizing CVA VMs as large as possible but not
crossing NUMA nodes, sub-NUMA clusters or rings at the same time.
• If you sized your CVA VMs too large and they effectively spanned NUMA nodes or rings, it can lead to
NUMA “thrashing” by accessing non-local resources and this would yield reduced SSS.
N
ot
fo
• Citrix Virtual Apps and Desktops Single-Server Scalability: https://docs.citrix.com/en-us/tech-
zone/design/design-decisions/single-server-scalability.html
rr
es
al
e
or
di
s tri
but
io
n

Single-Server 2x UPI x 20 @ 1x16x2x8/4x4
1x16x2x8/4x4
PCIe @ 8GT/s 1x UPI x 20 @ 1x16x2x8/4x4
10.4GT/s PCIe @ 8GT/s X4 DMI 10.4GT/s PCIe @ 8GT/s
Scalability
2x UPI x20 PCIe x16 PCIe x16 On Pkg 1x UPI x20 PCIe x16
DMI x4 PCIe x16
CBDMA
Mesh-Based Architecture CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC
N
SKX Core SKX Core SKX Core SKX Core SKX Core SKX Core
ot
3x DDR4 2666
3x DDR4 2666
DDR 4 MC MC DDR 4
CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC
DDR 4 DDR 4
fo
SKX Core SKX Core SKX Core SKX Core
DDR 4 DDR 4
rr
CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC CHA/SF/LLC
es
al
e
or
di
s
CHA-Caching and Home Agent; SF – Snoop Filter; LLC – Last Level Cache;
tri
SKX Core – Skylake Server Core; UPI – Intel UltraPath Interconnect
b
Intel Xeon processor Scalable family mesh architecture.
ut
io
n
Key Notes:
• As the number of cores on the CPU increased with each generation, the access latency increased and available
bandwidth per core diminished. Intel mitigated this trend by dividing the chip into two halves and introducing a second ring
to reduce distances and to add additional bandwidth which is known as mesh-based architecture.
• Mesh-Based Architecture
• This new mesh architecture introduced in Skylake does not have the same limitations as before where we have to
split chips, divide cores or add rings which changes the way we size Citrix Virtual Apps servers in particular.

• Mesh-based architecture encompasses an array of vertical and horizontal communication paths allowing
traversal from one core to another through a shortest path which helps reduce latencies and bandwidth
constraints associated with ring-based architecture.
• Mesh architecture has also improved the latency for IO initiated access by allowing a core or IO to
access the data in LLC, memory, or IO through the shortest path over the mesh.
N
• Intel Xeon Processor Scalable Family Technical Overview:
ot
https://software.intel.com/content/www/us/en/develop/articles/intel-xeon-processor-scalable-family-technical-
fo
overview.html
rr
es
al
e
or
di
s tri
but
io
n

Virtual Delivery Agent Machine Sizing
Multi-Session OS VDA Machines
CPU Memory Disk
N
ot
fo
Ring-Based Architecture Light Workload • Each VM requires enough
• Assign vCPUs that equal to • WS 2012 R2: 256 MB per user storage for the entire OS and
rr
NUMA node size or ½ of NUMA • WS 2016: 320 MB per user locally installed applications.
es
node size.
Medium Workload • If using MCS or Citrix
al
Mesh-Based Architecture • WS 2012 R2: 512 MB per user
• Start with 1.5 to 2.0 CPU • WS 2016: 640 MB per user
Provisioning, the differencing
e
oversubscription based on disk/write cache disk sizing
or
hardware model. Heavy Workload depends on OS and workload.
• WS 2012 R2: 1024 MB per user
di
• WS 2016: 1280 MB per user
s tri
but
io
n
Key Notes:
• For ring-based architecture, It is often ideal to allocate the number of cores within a NUMA node to a virtual machine or
allocate ½ of the cores to a virtual machine, while doubling the number of virtual machines.
• Each socket is divided into one or more NUMA nodes. Multi-Session OS workloads will often utilize 4 or more
processors. Allocating more vCPU than the NUMA node contains results in a performance hit. Allocating a portion of
a NUMA node to a virtual machine results in a performance hit if the portion allocated is not easily divisible by the
size of the NUMA node.

• For Multi-Session OS VMs, it is OK to create larger VMs, or VMs with an odd number of vCPUs, as long
as they fit into the NUMA nodes of the underlying hardware. For on-premises deployments, creating
larger VDA machines often achieves linear scalability and reduces the amount of VMs that must be
managed. On the other hand, also consider the failure domain the organization is comfortable with and
create N+1 VDA machines for each Delivery or Application Group for redundancy purposes.
• For mesh-based architecture, an oversubscription ratio between 1.5 and 2 is appropriate for multi-session OS
workloads. The optimal ratio will depending on the capabilities of the underlying hardware.
N
• The amount of memory allocated to each resource is a function of the user’s expected workload and
ot
application footprint. Assigning insufficient memory to the virtual machines will cause excessive paging to
fo
disk, resulting in a poor user experience; allocating too much RAM increases the overall cost of the
solution.
rr
• Note that the baseline RAM allocations do not include any RAM cache that would be required if Citrix
es
Provisioning or MCS is used.
al
• Deploying machines through Machine Creation Services or Citrix Provisioning can substantially reduce the
storage requirements for each virtual machine. Recommended differencing/write cache disk sizes can range
e
from 10-60 GB per VM depending on the OS and workload. In general, newer operating systems will have
or
greater resource requirements.
di
s tri
but
io
n

Single-Session OS VDA Machines
CPU Memory Disk
N
ot
fo
• 2 to 4 vCPUs per VM based on Light Workload: • Each VM requires enough
workload • 2-3 GBs per VM storage for the entire OS and
rr
Medium Workload: locally installed applications.
• CPU oversubscription ratios
es
can typically be higher for • 3-4 GBs per VM • If using MCS or Citrix
al
single-session OS VDA Heavy Workload: Provisioning, the differencing
e
machines; 6:1 is a starting • 6-8 GBs per VM disk/write cache disk sizing
or
point. depends on workload.
di
s tri
but
io
n
Key Notes:
• For hosted VDI models (hosted random desktops and hosted static desktops), the general recommendation is two or
more vCPUs per virtual machine so multiple threads can be executed simultaneously. Although a single vCPU could be
assigned for extremely light workloads, users are more likely to experience session hangs.
• Oversubscription can be higher for single-session OS VDA machines due to the lower user density.
• Note that the baseline RAM allocations do not include any RAM cache that would be required if Citrix Provisioning or MCS
is used.

• For single-session OS VDA machines, consider that static, persistent desktops are likely to require more
resources than random, non-persistent desktops due to the additional applications installed by the users.
When performing scalability testing, add some typical “user-installed” apps to the image to account for this.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Example Scenarios
Processor
Workload Type Physical Servers VM Specifications Results
Architecture
N
• HP Blades
• 6 vCPU 10 x 24 = 240 users per
Multi-Session OS VDAs Ring-Based • 24 cores (2x12)
ot
• 24 GB RAM host
• 256 GB RAM
fo
• Dell Blades
• 16 vCPU 10 x 32 = 320 users per
rr
Multi-Session OS VDAs Mesh-Based • 32 cores (2x16)
• 48 GB RAM host
• 256 GB RAM
es
• Cisco Blades
• 2 vCPU
al
Single-Session OS VDAs N/A • 36 cores (2x18) 5 x 36 = 180 VMs per host
• 4 GB RAM
• 768 GB RAM
e
or
di
s tri
utb
io
n
Key Notes:
• As mentioned previously, we realize there are many more variables or parameters that influence scalability versus just the
number of physical cores in a server. And there may be certain situations where the CVAD workload is not CPU-bound so
extra care is required when sizing. In addition, other factors we haven’t discussed such as CPU clock speed and logon
storms also matter and further complicate sizing exercises. But we have found through years of field experience and
hundreds of deployments that nothing matters as much as the number of physical cores.
• First, let’s look at an example on sizing Multi-Session OS VDAs using ring-based architecture:

• Let’s assume you’re running an application such as SAP on Windows Server 2012 R2 via CVA. You’re
repurposing some older HP blades with 24 physical cores (2x12) and 256 GB of RAM. You’ve
researched on Intel’s website that the underlying chip employs a ring buffer architecture, and each socket
is effectively split into 2 NUMA nodes with 6 cores each. Therefore, a 6 vCPU / 24 GB RAM VM
specification seems optimal to maximize linear scalability and minimize NUMA thrashing. Using a 2:1
CPU over-subscription ratio, you utilize all 48 logical cores and deploy 8 XenApp servers on each host
(48 / 6 = 8). Utilizing the Rule of 10 for CVA: 10 x 24 = 240 users per host.
N
• Next, let’s look at an example on sizing Multi-Session OS VDAs using mesh-based architecture:
ot
• Assume you’re running a popular healthcare application on Windows Server 2016 via CVA. You’re
fo
considering purchasing Dell blades with 32 physical cores (2x16) and 256 GB of RAM. You’ve
researched on Intel’s website that the underlying chip employs a mesh architecture and there is a
rr
business directive to decrease your VM footprint as much as possible. You decide on a 16 vCPU / 48 GB
es
RAM VM specification. Using a 2:1 CPU over-subscription ratio, you utilize all 64 logical cores and
al
deploy 4 Multi-Session OS VDAs on each host (64 / 16 = 4). Utilizing the Rule of 10 for CVA: 10 x 32 =
320 users per host.
e
• Now let’s review an example on sizing Single-Session OS VDAs:
or
• Let’s assume you’re running Windows 10 with standard Office applications and a few custom
di
applications. You’ve identified that a 2 vCPU / 4 GB RAM VM specification would work best given the
workload/image. You’re considering purchasing Cisco blades with 36 physical cores (2x18) and 768 GB
s tri
of RAM. And you’d like to understand what kind of density you can expect. Let’s utilize the Rule of 5 for
b
CVD: 5 x 36 = 180 VMs per host.
ut
io
n

Virtual Delivery Agent Machine Scalability
Cloud Considerations
Microsoft Azure Amazon Web Services (AWS)
N
ot
Recommended Sizes Recommended Sizes
fo
• FS v2-series for low memory consumption • Pooled/Persistent Single-Session OS VDI
rr
workloads. • C5.large (Task worker)
• M5a.large (Knowledge worker)
es
• D_v2-series for memory-intensive workloads. • M5a.xLarge (Power worker)
al
• Hosted Shared Apps and Desktops
e
• M5a.2xlarge (All workers)
or
• Burstable VDIs (Pooled/Persistent Multi-Session
OS VDI)
di
• T3a.medium (Task worker)
s
• T3a.large (Knowledge worker)
tri
• T3a.xlarge (Power worker)
b ut
io
n
Key Notes:
• Unlike on-premises deployments, we do not have information about the hardware that will support cloud-based
deployments. As a result, these recommendations are based on testing to find the optimal balance between performance
and price. Choosing the right delivery models is critical and has broad implications beyond just cost.
• Microsoft Azure
• For Azure public cloud deployments, the FS v2 instances were found to have the best value for low memory
consumption workloads while the D_v2-series is the best choice for memory-intensive workloads.

• The Fsv2-series runs on the Intel® Xeon® Platinum 8272CL (Cascade Lake) processors and Intel®
Xeon® Platinum 8168 (Skylake) processors.
• Dv2-series run on Intel® Xeon® Platinum 8272CL (Cascade Lake), Intel® Xeon® 8171M 2.1GHz
(Skylake), Intel® Xeon® E5-2673 v4 2.3 GHz (Broadwell), or the Intel® Xeon® E5-2673 v3 2.4 GHz
(Haswell) processors with the Intel Turbo Boost Technology 2.0.
• Amazon Web Services
• For Amazon Web Services deployments, which AWS EC2 instance type to choose for your VDAs
N
depends heavily upon the specific workload and delivery type.
ot
• As a general guideline, the M5 or M5a series are often most suitable for pooled and persistent Single-
fo
Session OS VDI workloads and Hosted Shared workloads. M5a instances are the latest generation of
General Purpose Instances powered by AMD EPYC 7000 series processors.
rr
• The T3 or T3a (AMD) functions best for general-purpose applications used on pooled or persistent Multi-
es
Session OS VDIs. This is because the T3 line are “burstable” instances that require credits to increase
al
CPU usage above a given baseline. T3 instances feature either the 1st or 2nd generation Intel Xeon
Platinum 8000 series processor (Skylake-SP or Cascade Lake).
e
• Overall, AWS and Azure launch new instance types and changes pricing regularly. Examine the cost models
or
at the time of your design, as these examples should be considered illustrative only and may have changed
di
since this testing was performed, changing the optimal VM size.
s tri
b
• The Scalability and Economics of Delivering Citrix Virtual App and Desktop Services on Azure:
ut
https://docs.citrix.com/en-us/tech-zone/design/design-decisions/azure-instance-scalability.html
io
• Reference Architecture for Citrix Virtual Apps and Desktops on AWS: https://docs.citrix.com/en-us/tech-
n
zone/design/reference-architectures/citrix-virtual-apps-and-desktops-on-aws.html

Scalability Testing and Monitoring
On-Premises
• Using the recommended baselines is useful for providing quick scalability estimates that are often necessary to
N
get a project off the ground.
ot
• Once the project is underway, these numbers need to be validated on the actual hardware that will be used.
fo
• Scalability testing can be conducted during a design or the early phases of a build to validate the initial
rr
estimates.
es
• Another approach that can be used is to monitor the actual users’ load during a phased rollout of an
environment.
al
e
or
di
s tri
but
io
n
Key Notes:
• Business decision makers need to have a general idea about the required infrastructure and costs for a new environment
before committing to a full lifecycle project, which is why scalability recommended baselines and quick sizing rules are
useful.
• However, once the project is underway, these numbers need to be validated on the actual hardware that will be used.
Otherwise, if you over-specify you’re going to cost your company money.
• If you under-specify you’ll reduce the number of users that can be supported – or even worse, you’ll impact performance.

This is particularly important for multi-session OS workloads that will have multiple sessions per VM.
• Tools such as LoginVSI and MicroFocus LoadRunner can be used to verify how many sessions can be
supported on each VDA machine and physical host. As a result of the testing, the sizing of the environment
can be adjusted as needed before a majority of the deployment has occurred.
• While these tools can be incredibly useful, note the tools use scripts to simulate user behavior. These
scripts often require customization to more accurately reflect the expected activity of the user groups in the
organization.
N
• For example, you may not expect users to regularly play videos, or the activity/idle ratio may need to be
ot
adjusted.
fo
• Monitoring during a phased rollout has the benefit of measuring actual user activity, and tends to result in the
most accurate sizing. However, this may provide less time to make adjustments, depending on the overall
rr
project schedule.
es
al
e
or
di
s tri
b ut
io
n

Scalability Testing
and Monitoring
In the Cloud
FS_v2 and D_v2 Instance Type Performance and Cost per Hour
$0.050 80
$0.045
70
Goal is to verify optimal cost $0.040
Cost per Hour US West 2 (USD)

N
per user, per hour. 60
$0.035
ot
1. Determine maximum
VSI Max Users

50
$0.030
users per VM on the
fo
$0.025 40
73 74
expected workload. 71
rr
$0.020 63
61 30
55 54
2. Divide the VM’s current
es
$0.015
43 20
36 38
cost per hour by that $0.010 35
al
28
figure to determine the $0.005
13 14 14 16
10
e
5 6 5 6
cost per user per hour $0.000 0
or
F2S_v2 F4s_V2 F8s_V2 F16s_V2 D2_V2 D3_v2 D4_v2 D5_V2 D13_v2 D14_v2
Knowledge Worker VSI Max Users Task Worker VSI Max Users
di
Knowledge Worker Cost per Hour (USD) Task Worker Cost per Hour (USD)
s tri
b ut
io
n
Key Notes:
• Scalability testing and monitoring in the cloud can make use of many of the same tools as on-premises work. However,
the price model of cloud infrastructure is completely different from that of an on-premises deployment. The key objective is
to validate that the VM size that has been selected for the VDA machines offers the best value in terms of cost per user,
per hour.
• First, use a tool such as LoginVSI’s VSImax to determine the maximum number of users that can be supported by a given
VM size while still maintaining a good experience. Then, divide that number by the price of running that VM per hour.

• As might be expected, larger VM sizes tend to be more expensive than smaller ones. As a result, their
increased capacity must justify the additional cost.
• Also consider that these calculations assume that the VM will be fully utilized – otherwise you would not be
getting the full value for each running VM. This is more likely to happen with larger VMs, which are more
difficult to fully drain of users and power off when not needed.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Group Discussion
Consider the following example organizations:

• Small school - no budget for new hardware,
primary business driver is desktop transformation.
• Large bank - recently purchased 2x14 UCS B200
N
M4s, primary business driver is securing SWIFT
ot
applications used by task workers.
fo
• Medium-sized real estate firm - does not currently
rr
have a datacenter environment, primary business
es
driver is disaster recovery for upper management.
al
e
• What FlexCast models might they use?
or
• Would VDA machines ideally be situated on-
di
premises or in the cloud?
s
• How might the VMs be sized?
tri
b
ut
io
n

N
ot
Machine Security
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Integrate security considerations into an image
N
design.
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n
Key Notes:
• Integrate security considerations into an image design.

Securing VDA
Machines Some Industries: Only External Traffic secured using TLS is sufficient.
Network Traffic
TLS
• As the component accessed Citrix Gateway VDA machine

Endpoint Devices
N
by end users, it is critical to
ot
secure VDA machines.
• By default, the Citrix
fo
Gateway is not using TLS to
rr
secure the HDX proxy to the
es
session. Other Industries: All Traffic is secured using TLS.
al
• Depending on the
e
organization, this may not be
or
TLS TLS
sufficient.
VDA machine
di
Endpoint Devices Citrix Gateway
s
tri
b ut
io
n
Key Notes:
• TLS encryption between components, even internally, is a requirement for FIPS and PCI compliance. Other organizations
may wish to encrypt HDX communications to prevent the risk of a man-in-the-middle attack.
• By default, HDX traffic uses a basic XOR-based encryption algorithm; It protects the data stream from being read directly,
but it can be decrypted. A SecureICA minimum encryption level Citrix policy is available as a way to increase the
encryption level of the HDX logon traffic to Multi-Session OS VDA machines by using a 128-bit RC5 algorithm.
• Although simple to implement, this policy only covers logon data, does not perform authentication or check data integrity,

and RC5 is not a FIPS-compliant algorithm.
• Rather then use the SecureICA minimum encryption level setting, for Citrix Virtual Apps and Desktops 7.1x,
Citrix recommends using TLS to secure HDX traffic if end-to-end traffic encryption is desired.
• To use TLS for communications to the VDA machines, you must do the following:
• Deploy certificates to the VDA machines
• Run a Citrix-provided PowerShell script on the VDA machine image to enable TLS
• Enable TLS for Delivery Groups on the Delivery Controller
N
ot
fo
• Security policy settings: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/policies/reference/ica-policy-settings/security-policy-settings.html
rr
• Transport Layer Security (TLS): https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
es
ltsr/secure/tls.html
al
e
or
di
s tri
b ut
io
n

Securing VDA Machines
Preventing Breakouts
• Design appropriate group-based resource assignments.
N
• Remove HDX session shortcuts and help keys.
ot
• Restrict access to the ICA file.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Overall, keep in mind that every restriction or lockdown may be preventing the use of a resource or feature that is needed
to perform a required workflow. This is why it is important to prioritize business drivers early on to facilitate these type of
decisions.
• Let’s begin by reviewing the leading practices using Active Directory and securing the ICA file:
• Use AD security groups instead of user accounts for assigning resources:
• Try to avoid exceptions if at all possible

• Avoid publishing resources to all users (domain users, authenticated users)
• Avoid publishing to non-specific users (anonymous accounts, shared accounts)
• In Citrix Cloud, subscriber identity defines which subscribers (users) have access to services. These
identities come from Active Directory domain accounts provided from the domains within the Resource
Location.
• Active Directory is queried through Citrix Cloud Connector, which is deployed on-premises or in a public
cloud where an express route or VPN to the datacenter is defined.
N
• There are a couple potential methods for unauthorized access within an HDX session, including the desktop
ot
viewer and keyboard shortcuts or hotkeys.
fo
• These can be mitigated by implementing GPOs using Citrix ADM templates or configuration files on the
StoreFront server.
rr
• Some customers have been known to preconfigure ICA files with a username and password (in clear text!)
es
and provide them to users as an easy way to access published resources with an unbrokered HDX
al
connection.
• In general, it is strongly recommended to refrain from doing this, especially for production environments.
e
• Going further, it is a good idea to restrict download access to the ICA file in general.
or
di
• Configure (See Keyboard Shortcuts and Desktop Viewer sections): https://docs.citrix.com/en-us/citrix-
s tri
workspace-app-for-windows/1912-ltsr/configure.html
b
• How to Configure Desktop Viewer: https://support.citrix.com/article/CTX209468
ut
• How to Enable or Disable Hotkeys within an ICA File (including Template.ica file):
io
https://support.citrix.com/article/CTX140219
• Support for ICA files in Citrix Virtual Apps and Desktops Environment:
n

Preventing Breakouts Continued
• Disable unneeded HDX channels and redirections.
N
• Remove unneeded devices and drivers.
ot
• Restrict access to administrative tools such as the command-line, PowerShell, and the registry.
fo
• Restrict access to certain areas of the Control Panel.
rr
• Limit local VDA machine and client drive access.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• It is also just as important to restrict unnecessary device and drive redirection as well as lock down access to make
changes to the operating system. This includes items such as:
• Disable all HDX channels that are not required. Every redirection is potentially dangerous, for example client to server
redirections (USB/CDM) and server to client redirections (HTML5/Media offloading).
• Redirection (or offloading) is one of the areas where you have to balance user experience with security. Offloading
(HTML5 or Windows Media) essentially allows you to transfer data between the session and endpoint, which is always

potentially dangerous.
• For environments where security is important, it’s recommended to disable all offloading.
• Overall, it makes sense to remove unwanted access to printers or other devices, as well as unwanted drivers.
• Also disable or remove floppy drives and USB ports. Even if there appears to be no direct security threat, it
is important to minimize the attack surface by removing unnecessary functionality.
• For example, “Print to File” can often lead to file system access.
• Client drive access can be configured through Studio policies. It is inherently less secure to allow client drive
N
access because this allow files to freely be transferred to-and-from a potentially untrusted endpoint.
ot
• Access to the Control Panel means access to your entire system. Use Group Policies to restrict access to
fo
items such as: Add or Remove Programs, Display, Network, Passwords, Printers, System, Internet Options,
and Applets.
rr
• As a rule, users should not be able to view or access the local drives of a VDA machine. This is especially true
es
for Multi-Session OS VDA machines, because users can impact the experience of other users through
al
accidental or malicious tampering with the files in the VDA machine’s local drive.
• Command-line and PowerShell can be used to gain system info and run commands and scripts, and thus
e
should be one of the most obvious areas to lock down. The registry is a system-defined database in Windows
or
in which applications and system components store and retrieve configuration data. As such, unauthorized
di
access to the registry and registry-editing tools can lead to a serious attack.
• When locking down registry executables, ensure both regedit.exe and reg.exe and included in the
s tri
lockdown.
b
• GPO settings exist to lock down the registry and command line, but not PowerShell, which must be blocked
ut
via executable whitelist/blacklist.
io
n
• Citrix TIPs: Top 10 recommendations to improve your security posture:
https://www.citrix.com/blogs/2019/05/07/citrix-tips-top-10-recommendations-to-improve-your-security-posture/

Securing VDA
Many layers of defense are required for a hardened environment.
Machines
Implement Hardening Datacenter
Network and Services
Hypervisor
• Application hardening
N
Operating System
• Web browser hardening
ot
• Lockdown of administration HDX Session
fo
tools and privileges
rr
App-to App
• Script execution prevention Policy
es
Application Hardening Application Hardening
• Process management
al
• Application segregation
e
or
• Secure the outside
perimeter
di
s tri
b ut
io
n
Key Notes:
• Apply application hardening configurations and policies based on guidance from the vendor. When considering the
security risk of individual applications, be especially careful with applications that provide a development
environment.
• Browsers tend to pose a significant security risk relative to other apps because by their nature, they are intended to
access content from outside the internal network. However, users need to browse the web to do their job, so we cannot
simply remove access to browsers.

• There are areas that should be addressed, such as:
• Protocol and network security: Usage of HTTPS, usage of HTTP response headers for security policies,
preventing open redirection, implementing domain relaxation, and usage of web proxies.
• Encryption: Usage of appropriate certificates for web sites, hashes and algorithms used.
• Session and state management: Session persistence, in-browser security indicators.
• Authentication: Using MFA for access to web apps.
• Content filtering and security: Treatment of embedded objects, treatment of various file types within a
N
web page.
ot
• Published browsers can be provided via Citrix Virtual Apps in kiosk mode. Citrix Secure Browser is a
fo
specialized form of this approach that can be configured on-premises or used as a Citrix Cloud service. Most
major browsers also have additional security policy settings that can be imported into Active Directory.
rr
• Finally, if an attacker is not able to use his own code, he will try to use whatever is available on the box. Make
es
sure to secure (using policies or NTFS permissions) all administrative tools that could be abused – command
al
prompt (and PowerShell), Registry editor, Task Manager and many others.
• You can also use 3rd party tools to password protect the executables (if you still need to execute them for
e
troubleshooting purposes).
or
• Be aware of hidden scripting environments. There are many technologies that are very powerful and a
di
professional attacker can use them to his advantage.
• One of the good examples is Office suite. It includes Visual Basic for Applications. VBA can be
s tri
used as a replacement of PowerShell.
b
• Restrict access to file system dialog – The goal here is to prevent access to the file system where an
ut
attacker may have unintended access to launch executables, data-mine files, or write malware. This
io
does not only mean Windows Explorer, but also any other methods that access the file system.
• If an executable is able to reach your VDA machine, do not allow it to be executed. Allow users to run
n
executables only from locations where they don’t have write permissions.
• For example, allow executables from Program Files and Windows folders, and reject them in the user
profile or temporary folder.
• In general, logon or logoff scripts can limit the amount of lockdowns that can be applied to the command-line,
PowerShell ISE, or the registry if the script requires silent access to these items. In this scenario, an attacker

could exploit that to run their own scripts.
• If possible, examine whether there is an alternative method of achieving the script results. If some scripts
must be used, consider: Are any passwords stored in plaintext? Are login/logoff scripts using backdoors in
ways you wouldn’t want your users doing?
• Tools such as Microsoft AppLocker and Citrix Workspace Environment Management can be used to control
which processes are allowed to run on a VDA machine (or any other machine) through the use of whitelisting
or blacklisting.
N
• It is recommended to take steps that will mitigate the impact of any breakouts that end up occurring. One way
ot
to do this is to use segregated servers to host very sensitive applications.
fo
• Beyond preventing a breakout from another application to be used to compromise the secure app, it also
allows you to separate them on a network level (and better protect the backend data by configuring security
rr
zones).
es
• If applications must stay on the same server, restrict access to applications via NTFS permissions on
al
application folders\executables. You can use the same AD group that is used for published app access.
• Finally, if an attacker is able to break out of the application, he will try to get their toolkit to one of your servers.
e
Therefore you want to block every possible way that they could transfer executables to your Citrix Virtual Apps
or
server.
di
• This includes items like client drive mapping, HTTP/FTP, file shares, and email.
s tri
b
• Citrix Virtual Apps and Desktops Secure Browser: https://www.citrix.com/virtualization/secure-browser.html
ut
• Protect your network from browser-based attacks: https://www.citrix.com/digital-workspace/secure-
io
browser.html

Antivirus Leading Practice
Manage Antivirus
Exclusions
N
(scans and updates) (non-persistent images)
ot
fo
• Appropriate exclusions improve • The challenge is to keep • Antivirus definition updates
rr
performance of the system and definition files up-to-date while should be included as a part of
Citrix products. minimizing disruption to end regularly scheduled image
es
users. update processes.
• Files, folders and processes to
al
• Schedule full scans and
be excluded vary with each • If supported, redirect definitions
e
product. updates during non-peak to the write cache disk for Citrix
business hours.
or
Provisioning target devices.
di
s tri
but
io
n
Key Notes:
• In general, antivirus software is intended to protect against viruses, spyware, adware/malware, spam email, and identity
theft.
• Citrix does NOT recommend implementing any of the recommended exclusions in production without validation.
• A few general recommendations by Citrix for all products:
• Set real-time scanning to scan local drives only and not network drives
• Disable scan on boot

• Remove any unnecessary antivirus related entries from the Run key
• Exclude the pagefile(s) from being scanned
• Exclude Windows event logs from being scanned
• Exclude IIS log files from being scanned
• When excluding processes, what we want is to prevent any reads and writes done by those processes from
being scanned; not necessarily to prevent the exe file from being scanned. In some antivirus solutions, this
is referred to as defining trusted processes.
N
• Antivirus protection on physical Multi-Session OS VDA machines hosting published applications and
ot
desktops can be a challenge when the appropriate exclusions are not set up because performance and
fo
availability can suffer drastically. Some of the issues that can be avoided by exclusion include hanging user
sessions, long delays at logon and logoff, long delays launching apps, server unresponsiveness, etc.
rr
• When maintaining an antivirus solution, consider the following:
es
• Updated signature files are released frequently by most antivirus vendors to identity the newest known
al
threats, while scan engine updates tend to occur less frequently, and either fix a scan engine issue or make
it scan faster, perform better and detect fewer false positives.
e
• Both types of update should be included in the update operations employed at an organization.
or
• Consider how antivirus will be handled on any non-persistent images in the environment, such as those
di
deployed using MCS and Citrix Provisioning. Different vendors address non-persistent images in different
ways – some will not support this use case at all, while others allow for the redirection of antivirus
s tri
definitions, and ways to generalize the antivirus agent installed on a shared image so that it functions
b
correctly on all machines using that image.
ut
io
• Endpoint Security and Antivirus Best Practices: https://docs.citrix.com/en-us/tech-zone/build/tech-
n
papers/antivirus-best-practices.html
• Citrix Ready Marketplace (to check certified antivirus compatibility): https://citrixready.citrix.com/

App Protection 1
App protection prevents exfiltration of confidential information such as user credentials and sensitive information
N
displayed on the screen by restricting users and attackers from taking screenshots and from using keyloggers to
ot
exploit sensitive information.
fo
rr
After purchasing the app protection, follow these steps to fully configure and enable the feature:
es
1. Import the app protection license.
al
2. Install the app protection component during Citrix Workspace app installation.
e
3. Use PowerShell to enable the app protection policies on the Delivery Controller:
or
• AppProtectionKeyLoggingRequired: True
di
• AppProtectionScreenCaptureRequired: True
s
tri
but
io
n
• App protection: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/secure/app-protection.html
• Configure (See App Protection section): https://docs.citrix.com/en-us/citrix-workspace-app-for-windows/1912-
ltsr/configure.html

Lesson Review
N
ot
Should the security practices mentioned in this
fo
lesson be implemented at all organizations? Why
or why not?
rr
es
It depends on the organization.
al
• In some cases, less secure configurations will be
e
needed to achieve a higher priority business
or
objective.
• For example, client drive mapping may be required
di
for certain trusted user groups as part of their
s
tri
workflow.
b
ut
io
n

N
Provisioning Strategy / Image
ot
Management
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine key design considerations to determine
N
whether to use Citrix Provisioning, Machine
ot
Creation Services or App Layering to provision and
deploy Virtual Delivery Agent Machines.
fo
• Differentiate the available image management
rr
methods.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Examine key design considerations to determine whether to use Citrix Provisioning, Machine Creation Services or
App Layering to provision and deploy Virtual Delivery Agent Machines.
• Differentiate the available image management methods.

Review of Image Management Methods
Commonly used for Citrix Virtual Apps and Desktops environments
Citrix Provisioning Machine Creation Services App Layering
N
ot
Virtual Machine Virtual Machine Virtual Machine App Layer
Provisioning Server Appliance MCS
Virtual Machine
fo
rr
Repository
Citrix Provisioning
es
Virtual Machine
Master
al
Image
Master Image Layered
vDisk Identity Disk Differencing Disk Layers
vDisk Virtual Machine Images
e
MCS Manual
Store SnapShot
or
Leverages streaming technology to Leverages hypervisor APIs through Studio • Creates and manages layers which are
di
provision virtual machines from a single to deploy virtual machines from a single assigned to users or machines.
shared master image. master image snapshot.
s
• The layered images can be integrated
tri
with MCS, Citrix Provisioning, or
manual provisioning.
b ut
233 © 2020 Citrix | Confidential
io
n
Key Notes:
• MCS, Citrix Provisioning and App Layering are the primary Citrix technologies that can be used to provision and manage
VDA machine images.
• Manual provisioning is significantly more likely to be used in Multi-Session OS-only environments, while MCS and Citrix
Provisioning are relatively popular in Single-Session OS-only environments. This is likely because the number of VDA
machines that must be managed tends to be higher for Single-Session OS VDA machines.
• Although App Layering is another Citrix technology that enhances image management, it actually integrates with any of

the provisioning methods mentioned above.
• Citrix Provisioning 1912 LTSR: https://docs.citrix.com/en-us/provisioning/1912-ltsr
• Citrix App Layering: https://docs.citrix.com/en-us/citrix-app-layering/4.html
• Citrix Virtual Apps and Desktops Image Management: https://docs.citrix.com/en-us/tech-
zone/design/reference-architectures/image-management.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Provisioning
Overall Benefits and Considerations
Key Benefits Key Considerations
N
• Mostly hypervisor agnostic; able to stream images • Requires additional infrastructure components:
ot
to virtual or physical VDA machines. (Citrix Provisioning servers, database, store
locations).
fo
• Well-known leading practices facilitate environment
optimization. • Citrix Provisioning supports a connector for Citrix
rr
Cloud integration to enable provisioned VDAs to be
• Advanced functionality built into console.
es
used in a Citrix Virtual Apps and Desktops
• Rapid image updates and rollbacks. environment.
al
e
• Not supported for persistent desktop VDI.
or
di
s
tri
but
io
n
Key Notes:
• Citrix Provisioning is a relatively mature technology, and its benefits and considerations are well known. The decision on
whether to use Citrix Provisioning will largely depend on the FlexCast models that need to be supported, the location of
the environment (on-premises or virtual), the number of VDA machines that must be supported, and the licensing
available.
• On-premises Citrix Provisioning deployments can be integrated with Citrix Cloud which allows an administrator to manage
provisioned VDAs in a Citrix Virtual Apps and Desktops Service deployment. The Citrix Provisioning server communicates

with the Citrix Cloud Connector and provides the same functionality used in on-premises Citrix Virtual Apps
and Desktops deployments.
• Citrix Provisioning managed by Citrix Cloud: https://docs.citrix.com/en-us/provisioning/1912-
ltsr/configure/cloud-connector.html
• Tech Zone: Citrix Provisioning managed by Citrix Cloud: https://docs.citrix.com/en-us/tech-
N
zone/design/reference-architectures/image-management.html#citrix-provisioning-managed-by-citrix-cloud
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Provisioning – Key Design Considerations
Target Device Boot Method
Boot Method Advantages Disadvantages
• Easy to implement.
• Can interfere with other running PXE services on the same subnet.
PXE • Compatible with BIOS and UEFI-based VMs
• Requires UDP/DHCP helper for targets on different subnets.
N
on the same subnet.
ot
• Requires changes to production DHCP service.
• Easy to implement • DHCP service may only allow one option 66 entry.
fo
DHCP Options
• Compatible with BIOS and UEFI-based VMs. • Difficulty of implementation on 3rd party services varies.
rr
• Requires UDP/DHCP helper for targets on different subnets.
es
• UEFI-based VMs must be provisioned using Citrix Virtual Apps
BDM ISO • Does not require PXE or TFTP services. and Desktops Setup Wizard.
al
• Extra effort required to boot physical target devices.
e
• UEFI-based VMs must be provisioned using Citrix Virtual Apps
• Does not require PXE or TFTP services.
or
BDM Disk Partition and Desktops Setup Wizard. Extra effort required to boot physical
• Easier bootstrap update with PVS 7.9+.
target devices.
di
s
• Restricted to specific physical endpoints.
BIOS Embedded • Works “out of the box.”
tri
• Requires multi-vendor support.
b ut
io
n
Key Notes:
• When deciding on a boot method for the Citrix Provisioning target devices, a few key considerations include:
• Whether the target devices are BIOS or UEFI-based
• The number of subnets where the target devices will be placed, the availability of PXE and DHCP services on those
subnets, and whether PXE is used for other purposes on those subnets
• The bootstrap update processes that can be supported by the administrative team

• Using the Manage Boot Devices utility: https://docs.citrix.com/en-us/provisioning/1912-ltsr/configure/configure-
targets/boot-devices-utility.html
• Unified Extensible Firmware Interface (UEFI) pre-boot environments: https://docs.citrix.com/en-
us/provisioning/1912-ltsr/configure/configure-UEFI.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Read Cache Method and Sizing
Cache in Provisioning Server Memory Cache in Citrix Hypervisor Host Memory
N
• Baseline RAM sizing formula to use for testing: • The PVS-Accelerator cache can use host memory OR a
ot
storage repository. Baseline sizing is as follows:
• 2GB + (#CVA_vDisk * 4GB) + (#CVD_vDisk * 2GB) +
15% (Buffer) • Control Domain Memory: 4 GB
fo
• #CVA_vDisk = number of vDisks for Multi-session OS • Cache Space per vDisk: 5 GB
rr
• #CVD_vDisk = number of vDisks for Single-session OS • Cache captures vDisk reads going through host’s virtual
es
• This caching type is built into Citrix Provisioning. switch.
al
• Primary design consideration is sizing RAM on the • Supplements the Provisioning Server read cache.
e
Provisioning Servers based on the type and number
or
of vDisks in the environment.
di
stri
b ut
io
n
Key Notes:
• One of the key benefits of Citrix Provisioning is the ability to store vDisk information on the system cache of Provisioning
Servers. This can dramatically reduce the amount of read IOPS to the Citrix Provisioning Store.
• The streaming cache also helps lower network utilization between the Provisioning Servers and the Store.
• In general, the amount of memory needed will depend on the number and type of vDisks in the environment. From
there, adjust as needed based on actual performance. Tools such a Resource Monitor and RamMap can be used to
monitor memory usage.

• It is recommended to reboot the Citrix Provisioning servers regularly. This clears the system cache, which
may be storing disk information that is no longer needed or used due to vDisk updates, and allows it to
rebuild with up-to-date vDisks.
• Citrix Provisioning Accelerator enables a Citrix Provisioning proxy to reside in Dom0 Citrix Hypervisor's Control
Domain on a Citrix Hypervisor host where streaming of a vDisk is cached at the proxy before being forwarded
to the VM. Using the cache, subsequent booting (or any IO requests) of the VM on the same host can be
streamed from the proxy rather than streaming from the server over the network.
N
• PVS-Accelerator provides two cache modes:
ot
• Memory Only
fo
• Memory and Disk
• Cache size considerations:
rr
• Citrix recommends that you allocate at least 4GB of Control Domain memory per host to avoid
es
frequent disk accesses that cause higher read-latency and consequently degrade performance.
al
• Citrix recommends that you allocate at least 5GB of cache space per vDisk version that will be
actively used on.
e
• Using this model, more local resources on the Citrix Hypervisor host are consumed, but streaming from the
or
server over the network saves resources, effectively improving performance.
di
• Internal testing has shown that this feature can result in 25% faster desktop boot up times, up to 98% lower
network bandwidth usage, and up to 93% reduced Citrix Provisioning CPU usage.
s tri
• Additionally, by providing an additional caching location for vDisk information, it can provide some fault
b
tolerance for Citrix Provisioning Server outages.
ut
• Cache sizing will depend on the OS and number of vDisks. Newer operating systems tend to require more
io
disk reads to fully boot. During configuration, you are able to use host memory for the cache, or designate a
storage repository.
n
• Advanced Memory and Storage Considerations for Citrix Provisioning:
• Citrix Provisioning Accelerator: https://docs.citrix.com/en-us/provisioning/1912-ltsr/configure/
configure-accelerator.html

• PVS 7.13: XenServer PVS-Accelerator Cache Storage Considerations:
N
ot
fo
rr
es
al
e
or
di
stri
but
io
n

Write Cache Type
Cache Type Advantages Disadvantages

• Able to use diskless target devices without risks of • Increases network bandwidth requirements.
cache in device RAM method. • Increases Citrix Provisioning server utilization and storage
Cache on server
requirements.
• Not preferred for High Availability.
N
• Allows user changes to disk to be saved between • Persistent cache files are created for each target device/vDisk
ot
reboots. combination per user, greatly increasing storage requirements for
Cache on server persistent
• Target devices still accessing common vDisk image. Citrix Provisioning server.
• Persistent cache files become invalid after a vDisk update.
fo
• Does not consume resources on the Citrix • Storage must support the IOPS for all the virtual machines on the
rr
Provisioning servers. host.
Cache on device hard drive
• Relatively low cost. • Performance not as good as caching in device RAM.
es
• Deprecated and will be removed in a future release.
al
• Allows user changes to disk to be saved between • Considered an experimental feature.
Cache on device hard drive reboots. • Increases storage requirement for the target devices.
e
(persisted) • Requires a custom bootstrap file to be used.
• Deprecated and will be removed in a future release.
or
• Able to use diskless target devices. • If the target device RAM cache runs out of space, the virtual
• Provides high performance due to the speed of RAM. machine will become unusable.
di
Cache in device RAM
• To reduce the risk of machine failures, significant amounts of
s
RAM must be allocated to the target devices, increasing cost.
tri
• Able to take advantage of the high performance of a • Not able to create diskless VMs.
Cache in device RAM w/ overflow
RAM cache will providing a safeguard in the event
b
on hard disk
that RAM is not available.
ut
io
n
Key Notes:
• Cache on device RAM w/ overflow to disk should be used in most production environments. By default, the RAM buffer
used in this method is 64MB; however, for best performance and to reduce IOPs and size of write cache overflow disk
increase this buffer.
• The disk-based portion of the write cache can initially grow larger than previous methods due to a larger 2 MB blocks
being reserved on the write cache.
• A larger RAM buffer may alleviate the larger write cache requirement for environments that do not have storage capacity.

With enough RAM you can even eliminate the need for ever writing to the storage. For desktop operating
systems start with 256-512MB and for server operating systems start with 2-4GB.
• The sizing of the overflow disk-based write cache will depend on the RAM allocation provided to each of the
target devices. As we will see in the next lesson, you must also take into account other kinds of data you may
wish to redirect to this drive so that it can persist between target device reboots. Thin-provisioning the write
cache drive is supported, but there may be a small performance penalty associated with doing so. On the
other hand, for large environments, the savings in terms of storage requirements justifies the performance hit.
N
And if the RAM buffer is increased from the default value, the number of writes to this overflow disk will be
ot
minimal.
fo
rr
• Selecting the write cache destination for standard vDisk images: https://docs.citrix.com/en-
es
us/provisioning/1912-ltsr/manage/managing-vdisks/write-cache.html
al
• Analyzing PVS RAM Cache with Overflow: https://docs.citrix.com/en-us/advanced-concepts/implementation-
guides/digging-into-pvs-with-poolmon-and-wpa.html
e
or
di
s tri
b ut
io
n

Citrix Provisioning - Centralized Store (SMB/NFS Share)
Key Design
Considerations
vDisk Store Location Provisioning Server Provisioning Server
Centralized Share
N
ot
• vDisk Store locations: FileServer
• Centralized Store
fo
(SMB/NFS Share)
rr
• Decentralized Stores Decentralized Stores (Locally Attached or SAN)
es
(Locally Attached or SAN)
Server-Allocated Server-Allocated
• Each Store location has its
al
Storage Storage
own benefits and
e
considerations.
or
Provisioning Server Provisioning Server
di
s tri
b
FileServer FileServer
ut
io
n
Key Notes:
• Both centralized and decentralized stores have been used successfully by many customers, and there is no leading
practice in this area. However, some items to consider:
• Centralized stores require less storage for vDisks, and also work well when versioning is used for vDisk updates, since
no replication between Stores needs to occur. However, proper tuning and testing of the centralized store is
recommended, especially since the entire Citrix Provisioning Site depends on it.
• By adding another component to the environment, this option also adds more complexity, meaning the typical design

considerations (high availability, performance) must be addressed.
• Decentralized stores are typically easier to configure, since they make use of storage already allocated to
the Provisioning Servers. Additionally the required storage performance can potentially be distributed
among multiple separate storage locations.
• The primary consideration of decentralized stores is that all vDisks must be replicated between the different
Store locations, introducing the possibility of Citrix Provisioning replication issues.
• VDisk replication can be handled efficiently using the vDisk Replicator Utility.
N
• It provides:
ot
• Automation to help manage Citrix Provisioning replication using a DevOps methodology.
fo
• The ability to run scripts on a schedule to keep Citrix Provisioning stores in-sync between Site or
Farms.
rr
• The ability to save administrators a significant amount of time
es
• The capability to add, change, and delete vDisks.
al
• The capability to replicate between stores on the same Provisioning Server.
• There are two ways now that you can remove vDisks:
e
1. The Citrix Provisioning console on the Master server.
or
2. The vDisk Replicator Utility (script).
di
• With the vDisk utility you can select vDisks to delete. The utility will perform the delete first on the Master
server, then the changes will be replicated, then the utility will remove the vDisk from and Secondary Site
s tri
Master servers or Secondary Farm Master servers.
b
• There is a status tab in the script that shows how much disk space is available on all of the Provisioning
ut
Stores. Additionally, you can configure warning and critical percent full amounts, along with related colors
io
on the status page.
• To run the utility on a regular basis set up a scheduled task on your scripting server.
n
• Virtual disks: https://docs.citrix.com/en-us/provisioning/1912-ltsr/manage/managing-vdisks.html
• vDisk Replicator Utility: https://www.citrix.com/blogs/2018/06/08/vdisk-replicator-utility/
• The vDisk Replicator Utility is finally finished!: https://www.citrix.com/blogs/2019/06/04/the-vdisk-
replicator-utility-is-finally-finished/

• Citrix Provisioning vDisk replication status: https://www.citrix.com/blogs/2019/01/03/provisioning-services-
vdisk-replication-status/
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Citrix Provisioning - Key Design Considerations
Network Design 1
Hypervisor Uplink
Hypervisor Host
1 Gbps is sufficient for most
N
workloads
ot
Citrix Provisioning Server
Physical NIC
fo
Virtual switch
Virtual NIC
rr
es
Virtual NIC
Physical
al
switch
Physical NIC
e
or
PVS Uplink Virtual NIC
At least 1 Gbps per 500
di
target devices VM Uplink
s
100 Mbps per VM is sufficient for most workloads
tri
b ut
io
n
Key Notes:
• It is essential that the network is sized correctly to prevent network bottlenecks causing high disk access times and
directly affecting VDA machine performance. Today, most networks have sufficient bandwidth to accommodate Citrix
Provisioning streaming along with other types of traffic on the same network, so it is usually not necessary to isolate
streaming traffic (although this might still be desired to meet a security requirement); however, it is still recommended to
segment management and storage (e.g. NFS or iSCSI) traffic.
• All disk access from the target devices will be transferred via the Citrix Provisioning network uplink. This means hundreds

or even thousands of devices will use this network connection; therefore, it is vital that this connection is
redundant and can failover without any downtime. For virtual provisioning servers, a respective QoS quota or
a dedicated physical network uplink should be configured to ensure best performance.
• The hypervisor uplink is used by all Citrix Provisioning target devices hosted on a particular hypervisor host.
Therefore, redundancy with transparent failover is strongly recommended.
• The suggested bandwidth of 1 Gbps is sufficient unless the target devices run a very I/O intensive workload or
perform I/O intensive tasks (e.g. booting) simultaneously.
N
• All network traffic for a virtual machine, including Citrix Provisioning streaming traffic, will traverse the VM
ot
uplink. The suggested bandwidth of 100 Mbps per VM is sufficient even under peak loads unless the workload
fo
is extremely I/O intensive.
• For example, a Windows 2012 R2 Server will read approximately 232MB during a period of 90 seconds
rr
from the vDisk until the Windows Logon Screen is shown. During this period an average data rate of 20.5
es
Mbps with peaks up to 90 Mbps can be observed.
al
• Beyond link sizing, there are several documented leading practices regarding Citrix Provisioning-related
network optimizations.
e
• Spanning Tree Protocol (STP) or Rapid Spanning Tree Protocol causes ports to be placed into a blocked
or
state while the switch transmits Bridged Protocol Data Units (BPDUs) and listens to ensure the BPDUs are
di
not in a loopback configuration. The amount of time it takes to complete this convergence process depends
on the size of the switched network, which might allow the Preboot Execution Environment (PXE) to time
s tri
out - this prevents target devices from getting an IP address.
b
• This optimization is only necessary if the PXE boot method will be used.
ut
• STP can be disabled on edge-ports connected to clients.
io
• Some switch manufacturers have released features that can mitigate this issue when enabled. For
example, Cisco has PortFast or STP Fast Link, Dell has Spanning Tree FastLink, Foundry has Fast Port,
n
and 3COM has Fast Start.
• TCP Large Send Offload, which is enabled by default on modern NICs, is a feature that allows a network
interface card (NIC) to re-segment network packets for transmission, which reduces CPU overhead. The
AIX TCP layer is able to build a TCP message up to 64 KB long and send it in one call down the stack
through IP and the Ethernet device driver.

• The adapter then re-segments the message into multiple TCP frames to transmit on the wire. The TCP
packets sent on the wire are either 1500-byte frames for a Maximum Transmission Unit (MTU) of 1500 or
up to 9000-byte frames for a MTU of 9000 (jumbo frames). In a Citrix Provisioning environment, this
process causes latency and timeouts in streaming traffic between Provisioning servers and target devices.
• Some NICs allow you to disable the feature via the NIC properties in Windows. Alternatively, it can be
disabled via a registry key as well (see Additional Resources for more details).
• Auto-Negotiation requires network devices and its switch to negotiate a speed before communication
N
begins. This can cause long starting times and PXE timeouts, especially when starting multiple target
ot
devices with different NIC speeds. Citrix recommends hard coding all Provisioning Server ports (server and
fo
client) on the NIC and on the switch.
• Be sure to sync-up with your networking team to find out the link speed and duplex settings on the
rr
network switches, and then matching those settings on the Provisioning servers and targets. The method
es
used to configure the NIC speed and duplex settings will vary depending on whether the target devices
al
are physical or virtual, and if virtual, which hypervisor is hosting them.
e
or
• Best Practices for Configuring Citrix Provisioning Server on a Network:
di
s tri
b ut
io
n

Citrix Provisioning - Key Design Considerations
Scalability
Physical or Virtual Ports and Threads CPU Sizing Scale Up or Scale Out
N
ot
Overall, virtual When increasing ports, Best performance is Scaling Citrix Provisioning
fo
Provisioning servers are ensure its aligned to the attained when the threads up past 8 vCPUs is not
preferred when sufficient cores available on the per port is not greater than recommended.
rr
performance is available. Citrix Provisioning the number of cores
es
Servers. available.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Physical vs. virtual Citrix Provisioning servers:
• In general, virtual Provisioning servers offer rapid server provisioning, snapshots for quick recovery or rollback
scenarios and the ability to adjust server resources on the fly. Virtual provisioning servers allow target devices to be
distributed across more servers helping to reduce the impact from server failure.
• Virtualization also makes more efficient use of system resources.
• Physical servers offer higher levels of scalability per server than virtual servers, and mitigate the risks associated with

virtual machines competing for underlying hypervisor resources.
• Overall, virtual Provisioning servers are preferred when sufficient processor, memory, disk and networking
resources can be made available and guaranteed to be available.
• PVS Ports & Threads
• Citrix Provisioning is not CPU intensive. However, under-allocating the number of CPUs does impact the
optimization of the network streams.
• By default, the Streaming Service is configured with 20 sequential network ports, and 8 threads per port.
N
Therefore, by default, a provisioning server can support 160 concurrent targets.
ot
• If more than 160 streams are required, Citrix Provisioning continuously switches between streaming
fo
different target devices.
• Ideally, if the environment needs to support more than 160 concurrent targets, the number of ports, and
rr
threads per port can be adjusted in the Citrix Provisioning console.
es
• Note: when increasing the number of ports 6969 is used by the Provisioning two-stage boot (Boot ISO)
al
component.
• During the design phase, consider implementing Citrix Provisioning server Maintenance/DR scenarios to
e
reduce the possible issue of target devices being unable to boot due to incorrect tuning of threads/ports.
or
• CPU Sizing
di
• Best performance is attained when the threads per port is not greater than the number of cores available on
the Citrix Provisioning server. If the provisioning server does not have sufficient cores, the server will show
s tri
a higher CPU utilization, and target devices waiting for requests to be processed will have a higher read
b
latency.
ut
• Scale up or scale out?
io
• For small to medium environments of up to 500 target devices, allocate 4 vCPUs per Citrix Provisioning
server, then add more ports or scale out. Note that for this configuration, the default threads per port
n
configuration should be reduced to 4 threads per port.
• For large environments of more than 500 target devices, allocate up to 8 vCPUs per Citrix Provisioning
server, then add more ports or scale out. Overall, scaling up Citrix Provisioning servers past 8 vCPUs is not
recommended; scaling out will increase redundancy and reduce failure domains.
• As with other components, utilize the N+1 rule to add redundancy to the environment. As an added benefit,

the overall capacity will not be impacted during Citrix Provisioning server reboots, and the redundant
Provisioning Server can also be temporarily used to boot development or test target devices without
impacting production performance.
• Citrix Provisioning Sites do not have a technical scalability limit; for ease of management, use a one
Farm/one Site architecture unless additional Sites are required for organizational reasons.
N
• Updated Guidance on PVS Ports and Threads: https://www.citrix.com/blogs/2016/03/30/updated-guidance-on-
ot
pvs-ports-and-threads/
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Machine Creation Services
N
• Easy to deploy and does not require additional • MCS optimizations vary based on the hypervisor
ot
infrastructure; Delivery Controllers handle MCS and storage used for the environment.
orchestration tasks.
fo
• Cannot provide images to physical machines.
rr
• Available with all licensing editions.
• Requires use of PowerShell for advanced
es
• Supported for on-premises or cloud-based functionality.
deployments.
al
• Slower image updates and rollbacks compared to
e
• Can be used to create persistent desktops. similar number of VDA machines in a Citrix
or
Provisioning environment.
di
s tri
b ut
io
n
Key Notes:
• Citrix Machine Creation Services is a mature provisioning platform proven at scale.
• Citrix MCS is easy to deploy since it is embedded into the Delivery Controller and managed from within the Citrix Studio
Console.
• Citrix Machine Creation Services uses Application Programming Interfaces (APIs) from the underlying hypervisor or public
cloud platform that enables Citrix MCS to create, configure, start, stop, and delete virtual machines to the on-premises,
hybrid, private, and public cloud environments.

Machine Creation Services – Key Design Considerations
Cloning Type
Thin Clone (Non-persistent desktops) Full Clone (Persistent desktops)
N
ot
Benefits: Benefits:
fo
• Greater storage savings. • Easy to backup and restore.
rr
• Fast provisioning speed. • Faster performance.
es
Considerations: Considerations:
al
e
• Difficult to backup or restore. • High storage space requirements.
or
• Slower performance. • Slower provisioning speed; can be mitigated by
storage optimization technologies.
di
• High storage impact during boot storm.
s
• Boot storms have low storage impact.
tri
but
io
n
Key Notes:
• When using thin clones, very VM uses a single, read-only master image for all reads. A differencing disk is attached to
each VM to capture all write I/O activity. This deployment type has a reduced storage footprint compared to full clones,
and as a result initial provisioning times are faster. However, keep in mind the increased read I/O requirements, since
machines will sometimes need to read from the master image as well as the differencing disk. This can be mitigated
through the use of host caching technologies, which differ by hypervisor.
• Conversely, with full clones, every VM receives a full copy of the master disk image and fully owns the copy, allowing for

read/write activity. This can be used for dedicated desktops where users need to save all changes to the local
disk. In this model, MCS is only used for the initial provisioning of VMs based on a master image; afterwards,
image updates must be performed via traditional methods such as WSUS or ESD.
• Ultimately, the cloning method used will depend on the use cases that must be supported by the environment
and the FlexCast models that will support them.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Storage Location
Citrix Hypervisor IntelliCache

Shared Storage Hybrid Storage
Hypervisor Host Hypervisor Host Citrix Hypervisor Host
N
ot
fo
rr
IntelliCache
es
al
e
or
di
Shared Storage Shared Storage Shared Storage
s
Identity Disk
tri
Master Image Identity Disk Differencing Disk Master Image Identity Disk Differencing Disk Master Image Differencing Disk
b ut
io
n
Key Notes:
• Machine Creation Services allows administrators to break up a virtual desktop into multiple components and store those
pieces on different storage arrays. The three components that must be accessible to each MCS-provisioned VM are the
master image, the identity disk, and the differencing disk.
• Note that this applies to non-persistent, linked clone machines. For a persistent desktop use case, full clones of the
master image would be created, and no differencing disk would be used.
• All components can be placed on shared storage. This facilitates the sharing of the master image among multiple

hypervisor hosts; however, the presence of the differencing disks will put more strain on the shared storage
array because it is hosting temporary data.
• A hybrid approach can be used where the master image and identity disks remain in shared storage, but
differencing disks are placed in local hypervisor storage. This still provides the benefit of sharing the master
image among multiple hosts, but offloads expensive, temporary IOPS from differencing disk operations to
cheap, local hypervisor storage.
• If Citrix Hypervisor hosts are being used to host the VDA machines, the IntelliCache feature can store master
N
image reads locally on each host. This further reduces read IOPS from shared storage. If Citrix Hypervisor
ot
RAM is limited, IntelliCache can coexist with a Citrix Hypervisor RAM-based read cache.
fo
rr
• Create machine catalogs: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/install-
es
configure/machine-catalogs-create.html
al
e
or
di
s tri
but
io
n

Storage Sizing
Sample Equation Storage Planning
ImageSize: The size of the master image in GBs.
N
#LUNS: The number of storage resource locations for the Catalog hypervisor connection.
(ImageSize * #LUNS * #Updates * #Catalogs)
ot
#Updates: The number of updates deployed between complete Catalog restarts + 12 hours.
#Catalogs: Each machine catalog will need to access a copy of the master image.
fo
rr
#FullCloneVMs: The number of VMs that will be Full Clones (and reserve 100% of the image space)
(#FullCloneVMs * 100%ImageSize)
#InUseThinCloneVMs: The number of VMs that are thin provisioned (typically 15% writes to diffdisk
(#InUseThinCloneVMs * 15%ImageSize)
es
between reboots)
al
e
(#TotalVMs * 0.016 GB) #TotalVMs: Each VM will be provisioned an identity disk of 16 MBs.
or
di
#OnVMWareVMs: The number of running VMWare hosted VMs.
s
(#OnVMWareVMs * #VMWareSwapFile *2)
#VMWareSwapFile: This file is equals allocated memory minus reserved memory.
tri
b ut
io
n
Key Notes:
• Storage must be properly planned out in any MCS deployment by considering all the consumers of the available storage
solution. It is best to add a buffer to any calculations you have made since it is much easier to provision the extra storage
up front than it is to repair a site that has been affected by storage related issues.
• A sample equation that can be used to calculate the storage needed for an MCS deployment of Single-Session OS VDA
machines providing random, non-persistent desktops is shown above.
• The items in the blue section are used to calculate the storage required for the consolidated image:

• 1: The master image needs to be copied into every defined storage location in Citrix Studio that will host
MCS-provisioned non-persistent machines.
• 2: For each image update, both the new and existing version of the image needs to be available until all the
MCS-provisioned machines have rebooted and started using the new version. However, if multiple image
updates are performed before the machines can reboot (for example, due to a critical patch that needs to
be applied), more concurrent versions of the image will exist until the reboots can be performed.
• After an image update is initiated, MCS checks every 8 hours to verify whether all the machines have
N
successfully booted with the new version of the image before deleting the old version. In the equation, we
ot
are adding 12 hours to the time period considered because we do not know precisely when MCS last
fo
checked the update status since the machines all rebooted.
• 3: When calculating the master image size, if thin-provisioning is being used, use the actual size, not the
rr
allocated size, unless you expect the image size to grow significantly.
es
• 4: Typically, machines sharing the same master image would be placed into the same machine catalog
al
unless limited by the amount of storage available for each catalog. In this case, multiple machine catalogs
would be created, each using a different datastore or LUN, and a copy of the master image would be
e
placed in each location.
or
• The items in the green section are used to calculate the storage required for the differencing disks:
di
• 5: When calculating the total storage used by differencing disks, the equation uses maximum concurrent
users, not total number of machines. This is based on the assumption that random, non-persistent desktops
s tri
typically reboot after a user logs off, wiping away the differencing disk and returning the available storage.
b
• However, some organizations may want to size conservatively and use total number of VMs instead of max
ut
concurrent users.
io
• The items in the orange section are used to calculate the storage required for the identity disks:
• 6: Each MCS machine requires an identity disk of 16 MBs to be present for the lifetime of the VM.
n
• The items in the red section are only applicable to a vSphere deployment:
• 7: In vSphere, each VM that is powered on creates a memory swap files, called a .vswp file, that can be
used instead of physical host memory when the latter is overcommitted. The size of this file can be modified
by increasing the reserved memory of the VM, because the swap file size is calculated by subtracting
reserved memory from allocated memory.

• Note that the swap file is only used if the physical host runs out of available memory, and because it is file-
based, VM performance will be impacted. The file is deleted when a VM is powered off, so in this equation
the number is multiplied by maximum concurrent users, but total VMs can be used instead for a more
conservative estimate.
• Create a Machine Catalog (See MCS storage considerations section): https://docs.citrix.com/en-us/citrix-
N
virtual-apps-desktops/1912-ltsr/install-configure/machine-catalogs-create.html
ot
• Machine Creation Services (MCS) Storage Considerations: https://support.citrix.com/article/CTX218082
fo
rr
es
al
e
or
di
s tri
but
io
n

Machine Creation Services - Key Design Considerations
Read and Write Cache Design 1
Hypervisor
• Citrix Hypervisor IntelliCache and RAM-
Read Cache
N
based read cache are separate, but (Hypervisor dependent)
Virtual Virtual Virtual
1
ot
complementary, features. Machine Machine Machine
Write Cache Write Cache Write Cache
• MCS on Citrix Virtual Apps and Desktops
fo
RAM
can utilize virtual machine memory as a
rr
write cache.
es
• Other hypervisors also have read caching
al
features that can be used.
e
Storage Storage
or
Repository 1 Repository 2
di
1 1
s tri
Master
Identity Disk Differencing Disk
Image
b ut
Identity Disk Differencing Disk
io
n
Key Notes:
• Citrix Hypervisor offers two levels of read caching for non-persistent MCS machines. When new reads of the master
image occur from a storage repository, they are initially stored in the IntelliCache, which is on storage local to the
hypervisor host, as well as the in-memory read cache.
• IntelliCache can also cache writes to a differencing disk located in shared storage, reducing subsequent read IOPS. If disk
data is stored in IntelliCache only, the in-memory cache will store it the next time it is requested.
• We can configure a Machine Catalog to use RAM to optimize the temporary writes (similar to the Citrix Provisioning option

“write cache in memory with offload to disk”). This feature is available for all thin cloned MCS machines,
regardless of whether they are hosted on Citrix Hypervisor, Hyper-V or vSphere.
• Collectively, these caching options can reduce the storage burden of an MCS deployment, and makes it more
viable to use in a variety of environments.
• IntelliCache: https://docs.citrix.com/en-us/citrix-hypervisor/storage/intellicache.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Azure Performance
Old Power Action Time New Power Action Time
N
Catalog (1,000 VMs) Power Action
(minutes) (minutes)
ot
Dedicated On 45 10
fo
rr
Dedicated Off 85 12
es
al
Pooled On 50 12
e
or
Pooled Off 110 15
di
s tri
but
io
n
Key Notes:
• Running Machine Creation Services in an Azure Cloud deployment has greatly improved the administrative experience
providing more capabilities and faster performance.
• Azure limits have recently been expanded to support a higher number of API calls which has allowed Citrix to modify MCS
to use all available API request quota.
• The biggest change we’ve implemented is modifying MCS to use a reactive throttling approach when making cloud API
calls. Requests are made without limitation until Azure notifies Citrix that a request limit has been exceeded. The “quota

limit exceeded” message also includes the time period Microsoft requires to elapse before requests can be
successfully sent again. MCS will queue all requests of that type for the “silent” time period and will retry any
failed requests to resume normal operations. This optimizes our interactions with the cloud service APIs and
results in much faster operations when we stay under the threshold.
• During testing of 1,000 VMs in a dedicated and pooled catalog, the operation times were dramatically
improved and were consistent across different Azure regions (Note: these tests were against US-based Azure
regions).
N
• Pooled catalogs tend to take slightly longer than dedicated because MCS deletes the OS Disks of pooled VMs
ot
at stop time in order to refresh the VMs and creates the OS Disks / VMs at start time to maximize the savings
fo
when the VMs are not being utilized.
rr
es
• Improving Azure performance with Machine Creation Services:
al
https://www.citrix.com/blogs/2020/05/06/improving-azure-performance-with-machine-creation-services/
• Create and manage connections (see Configure Azure throttling): https://docs.citrix.com/en-us/citrix-virtual-
e
apps-desktops-service/install-configure/connections.html#edit-connection-settings
or
di
s tri
b ut
io
n

App Layering
N
• Allows applications to be managed independently • Does not provide isolation between applications
ot
from the underlying OS image. on the same operating system.
fo
• Reduces time spent on application and image • Elastic layers will add to logon times.
rr
management.
es
• Nearly 100% application compatibility when using
layered images.
al
e
or
di
s tri
but
io
n
Key Notes:
• Citrix App Layering is a Windows Operating System and application management solution designed for on premise private
clouds and public clouds. Citrix App Layering's underlying technology, called layering, enables all components of a virtual
machine to be independently assigned, patched, and updated on individual layers.
• App Layering can be used for image consolidation, but the primary goal is to reduce the hours spent on image
management, not necessarily the number of images. This can be achieved if multiple layered images are sharing common
layers.

• Unlike App-V, App Layering does not provide isolation between applications. On the other hand, this allows
individual apps to be placed in their own application layer, between all the layers are blended together when a
layered image is created.
• Citrix App Layering: https://docs.citrix.com/en-us/tech-zone/design/reference-architectures/app-layering.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

App Layering
Key Design Considerations
App Layering Appliance Network Share (elastic images)
N
• Considered an image build tool and is not • Strongly recommended to have High Availability
ot
needed to support an Citrix Virtual Apps and implemented for the share; otherwise elastic
Desktops Site. images will not be available during runtime.
fo
rr
• Pre-built appliance assigned 4 vCPUs, 8 GB of • Share must be configured using Server Message
RAM and 350–500 GB storage space. Block (SMB) protocol.
es
• Different connectors must be used to integrate • Appropriate user permissions need to be
al
with different resource types. configured on the (SMB) share.
e
or
• Standalone appliance:
• Not currently available in a clustered/HA setup.
di
• Recommended to regularly backup the appliance so it can
be recovered in a Disaster Recovery scenario.
s
tri
but
io
n
Key Notes:
• The App Layering appliance appliance is available for Citrix Hypervisor, Hyper-V, vSphere, Azure, and Acropolis and is
responsible for all management activities. The database and other configuration information, including master copies of all
layers, are all contained on this appliance.
• The App Layering appliance is built on CentOS, configured with 4 vCPUs and 8 GB of RAM. These settings are not to be
changed as the appliance is designed to work in that configuration.
• The appliance is built with two disks. The first disk is a 30 GB boot disk for the operating system. The second disk is the

300 GB layer repository. This disk can be extended or expanded as necessary if more space is required.
• The network share stores layers that are delivered as Elastic Layers, including a metadata file containing all
relevant user/machine mapping information (and is also used as a connector). New file shares must be
configured with SMB.
• Note that while DFS-R is a possible option for creating a highly available file share for elastic layers, if
Windows file servers will be used, clustering is preferred due to failover behavior.
• Cloud Connectors are required for the Citrix Cloud-hosted management console to communicate with the ELM
N
appliance.
ot
fo
• Enterprise Architect TechTalk: Citrix App Layering FAQ: https://www.citrix.com/blogs/2017/08/07/enterprise-
rr
architect-techtalk-citrix-app-layering-faq/
es
• System Requirements: https://docs.citrix.com/en-us/citrix-app-layering/4/system-requirements.html
al
• Citrix App Layering – Tips and Tricks: https://www.citrix.com/blogs/2017/09/19/citrix-app-layering-tips-and-
tricks/
e
• 4.x Layering Best Practices: https://support.citrix.com/article/CTX225952
or
• Storage: https://docs.citrix.com/en-us/citrix-app-layering/4/manage/storage.html
di
• Connector configurations: https://docs.citrix.com/en-us/citrix-app-layering/4/connect.html
s tri
b ut
io
n

App Layering
Key Design Considerations - Layers
OS Layer:
N
• Keep basic (base OS, OS updates, frameworks)
• Hypervisor tools (if only a primary hypervisor is used in the environment, or a sole platform).
ot
• Do not join to a domain.
fo
• If needs to be updated, the platform layer must be updated too.
rr
Platform Layer:
es
• Hypervisor tools (if multiple hypervisor platforms are being used).
• VDA machine software and Citrix Provisioning target device software.
al
• Join a domain when creating this layer.
e
Application Layer:
or
• If possible, keep each application in a separate layer to maximize layered image flexibility.
• Application layers are OS-specific and cannot be used cross platform.
di
• Antivirus should be installed on an App layer.
s tri
b ut
io
n
Key Notes:
• A layer is a virtual disk that contains the software for your operating system, platform tools, apps, or the user’s data and
settings.
• There are three different kinds of layers that can be included in the image templates and layered images – OS, Platform
and Application Layer.
• The OS Layer is where you install the Windows Operating System and can be reused with other compatible platform and
application layers. This layer is not joined to a Domain and if the image needs to be updated at any point, the platform

layer must also be updated.
• The Platform Layer is where you install and configure software for specific on-premises or cloud environments
including Hypervisor tools, Virtual Delivery Agent and Citrix Provisioning software. This layer should be joined
to a domain.
• The Application Layer is where you install any required applications. It is leading practice to install one app per
layer; however, you can include more. Application layers are OS specific and cannot be used across multiple
platforms.
N
ot
fo
• Layer: https://docs.citrix.com/en-us/citrix-app-layering/4/layer.html
• Create the OS layer: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/create-os-layer.html
rr
• Create the Platform layer: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/create-platform-layer.html
es
• Create or clone an app layer: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/create-app-layer.html
al
e
or
di
s tri
b ut
io
n

App Layering
Key Design Considerations - Layers
Elastic Layer:
N
• App layers that are assigned to specific users and delivered when the users login.
• Not included in the base image.
ot
• Not all applications can be installed on an Elastic layer.
fo
User Layer:
rr
• Keep persistent user data, settings, and installed applications in non-perisistent VDI environments.
es
• Three types of user layers:
• Full
al
• Office 365
• Session Office 365
e
or
di
s tri
b ut
io
n
Key Notes:
• There are two different kinds of layers that can be enabled on layered images: Elastic Layers and User Layers.
• Elastic Layers are app layers that are assigned to specific users and delivered when the users login. An elastic layer is not
included in the base image, but is delivered on it. Elastic apps appear on the user’s desktop. Not all applications can be
installed on an Elastic Layer.
• Enabling user layers on a layered image allow you to persist a user’s data and settings, and any applications that they
install themselves in non-persistent VDI environments. When enabled, a user layer is created for each user the first time

they log on to an image. There are three types of user layers:
• Full – All of a user’s data, settings, and locally installed apps are stored on their user layer.
• Office 365 – Only the user’s Outlook data and settings are stored on their user layer for single-session
OS VDAs.
• Session Office 365 – Only the user’s Outlook data and settings are stored on their user layer for multi-
session OS VDAs.
N
ot
• Deploy App layers as elastic layers: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/assign-elastic-
fo
layers.html
• App Layering Recipes: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/app-layering-recipes.html
rr
• Deploy user layers: https://docs.citrix.com/en-us/citrix-app-layering/4/layer/enable-user-layers.html
es
al
e
or
di
s tri
b ut
io
n

Compare Image Management Methods
Image
Ease of Image
Management Scalability Resource Delivery Options Licensing Ease of Deployment
Maintenance
Method
• Dependent on • Able to deliver images to • Available with Citrix • Requires some • Enables rapid image
Citrix physical or virtual endpoints. Virtual Apps & additional design and updates and rollbacks.
Citrix Provisioning Provisioning Desktops Advanced deployment effort.
N
Server sizing and and Premium.
ot
network.
• Dependent on • Able to deliver images to on- • Available with all • Built into Delivery • Lacks built-in
fo
Machine Creation storage premises or cloud licensing types. Controllers, but versioning, updates
Services availability and deployments, but not physical storage requirements can take longer for
rr
performance. endpoints. should be addressed. larger environments.
es
• Dependent on • Supported for on-premises or • Available with all • Some additional setup • Eases image and
image cloud deployments. Not licensing types, but and configuration application
al
deployment supported for physical advanced features required. maintenance
App Layering method’s endpoints. come with Premium. regardless of image
e
scalability. • User layers will enable deployment method,
dedicated desktop model for especially in larger
or
any provisioning method. environments.
di
• Only if using 3rd • Uses native functionality of • N/A; licensing may be • Varies based on image • Varies based on
party tools to resource platform. required for 3rd party management tools image management
s
Manual Provisioning assist. image management used. tools used.
tri
products
b ut
io
n
Key Notes:
• Both Citrix Provisioning and MCS can scale, as long as you add more storage clusters or more servers. But one thing you
should keep in mind is that the user experience, or how well the target device performs, is based on different factors:
• Citrix Provisioning links user experience to the stability and performance of your network.
• Machine Creation Services links user experience to the stability and performance of your storage.
• Resource delivery restrictions could potentially be the deciding factor for which image management tools are used. MCS
will be the leading option for cloud deployments, while Citrix Provisioning will take the lead in situations where the image

should be streamed to a physical target, or a mixture of physical and virtual targets.
• Note that App Layering is also not supported for physical endpoints. However, with the introduction of
persistent User Layers (currently a Lab feature as of version 4.5), you will be able to provide persistent
desktops to users with either MCS or Citrix Provisioning.
• Licensing could also be a deciding factor. For example, to get the User Layers mentioned in the previous
point, you would need Premium licensing because it is considered a premium feature of App Layering. On the
other hand, MCS is available with all licensing types, making it available to a wider range of organizations.
N
• Deployment has become easier over time as the products have matured, although MCS has an edge due to
ot
being built into the Delivery Controllers. On the other hand, Citrix Provisioning provides a versioning feature
fo
and it is faster to push out and roll back updates as needed. Overall, App Layering can ease image and
application management for either method, since individual layers can be updated once and then included in
rr
multiple layered images.
es
• Manual provisioning is hard to compare as a method, because it can be combined with a number of 3rd party
al
image management tools that could change the considerations in each category. Using manual provisioning
without any additional tools will not be scalable, and presents additional challenges in terms of maintaining
e
consistent machines over time and deploying updates.
or
• However, 3rd party tools will also have licensing, deployment, and maintenance considerations that need to be
di
taken into account as well. Regardless, their lack of integration with Citrix Virtual Apps and Desktops will make
manual provisioning less attractive as an image management solution unless a 3rd party tool is already being
s tri
widely and effectively used in other parts of the organization.
b ut
io
n

Lesson Review
You are designing a Citrix Virtual Apps and

Desktops environment for an organization. Based
N
on the assessment and early stages of the design,
ot
they require the following:
fo
• Hybrid cloud deployment for 3,000 total users.
rr
• Mixture of non-persistent and persistent virtual
es
desktops.
al
• 50 applications identified for inclusion in environment;
e
some are only needed for a handful of users.
or
What would you recommend as their image
management solution? Would you ask any follow-
di
up questions?
s
tri
utb
io
n

Lesson Review
N
ot
fo
Based on the requirements, using Machine Creation
rr
Services with App Layering seems like a good fit.
es
However, some follow-up questions could be asked to
al
verify this, such as:
e
• What license edition will be available for the environment?
or
• What storage is available for the on-premises environment?
di
• Are versioning or rapid updates/rollbacks required?
s
tri
but
io
n
Key Notes:
• In a hybrid environment, it is possible to use different image management methods for the on-premises and cloud portions
of the environment. However, this will increase the complexity of the environment, and should only be considered if there a
strong requirement for some of the features of Citrix Provisioning for the on-premises portion of the environment, such as
streaming to physical devices or rapid update/rollback speed. Otherwise, using MCS for the entire environment would
ease management because the same master image(s) could be used throughout the environment.

Exercise 4-1: Conduct an Image
Layer Assessment
Your team completed the Image Layer design based
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 4-1A:
Task:
N
ot
fo
rr
met:
es
• AD / DHCP
• SQL
al
• Citrix Provisioning
e
or
di
s
tri
b
ut
io
n

Exercise 4-1A

meets requirements.
N
• No single point of failure.
ot
• Principle of least security privilege followed.
• Provisioning infrastructure and provisioned virtual
fo
machines optimized for performance.
rr
• IOPS kept to a minimum to reduce storage
overhead.
es
al
e
or
di
s
tri
b
ut
io
n

Task:
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Task:
N
ot
• AD / DHCP
• SQL
fo
• Citrix Provisioning
rr
es
al
e
or
di
s
tri
b
ut
io
n

General

Yes/No Yes/No
Image-1 High Standardize on Microsoft Windows Server 2016. Yes Yes
N
No No
ot
Single TFTP server specified for Single TFTP server specified for
No single points of failure. Provisioning infrastructure can
Image-2 High option 66. Offline database support option 66. Offline database support
survive complete SQL Server outage.
fo
not designed. vDisk load balancing not designed. vDisk load balancing
not designed. not designed.
rr
Image-3 Medium Management overhead kept to a minimum. Yes Yes
es
No No
Image-4 High Principle of least security privilege followed.
al
Helpdesk users are Farm Admins Helpdesk users are Farm Admins
e
No
No
Insufficient RAM assigned to
or
Provisioning infrastructure and provisioned virtual machines Provisioning server. Antivirus
Image-5 Medium Provisioning server. Antivirus
optimized for performance. optimizations not configured for
optimizations not applied to target
target device. Write cache on
di
device. Write cache on server.
server.
s
Help Desk user group able to power manage provisioned
tri
Image-6 Medium Yes Yes
machines.
b
Provisioned machines automatically integrated into Citrix Virtual
ut
Image-7 Medium Yes Yes
© 2021 Citrix Authorized Content Desktops.
io
n

Image Management

Yes/No Yes/No
Image-8 High Changes to provisioned machines reset following reboot. Yes Yes
N
No
No
ot
fo
Image-9 High IOPS kept to a minimum to reduce storage overhead. Provisioning server. Antivirus
Provisioning server. Antivirus
optimizations not configured for
optimizations not applied to target
rr
target device. Write cache on
device. Write cache on server.
server.
es
Image-10 High All provisioned machines hosted on Hyper-V. Yes Yes
al
e
or
di
s
tri
but
io
n

Security

Yes/No Yes/No
No
Image-11 High Event logs of provisioned machines retained between reboots. Yes
N
No extra disk added to Provisioning
target devices
ot
No
Antivirus software deployed on all image management
fo
Image-12 Low Yes Antivirus optimizations not applied to
infrastructure and provisioned machines.
target device. Defender is not
rr
configured for infrastructure servers.
es
al
e
or
di
s tri
b
ut
io
n

Citrix Provisioning Server
Number of PVS Farms 1 One Citrix Virtual Apps and Desktops Site.
Farm Name WorkspaceLab Corporate naming standard.
N
Sites per Farm 1 One site in New York City.
ot
Site Name(s) NYC Corporate naming standard.
fo
2 Provisioning Servers:
rr
Design Requirement Image-2: No single points of failure. Provisioning infrastructure can
Number of Provisioning Servers
NYC-PVS-001 survive complete SQL Server outage.
es
NYC-PVS-002
al
Provisioning Server Operating • Workspace Lab standard.
Microsoft Windows Server 2016
System • Design requirement Image-1: Standardize on Microsoft Windows Server 2016.
e
or
Provisioning Server Version 1906 Workspace Lab standard.
Provisioning SQL Server
• Highly available SQL Server (mirror) dedicated to support Citrix infrastructure.
di
• Note: SQL Mirroring is not currently implemented in the environment. Workspace Lab
NYC-SQL-001.workspacelab.com
s
should ensure that a redundant SQL server is added, and that mirroring is configured
NYC-SQL-002.workspacelab.com
tri
prior to moving the environment to production
• Design Requirement Image-2: No single points of failure. Provisioning infrastructure
Enable offline database support
b
can survive complete SQL Server outage.
ut
• Design Verification: SQL server is not redundant.
io
n

Citrix Provisioning Server (Continued)
CPU Allocation 4
1GB + (1XA vDisk * 1GB) + (6 XD vDisk x 500MB).
N
ot
(2GB + (1 * 4GB) + (1 * 2GB)) * 1.15 = 9.2GB
5GB
RAM Allocation
10GB • Design Requirement Image-5: Provisioning infrastructure and provisioned virtual
fo
rr
• Note: Provisioning Server in Design Verification environment configured with 4GB due
to limited resources.
es
• No requirement to separate provisioning traffic.
Network Configuration 1 virtual network (10Gbps)
• Design Requirement Image-3: Management overhead kept to a minimum.
al
Exclude:
e
• Streamprocess.exe
or
• Streamservice.exe
• Citrix recommended exclusions. CTX124185.
• Soapserver.exe
• vdiskdif.vhdx and .vdiskcache will not be excluded as they will be stored on the vDisk
• Inventory.exe
di
Store and not on the Provisioning server.
• MgmtDaemon.exe
Antivirus • Antivirus configuration updated using Adaware console within each master image.
s
• Notifier.exe
There is no central management console.
tri
• BNTFTP.exe
• Design Requirement Image-5: Provisioning infrastructure and provisioned virtual
• PVSTB.exe
b
• BNPXE.exe
ut
• BNAbsService.exe
© 2021 Citrix Authorized Content • CdfSvc.exe
io
n

• Device operators can view target device properties (read-only), boot or

Farm Administrators:
shut down target devices, and send messages to target devices within a
• Help Desk
device collection to which they have privileges.
• Administrators
N
Citrix Provisioning Administrators • Design Requirement Image-4: Principle of least security privilege
followed.
ot
Device Operator:
• Design Requirement Image-6: Design Requirement Image-6: Help Desk
• Help Desk
user group able to power manage provisioned machines.
fo
NYC-SRV-PVS-MST
rr
Device Collection Names • Corporate naming standard.
NYC-SRV-PVS-APP
es
NYC-SRV-MST
Image Names • Corporate naming standard.
NYC-SRV-APP
al
Image Load Balancing All production images should be configured to • Design Requirement Image-2: No single points of failure. Provisioning
e
stream from more than 1 PVS server. infrastructure can survive complete SQL Server outage.
or
• Agreed with business.
Local stores:
• 2 master images + 2 test images + 2 production images + 2 rollback
di
• NYC-PVS-001: E:\LocalStorePVS-001
images = 8 images
vDisk Store Storage • NYC-PVS-002: E:\LocalStorePVS-002
s
• Dynamic disks = 40GB estimate
tri
• (8 images * 40GB) + 180GB buffer = 500GB
500GB of storage
• Design Verification: vDisk store will not have full 500GB available.
b ut
io
n

• Redundancy achieved through multiple local Stores.

• Design Requirement Image-2: No single points of failure. Provisioning
vDisk Redundancy vDisk located on multiple local Stores. infrastructure can survive complete SQL Server outage.
N
• Design Requirement Image-3: Management overhead kept to a
minimum.
ot
vDisk Replication Strategy File copy between Stores. • vDisks will be copied between local Stores.
fo
rr
DHCP with options:
• 11: Hyper-V • Bootstrap delivered using DHCP options. No requirement for PXE helper
es
• 66: NYC-PVS-001 or BDM file. Using UEFI boot.
Bootstrap Delivery Method
• 66: NYC-NLB-FTP.workspacelab.com • Design Requirement Image-3: Management overhead kept to a
al
(192.168.10.53) minimum.
• 67: pvsnbpx64.efi
e
• Ensure TFTP service is not a single point of failure.
or
TFTP load balanced Citrix Gateway vServer - NYC-
Bootstrap Redundancy • Design Requirement Image-2: No single points of failure. Provisioning
NLB-FTP
infrastructure can survive complete SQL Server outage.
di
• Provisioned machines integrated with Citrix Virtual Desktops.
s
Target Device Provisioning
Citrix Virtual Desktops Setup Wizard • Design Requirement Image-7: Provisioned machines automatically
tri
Method
integrated into Citrix Virtual Desktops.
b ut
io
n

Target Device
• Scan on read/write
• Recommended configuration for Citrix Provisioning target devices.
CVhdBusP6.sys not required for Citrix Provisioning Build 1906.
Exclude
N
• Antivirus configuration updated using Windows Defender console within
• Bndevice.exe
each master image. There is no central management console.
ot
Antivirus • Bnistack6.sys
• Design Requirements Image-5: Provisioning infrastructure and
• CNicTeam.sys
provisioned virtual machines optimized for performance.
• CFsDep2.sys
fo
• Design Requirement Image-12: Antivirus software deployed on all image
• CVhdMp.sys
management infrastructure and provisioned machines.
rr
• vdiskdif.vhdx
es
• Caching in RAM will improve performance and reduce IOPS. Write cache
will overflow to disk when RAM is exhausted.
Cache on a server
al
• Design Requirement Image-5: Provisioning infrastructure and provisioned
Cache in device RAM with overflow on hard disk
virtual machines optimized for performance.
Write Cache
e
• Design Requirement Image-9: IOPS kept to a minimum to reduce storage
Server: 2GB
overhead.
or
Desktop: 256MB
• Design Verification: Maximum RAM size will be limited to 64GB due to
limited resources.
di
s
Design Requirement Image-11: Event logs of provisioned machines retained
Target Device Redirection Event Logs redirected to write cache.
tri
between reboots.
b ut
io
n

Key Takeaways
• Assign user groups to FlexCast models in order to

determine which resource types will meet user
requirements.
• Use recommended sizing baselines to provide quick
N
scalability estimates at the start of a project, then
ot
use scalability testing and/or monitoring to validate
the projections.
fo
• Secure the Virtual Delivery Agent Machines to
rr
mitigate the risk of a breakout. Antivirus
es
configuration and updates should be part of the
al
Virtual Delivery Agent maintenance schedule and
deployment.
e
or
• Citrix Provisioning, Machine Creation Services, and
App Layering all have benefits and considerations
di
as image management solutions.
s tri
b ut
io
n
Key Notes:
• Assign user groups to FlexCast models in order to determine which resource types will meet user requirements.
• Use recommended sizing baselines to provide quick scalability estimates at the start of a project, then use scalability
testing and/or monitoring to validate the projections.
• Secure the Virtual Delivery Agent Machines to mitigate the risk of a breakout. Antivirus configuration and updates
should be part of the Virtual Delivery Agent maintenance schedule and deployment.

• Citrix Provisioning, Machine Creation Services, and App Layering all have benefits and considerations as
image management solutions.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
Resource Layer - Applications and
fo
Personalization
rr
es
al
e
Module 5
or
di
s tri
b ut
io
n
Key Notes:
• Welcome to the Resource Layer – Applications and Personalization module. This is the fifth module in the Citrix Virtual
Apps and Desktops 7 Assessment, Design and Advanced Configuration course.
• Throughout this module, we will investigate the differences between the available application delivery options, identify the
leading practices of configuring profile and folder redirection, define policies that can help optimize the user experience as
well as highlight the options for enabling users to print within their sessions.

Learning Objectives
• Determine the appropriate application delivery
N
options.
ot
• Determine the appropriate profile strategy to use.
fo
• Examine how policies can be deployed to optimize
rr
the user experience.
es
• Assess the printing deployment methods and
implement Citrix printing leading practices.
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the appropriate application delivery options.
• Determine the appropriate profile strategy to use.
• Examine how policies can be deployed to optimize the user experience.
• Assess the printing deployment methods and implement Citrix printing leading practices.

N
ot
Application Delivery
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the appropriate delivery options for
N
application deployment based on the analysis of the
ot
given environment.
fo
rr
es
al
e
or
di
stri
b ut
io
n
Key Notes:
• Determine the appropriate delivery options for application deployment based on the analysis of the given
environment.

Application Delivery Options
Overview
Installed App Streamed App Layered App Hosted Local App SaaS / Other
Windows App
N
ot
fo
File
Server Multi-Session
OS VDA
rr
es
al
e
Single-Session
or
Single-Session Single-Session Single-Session Single-Session Single-Session OS VDA
OS VDA OS VDA OS VDA OS VDA OS VDA
di
stri
b
Endpoint Endpoint Endpoint Endpoint Endpoint
ut
io
n
Key Notes:
• It is unlikely that a single application delivery method will meet all the requirements of the various applications that must be
included in an environment. Based on the outcome of the application categorization assessment process and the overall
image management strategy (installed images, scripted images and layered images), several application delivery methods
can be considered.
• Installed App - This application is part of the base desktop image. The install process involves dll, exe, and other files
copied to the image drive as well as registry modifications.

• Streamed App (App-V) - The application is profiled and delivered to the desktops across the network on-
demand. Application files and registry settings placed in a container on the virtual desktop and isolated from
the base operating system and each other, which helps to address compatibility issues.
• Citrix App Layering - As mentioned in the previous module, each Layer contains a single application, agent or
operating system. Layering simplifies ongoing maintenance, as an OS, agent or application exists in a single
layer; update the layer and all deployed images containing that layer are updated. A Citrix Virtual Apps and
Desktops user can also dynamically receive an elastic app layer based at logon.
N
• Hosted Windows App - An application installed on a Multi-Session OS VDA host and deployed as an
ot
application and not a desktop. A user accesses the hosted Windows app seamlessly from the VDI desktop or
fo
endpoint device, hiding the fact that the app is executing remotely.
• Local App - An application deployed on the endpoint device. The application interface appears within the
rr
user’s virtual desktop session even though it executes on the endpoint.
es
• SaaS / Other - This category includes web applications, mobile applications and other applications not
al
deployed using the other methods. Although these may not involve the Citrix Virtual Apps and Desktops
environment, they could be accessed within a virtual desktop using a web browser or other access point.
e
or
di
• Delivery Methods: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/technical-
overview/delivery-methods.html
s tri
b ut
io
n

App Delivery
Options
Installed Apps
• Deploying and maintaining applications within the desktop master image
N
requires no additional tools, technologies or knowledge.
ot
• Considerations:
• Automate application deployment with SCCM / Altiris.
fo
• Hosting many applications in a single image leads to image complexity.
rr
• Provisioning different images for different user groups leads to administrative
es
overhead.
• Storage deduplication to reduce storage cost.
al
• Deploy applications that all users need within image and deploy special
e
Single-Session OS applications using other technologies.
VDA
or
di
s tri
b ut
io
n
Key Notes:
• Within a Citrix Virtual Apps and Desktops environment, installed applications are typically accessed from a published
Single-Session OS or Multi-Session OS desktop.
• Because this method is relatively easy to use, it is recommended for common apps that will be used by a majority of users
in an organization, as well as management apps that will be leveraged, such as antivirus or monitoring agents.
• Using this method for departmental or individual apps can lead to image sprawl or application compatibility issues if too
many apps are installed on the same image. Consider using a different application delivery method for these apps.

App Delivery
Options
Streamed Apps
• Utilizing App-V to stream applications can reduce the amount of unique
N
images and maintenance efforts.
ot
• Considerations:
• App-V infrastructure and App-V knowledge is required for this method.
fo
• Include corporate-wide applications in image.
rr
File Server
• Helpful when hosting multiple versions of the same application or facing
es
application compatibility issues.
• Complex applications may not be candidates for App-V.
al
• App-V isolation may interfere with inter-app-communication from OS layer to
e
App-V layer.
or
di
s tri
b ut
io
n
Key Notes:
• App-V is a Microsoft product, and can be used independently of the Citrix Virtual Apps and Desktops infrastructure;
however, it can be integrated with Citrix Virtual Apps and Desktops so that users can access packaged App-V apps from
the same place as other published resources.
• Within a Citrix Virtual Apps and Desktops environment, App-V streamed apps can be deployed to a published Multi-
Session OS or Single-Session OS virtual desktop. They can also be streamed to a Multi-Session OS Virtual Delivery
Agent, which in turn presents them as seamless published apps to the end user.

• App-V is recommended for departmental apps, particularly when a department or group requires a different
version of an application that cannot normally co-exist on the same image as another version.
• For example, the accounting department may require specific Office 2010 add-ins, but the rest of the
organization uses Office 2016.
• App-V can also be used for common and user apps, but these can typically be delivered in a more efficient
way that does not require the App-V infrastructure.
• Most management apps are not recommended for deployment using App-V. These applications often cannot
N
function as needed in an isolated App-V package without access to OS-level components.
ot
fo
• Using App-V with XenApp and XenDesktop: https://docs.citrix.com/en-us/xenapp-and-xendesktop/current-
rr
release/install-configure/appv.html
es
al
e
or
di
s tri
but
io
n

App Delivery
Options
Layered Apps
• App Layering can separate OS, Platform and Applications into individual
N
layers to reduce ongoing maintenance even further.
ot
• Considerations:
• To create a layered image (VM or vDisk) the OS, Platform, and App Layers are
fo
merged to one complete image.
rr
• CIFS file share is only needed if you are using elastic layers.
es
• Apps are not isolated – OS and Apps do not know they were layered.
• Apps with services and drivers work like they were installed natively.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• If layered images are used, all the application layers are included in the constructed image and can be included in any of
the FlexCast models.
• Application layering is compatible with most Windows applications and is a viable deployment method for any category of
application. The primary consideration is whether the application will be installed in the OS layer, the Platform layer, or an
individual Application layer.
• Common applications could be installed in the OS layer, or an individual App Layer.

• Departmental applications can be installed in an Application Layer.
• Management applications can be installed in an OS, Platform, or Application Layer depending on how
widespread they will be in the environment.
• Individual applications can be delivered as an Elastic Layer so that a separate Layered Image does not
have to be created (see the next slide for most on Elastic Layers).
• Keep in mind that App Layering is currently available for supported Windows operating systems only.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

App Delivery
Options
Layered Apps - Continued
with Elastic Layering
• Elastic Layering provides the ability for layers to be attached at logon to
N
non-persistent VMs.
ot
• Considerations:
• Use for Apps that only some users need, but others do not.
fo
• Does not work with apps that include drivers or services.
rr
File Server
• Use only with non-persistent VMs.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Elastic layers can be assigned to individual users or user groups and can be inserted during logon to a published Multi-
Session OS or Single-Session OS virtual desktop.
• If all the users accessing a particular image need an application, it can be included in an App layer. However, for special
cases where a small subset of users need a particular app, it makes more sense to use an Elastic layer so only those
users can access the app.
• For example, all users need to use Microsoft Office, which is in an App layer that is included in the layered image.

Only managers need access to Microsoft Project, so it is inserted as an Elastic layer when anyone from
the Managers group accesses the image.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

App Delivery
Options
Layered Apps - Continued
with User Layers
• User Layer persists each user’s profile settings, user’s data, and user-
N
installed applications in a non-persistent VDI environment.
ot
• Considerations:
• All Windows updates must be disabled on the User layer.
fo
• Citrix Profile Management disables Store add-ins.
rr
File Server
• GPO-installed printers are supported for users on non-persistent Windows 10
es
desktops.
• With VMware Horizon View, you must configure it to refresh at logoff with any
al
non-persistent desktops.
e
• Not all applications are supported:
• Enterprise applications
or
• Applications with drivers that user the driver store
• Applications that modify the network stack or hardware
di
• Applications that have boot level drivers
s
• Applications that require you to add a local user or group
tri
b ut
io
n
Key Notes:
• Substantially Improves end-user login time performance.
• User Layers persist each user’s profile settings, user’s data and user-installed applications in a non-persistent VDI
environment.
• All desktop settings, user customizations, and other changes are stored in a writable virtual disk that is attached to the
virtual machine when the end-user logs in.
• With User Layer, IT administrators can provide a fully persistent environment to end users while utilizing floating pools,

providing cost savings.
• Any changes that a user can make including profile settings, things like Office plugins, and other user-installed
applications are all captured and maintained.
• The following applications are not supported on the User layer:
• Enterprise applications: Enterprise applications, such as MS Office and Visual Studio, must be installed
in app layers.
• Applications with drivers that use the driver store. Example: a printer driver.
N
• Applications that modify the network stack or hardware. Example: a VPN client.
ot
• Applications that have boot level drivers. Example: a virus scanner
fo
• Applications that require you to add a local user or group
rr
es
• Deploy user layers (see Applications that are not supported on a user layer): https://docs.citrix.com/en-
al
us/citrix-app-layering/4/layer/enable-user-layers.html
e
or
di
s tri
b ut
io
n

App Delivery
Options
Hosted Windows Apps
• Delivering seamless application sessions to end users is the oldest and
N
one of the most widespread methods of delivering applications via Citrix
ot
Virtual Apps and Desktops.
• Considerations:
fo
• Using this method does not solve complexity, it just moves it elsewhere.
rr
• Inter-app communication between local and hosted apps not available.
Multi-Session OS
es
• Double-hop HDX scenarios
• Requires extra attention to profiles and folder redirection.
al
• Use default graphics settings (selective encoding) on the first and second hops.
e
• Consider the added latency between the first and second hops.
• Server-side (in session) rendering of audio and video content performs best in the first
or
hop.
• Pay special attention to which generic and optimized redirection modes is used to
di
support USB devices at each hop.
s tri
b ut
io
n
Key Notes:
• Hosted Windows Apps are installed on Multi-Session OS Virtual Delivery Agent machines and delivered as a seamless
application session to an endpoint device.
• A variation of this method is the VM-Hosted app. The primary difference is that the application is installed on a Single-
Session OS Virtual Delivery Agent machine, but it is still presented to the end user as a seamless application session.
Keep in mind that only one user can use a VM-Hosted app at a time; this FlexCast model is typically used for applications
that are not compatible with a Multi-Session OS or require dedicated resources at the VM level.

• Hosted Windows Apps are ideal for departmental apps that should be available to a subset of users within an
organization. However, it is a viable solution for any application that is compatible with a Multi-Session OS
environment.
• Delivering Hosted Windows Apps on a virtual desktop is typically referred to as an HDX double-hop scenario.
This method can help reduce the complexity of the VDI images.
• Citrix recommends that customers conduct thorough testing of required HDX capabilities to ensure user
experience and performance is adequate for a given environment configuration.
N
• Graphics - Use default graphics settings (selective encoding) on the first and second hops. In the
ot
case of HDX 3D Pro, Citrix highly recommends that all applications that require graphics acceleration
fo
run locally in the first hop with the appropriate GPU resources available to the VDA.
• Latency - End-to-end latency can impact the overall user experience. Consider the added latency
rr
between the first and second hops. This is especially important with redirection of hardware devices.
es
• Multimedia - Server-side (in session) rendering of audio and video content performs best in the first
al
hop. Video playback in the second hop requires decoding and re-encoding at the first hop, increasing
bandwidth and hardware resource utilization as a result. Audio and video content must be limited to
e
the first hop whenever possible.
or
• USB device redirection - HDX includes generic and optimized redirection modes to support a wide
di
array of USB device types. Pay special attention to the mode in use at each hop.
s tri
b
• Double-hop sessions (see Deployment considerations for HDX in double hop section):
ut
https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/technical-overview/double-hop.html
io
n

App Delivery
Options
Local Apps
• Some apps may need to run locally on the endpoint due to licensing or
N
peripheral constraints. These apps can be included in a virtual desktop
ot
session using the Local App Access feature.
• Considerations:
fo
• Local apps blends well with published apps.
rr
• In published desktop scenarios, use Local App Access to display local apps
es
within the full screen desktop session.
• Allow all local apps or a limited list by publishing the local apps in Studio.
al
• Supports URL redirection.
e
Endpoint • Requires both a Citrix Workspace app install parameter and a Group Policy
or
template to configure.
di
s tri
b ut
io
n
Key Notes:
• Local app access is intended for users accessing a published Single-Session OS or Multi-Session OS virtual desktop. It
enables them to use applications locally installed on the endpoint within the virtual desktop session so that their workflow
is not interrupted by minimizing and restoring the HDX session.
• Local app access makes the most sense for specialty applications that cannot be virtualized, would have large data
transfer requirements between the Virtual Delivery Agent and the endpoint, or video conferencing software.
• To provide access to only published applications:

• On the server where the Delivery Controller is installed, run regedit.exe.
• Navigate to HKLM\Software\Wow6432Node\Citrix\DesktopStudio.
• Add the REG_DWORD entry ClientHostedAppsEnabled with a value of 1. (A 0 value disables Local
App Access.)
• Restart the Delivery Controller server and then restart Studio.
• Publish Local App Access applications.
• Select Delivery Groups in the Studio navigation pane and then select the Applications tab.
N
• Select Create Local Access Application in the Actions pane.
ot
• Select the desktop Delivery Group.
fo
• Enter the full executable path of the application on the user's local machine.
• Indicate if the shortcut to the local application on the virtual desktop will be visible on the Start menu,
rr
the desktop, or both.
es
• Accept the default values on the Name page and then review the settings.
al
• Enable Local App Access and URL redirection when you install Citrix Workspace app for all users on a
machine. This action also registers the browser add-ons required for URL redirection.
e
• From the command prompt, run the command to install Citrix Workspace app with the following option:
or
• CitrixReceiver.exe /ALLOW_CLIENTHOSTEDAPPSURL=1
di
• CitrixReceiverWeb.exe /ALLOW_CLIENTHOSTEDAPPSURL=1
• Set the Allow local app access policy setting to Enabled. When this setting is enabled, the VDA allows
s tri
the client to decide whether administrator-published applications and Local App Access shortcuts are
b
enabled in the session. (When this setting is disabled, both administrator-published applications and
ut
Local App Access shortcuts do not work for the VDA.)
io
n
• Local App Access and URL redirection: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/general-content-redirection/laa-url-redirect.html

App Delivery
Options
SaaS / Web-based
• Software as a Service (SaaS) is a software distribution model to deliver
N
software remotely as a Web-based service. Commonly used SaaS apps
ot
include Salesforce, Workday, Concur, GoToMeeting, and so forth.
• Considerations:
fo
• SaaS apps can be accessed using Citrix Workspace using Citrix Gateway
rr
service.
es
• Can be configured using Template based configuration or Manual configuration
al
e
Single-Session OS VDA
or
di
s tri
b ut
io
n
Key Notes:
• Software as a Service (SaaS) is a software distribution model to deliver software remotely as a Web-based service.
Commonly used SaaS apps include Salesforce, Workday, Concur, GoToMeeting, and so forth.
• SaaS apps can be accessed using Citrix Workspace using Citrix Gateway service. The Citrix Gateway service coupled
with Citrix Workspace provides a unified user experience for the configured SaaS apps, configured virtual apps, or any
other workspace resources.
• SaaS apps delivery using Citrix Gateway service provides you an easy, secure, robust, and scalable solution to manage

the apps. SaaS apps delivered on the cloud has the following benefits:
• Simple configuration – Easy to operate, update, and consume.
• Single sign-on – Hassle free logon with Single sign-on.
• Standard template for different apps – Template based configuration of popular apps.
• Support for SAAS applications: https://docs.citrix.com/en-us/citrix-gateway-service/support-saas-apps.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Determining the Optimal Deployment Method for an App
Hosted
App Streamed
Installed App Layered App Windows Local App SAAS App
Category App
App
N
ot
Not
Common Recommended Viable Recommended Viable Recommended
Recommended
fo
rr
Not
es
Departmental Viable Recommended Recommended Recommended Recommended
Recommended
al
e
Not
User Viable Recommended Viable Recommended Recommended
or
Recommended
di
Not Not
s
Management Recommended Recommended Viable Recommended
Recommended Recommended
tri
but
io
n
Key Notes:
• The application category information gathered during the application assessment phase is key to complete this step.

General Application Concerns
• Understand how applications work to chose the right deployment method:
N
• Temporary data locations
• Application user configuration locations
ot
• Data in user profiles
fo
• Data in non-user areas
• Dependencies
rr
• Registry locations
es
• Lockdown restrictions
• Licensing restrictions
al
• Application behavior in read-only image
e
or
di
s tri
but
io
n
Key Notes:
• Integrating applications requires understanding compatibility and how the user/business requirements influences the
appropriate delivery method.
• Application compatibility can be achieved using a combination of manual, user testing or using an automated application
compatibility solution.
• Temporary data locations: Applications may store temporary files on the device which may consume unnecessary
disk space and affect logon performance.

• Application user configuration locations: Applications may reference a user configuration file for
applications preferences or user personalization, such as a Terminal Emulator.
• Data in user profiles: Applications may install data or cache files into the user profile, such as user
certificates or Outlook cache files.
• Data in non-user areas: Applications may require to access data stored on the device, such as local
database or machine certificates.
• Dependencies: Applications may need to interact with each other to provide the user with a seamless
N
experience., applications that present information in a PDF format will require a PDF viewer to be
ot
available.
fo
• Registry Locations: Applications which share registry hives may experience issues and cannot coexist on
the same device. Appropriate remediation can be taken or alternative delivery method selected,
rr
Streamed App (Microsoft App-V)
es
• Lockdown capabilities: Applications may need to be restricted to a device to comply with security
al
requirements.
• Licensing restrictions: Applications may need to be restricted to a device to comply with licensing
e
requirements.
or
• Application behavior in read-only image: Applications may download and install updates or plugins, these
di
updates will be lost when the device reboots.
s tri
but
io
n

Special App Focus
Outlook/Exchange
File Server
Multi-Session OS /
N
Endpoints
Single-Session OS VDA
ot
fo
rr
On-Prem
Exchange
es
al
e
or
di
Office 365
s tri
but
io
n
Key Notes:
• For deployments where the Exchange Servers and the VDA sit in the same datacenter, most customers would deploy
Outlook in online mode.
• When introducing Office365 or having VDAs deployed away from the Exchange server, consider deploying Outlook in
cached exchange mode.
• Recommendations:
• Download the Microsoft Office Administrative Template files for Office Customization (Group policy)

• Set the Sync Settings policy to limit synchronization to 3 months.
• Decide where in the profile path to store the Cached Exchange Mode file (.OST) file.
• Use the Microsoft Office group policy template to set the default location for OST files
• Utilize Citrix Profile Management
• Set a policy for Profile Management that excludes the folder containing the OST from being copied to the
Citrix Virtual Apps and Desktops hosts.
• Utilize at least SMB 2 on the file server and monitor appropriately
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Special App Focus
Skype for Business
Multi-Session OS / Single- Multi-Session OS / Single-

Session OS VDA Session OS VDA
N
ot
Skype Server
fo
rr
es
al
e
or
Endpoint Endpoint
di
Initialize
SIP Call
s
Media Place Call Receive Call
Registration Established
tri
Engine
b ut
io
n
Key Notes:
• When deploying Skype in combination with the HDX RealTime Optimization Pack and Citrix Workspace app calls are
connected directly between endpoints, minimizing the overhead inside the VDA sessions, the network traffic inside the
HDX protocol and optimizing the user experience.
• HDX RealTime Optimization Pack 2.1:
• Ability to leverage H.264 on conference calls, too. And it uses an updated H.264 implementation featuring Scalable
Video Coding (SVC) and Forward Error Correction (FEC).

• The SILK audio codec was added to our HDX RealTime Media Engine.
• Endpoint location identification passes endpoint location information such as IP address, MAC address
and next-hop router to the Skype for Business client.
• HDX RealTime optimization pack technical overview: https://docs.citrix.com/en-us/hdx-optimization/current-
release/overview.html
N
• Skype for Business Feature Support: https://support.citrix.com/article/CTX200279
ot
• Are You Ready for Skype for Business 2016: https://www.citrix.com/blogs/2016/06/29/are-you-ready-for-
fo
skype-for-business-2016/
rr
• A Hybrid Skype for Business Deployment: https://www.citrix.com/blogs/2016/02/26/a-hybrid-skype-for-
business-deployment/
es
al
e
or
di
s tri
but
io
n

Special App Focus
Citrix Virtual Delivery Agent (VDA)
Microsoft Teams 1
Authentication
2
Microsoft
Signaling, Presence & IM
Data Center
3 Azure
Citrix API 8
(HdxWebRTC.js) Data Collaboration
JSON
wss://127.0.0.1:9002
HDX Teams Services
N
(WebSocketService.exe)
4 (WebSocketAgent.exe)
For multi-
ot
(CtxSvcHost.exe)
party
conference
fo
Channel
GVCH
Virtual
ICA
5 7
rr
es
13.107.64.0/18
HDX new 6
embedded 52.112.0.0/14
al
Media Engine
User Device
(WebRPC.dll/WebRTC.dll) A/V media
Screensharing
e
Or other
Teams peers
UDP 3478 (TRAP)
(for p2p)
or
UDP 3479 (Audio)
UDP 3480 (Video)
Citrix Workspace App UDP 3481 (VBSS)
TCP 443 (fallback)
di
40k + UDP (P2P)
s tri
Microsoft Component
b
Existing Citrix Component
ut
New HDX Component
io
n
Key Notes:
• Citrix delivers optimization for desktop-based Microsoft Teams using Citrix Virtual Apps and Desktops and Citrix
Workspace app. By default, we bundle all the necessary components into Citrix Workspace app and the Virtual Delivery
Agent (VDA).
• Our optimization for Microsoft Teams contains VDA-side HDX services and API to interface with the Microsoft Teams
hosted app to receive commands. These components open a control virtual channel to the Citrix Workspace app-side
media engine.

• The endpoint decodes and renders the multimedia locally. Reverse seamless snaps-in the local Citrix
Workspace app window back into the hosted Microsoft Teams app.
• Authentication and signaling occurs natively on the Microsoft Teams-hosted app, just like the other Microsoft
Teams services (for example chat or collaboration). Audio/video redirection doesn’t affect them.
• Only Client-fetch/client-render is available.
N
• Optimization for Microsoft Teams: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ot
ltsr/multimedia/opt-ms-teams.html
fo
• Proof of Concept guide for Microsoft Teams optimization in Citrix Virtual Apps and Desktops environments:
https://docs.citrix.com/en-us/tech-zone/learn/poc-guides/microsoft-teams-optimizations.html
rr
es
al
e
or
di
s tri
b ut
io
n

Special App Focus
Microsoft Teams Considerations
Profile Management
Microsoft Teams Installation Peripherals Recommendations
Recommendations
N
Install the VDA before installing Teams in Disable auto-start by deleting the Teams Use Microsoft Teams certified headsets
ot
the master image. registry keys. with built-in echo cancellation.
fo
rr
Use the machine-wide installer for If the VDA does not have a GPU/vGPU,
es
Windows Server and Pooled VDI Windows Disable GPU hardware acceleration in the Use Microsoft Teams certified cameras.
10 environments. Teams Settings to improve performance.
al
e
Citrix Workspace app media engine cannot
If using WEM, enable CPU Spikes
Avoid using the .exe installer that installs take advantage of CPU offloading with
or
Protection to manage processor
Teams in AppData. webcams that perform on-board H.264
consumption for Teams.
encoding -UVC 1.1 and 1.5.
di
s tri
b ut
io
n
Key Notes:
• Microsoft Teams Installation Recommendations:
• Citrix recommends installing the VDA before installing Teams in the master image. This installation order is
necessary for the ALLUSER=1 flag to take effect.
• In ALLUSER=1 mode, the Teams application doesn’t auto-update whenever there is a new version. We
recommend this mode for non-persistent environments.
• Use the machine-wide installer for Windows Server and Pooled VDI Windows 10 environments.

• Follow the Microsoft Teams machine-wide installation guidelines and avoid using the .exe installer
that installs Teams in AppData.
• Profile Management Recommendations:
• Disable auto-start by deleting the Teams registry keys. Doing so prevents “8AM logon storms” from
spiking up the VM’s CPU. If the Virtual Desktop does not have a GPU/vGPU, we recommend
setting Disable GPU hardware acceleration in the Teams Settings to improve performance. This setting
("disableGpu":true) is stored in %Appdata%\Microsoft\Teams inside the desktop-config.json file. You can
N
use a logon script to edit that file and set the value to true.
ot
• If using Citrix Workspace Environment Management (WEM), enable CPU Spikes Protection to manage
fo
processor consumption for Teams.
• Peripherals Recommendations:
rr
• Use Microsoft Teams certified headsets with built-in echo cancellation. In setups with multiple
es
peripherals, where microphone and speakers are on separate devices an echo might be present. For
al
example, a webcam with a built-in microphone, and a monitor with speakers. When using external
speakers, place them as far as possible from the microphone and from any surface that might refract the
e
sound into the microphone.
or
• Use Microsoft Teams certified cameras, although Skype for Business certified peripherals are compatible
di
with Microsoft Teams.
• Citrix Workspace app media engine cannot take advantage of CPU offloading with webcams that perform
s tri
on-board H.264 encoding -UVC 1.1 and 1.5.
but
io
• Deploy the Teams desktop app to the VM: https://docs.microsoft.com/en-us/MicrosoftTeams/teams-for-
vdi#deploy-the-teams-desktop-app-to-the-vm

N
ot
fo
Where does App Layering store
Elastic Layers?
rr
es
Elastic Layers are stored on a file share.
al
e
or
di
s
tri
b
ut
io
n

N
ot
Profiles
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the appropriate profile strategy to use
N
based on user requirements.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the appropriate profile strategy to use based on user requirements.

Profile Strategy
FlexCast Model Local Roaming Mandatory Hybrid
User Setting Persistence
Hosted Windows App X  X 
Required
Web Browser App X  X 
N
Published Desktop (Multi-Session OS) X  X 
ot
Hosted VDI (Random / non-persistent) X  X 
fo
rr
Hosted VDI (Static / persistent) O  X 
es
Hosted VDI (Static / persistent, uses vGPU) O  X 
al
Streamed VHD (Physical machine using Citrix
e
Provisioning)
X  X 
or
Remote PC Access  O X O
 = Recommended
di
O = Viable
s
X = Not Recommended
tri
b ut
io
n
Key Notes:
• The chart shows the Citrix Consulting recommendation for what profile types to use for each of the listed FlexCast
models, specifically for use cases where user setting persistence is required. That is why mandatory profiles, which
deletes any user-specific settings after logoff, is not recommended for any of the models.
• Recommended options will provide the best user experience for the given FlexCast model.
• Viable options can work, but one or more factors make them less preferable than the recommended profile type(s).
• Not recommended options will not meet the user requirements or will present considerable challenges in practice.

• Recommendation for published apps, published web browsers, published desktops, and Hosted VDI (random
/ non-persistent): Use roaming or hybrid profiles
• These profile types will allow users to retain their user settings between sessions. They also allow users
to access these settings regardless of which Virtual Delivery Agent is accessed.
• Mandatory profiles do not retain user settings. Local profiles only retain settings on a specific machine,
resulting in an inconsistent experience for these models.
• Recommendation for Hosted VDI (Static / persistent, with or without GPU usage): Use roaming or hybrid
N
profiles
ot
• These profile types will allow users to retain their user settings between sessions. They also allow users
fo
to access these settings regardless of which Virtual Delivery Agent is accessed.
• Local profiles are also viable if the statically assigned desktop is the only resource accessed by a user.
rr
However, if users need access to other resources (such as published apps), this could result in an
es
inconsistent experience.
al
• Recommendation for Streamed VHD: Use roaming or hybrid profiles
• Because Streamed VHD turns a physical endpoint into a non-persistent machine, user profiles should be
e
stored in another location so that settings can persist between reboots.
or
• Recommendation for Remote PC Access: Use local profiles
di
• In these FlexCast models, the end user will access the same, persistent machine over time. Roaming
and hybrid profiles are still viable but could experience issues if and when the user decides to take their
s tri
endpoint offline.
but
io
n

Profile Strategy
FlexCast Model Local Roaming Mandatory Hybrid
User Setting Persistence
Published App X X  X
Not Required or Not
Desired Web Browser App X X  X
N
Published Desktop (Multi-Session OS) X X  X
ot
Hosted VDI (Random / non-persistent)  X  X
fo
rr
Hosted VDI (Static / persistent) X X  X
es
Hosted VDI (Static / persistent, uses vGPU) O X  X
al
e
Streamed VHD (Physical machine using PVS)  X  X
or
Remote PC Access O X  X
 = Recommended
di
O = Viable
s
X = Not Recommended
tri
b ut
io
n
Key Notes:
• The chart shows the Citrix Consulting recommendation for what profile types to use for each of the listed FlexCast
models, specifically for use cases where user setting persistence is NOT required or not desired. That is why roaming and
hybrid profiles, which retain user-specific settings after logoff, is not recommended for any of the models.
• In general, mandatory profiles provide a consistent experience for all users, and delete any profile changes upon logoff,
meeting this requirement across all FlexCast models.
• Hosted VDI (Random/ non-persistent) and Streamed VHD machines can utilize local profiles, since those profiles will be

deleted after every reboot.
• Local profiles could be viable for FlexCast models where the machine is typically accessed by a single person.
The storage cost associated with retaining user data in these scenarios is typically minor, however profile
cleanup scripts could be used if mandatory profiles cannot be configured for these machines.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Profile Strategy
Folder Local Roaming Mandatory Hybrid
Folder Redirection
Application Data X O X O
Contacts X  X O
Desktop X  X O
N
Downloads X O X O
ot
Favorites O  O 
fo
Links X  X O
rr
My Documents O  O 
es
My Music O  O O
al
My Pictures O  O O
e
My Videos O  O O
or
Saved Games X O X O
 = Recommended
di
O = Viable
Searches X  X O
s
X = Not Recommended Start Menu X X X X
tri
but
io
n
Key Notes:
• Redirecting special folders can supplement any of the profile types covered in this lesson. While redirecting profile folders,
such as user documents and favorites, to a network share is a good practice to minimize profile size, architects need to be
aware that applications may frequently read and write data to profile folders such as AppData, causing potential issues
with file server utilization and responsiveness. It is important to thoroughly test profile redirection before implementation in
production to avoid these issues.
• Therefore, it is important to research profile read / write activities and to perform a pilot before moving to production.

Microsoft Outlook is an example of an application that regularly performs profile read activities, as the
user signature is read from the user profile every time an email is created.
• The chart shows the Citrix Consulting recommendation for the appropriate folders to redirect for each of the
listed profile types.
• Application data can potentially be redirected for roaming or hybrid profiles. However, it should be
determined whether each application supports this, or whether it requires app data to reside on the local
machine.
N
• Local profiles are not typically configured with folder redirection, but it can be leveraged for folders such
ot
as My Documents, My Pictures, and other folders that may use a lot of local storage space over time.
fo
• Most folders should be redirected when using roaming profiles, because it helps keep the profile size
small and logon times low.
rr
• Mandatory profiles are typically used when the organization wants to keep profiles small, and user
es
settings do not need to persist between sessions. However, folders such as My Documents can be
al
redirected if users need to use this folder to store documents.
• Most folders can be redirected for hybrid profiles, similar to roaming profiles. However, solutions such as
e
Citrix Profile Management allow for more granularity, allowing subfolders to be redirected even if the root
or
folder is not, or vice versa. As a result, most folders can be reviewed, and only the necessary parts
di
redirected, with the remaining portions are excluded from synchronization.
s tri
Additonal Resources:
b
• Plan folder redirection with Profile Management: https://docs.citrix.com/en-us/profile-management/current-
ut
release/plan/folder-redirection.html
io
n

Citrix Profile
Management
• Profile streaming
N
• Active Write Back
ot
• Folder Exclusion
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Profile streaming:
• With user profile streaming, files and folders contained in a profile are fetched from the user store (file server) to the
local computer when a user accesses them. During the logon process, Citrix Profile Management immediately
reports that the profile load process has completed, reducing profile load time to almost zero.
• Citrix recommends enabling profile streaming for all scenarios. If it is desired to keep a local cached copy of the user
profile for performance reasons, it is recommended to enable the “Always Cache” setting and configure a size of 0.

This ensures that the user profile is downloaded in the background and enables the system to use this
cached copy going forward.
• Active Write Back:
• By enabling the active write back feature, Citrix Profile Management detects when an application has
written and closed a file and copies the file back to the network copy of the profile during idle periods. In
scenarios where a single user leverages multiple virtual desktops or hosted shared desktops
simultaneously, this feature can be tremendously beneficial.
N
• However, Citrix Profile Management does not copy any registry changes back to the network, except
ot
during an ordered logoff. As such, there is a risk that the registry and files may get out of alignment on
fo
non-persistent systems where locally cached profile information is wiped upon reboot. Therefore, it is
recommended to disable active write back functionality for non-persistent scenarios.
rr
• Folder Exclusion:
es
• Excluding folders from being persistently stored as part of a roaming or hybrid profile can help to reduce
al
profile size and logon times. By default, Windows excludes the AppData\Local and AppData\LocalLow
folders, including all subfolders, such as History, Temp and Temporary Internet Files.
e
• In addition, the downloads and saved games folders should also be excluded. All folders that are
or
redirected should be excluded from the profile solution.
di
s tri
• Citrix Profile Management Recommended Exclusions and Inclusions:
b
ut
io
n

Citrix Profile
Management
• Profile Caching
N
• Profile Path variables vs. Cross-platform
ot
• Profile conflicts and force user logoffs
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Profile caching:
• Local caching of roaming or hybrid user profiles on a server or virtual desktop is default Windows behavior and can
reduce login times and file server utilization / network traffic. With profile caching, the system only has to download
changes made to the profile. The downside of profile caching is that it can consume significant amounts of local disk
storage on multi-user systems, such as a Multi-Session OS VDA machines.
• Additionally, in certain FlexCast models and configurations, the machine is reset to a pristine state after each reboot.

Therefore, having locally cached profiles be deleted upon logoff is an unnecessary consumption of
resources. Based on these factors, the leading recommendation is to not delete locally cached profiles
for the following VDI models:
• Hosted VDI (static, persistent)
• Hosted VDI (random, non-persistent) – only in situations where a reboot occurs after logoff
• Remote PC Access
• Configuring the “Delay before deleting cached profiles” Citrix policy sets an optional extension to the
N
delay before locally cached profiles are deleted at logoff. Extending the delay is useful if a process keeps
ot
files or the user registry hive open during logoff. This can also reduce logoff times for large profiles.
fo
• Profile path variables vs. cross-platform:
• Determining the network path for the user profiles is one of the most significant decisions during a user
rr
profile design process. In general, it is strongly recommended to leverage a redundant and high
es
performance file server or NAS device.
al
• User profiles have a tight integration with the underlying operating system and it is not supported to reuse
a single user profile on different operating systems or different platforms like 64-Bit (x64) and 32-Bit
e
(x86).
or
• Windows 2008 and Windows Vista introduced a new user profile structure, which can be identified by .V2
di
profile directory suffix, which makes older user profiles incompatible with newer operating systems such
as Windows 2012, 7 and 8. In order to ensure that a separate profile is used per platform, the profile
s tri
directory has to be adapted.
b
• The user profile path can be configured by means of computer specific group policies or system
ut
variables. This enables administrators to ensure that a user profile is dedicated to the platform. Since
io
computer specific configurations affect all users of a system, all user profiles will be written to the same
file server. To load balance user profiles across multiple servers dedicated Delivery Groups have to be
n
created per file server.
• Profile conflicts and force user logoffs:
• There are certain scenarios where there is both a profile in the user store and a local Windows user
profile (not a Citrix user profile) existing on the same machine.
• By default, Citrix Profile Management uses the local profile, but does not change it in any way. This was

done so that local profile data is not inadvertently lost when deploying Citrix Profile Management on
production machines for the first time.
• Alternatively, this setting can renames the local Windows user profile (for backup purposes) and then
import the Citrix user profile from the user store. Or the local profile can be deleted and replaced with
the Citrix profile. The appropriate setting will depend on the situation.
• By default, users are given a temporary profile if a problem is encountered during loading the Citrix
profile (for example, the user store is unavailable).
N
• Profile management can be configured to instead display an error message and then log users off.
ot
This can help with troubleshooting but could cause prevent users from accessing their resources. The
fo
setting should be adjusted only if a temporary profile would not be sufficient for users to perform their
work or if they should not have access to a temporary profile for other reasons.
rr
• For example, temporary profiles are treated similar to mandatory profiles – the temporary profiles are
es
discarded when the user logs off. Without appropriate folder redirection, this could cause users to
al
inadvertently save documents and data in a non-persistent location.
e
or
• Cross-platform policy settings: https://docs.citrix.com/en-us/citrix-virtual-apps-
di
desktops/policies/reference/profile-management/cross-platform-policy-settings.html
s tri
b ut
io
n

Citrix Profile Management
FSLogix
Key Benefits with WEM

Features Configuration
and App Layering
Easy adoption of new Office 365 Profile
N
Allows users to save changes in multi-session
Containers in existing WEM Disabled by default.
scenarios.
ot
Environments. (WEM)
fo
FSLogix mounts Profile Container and redirects
Leverage Azure Files storage for profile
I/O requests to the mounted disk. Profile Enable multi-session write-back for
rr
data in Hybrid Cloud deployments.
Management then synchronizes changes from the FSLogix Profile Container policy.
(WEM)
es
user store to the local profile.
al
Reduced number of golden images,
If read-only mode is used, Profile Management Ensure that FSLogix Profile Container is
making more efficient use of workload
e
writes back changes to the user store. installed and enabled.
capacity. (App Layering)
or
If read/write mode is used, Profile Management
App masking also enforces per device Ensure that the profile type is set to Try
applies changes from the user store to the local
di
licenses on applications such as MS for read-write profile and fall back to
profile directly. Then, FSLogix Profile Container
s
Visio and Project. (App Layering) read-only.
merges changes to the profile container disk.
tri
b ut
io
n
Key Notes:
• FSLogix Profile Container provided by Microsoft is a VHD-based profile solution for non-persistent environments and is
common to use, especially if you’re running Office 365. It does not support saving changes in a multi-session OS VDA as
it only lets one session write back changes. Changes in other sessions are discarded.
• Implementing Citrix Profile Management with FSLogix Profile Containers, allows users to save changes in multi-session
scenarios. If the same user launches multiple sessions on different machines, changes made in each session are
synchronized and saved to the FSLogix Profile Container.

• During the user logon process, FSLogix mounts Profile Container and redirects I/O requests to the mounted
disk. Profile Management then synchronizes changes from the user store to the local profile.
• During the user logoff process, Profile Management works differently depending on which FSLogix Profile
Container mode is used in the session. If read-only mode is used, Profile Management writes back changes to
the user store. If read/write mode is used, Profile Management applies changes from the user store to the
local profile directly. Then, FSLogix Profile Container merges changes to the profile container disk.
• FSLogix integrates seamlessly with Citrix Workspace Environment Management (WEM) and Citrix App
N
Layering.
ot
fo
• Leveraging new FSLogix platform capabilities in virtual environments:
rr
https://www.citrix.com/blogs/2019/07/08/leveraging-new-fslogix-platform-capabilities-in-virtual-environments/
es
• Enable multi-session write back for FSLogix Profile Container: https://docs.citrix.com/en-us/profile-
al
management/current-release/configure/enable-multi-session-write-back-for-fslogix-profile-container.html
• Citrix App Layering and FSLogix profile containers: https://www.citrix.com/blogs/2020/01/07/citrix-app-layering-
e
and-fslogix-profile-containers/
or
di
s tri
but
io
n

1
Scaling
File Server Performance Factors Influencing Citrix
N
and Scalability Profile Management Scalability
ot
fo
• IOPS – RAID, Spindles, Caching, Tiering • Logon and logoff events
rr
• RAM – CIFS read caching • Streaming or caching of profile
es
• CPU – Model, Cores, Frequency • Active write back
al
• NIC – Speed, Teaming, Bonding • Folder redirection
e
• SMB – Version 1, 2 or 3 • Application usage of redirected folders
or
• TCP – Tune for CIFS • Open file handles
di
s
tri
b ut
io
n
Key Notes:
• If fileservers are overloaded and not scaled right, it will negatively impact both logon performance and application
performance when you implement roaming profiles and folder redirection.
• Scaling fileservers involves understanding usage pattern, such as logon / logon events, streaming or caching of profile,
active write back, folder redirection, application usage of redirected folders.
• Several features in Citrix Profile Management can impact the performance of the file servers hosting the profiles:
• The number of logon and logoff events is the biggest determining factor in the load of the fileserver.

• While streaming helps making the logon process faster, each subsequent set of data that is needed from
the profile will be picked up on demand by the user or the application, a bad performing fileserver will
typically cause the applications to seem slow or unresponsive.
• Caching the streamed profile can help on the bullet above, but you might be transferring a large dataset
on every logon, this will not show up in the logon performance reports.
• Active write back will write any file that is being changed in the profile back to the fileserver, this could
have a negative impact on the fileserver if configured for many users and the applications are changing
N
many files in the profile.
ot
• Folder redirection is almost the same consideration as active write back, it is a great feature, but if an
fo
application is relying heavily on putting temporary data in a redirected appdata folder, you might see poor
performance in the application and even in the general user experience and logon performance.
rr
• The amount of open file handles that a fileserver can support has increased with every new release of
es
SMB, however it is still a thing to keep in mind as you design your profile strategy, this is essentially the
al
same consideration as folder redirection and active write back.
e
or
di
s tri
but
io
n

Securing Profiles
Share Permissions
Group or Username Permission Apply To
<Group of accounts under Profile management control> Full Control Root of profile share
N
ot
Optional <Administrator group / Helpdesk group> Full Control Root of profile share
fo
NTFS Permissions
rr
es
Group or Username Permission Apply To
al
Creator Owner Full Control Subfolders and files only
e
List Folder / Read Data and Create
<Group of accounts under Profile management control> This folder only
or
Folders / Append Data
Local System Full Control This folder, subfolders and files
di
s
Optional <Administrator group / Helpdesk group> Full Control Subfolders and files only
tri
b ut
io
n
Key Notes:
• Recommendations on creating secure user stores are available in the article called “Create a file share for roaming user
profiles” on the Microsoft TechNet Web site. These are minimum recommendations that ensure a high level of security for
basic operation. Additionally, when configuring access to the user store include the Administrators group, which is required
in order to modify or remove a Citrix user profile.


Desktops environment for a large organization.
The CIO is asking whether enabling Active Write
N
Back in Citrix Profile Management is the right
ot
solution.
fo
What is one of the concerns of enabling Active
Write Back in Citrix Profile Management?
rr
es
Enabling Active Write Back may impose extra load on
file servers, if the file server does not have adequate
al
resources to handle the load it may lead to a poor user
e
experience.
or
di
s
tri
utb
io
n

N
ot
Policies
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine how policies can be deployed to optimize
N
the user experience.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Examine how policies can be deployed to optimize the user experience.

Deployment Method
Citrix Policies Microsoft Policies
N
ot
• Active Directory GPO • Active Directory GPO
fo
• Citrix Studio • Workspace Environment Manager
rr
• Local Policies • Local Policies
es
• Workspace Environment Manager
al
• Only Citrix Profile Management policies
e
or
di
s tri
b ut
io
n
Key Notes:
• You can use the following tools to work with Citrix policies:
• Studio - If you are a Citrix administrator without permission to manage group policy, use Studio to create policies for
your site. Policies created using Studio are stored in the site database and updates are pushed to the virtual desktop
either when that virtual desktop registers with the broker or when a user connects to that virtual desktop.
• Active Directory Group Policy Management Console can be used if you have administrative permission to create and
edit GPOs on a site or OU level in your active directory. Not all organizations allow Citrix Admins to create and edit

GPOs.
• Local Group Policy Editor or (Microsoft Management Console snap-in) - If your network environment
uses Active Directory and you do not have permission to manage group policy, you can use the Local
Group Policy Editor to create policies for your Site. The settings you configure in local policies may be
overridden by Studio policies and the Group Policy Objects (GPOs) you specify in the Group Policy
Management Console.
• Important: You must use the Local Group Policy Editor or AD GPOs to configure some policy settings,
N
including those related to registering VDAs with a Controller and those related to Microsoft App-V servers.
ot
• Do not mix-and-match policy engines. Choose one policy engine and configure all Citrix policies using that
fo
engine. For example, when using Active Directory group policies, do not use Citrix Studio to create other Citrix
policies.
rr
es
al
• Work with policies: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/policies/policies-
processes.html
e
or
di
s tri
b ut
io
n

Administrative Delegation
Built-in Administrative Roles Custom Administrative Role
N
ot
• Full Administrator • Provides more granular control over access to
fo
• Grants read and write access on all objects in a policies.
rr
Site
• Assign specific tasks to select administrators.
es
• Read Only Administrator
• Provides read-only permissions on objects within
al
the assigned scope in a Site.
e
or
di
s tri
b ut
io
n
Key Notes:
• Prevent unauthorized access by limiting the number of users who can access the policies.
• Leaving security too relaxed can lead to the exfiltration of the configuration details of the Citrix Virtual Apps and Desktops
deployment.
• The method to restrict access depends on the engine used to configure the policies. When using Citrix Studio as the
policy engine, assign roles to groups to delegate administrative access.
• There are two ways to delegate administrative rights to manage policies: Built-in Administrative Roles and Custom

Administrative Roles.
• Built-in Administrative Roles:
• A Full Administrator grants read and write access on all objects in the Citrix Virtual Apps and Desktops
Site. Pay special attention when assigning the “Full Administrator” role. Besides policies, the “Full
Administrator” role grants read and write access to all other objects within the entire Site as well.
• A Read Only Administrator provides read-only permissions on objects within the assigned scope in a
Citrix Virtual Apps and Desktops Site. Assigning a group to the “Read Only Administrator” roles grants
N
read-only access to all policies regardless of the assigned scope.
ot
• Custom Administrative Role
fo
• For more granular control over access to policies, create custom roles. A custom role enables
administrators to assign specific tasks to a group of administrators. Assign the “Manage Policies” or
rr
“View Policies” definition to delegate the appropriate permissions. As policies are not part of a specific
es
scope, the scope assigned to the administrator does not affect access to the policies. Add Active
al
Directory groups as Administrators and assign the custom role to delegate access.
e
or
• Design Decision: Administrative Delegation: https://docs.citrix.com/en-us/tech-zone/design/design-
di
decisions/baseline-policy-design.html#design-decision-administrative-delegation
s tri
b ut
io
n

Integration with
Active Directory
When applying an AD GPO, consider the following functionalities:
N
• Policy processing
ot
• Server local policies, Citrix Studio, AD Site, AD Domain, AD OU.
fo
• Policy precedence
rr
• AD OU, AD Domain, AD Site, Citrix Studio, Server local policies.
es
• Policy priority
• Priorities can be set both in GPMC and in the Citrix policies within the GPO.
al
• Policy scope
e
• Computer policies & User policies.
or
• Loopback processing
di
• Allows user settings to be read from a GPO applied to a Computer OU.
s tri
b ut
io
n
Key Notes:
• Some Citrix policy settings, if used, need to be configured through Active Directory group policy, such as Controllers and
Controller registration port, as these settings are required for VDAs to register.
• When applying an Active Directory GPO, consider the following functionalities:
• Policy Processing – When policies are applied, they following a specific order to be processed – Server local policies,
Citrix Studio, AD Site, AD Domain, AD OU; however, policies take precedence in the reverse order.
• Policy Precedence - You can apply policies on different levels of the network. Policy settings placed at the

Organizational Unit GPO level take the highest precedence on the network. Policies at the Domain GPO
level override policies on the Site Group Policy Object level, which override any conflicting policies on
both the Microsoft and Citrix Local Policies levels.
• Policy Priority - Prioritizing policies allows you to define the precedence of policies when they contain
conflicting settings.
• Policy Scope – Once policies are created, apply the policies to groups of users, computers, or both,
based on the required outcome.
N
• Loopback Processing – Allows user settings to be read from a GPO applied to a Computer OU.
ot
• Example scenario: In some cases, users may need a policy applied to them based on the location of
fo
the computer object alone.
rr
es
• Loopback processing of Group Policy: https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-
al
policy/loopback-processing-of-group-policy
e
or
di
s tri
but
io
n

Permissions and
Functionality
Considerations
• Citrix Policy Filters
N
• Access control, Citrix SD-WAN, Client IP address, Client name, Delivery group,
Delivery group type, Organizational unit, Tag, User or group.
ot
• AD Policy Security Filtering
fo
• Read and Apply permissions on policy.
rr
• Block inheritance - No override
es
• Avoid configuring identical settings in Citrix and RDS policies
al
• Example: Client Drive Mapping can be controlled both via RDS and Citrix policy
e
settings.
or
• Test and model using:
• Active Directory Resultant Set of Policy.
di
• Citrix Group Policy Modeling.
s
tri
b ut
io
n
Key Notes:
• When creating a policy, you assign it to certain user and machine objects; that policy is applied to connections according
to specific criteria or rules. In general, you can add as many assignments as you want to a policy, based on a combination
of criteria. If you specify no assignments, the policy is applied to all connections.
• In cases where exceptions are required, the application of policy settings from higher up the OU tree can be managed
using “block inheritance” and “no override” settings. Block inheritance stops settings from higher-level OUs (lower
precedence) from being incorporated into the policy. However, if a higher-level OU policy is configured with no override,

the block inheritance setting will not be applied.
• In some cases, particularly with respect to Windows Remote Desktop Services (RDS) and Citrix policies,
similar functionality can be configured in two different locations. For example, it is possible to enable client
drive mapping in a Citrix policy and disable client drive mapping in a RDS policy. The ability to use the desired
feature may be dependent upon the combination of RDS and Citrix policy. It is important to understand that
Citrix policies build upon functionality available in Remote Desktop Services. If the required feature is explicitly
disabled in RDS policy, Citrix policy will not be able to affect a configuration as the underlying functionality has
N
been disabled.
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Creating a Baseline
Policy
• Contains all common elements required for the majority of users within the
N
organization.
ot
• Set to lowest priority (1 is highest priority).
fo
• Unfiltered policy will apply to all users and computers.
rr
• Override baseline policy with specific settings.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• A baseline policy should contain all common elements required to deliver a high-definition experience to the majority of
users within the organization. A baseline policy creates the foundation for user access, and any exceptions that may need
to be created to address specific access requirements for groups of users. It should be comprehensive to cover as many
use cases as possible and should have the lowest priority, for example 99 (a priority number of “1” is the highest priority),
in order to create the simplest policy structure possible and avoid difficulties in determining the resultant set of policies.
• The unfiltered policy set provided by Citrix as the default policy may be used to create the baseline policy as it is applied to

all users and connections. In the baseline configuration, all Citrix policy settings should be enabled, even
those that will be configured with the default value, in order to explicitly define desired/expected behavior, and
to avoid confusion should default settings change over time.
• Baseline Policy Design: https://docs.citrix.com/en-us/tech-zone/design/design-decisions/baseline-policy-
design.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Optimize Logon Performance
Common Issue Description Mitigation
Merging GPOs takes additional time and Merge GPOs where possible, so that only several larger GPOs exist,
Many GPOs
adds load to the AD server. instead of hundreds of small ones.
N
ot
Having GPOs that heavily rewrite
fo
access to files and folders on boot Optimize access control to reduce number of required changes. Use
Access Control Rewrites
can have a significant impact on AD groups and build permissions into base image.
rr
logon times.
es
Optimize and merge logon scripts where possible.
Some scripts may complete a lot of
Assign logon scripts to users via GPOs rather than the AD User
al
Long Running Logon actions, including calls to other
Account property setting.
Scripts scripts, long loops and mapping network
e
Consider Group Policy Preferences or migrate to WEM instead of
drives.
logon scripts.
or
Reduce the number of required printer and driver mappings where
di
Having many printer and driver
Printer/Driver Mappings possible.
s
mappings can increase logon time.
Move client printer mapping to occur after logon.
tri
b ut
io
n
Key Notes:
• GPOs and logon scripts can have a large impact on start time. Some of the common ways that GPOs increase logon
times include:
• Numerous GPOs, rather than a few large ones
• Large numbers of access control rewrites on folders and files
• Long-running scripts
• Slow or resource-intensive startup scripts (for example, those that move large numbers of files)

• Inefficient loops in scripts
• Nested calls to different scripts
• Large numbers of mapped drives
• Large numbers of network printers
• Unused GPO sections (Computer/User) are not disabled
• Numerous Citrix Virtual Apps and Desktops policies
N
ot
fo
rr
es
al
e
or
di
stri
utb
io
n

N
ot
fo
Which priority would you typically give a Citrix
baseline policy?
rr
es
A Citrix baseline policy would typically be set to the
lowest priority so it can be overridden by higher priority
al
policies.
e
or
Remember 1 is the highest priority.
di
s
tri
utb
io
n

N
ot
Printing
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Assess the printing deployment methods and
N
implement Citrix printing leading practices.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Assess the printing deployment methods and implement Citrix printing leading practices.

Printer Provisioning
External Location Internal Location
N
External
ot
Endpoint
attached printer Printer-A
fo
VDA Sessions
Citrix Gateway
rr
es
External Internal
Endpoint Internal Endpoint
al
External Endpoint mapped local
Endpoint attached Internal printer
e
printer Endpoint
mapped local
PrintServer-
or
printer
001 PrintServer-002
di
s tri
b
Printer-C Printer-D
ut
Printer-B
io
n
Key Notes:
• The process of creating printers at the start of a Citrix Virtual Apps and Desktops session is called printer provisioning.
There are multiple approaches available:
• User Added – Allowing users to manually add printers gives them the flexibility to select printers by convenience. The
drawback to manually adding network-based printers is that it requires the users to know the network name or path
of the printers. There is also a chance that the native print driver is not installed in the operating system and the Citrix
Universal Print Driver is not compatible, thereby requiring the user to seek administrative assistance.

• Auto Created – Auto-creation is a form of dynamic provisioning that attempts to create some or all of the
available printers on the client device at the start of a user session. This includes locally attached printers
as well as network-based printers. Auto-creating all client printers can increase the session logon time as
each printer is enumerated during the logon process.
• Session Based – Session printers are a set of network-based printers assigned to users through a Citrix
policy at the start of each session.
• Universal Printer – The Citrix Universal Printer is a generic printer object that is auto-created at the start
N
of a session and is not linked to a printing device. When using the Citrix Universal Printer, it is not
ot
required to enumerate the available client printers during logon, which can greatly reduce resource usage
fo
and decrease user logon times. By default, the Citrix Universal Printer will print to the client’s default
printer, however the behavior can be modified to allow the user to select any of their compatible local or
rr
network-based printers.
es
al
• Baseline Printing Design: https://docs.citrix.com/en-us/tech-zone/design/design-decisions/baseline-printing-
e
design.html
or
di
s tri
but
io
n

Printer Routing
Auto-Created and User-Added Printers
Client Device Routing Windows Print Server Routing Citrix Universal Print Server Routing
N
ot
HDX VDA HDX VDA HDX VDA
fo
rr
Endpoint Compressed VDA Session Endpoint Print Job VDA Session Endpoint Print Job VDA Session
Print Job (fallback) (fallback)
es
Print Job Print Job Compressed
al
Print Job
e
or
di
Print Job Print Job
s
Print Server Universal Print
Locally Network Network
tri
Server
Attached Attached Attached
Printer Printer Printer
b ut
io
n
Key Notes:
• Print jobs can be routed along different paths: through a client device or through a print server.
• Client Device Routing – Client devices with locally attached printers (printers attached through USB, LPT, COM, TCP,
etc.) will route print jobs directly from the client device to the printer.
• Windows Print Server Routing – By default, print jobs sent to auto-created network-based printers will be routed from
the user’s session to the print server. However, the print job will take a fallback route through the client device when
any of the following conditions are true:

• The session cannot contact the print server
• The print server is on a different domain without a trust established
• The native print driver is not available within the user’s session
• Citrix Universal Print Server Routing – Print job routing follows the same process as Windows Print
Server Routing except that the Universal Print Driver is used between the user’s session and the Citrix
Universal Print Server.
N
ot
• Print Best practices, security considerations, and default operations: https://docs.citrix.com/en-us/citrix-virtual-
fo
apps-desktops/1912-ltsr/printing/printing-best-practices.html
rr
• Baseline Printing Design: https://docs.citrix.com/en-us/tech-zone/design/design-decisions/baseline-printing-
design.html
es
al
e
or
di
s tri
b ut
io
n

Printer Routing
Session Printers
Windows Print Server Routing Citrix Universal Print Server Routing
N
ot
HDX VDA HDX VDA
fo
rr
Endpoint VDA Session Endpoint VDA Session
es
al
Print Job Compressed
Print Job
e
or
di
Print Job Print Job
s
Print Server Universal Print
Network Network
tri
Server
Attached Attached
b
Printer Printer
ut
io
n
Key Notes:
• The print job routing changes slightly if the VDA provisions printers as session printers. The jobs can no longer route
through the user’s endpoint device and route from the session to the print server.
• The recommended option is based on the network location of the endpoint device, the user’s session and the print server.
• Client Device Routing
• Use for locally attached printer implementations.
• Use if a Windows endpoint device and printer are on the same high-speed, low-latency network as the Windows

Print Server.
• Windows Print Server Routing
• Use if the printer is on the same high-speed, low-latency network as the Windows Print Server and
user session.
• Windows Print Server Routing (with Universal Print Server)
• Use if non-Windows endpoint device and printer are on the same high-speed, low-latency network as
the Windows Print Server.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Printing
Leading Practices
• Limit number of print queues.
N
• Limit native drivers in VDA images.
ot
• Universal Print Server.
• Universal Print Driver for client print.
fo
• OEM Universal driver packages.
rr
• Print Driver Mapping and Compatibility.
es
• Test and understand drivers before deploying them.
• Substitute RAW session print with universal client print on WAN links.
al
• Use HDX QoS to ensure good user experience during print.
e
or
• PCL6 drivers uses lower bandwidth than PCL5.
di
s tri
b ut
io
n
Key Notes:
• Printing can often have a negative impact on user experience and environment performance/stability.
• Typically you can address stability by choosing the right drivers and/or limiting the amount of available drivers through the
use of Universal Print Server and Universal client print.
• Use print driver mapping and compatibility to reduce print drivers even further.
• Avoid using version 2 kernel-mode drivers.
• Avoid updating a driver. Always attempt to uninstall a driver, restart the print server, and then install the replacement driver.

• Uninstall unused drivers or use the Printer driver mapping and compatibility policy to prevent printers from
being created with the driver.
• To determine if a printer model is supported, contact the manufacturer or see the Citrix Ready product guide at
www.citrix.com/ready.
• In general, all of the Microsoft-supplied printer drivers are tested with Terminal Services and guaranteed to
work with Citrix. However, before using a third-party printer driver, consult your printer driver vendor so that
the driver is certified for Terminal Services by the Windows Hardware Quality Labs (WHQL) program. Citrix
N
does not certify printer drivers.
ot
• Performance is typically divided into two categories:
fo
• Logon performance
• Limit how many printers are added per user, both session printers but also client printers
rr
• Map client printers in the background after the application is started to hide the mapping delay.
es
• Print performance
al
• Avoid unnecessary printing double hops on wan links.
• Avoid RAW print data on wan links.
e
or
di
apps-desktops/1912-ltsr/printing/printing-best-practices.html
s tri
• Maintain the printing environment (see Manage printer drivers section): https://docs.citrix.com/en-us/citrix-
b
virtual-apps-desktops/1912-ltsr/printing/printing-maintain-environment.html
ut
io
n


Desktops environment for a large organization.
Discuss the best printer mapping options for:
N
ot
• Office workers using multifunction printer/copy
machines with stapling and sorting functions.
fo
rr
• Remote / home workers connecting with their
own printers.
es
• Satellite offices with 10 users sharing a 2Mbit
al
uplink.
e
• Task workers with simple print jobs and many
or
different printer manufacturers & models.
di
s
tri
b
ut
io
n

N
ot
• Office workers: Internal endpoint mapped local
printer.
fo
rr
• Remote/home workers: External endpoint attached
printer.
es
• Satellite offices: External endpoint mapped local
al
printer.
e
• Task workers: Internal endpoint mapped local printer,
or
use generic universal printer.
di
s
tri
utb
io
n

Exercise 5-1: Revise Application
Layering Business Requirements
Your team has documented the Application Layer
N
design requirements provided by the business.
ot
However, the business has now provided additional
requirements:
fo
• No single points of failure.
rr
• Management overhead kept to a minimum.
es
• Proprietary HR application requires close
al
integration with Mozilla Firefox.
e
• Firefox, which relies on a browser updater
or
service, should only be available in the
published application layer template for HR
di
employees only.
s
tri
utb
io
n

Exercise 5-1A:
Task:
N
• Navigate to \Module 5\Exercise 5-1
ot
• Copy and update Design Requirement document so
fo
all requirements are captured. Focus on the yellow
rr
highlighted fields.
es
al
e
or
di
s
tri
b
ut
io
n

Your team completed the Application Layer design
N
based on design requirements provided by the
ot
fo
rr
Task:
es
al
e
or
di
s
tri
b
ut
io
n

General
Number Priority Design Requirement Requirement Met in Design Yes/No
Standardize on Microsoft Windows Server 2016 where applicable for server

App-1 High Yes
N
infrastructure.
ot
No
App-2 High No single points of failure.
fo
Only 1 ELM server defined in the design.
No HA file servers for the templates defined.
rr
No
Management overhead kept to a minimum.
es
App-3 High
2 App Layers containing Office 2016.
al
e
App-4 Medium Enterprise Layer Manager version 4.5 or higher. Yes
or
App-5 Medium Comply with WorkspaceLab naming standards. Yes
di
s
tri
Separate management of operating systems and applications. Reduce time and
App-6 High Yes
b
effort required to make application updates.
ut
io
n

General (Continued)
Number Priority Design Requirement Requirement Met in Design Yes/No
Microsoft Office 2016 available on Windows 10 for all employees, allowing
N
App-7 High Yes
integration with other installed applications.
ot
No
fo
App-8 High Proprietary HR application requires close integration with Mozilla FireFox. Design has Firefox delivered to HR users as
rr
Elastic Layer, this may not support the close
integration with HR application.
es
No
Firefox, which relies on a browser updater service, should only be available in the
al
App-9 High Firefox is available to Sales via the NYC-
published application layer template for HR employees only.
DSK-MST-002 Layered Image.
e
Firefox is also available as an Elastic Layer.
or
App-10 Medium Adobe PDF Reader available as a published application for all employees. Yes
di
s tri
b ut
io
n

Application Layer
ELM Version 1906 Design Requirement App-4.

1
Number of ELM Servers 2 Design Requirements App-2, and App-5.
N
NYC-ELM-001
ot
ELM Server Specification 4 vCPU & 8 GB RAM
fo
ELM Server Operating System Linux Design Requirement App-1
rr
ELM SMB Share \\NYC-SRV-001\AppLayeringTemplates Design Requirement App-2
es
Windows fileserver cluster or DFS SMB share Windows fileserver cluster or DFS SMB share is required for synchronization
between two ELM servers as well as potential elastic layers.
al
2
e
1: Microsoft Windows Server-2016
Operating System Layer(s) Design Requirements App-3, App-5, and App-6.
• ELM-OSL-W16-001
or
2: Microsoft Windows 10
• ELM-OSL-W10-001
di
2
s
1: ELM-PFL-W16-001 Base image changes/components not included in the operating system layer.
tri
Platform Layer(s) • Join domain
• VDA Design Requirement App-3 and App-5.
b
• PVS target
ut
• Hypervisor tools
io
n

Application Layer (Continued)
2: ELM-PFL-W10-001
• Join domain Base image changes/components not included in the operating system layer.
Platform Layer(s) (continued) • Install VDA
N
• Install PVS target Design Requirement App-3 and App-5.
• Hypervisor tools
ot
3
fo
1: ELM-APL-OFF-001 (Windows 10) Three app layers required, one each for Office 2016, Mozilla Firefox, and
rr
• Office 2016 Adobe PDF Reader.
2: ELM-APL-OFF-002 (Windows 10)
es
App Layer(s) • Office 2016 Mozilla Firefox does not need to be installed on the same App Layer as Office
• Mozilla Firefox 2016. This reduces the management overhead for Office 2016 updates.
al
2: ELM-APL-MFX-001
• Mozilla Firefox Design Requirements Apps-3, App-5, App-6, App-7, App-8, App-9 and App-10.
e
3: ELM-APL-ADO-001 (Windows Server 2016)
or
• Adobe PDF Reader
di
Firefox delivered as elastic layer to HR user group only.
Elastic Layer(s)
s
1: ELM-ELL-MFX-001 (HR)
Design Requirement App-8 and App-9.
tri
Mozilla FireFox
b ut
io
n

Application Layer (Continued)
3
1: NYC-DSK-MST-001 (HR)
• ELM-OSL-W10-001
• ELM-PFL-W10-001
N
• ELM-APL-OFF-001
ot
• ELM-APL-MFX-001 Separate layered images created for Windows 10 machines (with and without
Firefox present) and Server 2016 machines.
fo
2: NYC-DSK-MST-002 (Sales)
Layered Image(s) • ELM-OSL-W10-001 Firefox layer added to HR layered image to ensure the browser updater
rr
• ELM-PFL-W10-001 service functionality and HR App integration.
• ELM-APL-OFF-001
es
• ELM-APL-OFF-002 Design Requirements Apps-3, App-5, App-6, App-7, App-8, App-9, and App-10.
al
3: NYC-SRV-MST-001
• ELM-OSL-W16-001
e
• ELM-PFL-W16-001
• ELM-APL-ADO-001
or
di
stri
b ut
io
n

Exercise 5-2: Revise
Personalization Layer Design
Requirements
Your team completed the Personalization Layer
N
design based on design requirements provided by the
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 5-2A:
Task:
N
ot
• Use Design Verification lab to check
fo
requirements met:
rr
• Endpoint NYC-WRK-001
es
al
• Copy and update Design Requirements
e
document to show which requirements met by
or
design. Focus on the yellow highlighted fields.
di
s
tri
b
ut
io
n

Exercise 5-2A

meets requirements.
N
• Profile changes regularly synchronized with profile
ot
on share. Proprietary HR application saves data to
profile folder. HR application crashes frequently
fo
resulting in data loss.
rr
• Documents, downloads, and favorites folders
accessible from virtual desktops and virtual
es
applications. Engineering users able to access the
al
same documents, downloads, and favorites folders
e
when using managed desktop.
• Windows saved credentials persist between
or
sessions.
di
• Adobe Acrobat Reader data persists between
sessions. Adobe *.txt files saved to
s
tri
AppData\LocalLow\Adobe\Linguistics\UserDictiona
ries\Adobe Custom Dictionary\all\*.txt.
utb
io
n

Your team completed the Personalization Layer
N
design based on design requirements provided by the
ot
fo
rr
Task:
es
al
e
or
di
s
tri
b
ut
io
n

Task:
N
ot
• Endpoint NYC-WRK-001
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

General

Yes/No Yes/No
Partners, employees, and administrators should all use the

Personal-1 Medium Yes Yes
N
same profile management solution.
ot
Separate profiles created for each operating system type. Icons
Personal-2 Medium and settings specific to one operating system type should not be Yes Yes
fo
available when a user logs on to another operating system.
rr
Microsoft Active Directory Group Policy Objects (GPOs) used to
es
Personal-3 Medium Yes Yes
configure all compatible products.
al
e
Personal-4 High All profiles and documents stored on file server: NYC-FSR-001. Yes Yes
or
If profile corruption occurs, helpdesk able to quickly and easily
Personal-5 Medium Yes Not yet configured
di
restore lost settings.
s
No
tri
Profile changes regularly synchronized with profile on share.
b
Personal-6 Medium Proprietary HR application saves data to profile folder. HR Enable active write back is Not yet configured
application crashes frequently resulting in data loss. disabled.
ut
io
n

General (Continued)

Yes/No Yes/No
Document folder restricted to owner. Principle of least privilege

Personal-7 High Yes Yes
N
applied to share and NTFS permissions.
ot
Documents, downloads and favorites folders accessible from No
virtual desktops and virtual applications. Engineering users able
Personal-8 Medium Not yet configured
fo
to access the same documents, downloads and favorites The downloads folder has not been
folders when using managed desktops. redirected.
rr
es
Personal-9 Medium Users able to customize their desktop. Yes Yes
al
e
or
di
s tri
but
io
n

General (Continued)

Yes/No Yes/No
No
N
Personal-10 High Windows saved credentials persist between sessions. Exclusion list - Directories policy Not yet configured
definition does not meet this
ot
requirement.
Adobe Acrobat Reader data persists between sessions. Adobe No
fo
*.txt files saved to
Personal-11 Medium Not yet configured
AppData\LocalLow\Adobe\Linguistics\UserDictionaries\Adobe Adobe Acrobat Reader data does
rr
Custom Dictionary\all\*.txt. not persist between sessions.
es
Personal-12 High Log on time less than 60 seconds. Yes Yes
al
e
Personal-13 High Log off time less than 60 seconds. Yes Yes
or
di
s tri
but
io
n

Personalization Layer
Advanced profile management solution designed specifically for Citrix Virtual Apps
Profile Management Solution Citrix Profile Management
and Desktops.
N
Workspace Lab standard for all compatible products.
ot
Active Directory Group Policy Objects
Configuration Method Design Requirement Personal-3: Microsoft Active Directory Group Policy Objects
(GPOs) used to configure all compatible products.
fo
Reduce log on and log off times.
rr
Profile Streaming Enabled
Design Requirement Personal-12: Log on time less than 60 seconds.
es
al
Not required.
Disabled
e
Active write back enabled for HR users minimizing data loss from session reset.
Enabled
Enable active write back.
or
Design Requirement Personal-6: Profile changes regularly synchronized with
New GPO (CPM-HRE) applied to HR Users.
profile on share. Proprietary HR application saves data to profile folder. HR
di
application crashes frequently resulting in data loss.
s tri
AppData\Roaming\Microsoft\Credentials Enhance security across solution
Exclusion list - Directories AppData\Roaming\Microsoft\Crypto
b
AppData\Roaming\Microsoft\Protect Design Requirement Personal-10: Windows saved credentials persist between
ut
AppData\Roaming\Microsoft\SystemCertificates sessions.
io
n

Personalization Layer (Continued)
All domain administrators are also local administrators.

Administrator
Process logons for local administrators
Profiles Design Requirement Personal-1: Partners, employees, and administrators should all
N
use the same profile management solution.
ot
Design Requirement Personal-1: Partners, employees, and administrators should all
Processed Groups Not configured
use the same profile management solution.
fo
rr
\\NYC-FSR-001\Users$\ Permissions agreed with the Workspacelab security team.
es
• System: Full control (this folder, subfolders, and files) Design Requirement Personal-4: All profiles and documents stored on a file server –
NTFS Permissions • Administrators: Full control (this folder only) NYC-FSR-001.
al
• Creator/Owner: Full control (subfolders and files only)
• Authenticated Users: List folder/read data, and create Design Requirement Personal-7: Document folder restricted to owner. Principle of
e
folders/append data (this folder only) least privilege applied to share and NTFS permissions.
or
Separate profiles for each operating system used. Helps prevent profile corruption.
di
Design Requirement Personal-2: Separate profiles created for each operating
s
\\NYC-FSR-001\Users$\ #SAMAccountName#\Profiles\ system type. Icons and settings specific to one operating system type should not be
tri
Profile Path
!ctx_osname!CTX_PROFILEVER!\ available when a user logs on to another operating system.
b
Design Requirement Personal-4: All profiles and documents stored on highly
ut
available Network Attached Storage (NAS) – NYC-NAS-001.
io
n

Highly available storage solution.

Network File Server
Design Requirement Personal-4: All profiles and documents stored on a file server – NYC-
Profile Storage
N
FSR-001.
NYC-FSR-001
ot
Design Verification: Profiles stored on NYC-FSR-001.
fo
Reduce profile log on and log off times by excluding unnecessary folders.
rr
AppData\* Excluding AppData will prevent saved Windows credentials from persisting between sessions.
Excluded Folders
None
es
Design Requirement Personal-10: Windows saved credentials persist between sessions.
al
Not required.
Ensure Adobe Acrobat data persists between sessions.
e
None
Files to Synchronize AppData\LocalLow\Adobe\Linguistics\UserDi
or
Design Requirement Personal-11: Adobe Acrobat data persists between sessions. custom
ctionaries\Adobe Custom Dictionary\all\*.txt
dictionary *.txt files saved to AppData\LocalLow\Adobe\Linguistics\UserDictionaries\Adobe
Custom Dictionary\all\*.txt
di
s tri
b ut
io
n

Documents, desktop and favorites folders redirected to reduce profile

size and improve logon times.
N
Design Requirement Personal-4: All profiles and documents stored on
Documents
ot
a file server – NYC-FSR-001.
\\NYC-FSR-001\Users$\#SAMAccountName#\Redirected\Documents
Desktop
Design Requirement Personal-8: Documents, downloads and favorites
fo
\\NYC-FSR-001\Users$\#SAMAccountName#\Redirected\Desktop
folders accessible from virtual desktops and virtual applications.
Redirected folders Favorites
rr
Engineering users able to access the same documents, downloads,
\\NYC-FSR-001\Users$\#SAMAccountName#\Redirected\Favorites
and favorites folders when using managed desktops.
es
Folder redirection settings applied to Folder Redirection GPO which is
Design Requirement Personal-12: Log on time less than 60 seconds.
applied to all Citrix virtual desktops and applications.
al
Design Requirement Personal-13: Log off time less than 60 seconds.
e
or
Design Verification: Redirected folders stored on NYC-FSR-001.
di
Redirected folders will be visible under the username folder.
s
Redirected Folders
\\NYC-FSR-001\Users$\#SAMAccountName#\Redirected
tri
Path Design Requirement Personal-4: All profiles and documents stored on
b ut
io
n

Proof of concept storage solution.

Network File Server
Folder Redirection
Storage
N
NYC-FSR-001 a file server – NYC-FSR-001.
Design Verification: Redirected folders stored on NYC-FSR-001.
ot
H drive mapped to each user’s documents folder.
fo
Home Drive Path NYC-FSR-001\Users$\ #SAMAccountName#\ Redirected\Documents
rr
es
Proof of concept storage solution.
Network File Server
al
Home Drive Storage
e
NYC-FSR-001
or
Design Verification: Home drives stored on NYC-FSR-001.
di
s tri
b ut
io
n

Key Takeaways
• Understanding how an application works is key to
N
selecting the appropriate deployment method and
ot
ensuring a good user experience.
• Examine the applications’ behavior before designing
fo
the profile strategy.
rr
• Policies can be deployed in Citrix Studio or Active
es
Directory.
al
• Understand a customers WAN link structure and
e
network equipment before designing the print
or
configuration.
di
s tri
but
io
n
Key Notes:
• Understanding how an application works is key to selecting the appropriate deployment method and ensuring a good user
experience.
• Examine the applications’ behavior before designing the profile strategy.
• Policies can be deployed in Citrix Studio or Active Directory.
• Understand a customers WAN link structure and network equipment before designing the print configuration.

N
ot
Control Layer
fo
rr
es
al
e
Module 6
or
di
s tri
but
io
n
Key Notes:
• Welcome to the Control Layer module. This is the sixth module in the Citrix Virtual Apps and Desktops 7 Assessment,
• Throughout this module, we will discuss key design and security considerations for the Site architecture, Delivery
Controller, SQL database, and Citrix License server components and identify how to design and use key Site
management features and tools.

Learning Objectives
• Determine the optimal architecture for a single-Site
N
Citrix Virtual Apps and Desktops deployment.
ot
• Optimize the way Machine Catalogs and Delivery
Groups are used within a Site.
fo
rr
• Design how the Site will be managed.
es
• Determine the appropriate Site design and baseline
specifications to ensure performance and stability.
al
e
• Assess the Control Layer security requirements and
or
features necessary to secure a Citrix Virtual Apps
di
s tri
but
io
n
Key Notes:
• Determine the optimal architecture for a single-Site Citrix Virtual Apps and Desktops deployment.
• Optimize the way Machine Catalogs and Delivery Groups are used within a Site.
• Design how the Site will be managed.
• Determine the appropriate Site design and baseline specifications to ensure performance and stability.
• Assess the Control Layer security requirements and features necessary to secure a Citrix Virtual Apps and Desktops
environment.
N
ot
Site Design
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the optimal architecture for a single-Site
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the optimal architecture for a single-Site Citrix Virtual Apps and Desktops deployment.

Pod Architecture
Introduction User Layer Access Layer Control Layer Resource Layer
POD Site 3
Delivery Controller VDAs
POD Site 2
• In general, a pod
N
architecture limits the failure Internal Users
StoreFront
VDAs
Delivery Controller
ot
domain of a large single-
datacenter environment.
POD Site 1
Firewall
fo
• Consider a datacenter with VDAs
rr
Delivery Controller
9,000 concurrent users. If a Firewall
es
Citrix Gateway
External Users
pod architecture is used so
License Server Databases
al
that 3,000 users are placed
in each pod / Site, the failure
e
Domain Controller
domain of a Site outage is
or
greatly reduced. Compute Layer
di
s
tri
Single
Datacenter
b ut
io
n
Key Notes:
• Each Pod could be a completely separate Citrix Virtual Apps and Desktops Site.
• Each Pod could be a Zone, collectively making one Citrix Virtual Apps and Desktops Site.
• Remember, if Pod Architecture is used:
• If you follow the diagram above to have three pods and choose Citrix Virtual Apps and Desktops Sites, then you need
three of everything, including three separate Databases.
• If you follow the diagram above to have three pods and choose Citrix Virtual Apps and Desktops Zones, then you

have shared Site architecture, but a single failure, such as the Database server could bring down all
pods.
• Pod Architecture is not a Citrix product or concept, but rather an industry wide concept used when scaling
large deployments linearly. The concept is also used by Google who uses shipping containers which contain
all compute elements needed to be fully self sustaining, when adding extra capacity to their datacenters.
• Beyond limiting failure domains, a pod architecture may also be used to create fully separated development,
test, and production environments. Or it could be required for organizational reasons, where individual
N
business units each wish to manage their own separate Site.
ot
• This type of setup is modular in nature and allows an environment to be built in self-contained pods that can
fo
be easily replicated. This allows organizations to build an environment which scales to large numbers of users,
while providing availability should a failure impact a single site structure.
rr
• In a modern Citrix Virtual Apps and Desktops environment, zones can be used to facilitate the creation of a
es
pod architecture, as long as the SQL database is configured with some form of high availability. Similarly, if
al
Citrix Provisioning is used, a single Farm, multi-Site architecture can be aligned with the FMA zones.
• This setup eases some of the administrative burden of maintaining multiple pods but does not fully separate
e
the SQL component.
or
• When designing a pod architecture, be sure to ensure there is enough capacity to support the additional load if
di
one of the pods becomes unavailable. The remaining pods should be able to accommodate the additional
users.
s tri
• This setup can be used both on-premises or in a private cloud in Azure or AWS.
b
• The concept presented here is just for pods, not individual Sites. Consideration for LHC etc, is covered in a
ut
later lesson in the module: "Control Layer Scalability and High Availability.”
io
n
• Citrix Virtual Apps and Desktops Technical Overview: https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops/1912-ltsr/technical-overview.html

Pod Architecture User 1 clicks the “Win 10
Pod 1
Desktop” icon and connects
Considerations to a VDA in Pod 1 even
though it is not the least
loaded because she has a
disconnected session there.
• When designed properly, “Win 10 Desktop” Delivery Group
pods are transparent to User 1 Hosted VDI (Random, Non-
persistent)
users due to Site 3000 Desktops / 2500 in use
aggregation and load User 2 launches a new
N
session in Pod 2, which is the
balancing features built into least loaded. Pod 2
ot
StoreFront. StoreFront Servers
fo
• One large caveat of a multi-
rr
pod design is that persistent
“Win 10 Desktop” Delivery Group
VDI can only live within a User 2
es
Hosted VDI (Random, Non-
persistent)
single pod. 3000 Desktops / 1500 in use
al
• Ideally, limit persistent User 3 launches the “My
e
Desktop” icon, which is only Pod 3
desktop users to no more available in Pod 3. Pod Load Balancing
or
All three Pods are collapsed
than about 20% of the user and presented to the end
population, and provide user as one entity. Each
di
“Win 10 Desktop” Delivery Group
assigned resource appears Hosted VDI (Random, Non-persistent)
them with Hosted Shared as a single icon.
s
3000 Desktops / 2700 in use
tri
desktops or Pooled VDI as a User 3
backup.
b
“My Desktop” Delivery Group
Hosted VDI (Dedicated, Persistent)
ut
io
n
Key Notes:
• Typically, components such as StoreFront, Citrix Director, the Citrix Licensing server, and file shares are not included in
every pod. These components can serve multiple Sites, although redundancy is still included at the component level.
• Managing multiple pods:
• Build identical pods and use configuration scripts
• Use Microsoft Group Policy or WEM for Citrix HDX policies
• PowerShell commands can help reduce the overhead of managing several individual sites, for example publishing

the same applications multiple times.
• Citrix Director is able to manage multiple Sites from the same console, however you have to switch
between sites, you cannot see metric averages across all deployments together.
• Persistent desktops present several challenges to a multi-pod or multi-site environment:
• Each persistent desktop VM is dependent on a single LUN, resource pool, Site, vLAN, etc.
• Persistent desktops use more storage and IOPS.
• It is resource intensive and difficult to provide a backup persistent desktop that is exactly the same as the
N
primary desktop.
ot
• Based on Citrix Consulting’s experience, as a rule of thumb, limiting persistent desktop usage to 20% will
fo
keep the overall number of these desktops at a manageable level.
• Instead of trying to replicate these desktops on alternate pods, create non-persistent Single-Session OS
rr
or Multi-Session OS-based desktops as a backup.
es
al
• Maximizing XenDesktop High Availability With a Pod Architecture: https://www.slideshare.net/citrix/synergy-
e
2015-session-slides-syn410-maximizing-xendesktop-high-availability-with-a-pod-architecture-2
or
di
s tri
b ut
io
n

Hub-Spoke Model Use a Hub-Spoke model for large scale
deployments in Azure.
Azure Deployments
Azure AD Citrix Cloud
App Registration Machine Catalog Machine Catalog Machine Catalog
N
IPsec
IPsec
ot
IPsec
Azure Subscription (bastion) Azure Subscription (Common Components) Azure Subscription Azure Subscription Azure Subscription
(Dedicated) (Dedicated) (Dedicated)
fo
AV Set
rr
Networking CC Resource D52v3
Resource Group Group
Firewall IPsec
es
HUB
VNet/Subnet
3x Citrix Cloud Connectors
al
3x Windows Server 2016
Express Route
Resource Location West Europe
e
or
Customer Internal Network
di
Other
Proxy Internal
s
AD Apps
tri
VDI Subscription VDI Subscription
b ut
io
n
Key Notes:
• Azure has limitations when using Machine Creation Services such as 1200 VDA’s per Microsoft Azure Subscription
because of an API limit and 1 virtual subnet per machine catalog.
• Because of these limitations, Citrix Consulting recommends using a Hub-Spoke model for large scale deployments which
would replace the POD architecture with a machine catalog linked to a dedicated Azure Subscription for VDAs. This allows
customers to scale up/down the environment as required.
• The hub is a virtual network in Azure and acts as a central point of connectivity to your on-premises network. The spokes

are virtual networks that peer with the hub, and can be used to isolate workloads. The traffic flows between
the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. An
ExpressRoute creates a private connection between Azure datacenters and on-premises or a colocation
environment.
• In a Citrix Cloud/hybrid environment, this architecture works best when workloads are deployed in different
environments, such as development, testing and production, that require shared Domain services.
N
ot
• Citrix Virtual Apps and Desktops Service – Azure Implementation with Azure Active Directory Domain Services
fo
for CSPs: https://docs.citrix.com/en-us/tech-zone/design/reference-architectures/csp-cvads-aad.html
• Lessons from the Field: Citrix on Azure network design: https://www.citrix.com/blogs/2020/04/21/lessons-from-
rr
the-field-citrix-on-azure-network-design/
es
• Hub-spoke network topology in Azure: https://docs.microsoft.com/en-us/azure/architecture/reference-
al
architectures/hybrid-networking/hub-spoke
e
or
di
s tri
b ut
io
n

Citrix Virtual Apps and Desktops Service Design
Citrix Cloud
User Access Control Resource Layer

Layer Layer Layer
Citrix Cloud ( Citrix Managed)
N
ot
Databases License
fo
Server
rr
Internal Users StoreFront
Domain Citrix Gateway StoreFront Delivery Controller
Controller Multi-Session OS Assigned Single-
es
Session OS
Firewall
al
e
Firewall Cloud Random Single- Remote PC
External Citrix Connector Session OS
or
Users Gateway
di
s
Resource Location
tri
On-Premise or Cloud
StoreFront and Citrix
Compute Layer
(Customer/Partner-Managed)
b
Gateway optional
on-prem or Cloud
ut
io
n
Key Notes:
• If Citrix Cloud is used, the Delivery Controller(s), Site database, and License Server are managed by Citrix. This includes
the underlying hardware, sizing, and updates to the managed components.
• As mentioned previously, you have the option of where to place the Citrix Gateway and StoreFront components.
• The Resource Layer components, which are the VDA machines, continue to be managed by the organization’s IT team.
These resources could be on-premises, in a public cloud, or a hybrid environment.
• Use the business drivers identified during the assessment phase to determine whether a Citrix Cloud environment is

appropriate for an organization. In general, Citrix Cloud reduces the administrative burden of supporting a
Citrix Virtual Apps and Desktops environment, but also decreases the amount of control the organization has
over the Citrix-managed components, and the amount of customization options available.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Virtual Apps
and Desktops Azure/AWS
Service Design
Active Directory
Example Hybrid
VDA
Environment
N
Cloud Connectors VDA File Server
ot
fo
A Citrix Virtual Apps and Zurich On-Premises Express
rr
Desktops Site can be hosted Route
on a mixture of on-premises Citrix Cloud
es
and public cloud
al
StoreFront VDA Cloud Connectors
infrastructure, with or without
e
Citrix Cloud. Production
Data
or
Citrix Gateway Active Directory Production Servers
di
s
This diagram shows an example hybrid environment of using Citrix Cloud, Public
tri
Cloud and On Premises to host the Citrix Virtual Apps and Desktops Site.
b ut
io
n
Key Notes:
• In this example, the organization has an existing infrastructure and user base that they want to continue hosting for the
time being. However, they also want to begin moving to the cloud by hosting new users in an Azure or AWS deployment.
In this example, all production data remains on-premises; however, this is not a technical requirement.
• Key Questions to address when deciding on the location of a Site:
• Do we want to be in the business of managing our own hardware?
• Do we want to be managing our own Citrix infrastructure?

• Are we comfortable with putting our data in the cloud? If not, can we design a hybrid environment that
ensures data stays on-premises only?
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Consider the optimal Site architecture for the following organizations? What follow-
N
up questions (if any) would you ask to help with the selection?
ot
1. Marketing firm with 100 employees. The firm has no existing datacenter infrastructure
and would like to enable their marketing analysts and graphic designers to work from
fo
home without procuring new hardware.
rr
2. A large web retailer maintains a corporate headquarters with 40,000 employees. The
es
organization maintains a significant amount of datacenter infrastructure globally, but
its core datacenter containing a majority of its consumer data is near headquarters.
al
The retailer would like to provide its employees with secure access to this data, while
e
also limiting the failure domain of the environment.
or
3. A mid-sized government agency would like to lower its hardware refresh cycle
expense by providing thin clients to its employees to access a new Citrix Virtual Apps
di
and Desktops environment. The agency is open to different architectures but must
s
comply with General Data Protection Regulation (GDPR).
tri
b ut
io
n

Marketing firm with 100 employees.
N
• Likely a great candidate for Citrix Cloud with resources hosted in public cloud.
ot
• Consider showcasing Citrix Virtual Desktops Essentials or Citrix Virtual Desktops Service.
fo
A large web retailer maintains a corporate headquarters with 40,000 employees.
rr
• POD architecture potentially with a multi location deployment.
es
A mid-sized government agency.
• Single site architecture.
al
e
or
di
s tri
b ut
io
n
• Citrix Virtual Desktops Essentials: https://docs.citrix.com/en-us/citrix-cloud/citrix-virtual-desktops-essentials.html
• Citrix Virtual Apps and Desktops service: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service.html

N
Machine Catalogs &
ot
Delivery Groups
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Published apps are installed on Server OS Virtual Delivery Agent machines and delivered as a seamless application
session to an endpoint device.
• A variation of this method is the VM-Hosted app. The primary difference is that the application is installed on a Desktop
OS Virtual Delivery Agent machine, but it is still presented to the end user as a seamless application session. Keep in
mind that only one user can use a VM-Hosted app at a time; this FlexCast model is typically used for applications that are
not compatible with a Server OS or require dedicated resources at the VM level.

• Delivering published apps on a virtual desktop is typically referred to as an HDX double-hop scenario. This
method can help reduce the complexity of the VDI images.
• Published apps are ideal for departmental apps that should be available to a subset of users within an
organization. However, it is a viable solution for any application that is compatible with a multi-user, Server OS
environment.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

• Use tagging to optimize the design of Machine
N
Catalogs and Delivery Groups.
ot
• Describe how load balancing can be used to control
the session utilization across Delivery Groups.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Use tagging to optimize the design of Machine Catalogs and Delivery Groups.
• Describe how load balancing can be used to control the session utilization across Delivery Groups.

Machine Catalogs Key
VDA
and Delivery Groups Visio Unpatched
Visio Patched 1 VDA

Implementing User Acceptance Testing – Step 1 Tags UAT
Application VDA
Group
1. A subset of VDA machines hosting a published
VDA
N
application receive a critical security patch.
ot
2. The updated VDA machines are tagged as UAT User Acceptance VDA
machines. The tag is also applied to the UAT
fo
Testers Delivery
Group
application group.
rr
VDA
3. The UAT user group accesses the patched
es
applications and validates functionality. VDA
al
MSFT
4. The remaining VDA machines are patched, and
e
Visio
VDA
the UAT tag is removed from the machines used Application
or
Group
for testing.
VDA
di
s tri
Architects VDA
(Visio Users)
b ut
io
n
Key Notes:
• Although implementing user acceptance testing is not traditionally considered part of an environment design, including
important, recurring processes into the design considerations can help to improve the long-term success of an
implementation.
• In this example, production users are able to continue using the published applications on VDA machines tagged as
Production while UAT is ongoing.
• Step 1: A subset of VDA machines hosting a published application receive a critical security patch.

• Tags: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-deployment/tags.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

VDA
Visio Patched VDA

Application VDA
Group
VDA
N
application receive a critical security patch. 2
ot
fo
Testers Delivery
Group
application group.
rr
VDA
es
al
MSFT
e
Visio
VDA
or
Group
for testing.
VDA
di
s tri
Architects VDA
(Visio Users)
but
io
n
Key Notes:
• Step 2: The updated VDA machines are tagged as UAT machines. The tag is also applied to the UAT application group.
• Note that in this step, the MSFT Visio Application group and production VDA machines are also tagged so that the
Architects group does not inadvertently access one of the untested, unpatched VDA machines.

VDA
Visio Patched VDA

Application VDA
Group
VDA
N
ot
3
fo
Testers Delivery
Group
application group.
rr
VDA
es
al
MSFT
e
Visio
VDA
or
Group
for testing.
VDA
di
stri
Architects VDA
(Visio Users)
b ut
io
n
Key Notes:
• Step 3: The UAT user group accesses the patched applications and validates functionality.
• Note that the Architects group can continue to work on the unpatched VDAs while the UAT group tests the new patch.

VDA
Visio Patched VDA

Application VDA
Group
VDA
N
ot
fo
Testers Delivery
Group
application group.
rr
VDA
es
applications and validates functionality. 4 VDA
al
MSFT
e
Visio
VDA
or
Group
for testing.
VDA
di
s tri
Architects VDA
(Visio Users)
but
io
n
Key Notes:
• Step 4: The remaining VDA machines are patched, and the UAT tag is removed from the machines used for testing.
• When UAT is completed and the update is validated, the UAT-tagged machines can become available to end users by
changing the tag assigned to the machines.

Virtual Delivery Agent Load Balancing
The Delivery Controller load balances sessions using heartbeat messages from the servers running the VDA.
This diagram is a closer look at the role of the VDA during load balancing.
Group Policy Settings CPU Load Rule Effective Load
Load Index Index
Index
Max CPU 90% Session Load
Memory Load Rule Index Load
Min Memory 768 MB VDA Heartbeat
N
Rule Index Bias
Max Memory 90% CPU Load Rule Index
ot
Max Disk Queue 8 Disk Load Rule Memory Load Rule Index Load Per VDA Selection Algorithm
Index Session
fo
Max Sessions (default) 250 Disk Load Rule Index
1. Exclude all VDA machines in
Concurrent Logon 2 Max Sessions Active Session Maintenance Mode (both Multi-Session
rr
Tolerance Count VDA and RDS) or that are not in the
Concurrent Logons Tol. Available state.
es
Pending Session 2. Return any VDA machine where
Colors indicate update frequency: RDS Drain Mode
reconnection or session sharing is
RDS Drain Mode Count
al
VDA State possible.
Changes based on trigger (admin
config change or external service). 3. Return the VDA machine with the
e
lowest Effective Load Index where
Sampled every 30 seconds VDA State (Pending Session Count < Concurrent
or
Logons Tolerance).
Updates on a VDA heartbeat; 4. Return the VDA machine with the
usually varies between 30 seconds lowest Pending Session Count.
di
and 5 minutes. 5. If multiple VDA machines have equal
VDA Controller
s
and lowest Pending Session Counts,
Updates when a user launches a
use least Effective Load Index as the
tri
new session or an existing session’s
tie-breaker.
state changes.
but
io
n
Key Notes:
• Each VDA machine has an effective load index value which is used to assist in load balancing decisions, which ranges
between 0 (completely unloaded) to 10000 (completely loaded).
• By default, this load index is based solely on the number of sessions currently running on the VDA machine, with a
maximum number of 250. It assumes that all VDA machines in a Delivery or Application group are equivalent in
performance and capable of supporting the same number of sessions.
• Beyond the max number of sessions, additionally HDX policies can be configured to influence how the load index is

calculated, which include max CPU, minimum and maximum memory, and max disk queue. Policy filtering and
tagging can be use to assign different load index rules to different Delivery Groups, Applications groups, sub-
groups, or individual VDA machines.
• A VDA machine heartbeat change may occur any time a Load Rule Index changes by 500 (5% of 10,000) or
immediately when the RDS Drain Mode or VDA machine State changes.
• The Load Index is the maximum of the four load rules, plus 5% of the other enabled rules.
• Load Per Session is the Load Index/Active Session Count. If the Active Session Count is 0, a Load Per
N
Session of 40 is assumed. However, if the Max Sessions policy setting is configured, Load Per Session has a
ot
minimum of (10,000/Max Sessions).
fo
• Load Bias is Load Per Session / Pending Session Count. However, Load Bias may never cause the Effective
Load Index to reach 10,000 unless the Load Index is already 10,000.
rr
• Remember there are other factors to impact load balancing, such as:
es
• Concurrent logon tolerance
al
• Is Maintenance mode enabled?
• Zone Preference
e
• Launch Tag Filtering
or
di
• Controlling VDA machine Load Balancing in FMA XenApp and XenDesktop:
s tri
https://www.citrix.com/blogs/2017/03/30/controlling-vda-load-balancing-in-fma-xenapp-xendesktop/
b
• How to Calculate the Load Evaluator Index on DDC: https://support.citrix.com/article/CTX202150
ut
• Load management policy settings: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-
io
ltsr/policies/reference/load-management-policy-settings.html

You have enabled all of the load management HDX

policy settings. For a test VDA machine, the Max
N
Sessions index is 6000, the CPU Load Rule Index
ot
is 8000, the Memory Load Rule Index is 5000, and
fo
the Disk Load Rule Index is 1000. What is the
combined Load Index for the VDA machine?
rr
es
The combined load index is 8600, because the highest
index input is 8000 from the CPU Load Rule Index,
al
and then 5% of the other inputs is added to it (0.05 *
e
12000 = 600).
or
di
s
tri
utb
io
n

N
Site Management
ot
Considerations
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the appropriate management and
N
administration design.
ot
• Describe how defining a change control structure
and process contributes to Site stability and
fo
consistency.
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Determine the appropriate management and administration design.
• Describe how defining a change control structure and process contributes to Site stability and consistency.

Citrix Director
1
Scalability High Availability Other Considerations
N
ot
• Recommended to use a • The Monitoring database can be • A Director server can access
fo
dedicated machine with at least configured for high availability. multiple Sites, but only data from
rr
4 CPU cores and 4 GB RAM per one Site can be viewed at a
• Configure Director to
100 Director Help Desk users. time.
es
communicate with multiple
• Director can be co-located with Delivery Controllers in a Site. • PowerShell can be used to
al
a Delivery Controller in small adjust the data grooming period.
e
• Multiple Director servers can be
environments.
or
load-balanced with a single
URL.
di
s
tri
but
io
n
Key Notes:
• When considering whether to co-locate the Delivery Controller and Director roles in a small environment, consider the
expected single server scalability of these roles with the available CPU and memory resources. If the size of the
environment is well below these limits, it would make sense to co-locate them, while recognizing the risk due to an
increased failure domain.
• Incorporating each of the high availability configurations mentioned above will ensure that administrators will continue to
have access to monitoring data regardless of whether a single database instance, Delivery Controller, or Director server

goes offline.
• By default, the data grooming value will depend on which licensing is in place. If Premium licensing is
available, this setting can be changed via PowerShell to take advantage of the maximum licensed historical
data (as of Build 7 1909, this is unlimited for Premium licensing, and limited to 31 days for Advanced
licensing).
• Set-MonitorConfiguration configures the configuration settings used by the Monitor Service.
• C:\PS>Set-MonitorConfiguration -GroomSessionsRetentionDays 5 -GroomFailuresRetentionDays 4 - Updates
N
the settings in the site database with the newly specified values.
ot
fo
• Best Practices for Citrix Director: https://support.citrix.com/article/CTX139382
rr
• Granularity and retention: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/director/data-
es
retention.html
al
e
or
di
s tri
b ut
io
n

Management
Distributed Model
Console Location
Distributed Model
StoreFront Studio Provisioning Console WEM
• Each console installed on its
respective component server.
N
WEM
ot
• Easy to set up; works for
POCs and smaller StoreFront Delivery Controller Citrix Provisioning WEM Server
fo
environments.
rr
Administrative Server Model
es
Administrative Server Model
• Each console installed on a
al
dedicated server apart from
e
their respective components.
or
• Easier to manage access to
StoreFront Studio Provisioning WEM
consoles and increases Console
di
scalability of components,
s
especially for larger
tri
environments.
b
Administrative Server
ut
io
n
Key Notes:
• Although web-based consoles such as Director, the Citrix Licensing server console, and the Citrix Gateway GUI are not
installed on a machine, access can be configured to occur only through the designated administrative server.
• The consoles can also be published using a Multi-Session VDA machine, this will allow IT teams to connect to these
consoles remotely and work more efficient.
• Ensure firewall ports allow communication from the Admin Server/Console to the respective components.

Change Control
Sample change control process
Change Request for

Requester
N
change
NO
ot
Update
fo
Valid request
OK? change
information
control log
Change
rr
No Review
Manager NO
change
es
Analyze Confirm Schedule Review request
Review trends and
change change OK? staging and staging OK?
implementation
al
impact priority Implementation results results
e
Change Assess Review
or
Advisory change OK? change
impact trends
Board
di
s
Change Conduct Conduct
tri
Implementer staging implementation
b
ut
io
n
Key Notes:
• Standardized processes that manage changes throughout a system’s lifecycle are necessary to ensure consistent and
accountable performance. The following change control leading practices should be considered.
• Use a change control window so that all applicable parties know when there might be downtime.
• Make sure that all teams are represented in the Change Advisory Board (CAB). The relevant resources should have
been identified during the Assessment phase.
• Every change should have a roll back plan.

• If a change fails, have meeting with key team members to determine what went wrong.
• Always use an automated change control system so that support staff can quickly and easily identify
changes.
• When available, ensure configuration logging is enabled to track any changes made to the Citrix
environment.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Examine the sample change control process on
N
the previous slide. What are some possible pitfalls
ot
that could occur if the following components are
not present in the change control process?
fo
rr
• Automated change control log
es
• Back-out plan
al
• Staging/test phase
e
• Change advisory board
or
di
s
tri
utb
io
n

Automated change control log
• Without an automated change log system it is easy
to forget an update or miss crucial parts of the logs,
possibly even introduce errors through the updates.
Back-out plan
N
• If a back-out plan is not defined you risk downtime
ot
when an update does not go as planned.
fo
Staging/test phase
• Skipping the staging/test phase limits your ability to
rr
predict the outcome of updating the production
es
environment.
al
Change advisory board
e
• The change advisory board will typically be
architects with a broader understanding of the whole
or
infrastructure and business drivers, their input and
sign of ensures that the update does not introduce
di
other errors.
s
tri
b
ut
io
n

N
Control Layer Scalability and
ot
High Availability
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the appropriate Site design and baseline
N
specifications to ensure performance and stability.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the appropriate Site design and baseline specifications to ensure performance and stability.

Site Database Scalability
SQL Server Sizing Database Storage Sizing

Database Expected
Users CPU RAM Key Sizing factors
type max. size
N
0 – 5K 2 cores 4 GB RAM Number of users, published
Site 31 – 426 MBs
ot
applications, virtual desktop type.
fo
Retention period, number of
605 MBs -
rr
5 – 15K 4 cores 8 GB RAM users, number of sessions,
Monitoring 2805 MBs
number of connections, VDI or
(After 1 Month)
es
HSD workers.
al
15K+ 8 cores 16 GB RAM Usage of MCS, number of
Config. Logging 30 – 200 MBs
administrative actions.
e
or
• Host database files and transaction logs on • Sizing estimates do not include transaction logs,
separate hard disk subsystems. and in larger environments these should be
di
monitored and backed up regularly to prevent
s
• This will help database cope with high number of
tri
excessive growth.
transactions during boot storms.
b ut
io
n
Key Notes:
• The SQL server must be sized correctly to ensure the performance and stability of an environment. Since every Citrix
product uses SQL server in a different way, no generic all-encompassing sizing recommendations exist, but are available
on a product-by-product basis.
• In addition to the Site, Monitoring, and Configuration Logging databases, a system-wide temporary database (tempdb) is
provided by SQL Server, and is used to store Read-Committed Snapshot Isolation data. Citrix Virtual Apps and Desktops
7.x uses this SQL Server feature to reduce lock contention on the Citrix Virtual Apps and Desktops databases (thus

extending the feasible range of a single Site).
• If Citrix Studio is used to create a new Citrix Virtual Desktops database, or upgrade an existing one, in
many cases it automatically enables Read-Committed Snapshot at that time, however this might not
always be possible, in which case it is necessary to manually enable the option.
• The size of the tempdb database will depend on the number of active transactions, but in general it is not
expected to grow more than a few MBs. The performance of the tempdb database does not impact the
performance of Citrix Virtual Apps and Desktops brokering, as any transactions that generate new data
N
require tempdb space.
ot
• Citrix Virtual Apps and Desktops tend to have short-lived transactions, which help keep the size of the
fo
tempdb small.
rr
es
• Database Sizing Guidance for XenApp and XenDesktops Versions 7.6 through Current Release:
al
https://docs.citrix.com/en-us/advanced-concepts/implementation-guides/database-sizing-guidance-for-
xendesktop-7-6.html
e
• Database sizing tool for XenDesktop 7: https://docs.citrix.com/en-us/advanced-concepts/design-
or
guides/database-sizing-tool-for-xendesktop-7.html
di
• How to Enable Read-Committed Snapshot in XenDesktop: https://support.citrix.com/article/CTX137161
s tri
b ut
io
n

Site Database High Availability
HA Feature Description Key Considerations
• When local host cache is active, only one Delivery

Controller per FMA zone can broker connections and
N
Local copy of SQL database on Delivery must be sized with that in mind.
ot
Local Host Cache Controller that allows users to connect to • Supported for server-hosted applications and desktops,
resources. and static (assigned) desktops.
fo
• No administrative functions available.
rr
• Requires an on-premises StoreFront deployment.
es
A VM is restored on another host, provides • Available for virtual SQL servers only.
all Site functions, including administrative • Provides availability in power loss scenarios but does
al
VM-Level HA
actions, monitoring, and configuration not protect from OS-level corruption.
e
logging data. • Failover may be slower than SQL HA methods.
or
SQL HA Can provide near-instantaneous failover of
di
• Requires additional SQL servers, configuration, and
(Mirroring, the SQL databases to provide continuous
s
licensing, but provides highest level of availability.
Clustering, access to Site and administrative
tri
• Recommended for enterprise-level environments.
AoAG) functions.
b ut
io
n
Key Notes:
• To Summarize Key Design Considerations, sample questions to answer are:
• Will Local Host Cache be used?
• Will we rely on VM-level HA for SQL itself, or can/will we leverage one of the SLQ HA features?
• This is typically based on the type of SQL licensing and implementation capabilities within the organization and
how important SQL HA is.
• Local Host Cache

• When using local host cache mode, a single Delivery Controller is responsible for all VDA registrations,
enumerations, launches and updates. The elected controller must have enough resources (CPU and
RAM) to handle the entire load for the zone.
• When the zones loses contact with the SQL database, an election occurs nominating a single Delivery
Controller as master. All remaining Delivery Controllers go into idle mode. A simple alphabetical order
determines the winner of the election.
• In an on-premises environment, the local host cache services can consume 2+GB of RAM depending on
N
the duration of the outage and the number of user launches during the outage and can use up to 4 CPU
ot
cores in a single socket. Citrix recommends using multiple sockets with multiple cores. In Citrix testing, a
fo
2x3 (2 sockets, 3 cores) configuration provided better performance than 4x1 and 6x1 configurations.
• In a Citrix Cloud environment, the Local Host Cache feature uses only one socket for multi-core CPUs for
rr
the connector VM configuration. In this scenario, Citrix recommends a 4-core, 1-socket configuration.
es
• During local host cache mode, storage space increased 1MB every 2-3 minutes with an average of 10
al
logons per second.
• Local Host Cache requires a customer-deployed on-premises StoreFront as part of the deployment. You
e
must add all Cloud Connectors that have (or can have) VDAs registered with them to the StoreFront as
or
Delivery Controllers. A Cloud Connector that is not added to the StoreFront cannot transition to outage
di
mode, which might result in user launch failures.
• VM-Level HA
s tri
• VM-Level HA means implementing high availability at the hypervisor level by replicating a virtual machine
b
to another host in case of a failure.
ut
• This type of high availability provides availability in power loss scenarios but does not protect from OS-
io
level corruption.
• Because a full copy of a machine has to be completed, this option may take longer to complete than
n
other SQL HA methods causing longer down times.
• SQL HA
• SQL HA provides near-instantaneous failover of the SQL databases to provide continuous access to Site
and Administrative functions.
• It requires additional SQL servers, configuration and licensing, but provides the highest level of

availability and therefore, is recommended for enterprise-level environments.
• The following database high availability solutions are supported:
• SQL Server AlwaysOn Failover Cluster Instances
• SQL Server AlwaysOn Availability Groups (including Basic Availability Groups)
• SQL Server Database Mirroring
N
• Local Host Cache: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-
ot
deployment/local-host-cache.html
fo
• Local Host Cache (Citrix Virtual Apps and Desktops Service): https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops-service/install-configure/resource-location/local-host-scale-and-size.html
rr
• Scale and size considerations for Local Host Cache (Citrix Virtual Apps and Desktops Service):
es
https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/install-configure/resource-location/local-host-
al
scale-and-size.html
e
or
di
s tri
b ut
io
n

Delivery Controller Scalability
Delivery Controller Sizing Equation
Number of Delivery Controllers

• The sizing equation shown can be used to help
=
N
determine how Delivery Controllers are needed in a
+1
ot
Site/Zone. 5,000
• The brokering and STA roles could be configured to
fo
be on dedicated Delivery Controllers but would only
rr
make sense for extremely large environments.
es
Assumed Specifications
• It is feasible to co-locate Delivery Controller with
al
StoreFront and/or Director roles in PoC, non- • 4 vCPU
e
production and small environments. • 4 GB RAM
or
• Bonded virtual NIC
• 40 GB storage
di
s tri
b ut
io
n
Key Notes:
• Delivery Controller scalability is based on CPU utilization. The more processor cores available, the more virtual desktops a
controller can support.
• Each desktop startup, registration, enumeration and launch request impacts the controller’s processor. As the storm
increases in intensity, the CPU utilization of the controller will increase.
• If the CPU reaches a critical threshold, roughly 80%, the site will need to either scale up or scale out.
• The duties performed by the STA are not expensive in CPU terms; it is a light XML service limited only by the performance

of IIS. In one test, a low-range server with a 1GHz processor and 256MB of RAM supported over 250 ticket
requests per second while CPU utilization stayed below 60%.
• Adding additional CPU cores to a Delivery Controller will lower the overall CPU utilization, thus allowing for
greater numbers of desktops supported by a single controller. This is really only feasible when dealing with
virtualized controllers as adding virtual CPUs is fairly easy and straightforward.
• The other alternative is to add another controller into the site configuration. The controller would have the
same configuration as other controllers, and the load would be evenly distributed across all controllers, thus
N
helping to reduce the overall load on each single controller.
ot
• The Delivery Controller can be collocated with the StoreFront and Director roles in small or non-production
fo
environments where user and session numbers are well below the expected single-server scalability of each
of the roles, and the increased failure domain is tolerable.
rr
es
al
e
or
di
s tri
but
io
n

Delivery Controller Component High Availability
Secure Ticket Authority Windows Communication

XML Brokering Function
N
(STA) Function Foundation (WCF) Function
ot
• Multiple Delivery Controllers can • Multiple STA servers should be • Commonly known as the VDA
fo
be configured per Site in configured for the Citrix Registration function.
rr
StoreFront. Gateway. Ensure consistency of
• Multiple Delivery Controllers
es
STA configuration within
• Alternatively, Citrix Gateway can should be configured for access
StoreFront and Citrix Gateway
al
provide a load-balanced VIP for by VDA machines using one of
virtual server.
e
the XML service. various methods.
or
• Network load balancing cannot
• VDA machines automatically
be configured because a VIP or
attempt to failover to an
di
other common name will break
alternate Delivery Controller if
s
the STA validation process.
tri
communications are interrupted.
b ut
io
n
Key Notes:
• If the only Delivery Controller fails…
• Published resources cannot be enumerated on StoreFront
• No new sessions can be launched (existing sessions unaffected)
• No Power Management on VDA machines
• No management via Studio or PowerShell
• Director cannot be used

• VDA machines cannot register with the Site
• To make resource enumeration and session brokering/launching highly available, at a minimum add N+1
Delivery Controllers to the applicable StoreFront Store(s). StoreFront can use a failover or round-robin load
balancing method to contact the Delivery Controllers.
• Load balancing is typically recommended in order to distribute the load across all Delivery Controllers. Citrix
Gateway can provide intelligent load balancing of the Delivery Controllers via the use of a VIP. The VIP would
then be added to StoreFront. Some customers prefer to place both the VIP and individual Delivery Controllers
N
within a Store configuration (in failover mode) to guard against a Citrix Gateway failure; however, keep in mind
ot
that with this method the first individual Delivery Controller in the failover list would need to support the entire
fo
environment.
• If possible, implement Citrix Gateway HA to mitigate the risk of this occurring.
rr
• Citrix Gateway allows for multiple Secure Ticket Authority (STA) URLs to be configured. These are contacted
es
in a round-robin fashion; if an STA fails to respond, the virtual server tries another STA on the list.
al
• The virtual server must always contact each STA individually based on its STA ID. When configuring the
address of each STA in the virtual server, each STA address must be the true address of the STA server — do
e
not enter the address of any hardware load balancer, cluster name, or round-robin DNS name here.
or
• Otherwise, users receive intermittent denials because, during the ticket validation process, the gateway might
di
be load balanced to an authority that did not originally generate the user’s ticket.
• VDA machines will automatically check the following locations for alternative Delivery Controllers is
s tri
communications with the Controller to which it is currently registered are interrupted:
b
• Persistent storage location provided via the auto-update feature (if enabled)
ut
• FMA policy settings (if configured)
io
• ListofDDCs registry key (if configured during VDA installation or the VDA has populated it afterwards)
• OU-based discovery (legacy method maintained for backwards compatibility)
n
• Personality.ini file (Machine Creation Services machines only)
• FAQ: Citrix Secure Gateway/ NetScaler Gateway Secure Ticket Authority (Scalability):
https://support.citrix.com/article/CTX101997#Q1_Scalability

Citrix License Server Scalability
• If necessary, the specification of the license server can be scaled out to support a higher number of license
N
requests per second.
ot
• However, this should only be necessary for very large environments that experience logon storms at certain
fo
times of day.
rr
• License server performance can be optimized by tuning the number of “receive” and “processing” threads.
es
al
Citrix License Server Specs
e
This server can …which translates
or
issue 170 licenses to 306,000 licenses
per second… per half hour.
di
CPU: 2 cores
s
RAM: 2 GBs
tri
b
Based on internal Citrix testing
ut
io
n
Key Notes:
• If the thread count is set too low, requests will be queued until a thread becomes available. Conversely, if the thread count
is set too high, the license server will become overloaded. These values are configured via the License Administration
console.
• The optimal values are dependent on the server hardware, site configuration, and license request volume. Citrix
recommends testing and evaluating different values to determine the proper configuration.
• Setting the maximum number of processing threads to 30 and the maximum number of receiving threads to 15 is a good

starting point for large scale deployments. This optimization will improve the Citrix License Server‘s ability to
provide licenses by increasing its ability to receive and process license requests.
• Improve performance by specifying thread use: https://docs.citrix.com/en-us/licensing/current-
release/manage/thread-use.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Citrix License Server High Availability
No Redundancy VM-Level Backup Windows Clustering
N
ot
• Citrix products enter a 30-day • Create a VM level backup of the • Clustering allows the license
fo
grace period if License Server license server. server role to automatically
rr
fails. failover during a failure.
• This creates a cold standby that
es
• Sufficient for typical can be used to quickly restore it
environments.
al
after a failure.
e
or
di
s
Grace period
tri
b ut
io
n
Key Notes:
• If the license server and the Citrix product do not communicate within 2 heartbeats (5-10 min), the Citrix product will enter
a grace period and will allow connections for up to 30 days. Once communication with the license server is re-established,
the license server will reconcile the temporary and actual licenses.
• A CNAME record in DNS is a convenient way to reference the license server. Using CNAMEs allows the license server
name to be changed without updating the Citrix products.
• Does the Citrix License Server need to be highly available? In most cases, the grace period is sufficient. Typically, high

availability for this component is only implemented at very large organizations with demanding
uptime/resiliency requirements.
• Each redundancy method allows an administrator to exchange a single license server for another without an
interruption in service; assuming that the change occurs during the grace period and that the following
limitations are considered:
• License files will reference the server specified during the allocation process. This means that the license
files can only be used on a server with the same binding information (Hostname) as the server that was
N
previously specified.
ot
• Two Windows-based, domain joined license servers cannot share the same name and be active in the
fo
environment at the same time.
• Because license servers do not communicate with each other, any additional licenses must be placed on
rr
both the active and backup license server.
es
• In addition to the methods mentioned above, some customers have also utilized Citrix Gateway load balancing
al
to provide automatic, instantaneous failover between servers. This method requires the most setup, but would
fulfill even the highest resiliency requirements.
e
or
di
• Clustered License Servers: https://docs.citrix.com/en-us/licensing/current-release/clustered-license-
servers.html
s tri
• Disaster Recovery - Back up and Redundancy: https://docs.citrix.com/en-us/licensing/current-
b
release/backup.html
ut
io
n

Citrix Cloud Scalability and High Availability Considerations
Citrix Connector Sizing
• Three Cloud Connectors (4vCPU, 4 GB RAM) can support 5K Single-Session OS VDAs or 500 Multi-Session
N
OS VDAs.
ot
• Always deploy N+1 Connectors in the environment because a Connector will become unavailable while it is
being updated.
fo
rr
• Keep Cloud Connectors online.
• If a Cloud Connector misses two updates in a row, it may lose connectivity with Citrix Cloud.
es
• Always deploy on dedicated Windows Servers. Citrix may reboot the machine during updates or as part of active
al
maintenance.
e
or
di
s tri
b ut
io
n
Key Notes:
• Most of the Control Layer components are managed by Citrix, which handles sizing and high availability considerations.
• Remember, Citrix has a goal of 99.5% availability over a 30-day period.
• These scalability recommendations enable the Cloud Connectors to handle registration storms, which would occur when
the Delivery Controllers and Site database are updated every two weeks. Remember:
• Citrix may roll out updates that require a Cloud Connector reboot, if the customer has multiple Cloud Connectors,
Citrix will automatically complete the reboot. Therefore, do not install the Cloud Connectors on file servers, database

servers and other critical production servers.
• A Cloud Connector receive automatic updates to be compliant with the build level of Citrix Cloud, if a
Cloud Connector is offline for an extended period of time >3 weeks, it may not receive the needed
updates to be compliant with Citrix Cloud. The automatic update function distributes deltas, so if you miss
an update window, the Cloud Connector may need re-install.
• The scalability test performed by Citrix only covers VDA registration and session launch, it does not include
HDX proxy through the Connector and it does not account for other services such as XenMobile using the
N
same Connectors.
ot
fo
• Citrix Cloud Virtual Apps and Desktops Service Sizing and Scalability Considerations:
rr
https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/install-configure/install-cloud-connector/cc-
es
scale-and-size.html
al
e
or
di
s tri
but
io
n

You are working with a non-profit organization that

plans to support 500 total users, and a maximum
of 100 concurrent users, on a Citrix Virtual Apps
and Desktops environment. The non-profit would
like to minimize its hardware requirements where
N
possible. What would you recommend in this
ot
situation?
fo
rr
• Option 1: If the organization wants to control the
entire infrastructure, it should consider co-locating
es
the Delivery Controller, StoreFront, and Director
al
components on two servers. A public cloud such as
e
Azure or AWS should be considered to minimize the
or
hardware that needs to be managed.
di
• Option 2: If the organization does not need or want to
s
control the entire infrastructure, it should consider
tri
using Citrix Cloud while potentially placing the VDA
b
machines in a public cloud.
ut
io
n

N
ot
Control Layer Security
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Assess the Control Layer security requirements and
N
features necessary to secure a Citrix Virtual Apps
ot
fo
rr
es
al
e
or
di
stri
b ut
io
n
Key Notes:
• Assess the Control Layer security requirements and features necessary to secure a Citrix Virtual Apps and Desktops
environment.

Secure Site Internal
Communications Unsecure Configuration:
XML Traffic sent in clear text:

• User credentials (passwords obfuscated)
• Available resources
N
Citrix recommends securing
ot
80
XML traffic between the
fo
StoreFront servers and StoreFront Delivery Controller
rr
Delivery Controllers using the
TLS protocol.
es
Recommended Configuration:
al
e
or
di
443
s tri
StoreFront Delivery Controller
utb
io
n
Key Notes:
• While it is leading practice to secure XML traffic, unsecured XML traffic does not present the same security risk as an
unsecured connection to StoreFront, because the XML traffic between StoreFront and Delivery Controller is typically
internal with both servers on the same VLAN- unlike a browser connection to StoreFront where the user could be coming
in from untrusted/public Wi-Fi connections.
• In addition, it is also recommended to secure XML communication to Cloud Connectors in a Citrix Cloud deployment.
• Steps for configuring SSL/TLS for XML traffic:

• Install server certificate on each Delivery Controller (private certificate should be used because it is only
accessed by StoreFront).
• Configure correct port (default: 443) with SSL/TLS certificate created in above step.
• Disable the port 80 listener on the Delivery Controller.
• Configure StoreFront to leverage https as the transport type for the Delivery Controller.
• The XML port is 80 by default and is shared with other FMA services. If 80 is unacceptable for security
reasons, a custom port can be configured via command line.
N
• Most customers use default port numbers now due to the availability of good network scanners. By
ot
default, many of the FMA services use the same port for different functions. For example, the broker
fo
service uses port 80 for VDA registrations, XML requests and the SDK. However, this prevents the
implementation of granular firewall rules for each of these different functions.
rr
• Fortunately, the FMA service can be configured to use different port numbers for different functions. From
es
a command prompt, query the executable of an FMA service to see what options you have.
al
• Example:
• BrokerService.exe –VdaPort 8081 –WiSSLPort 8082 –SDKPort 8083 –ConfigureFirewall
e
• In this example, instead of simply changing the port for all services, we are splitting the port (instead
or
of using single port, we will use different ports for different services). After doing this, we can
di
configure the firewalls to block access to specific ports – so for example port 8083 (SDK, required by
PowerShell\Citrix Studio for management) is not available for virtual desktops, but only from
s tri
management workstations.
b ut
io
• Transport Layer Security (TLS): https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-
ltsr/secure/tls.html
n
• How to Enable SSL on XenDesktop 7.x Controllers to Secure XML Traffic:
http://support.citrix.com/article/CTX200415
• How to Enable SSL on Cloud Connectors to Secure XML Traffic: https://support.citrix.com/article/CTX221671

Secure Site Internal Communications
SQL
1. Add certificate to SQL server.

2. Enable TLS by setting the Force Encryption flag to Yes.
• Configure on SQL Server to force encryption for all connections with that SQL Server.
• Configure on Delivery Controller to force encryption from Controller to any SQL Server.
N
• Use PowerShell on Delivery Controller to force encryption for individual SQL connection strings.
ot
fo
rr
es
al
e
FMA Services
443
or
di
Delivery Controller Site Database
s tri
b ut
io
n
Key Notes:
• By default, the SQL traffic between a Citrix Virtual Desktops Controller and an SQL Server is unencrypted, and because of
the nature of SQL, it is largely in plain text. If all the Site’s Controllers and SQL Server are on a secure network this is not
a concern, however in some cases it might be required to encrypt the SQL traffic using SSL.
• This can be accomplished in a number of ways.
• Microsoft SQL Server provides three basic configurations for encryption of SQL traffic between the Controllers (clients)
and an SQL Server. In all cases, a suitable certificate must be installed on the SQL Server that can be verified by an

appropriate certificate chain on each Controller.
• This requires the root certificate of the server certificate's Certificate Authority (CA) be exported and installed
on each Controller. Where connections to multiple SQL Servers are to be encrypted, the appropriate CA root
certificate for each server must be installed on all Controllers.
• Use of SSL in this way encrypts the data flowing through the SQL connections and authenticates the SQL
Server identity to the Citrix Virtual Desktops Controllers.
• Four potential approaches:
N
• Forcing Encryption at the SQL Server: Encryption can be specified as a requirement at the SQL Server.
ot
In this case, all incoming SQL connections from any client (Citrix Virtual Desktops Controller or
fo
otherwise) are encrypted. This is configured by specifying Force Encryption on the SQL Server.
• Forcing Encryption at the Controller (client): Encryption can be specified as a requirement at each Citrix
rr
Virtual Desktops Controller. In this case, all outgoing connections from a Controller to any SQL Server
es
are encrypted. This is configured by specifying Force Protocol Encryption on each Controller (client)
al
machine. If encryption is forced at the Controllers for a Citrix Virtual Desktops 7 Site using multiple SQL
Servers, appropriate certificates must be provisioned for all SQL Servers because all Controllers connect
e
to all the servers.
or
• Forcing Encryption for each Service: Encryption can be specified as a requirement on each individual
di
SQL connection through a setting in a service’s SQL connection string. In this case, neither the Force
Encryption option on the server nor the Force Protocol Encryption option on the Controllers should be
s tri
specified.
b
• To enable encryption in this configuration requires the connection strings of the Citrix Virtual Desktops
ut
services on all Controllers to be modified by the addition of the ‘Encrypt=True’ option. That is, a
io
connection string such as:
“Data Source=sqlserver.mydomain.net; Initial Catalog=CitrixXDSite; Integrated Security=True”
n
Becomes:
“Data Source=sqlserver.mydomain.net; Initial Catalog=CitrixXDSite; Integrated Security=True;
Encrypt=True” Warning! Setting the Encrypt=True option in a connection string where an appropriate
certificate and CA root certificate have not been provisioned results in the connection failing; this
prevents the impacted Citrix Virtual Desktops service from functioning.

• Encryption without validation: It is possible to configure encryption without provisioning appropriate
server and client certificates. In this case, a self-signed certificate is used by the SQL Server. This style
of encryption can be used in all three configurations listed above by setting the Trust Server Certificate
option to True on the SQL Server, Controller (client) or in the connection string respectively.
• While the resulting connections are encrypted, this is less secure than using provisioned certificates. It is
vulnerable to man-in-the-middle attacks and is thus not recommended for production environments.
• Each Citrix service accesses the site database using the Controller's AD machine account to enhance
N
security. Management tools do not have a direct connection to the database and must be proxied through a
ot
Delivery Controller.
fo
• SQL Security Authentication is a very important concept in FMA security. All the configuration is stored in
database and it’s crucial that this database is properly secured.
rr
• FMA is using computer accounts rather than user accounts to authenticate against SQL. By doing this,
es
the password for the service account is not stored anywhere (machine identity is used instead), and the
al
machine password is actually changed every 30 days.
• Management tools (Studio, Director or PowerShell) don’t have direct access to database and needs to be
e
proxied by a Controller – therefore you don’t need to expose your SQL server and can properly design a
or
security networking zone.
di
• What this also means is that while you need elevated privileges to add a new Controller to the site, these
privileges are not needed for runtime.
s tri
• Use of SQL logons (SQL authentication) is not supported, as it might lead to the account passwords being
b
exposed through SDKs. It should never be necessary to manually modify the users, roles, or permissions
ut
created within the Citrix Virtual Desktops database.
io
n
• How to Enable Secure SQL Database Connection String with XenDesktop:
• Enable Encrypted Connections to the Database Engine (SQL Server Configuration Manager):
https://msdn.microsoft.com/en-us/library/ms191192(v=sql.110).aspx
• Database access and permission model: http://support.citrix.com/article/CTX127998

Secure Site Internal
(1)
Communications
Licensing
.pfx file
• By default, the Citrix License Server uses a self-
N
signed certificate to secure communications with (2)
ot
the License Administration Console and Web
Services for Licensing.
fo
• If a CA-signed certificate is desired, the certificate
rr
must be manually installed: Private Key
es
Certificate
1. Obtain a .pfx file, which contains the certificate and
private key.
al
2. Extract the certificate and private key from the .pfx
e
file. (3)
or
3. Install the certificate and private key on to the
License Server program files.
di
s
Citrix License Server
tri
b ut
io
n
Key Notes:
• The web browser uses the License Administration Console and Citrix Licensing Manager. The Delivery Controller, Studio,
and Director use Web Services for Licensing.
• For new installations, the License Server uses HTTPS by default for both the License Administration Console (port 8082)
and for Web Services for Licensing (port 8083). For HTTPS, the License Server selects TLS 1.0, TLS 1.1, or TLS 1.2, as
determined by the web browser, Delivery Controller, Studio, or Director.
• Configuration of TLS version or TLS cipher suites within the License Server itself is not supported.

• If you use HTTPS, you must have a valid server certificate. The License Server generates a self-signed
certificating during installation, but you can create your own. Using the self-signed certificate will typically
generate web browser certificate warnings on the web browser used to access the console.
• The .pfx file can be obtained via one of two methods:
• Obtain the .pfx file using a domain certificate
• Obtain the .pfx file sending a request to a Certificate Authority (CA)
• Extracting the certificate and private key from the .pfx file requires OpenSSL or another tool with this
N
functionality. Note that the version of OpenSSL shipped with the License Server does not support extracting
ot
certificates and private keys.
fo
• When installing the certificate and private key, they must be installed to the following locations:
• Web Services for Licensing: c:\Program Files
rr
(x86)\Citrix\Licensing\WebServicesForLicensing\Apache\conf\
es
• License Administration Console: c:\Program Files (x86)\Citrix\Licensing\LS\conf
al
• The Citrix Web Services and Citrix Licensing Server must each be restarted so that they can begin using the
new certificates.
e
• Additional Citrix License Server security practices:
or
• Change port numbers
di
• The Licensing installation sets several port numbers for communications. After installation you can
use the License Administration Console to change port numbers.
s tri
• Console Web Server Port: The HTTP TCP/IP port that the Web server uses to listen for
b
communication with clients connecting to the License Administration Console. By default, the port is
ut
set to 8082. If you are already using that port number for another application, you can change it to a
io
range between 1 and 65535.
• If you use HTTPS, the default port is 443. If you change the port, you must stop and restart the Citrix
n
Licensing service.
• License Server Manager Port: This port number is used by the license server manager, which
handles the initial communication between the products, starts the vendor daemon, and relays check
out and check in requests to the vendor daemon. By default, this port number is 27000.
• Vendor Daemon Port: This port number is used by the Citrix vendor daemon, which is responsible for

the core operations of the license server, including license allocation. By default, this port number is
7279; however, you may need to change it if you have a firewall or if the number is already in use.
• Specify a user session timeout
• You can log out users after a specified time of inactivity, ensuring they do not leave the console
unattended.
• Require users to log onto dashboard
• You can optionally secure the Dashboard by forcing users to enter a password. The Administration
N
area is password-protected for all users.
ot
• Change the console password
fo
• You can change your License Administration Console password at any time.
• This applies only to accounts created by the License Server, not Windows user accounts. Active
rr
Directory users and local Windows users can change their passwords using their native operating
es
systems.
al
• On Windows, if you log on as a Locally Managed user and then log on, the Change Password link
displays at the bottom right corner.
e
or
di
• Licensing FAQ: https://docs.citrix.com/en-us/licensing/current-release/frequently-asked-questions.html
• Citrix Licensing Manager: https://docs.citrix.com/en-us/licensing/current-release/citrix-licensing-manager.html
s tri
• Licensing: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-
b
deployment/licensing.html
ut
• Security (Citrix License Server 11.16.3): https://docs.citrix.com/en-us/licensing/current-
io
release/manage/secure-console.html
• Citrix Common Criteria Certification Information (Citrix License Server PDF - look in Common Criteria
n
Documents for XenDesktop XenApp 7.6 Platinum): https://www.citrix.com/about/legal/security-
compliance/common-criteria.html

Compliance Reporting Options in Citrix Virtual Apps and Desktops
Citrix Virtual Apps and Citrix Virtual Apps and

Citrix Hypervisor Citrix Provisioning
Desktops Desktops Service
Audit Log report logs Citrix
Configuration changes and
Configuration changes and Hypervisor events, event objects The auditing tool can provide a
administrative activities initiated
N
administrative activities initiated and actions, including record of all administrative actions
from the service’s Studio
from Studio, Director, and import/export, host and pool made to the Citrix Provisioning
ot
(Manage), Director (Monitor), and
PowerShell scripts are logged. backups, and guest and host Farm.
PowerShell scripts are logged.
console access.
fo
Administrators cannot see log
rr
Administrators can use
entries for Citrix Cloud platform Audit log reports can be stored on
configuration logging reports Auditing information can be
es
internal operations, such as remote servers which are
within Studio to document exported and archived.
database setup and managed by a different team.
changes to a Site over time.
al
management.
e
Audit Log is always enabled in the
or
Configuration Logging is always
Enabled by default. Workload Balancing virtual Not enabled by default.
enabled. Cannot be disabled.
appliance.
di
s tri
b ut
io
n
Key Notes:
• With configuration logging on Citrix Virtual Apps and Desktops you can:
• Capture Site configuration changes and administrative activities to the Database.
• Assist change management and track configurations.
• Reports administration activity.
• Set Configuration Logging preferences, display configuration logs, and generate HTML and CSV reports from Citrix
Studio.

• This feature is enabled by default, and the configuration logging database supports the same high availability
features as the Site configuration database.
• Citrix Provisioning provides an auditing tool that records configuration actions on components within the Citrix
Provisioning Farm, to the Citrix Provisioning Database. This provides administrators with a way to
troubleshoot and monitor recent changes that might impact system performance and behavior.
• The Citrix Provisioning administrator privileges determine the audit information that can be viewed and the
menu options that are visible. For example, a Farm Administrator can view all audit information within the
N
Farm, unlike a Device Administrator whom can only view audit information for those Device Collections they
ot
have privileges to.
fo
• The Citrix Hypervisor audit log records any operation with side effects (successful or unsuccessful). This
record includes the server name targeted by the action and the success or failure of the action.
rr
• The audit log also records associated usernames or, if RBAC is not enabled, the type of account association
es
with the action.
al
• To increase the security and availability of the contents of the configuration/audit logs and reduce the risk of
an attacker changing its contents, consider sending your audit log to a remote server, ideally one inaccessible
e
to administrators of the monitored component.
or
• Citrix recommends both of the following:
di
• Remote servers for storing logs be managed by somebody with different operational role (for example, by
somebody on a team that does not manage the Citrix Hypervisor hosts or Citrix Provisioning Farm, for
s tri
example).
b
• Administrators with access to an administrative component should not be granted permissions to modify
ut
or delete logs on the remote server.
io
n
• Configuration Logging on XenApp and XenDesktop: https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops/1912-ltsr/monitor/configuration-logging.html
• Configuration Logging on Citrix Virtual Apps and Desktops Service: https://docs.citrix.com/en-us/citrix-virtual-
apps-desktops-service/manage-deployment/configuration-logging.html
• Auditing: https://docs.citrix.com/en-us/provisioning/1912-ltsr/troubleshooting/auditing.html

• Audit Log Events: https://docs.citrix.com/en-us/citrix-hypervisor/wlb/administer.html#generate-workload-
reports
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Session Recording
1. Policies are configured via
the SR Policy Console.
Session Recording SR Policy Console
2. HDX Session is established. Player
3. SR Agent verifies recording

policy with SR Server.
N
6 1
ot
4. SR Agent records session
and sends data to SR Server. 2 3 5
fo
5. SR Server logs session data;
rr
Multi-Session OS 4
it sends metadata to the Session Recording
Endpoints VDA Server
es
Session Recording
database and the recordings w/ SR Agent Database
to storage.
al
e
6. SR Player can retrieve and 5 7
play session recordings by
or
contacting SR Server.
di
7. Files can be archived via 3rd
s
3rd Party Archiving
party archive solutions. Storage
tri
Solution
b ut
io
n
Key Notes:
• Session Recording & Troubleshooting (SRT) is a technology available only in Citrix Virtual Apps and Desktops Premium
Edition. It uses flexible policies to automatically trigger recordings of Citrix Virtual Apps and Desktops sessions.
• This enables IT to monitor and examine user activity of applications – such as financial operations and healthcare patient
information systems – demonstrating internal control, thus ensuring regulatory compliance and successful security audits.
Similarly, it also aids in technical support by speeding problem identification and time-to-resolution.
• Customer Challenges:

• Logging access to sensitive information — Financial transactions and sensitive access to customer and
patient information must be monitored as a part of regulatory mandates. Organizations need to go
beyond traditional event log monitoring to capture the real access scenario that is taking place.
• Litigation readiness — Preparing for litigation means finding as much information as possible. In fact,
new eDiscovery rules allow for large fines if judges feel that appropriate effort was not taken to ensure
preservation of information that is reasonably accessible.
• However traditional tools are limited to gathering text logs of user activity. Responsible organizations
N
need better methods of gather information for litigation support.
ot
• Monitoring suspicious activity— When good users go bad, organizations need proof in order to protect
fo
themselves legally. At best, existing monitoring and tracking tools help determine the possibility of
criminal intent. Organizations need more definitive evidence to prove intent.
rr
• Reproducing support issues — Not all support issues are easy to solve. In fact, many issues are difficult
es
to reproduce and could require multiple calls between users and IT in order to resolve. IT needs a
al
solution for capturing user problems when they happen.
• Session Recording is considered a security feature, because it’s a similar idea to physical security cameras –it
e
provides direct visibility into what people are doing.
or
• If an employee is doing something “bad” you can quickly respond to that;
di
• And the recording can be used in litigation as evidence later.
• Caution:
s tri
• Remember this tool is meant to be used by the organization. Although a hacker may use a similar tool to
b
get credentials, data, etc; this is not the purpose of this tool.
ut
• It is highly recommended to refer to your legal department to determine the impact if this feature was to
io
be used. In some countries/organizations, it may be illegal to record on-screen activity, or in other cases,
a notification may be needed.
n
• Session Recording: https://docs.citrix.com/en-us/session-recording/1912-ltsr.html

N
ot
fo
What would be the benefit of securing the XML
traffic on the Delivery Controllers?
rr
es
Securing the XML traffic reduces the threat of
attackers sniffing sensitive data transmitted between
al
StoreFront and Delivery Controllers.
e
or
Most large organizations have security policies and
compliance rules in place that mandate such
di
connections to be secured.
s
tri
b
ut
io
n

Exercise 6-1: Conduct a
Redundant POD Deployment
Workspace Lab has informed your team that they
N
want to design for a redundant pod architecture for
ot
6,000 employees which will access resources in the
primary data center.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 6-1: Review Design
Requirements & Update Detailed
Task:
N
ot
fo
requirements met.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Design Requirements (for reference)
General
Support 6,000 concurrent sessions from the New York datacenter. Assume majority of users will be
Control-1 High
utilizing the Hosted Shared Desktop FlexCast model using MCS provisioning.
N
ot
Use fully redundant multi-pod architecture which can support entire user base in the event that a
Control-2 High
single pod becomes unavailable.
fo
Control-3 High All pods in use during normal operations.
rr
es
Control-4 High No single points of failure within a pod. Failure domains minimized where possible.
al
e
or
di
s tri
b ut
io
n

Delivery Controllers
Control-5 Medium Standardize infrastructure components on Windows Server 2016.
N
ot
Control-6 High Size Delivery Controllers to support maximum potential session count for each pod.
fo
Delegated administration used to separate permissions for the core administrator team, managers,
Control-7 Medium
rr
and help desk personnel. Managers only need access to view the user and session data.
es
al
e
or
di
s tri
b ut
io
n

Databases
Control-8 Medium Databases created on SQL 2016 Enterprise servers.
N
ot
Control-9 High Each pod has separate dedicated SQL infrastructure.
fo
Control-10 High SQL infrastructure provides automated failover with minimal downtime.
rr
es
Control-11 High SQL servers appropriately to support environment requirements.
al
e
or
di
s tri
b ut
io
n

Citrix Licensing
Control-12 High All concurrent Premium licenses shared across all pods.
N
ot
Control-13 High Citrix License server(s) sized appropriately for the environment.
fo
Minimize downtime of Citrix License Server failure without requiring advanced configuration and
Control-14 Medium
rr
maintenance.
es
al
e
or
di
s tri
b ut
io
n

Citrix Director
Control-15 High Retain up to one year of monitoring data for reporting and compliance purposes.
N
ot
Administrators and help desk able to access monitoring data from all pods within the same Director
Control-16 Medium
console.
fo
Control-17 Medium Secure access to Director console.
rr
es
Director sized appropriately to support environment. Assume that up to 50 administrators and help
Control-18 Medium
desk associates accessing Director at any given time.
al
e
or
di
s tri
b ut
io
n

Site

1912 LTSR or later • This is the latest Citrix Virtual Apps and Desktops current release version.
version
N
ot
Citrix Virtual Apps and Desktops • Licenses have already been purchased by Workspace Lab.
Platinum Concurrent Licenses
License Edition • Design Requirement Control-12.
fo
Number of Citrix Virtual Apps and • Meets organizational requirement for fully redundant pod architecture within NYC
rr
Desktops Sites at NYC 2 datacenter.
datacenter • Design Requirement Control-2.
es
• Satellite zones will not be used in this environment so that fully separate SQL
al
Number of zones per Site 1 instances can be used for each Site.
• No design requirements defined.
e
or
• Each pod will be able to support the entire user base, but typically users will be split
Typical and Maximum number of 3,000 (Typical)
between both pods.
users per Site 6,000 (Maximum)
• Design Requirement Control-1, Control-2 and Control-3.
di
s tri
b ut
io
n

Detailed Design – Answer Key (Continued)
Delivery Controllers
NYC-1
Site Name(s) • Follows existing naming convention.
NYC-2
Operating System Microsoft Windows Server 2016 • Workspace Lab standard.
N
• In order to implement N+1 redundancy, two or three Delivery Controllers will be
ot
Option 1: 2 needed per Site, depending on how they are sized, to accommodate the maximum
Delivery Controllers per Site
Option 2: 3 potential load.
fo
• Design Requirement Control-1, Control-3, Control-4 and Control-6.
rr
• Either two Delivery Controllers with 6 vCPUs each or three Delivery Controllers with 4
CPU Allocation per Delivery Option 1: 6 vCPUs
vCPUs each would be expected to handle the expected maximum load at each Site.
es
Controller Option 2: 4 vCPUs
al
• RAM is typically not a resource bottleneck for Delivery Controllers, so the allocation
RAM Allocation per Delivery
4 GB RAM can be set at 4 GB and monitored to ensure it is sufficient.
e
Controller
or
Storage Allocation per Delivery
40 GB • Aligns with Citrix baseline guidance.
Controller
di
Full Administrator
s
Read-only • Design Requirement Control-7 and Control-16.
tri
Administrator Groups
Help Desk
b ut
io
n

Databases

SQL 2016 Enterprise
SQL Version • Design Requirement Control-8.
• Although mirroring and clustering are also possibilities, mirroring is scheduled for
Dedicated Always On availability group deprecation, and the customer did not express a preference for one HA method over
High Availability Method
N
per pod. another.
• Design Requirement Control-9 and 10.
ot
• SQL Always On requires a minimum of 2 SQL Servers per Always On Availability
fo
Number of servers 2 in each pod Group.
• Design Requirement Control-9 and 10.
rr
• Based on Citrix sizing recommendations, particularly to accommodate registration
es
CPU Allocation per server 4 vCPU and logon storms in the event of a pod outage.
• Design Requirement Control-11.
al
• Based on Citrix sizing recommendations, particularly to accommodate registration
e
RAM Allocation per server 8 GB RAM and logon storms in the event of a pod outage.
or
di
Storage Allocation per server 250 GBs • Standard storage allocation per SQL server build.
s tri
Maximum Expected Size of Citrix Site: 40-50 MBs • Estimates based on information from requirements and the Citrix VDI Handbook
b
Virtual Apps and Desktops Monitoring: 3-8 GBs sizing guidelines. Ranges account for a variable amount of connections per pod.
databases Configuration Logging: 200-250 MBs • Design requirement Control-1 and Control-15.
ut
io
n

Citrix Licensing
• Latest Citrix License server version available at the time of the design. Citrix
License Server Version 11.16.3 or later
recommends always using the latest available version of this component.
N
OS Version Windows Server 2016 • Standard for Workspace Lab.
ot
6,000 Citrix Virtual Desktops Premium
fo
License number and type • Workspace Lab has already procured sufficient licenses for the expected user base.
concurrent licenses
rr
• Backup provides a way to quickly restore a Citrix License Server while minimizing
One active server, one cold standby
Redundancy configuration and maintenance time.
es
server
• Design Requirement Control-4 and Control-14.
al
• Based on Citrix baseline recommendation.
CPU Allocation per server 2 vCPUs
e
or
• Based on Citrix baseline recommendation.
RAM Allocation per server 2 GB RAM
di
s
Storage Allocation per server 40 GBs • Standard for Workspace Lab Windows Server 2016 build.
tri
b ut
io
n

Citrix Director
Director Version 1912 LTSR or later • This is the latest Citrix Virtual Apps and Desktops current release version.
Operating System Microsoft Windows Server 2016 • Workspace Lab standard.
N
ot
• Each pod will include a single Director server.
Number of Director servers 2
• Design Requirement Control 4 and Control-18.
fo
• Workspace Lab will leverage dedicated Director IIS servers instead of co-locating the
rr
Dedicated? Yes servers on Delivery Controllers.
• Design Requirement Control 4 and Control-18.
es
• This allocation should be sufficient for the expected number of console users.
CPU Allocation per server 4 vCPUs
al
• This allocation should be sufficient for the expected number of console users.
e
RAM Allocation per server 4 GB RAM
or
• Standard for Workspace Lab Windows Server 2016 build. Monitoring data is stored in
Storage Allocation per server 40 GBs
the Monitoring database.
di
• Workspace Lab will leverage certificates to secure the Director Site and ensure login
s
Security TLS credentials are encrypted.
tri
• Workspace Lab will configure both Director servers to enumerate all pods within the
b
Multi-Site Yes Director console. This will facilitate the monitoring of multiple Sites.
ut
io
n

Key Takeaways
• Citrix Virtual Apps and Desktops Sites can be on-
N
premises, in Citrix Cloud, a public cloud, or a
ot
mixture.
• Use application groups, tagging, local host cache,
fo
advanced reboot schedules, and other features to
rr
optimize the Citrix Virtual Apps and Desktops Site.
es
• Designing monitoring and management processes
al
will help the long-term health of a new Citrix Virtual
e
Apps and Desktops implementation.
or
di
s tri
b ut
io
n
Key Notes:
• Citrix Virtual Apps and Desktops Sites can be on-premises, in Citrix Cloud, a public cloud, or a mixture.
• Use application groups, tagging, local host cache, advanced reboot schedules, and other features to optimize the
Citrix Virtual Apps and Desktops Site.
• Designing monitoring and management processes will help the long-term health of a new Citrix Virtual Apps and
Desktops implementation.

Key Takeaways
• The sizing and availability of the Control Layer
N
infrastructure is crucial for its stability and
ot
performance.
• The Control Layer infrastructure should be secured
fo
and monitored to protect against potential internal
rr
threats and meet compliance requirements.
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• The sizing and availability of the Control Layer infrastructure is crucial for its stability and performance.
• The Control Layer infrastructure should be secured and monitored to protect against potential internal threats and meet
compliance requirements.

Assessment, Design, and
N
ot
Hardware/Compute Layer
fo
rr
es
al
e
Module 7
or
di
s tri
b ut
io
n
Key Notes:
• Welcome to the Hardware/Compute Layer module. This is the seventh module in the Citrix Virtual Apps and Desktops 7
• Throughout this module, we will explore items such as hardware and hypervisor considerations, sizing VMs, hosts and
Hypervisor pools, review storage solutions and IOPS optimizations, define data center networking and determine security
options for the compute layer.

Learning Objectives
• Analyze the appropriate hardware or hypervisor to
N
implement.
ot
• Determine the appropriate resource pool strategy.
fo
• Identify the appropriate hardware sizing and
rr
scalability for a given Hypervisor host.
es
• Differentiate the different storage solutions and how
to optimize IOPS.
al
e
• Examine datacenter networking and leading
or
practices.
• Identify how to meet the security objectives and
di
leading practices in the compute layer.
s tri
b ut
io
n
Key Notes:
• Analyze the appropriate hardware or hypervisor to implement.
• Identify the appropriate hardware sizing and scalability for a given Hypervisor host.
• Differentiate the different storage solutions and how to optimize IOPS.
• Examine datacenter networking and leading practices.

• Identify how to meet the security objectives and leading practices in the compute layer.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Assessment Considerations for
N
Hardware & Hypervisor
ot
Selection
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Analyze the appropriate hardware or hypervisor to
N
implement based on a given design.
ot
fo
rr
es
al
e
or
di
stri
b ut
io
n
Key Notes:
• Analyze the appropriate hardware or hypervisor to implement based on a given design.

Hypervisor Host Hardware Considerations
When approaching a new Hypervisor design, consider
1
the specs of the
hardware and common configurations.
Hardware Specification Considerations
N
Common Configuration Approaches
ot
• CPU Cores / Sockets / Hyper threading • Rack servers
fo
rr
• Local storage size and speed (caching) • Blade servers
es
• RAID controller and speed • Converged infrastructure
• HP SimpliVity
al
• Fiber channel extension • Nutanix
e
• RAM per host
or
• NIC speed and ports
di
• Hardware redundancy
s tri
• Hypervisor Hardware Compatibility List (HCL)
but
io
n
Key Notes:
• These lists are common examples of all the specifics that will need to be answered during the assessment of:
• What hardware do we have? What type of configuration is needed?
• Is this sufficient for my new design?
• If not, what do I need?
• Realize that the data collected during Hypervisor Host Hardware Considerations will lead to different requirements for
different types of workloads.

• Server hardware and storage infrastructure estimates are affected by VDAs per host, VDAs per site, VDAs per
controller, users per VDA, hosts per resource pool, IOPS per VM and many others.
• When considering host hardware, confirm with the Hypervisor Hardware Compatibility List (HCL) to ensure the
hardware components are currently certified and supported for use with Citrix. This can save time and
frustration down the road after the infrastructure has been deployed.
• In addition, it is also important to few firmware considerations, and available drivers from vendors.
• For example, when using a CISCO USC, there is a need to match the driver with the firmware (example
N
here https://ucshcltool.cloudapps.cisco.com/public/#). If the firmware is updated past a certain firmware
ot
level, Citrix may not have drivers that support it.
fo
rr
• Citrix Hypervisor Hardware Compatibility List: http://hcl.xenserver.org/
es
al
e
or
di
s tri
but
io
n

Advanced Graphics
Hardware Options 1
Three Methods for GPU Leading Vendors Cloud Deployments
N
ot
fo
• Pass-through GPU • NVIDIA GRID • Microsoft Azure NV-Series
rr
• Hardware Virtualized GPU • Intel Iris Pro • Amazon AWS EC2 G3
es
• Software Virtualized GPU • AMD FirePro
al
e
or
di
s
tri
but
io
n
Key Notes:
• Without a graphical processing unit (GPU), graphical processing is rendered with software by the CPU. A graphical
processing unit (GPU) can be leveraged to improve server scalability and user experience or enable the use of graphically
intensive applications.
• During the desktop design, it is important to decide how the GPU (if used) will be mapped to the virtual machines.
• There are three methods available to implement GPUs:
• Pass-Through GPU – Each physical GPU is passed through to a single virtual machine (hosted apps or hosted

desktops).
• Hardware Virtualized GPU – Using a hypervisor’s vGPU technology, an NVIDIA GRID or Intel Iris Pro is
virtualized and shared between multiple machines. Each virtual machine has the full functionality of GPU
drivers and direct access to the GPU.
• Software Virtualized GPU – The GPU is managed by the hypervisor and intercepts requests made by the
VDI desktops. This process is used if a GPU is not installed within the host. svGPU is not recommended
for graphics intensive workloads.
N
• Citrix recommends customers become familiar with different GPU vendor technologies and choose a GPU
ot
that meets the technical requirements for the use-case. There are three leading vendors that provide GPU
fo
platforms which Citrix supports: NVIDIA GRID, Intel Iris Pro and AMD FirePro.
• In Cloud deployments, HDX 3D Pro is supported when running on GPU-enabled virtual machines available
rr
from the following Cloud providers: Microsoft Azure NV-Series and Amazon AWS EC2 G3.
es
al
• HDX 3D Pro GPU Hardware Support and Deployment Considerations:
e
or
• HDX 3D Pro: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/graphics/hdx-3d-pro.html
di
s tri
but
io
n

Advanced Graphics
HDX 3D Pro 1
GPU Acceleration for Multi-Session OS GPU Acceleration for Single-Session OS
N
ot
fo
• Multiple users can share a GPU accessed by • Install multiple GPUs on the hypervisor and
Citrix Virtual Apps. assign VMs to each of these GPUs on a one-to-
rr
one basis.
es
• Supports full pass-through or virtual GPU (vGPU)
modes. • Supports physical host computers.
al
• Supports bare-metal deployments on physical
e
• Supports GPU pass-through and virtual GPU
Windows Server machines. modes.
or
• Scalability using GPU Sharing depends on • Supports user devices with up to four monitors.
di
several factors.
s
tri
but
io
n
Key Notes:
• The HDX 3D Pro capabilities in Citrix Virtual Apps and Desktops enable you to deliver desktops and applications that
perform best using a graphics processing unit (GPU) for hardware acceleration. These applications include 3D
professional graphics applications based on OpenGL and DirectX. The standard VDA supports GPU acceleration of
DirectX only.
• GPU Acceleration for Multi-Session OS VDAs
• Since Windows Server is a multi-user operating system, multiple users can share a GPU accessed by Citrix Virtual

Apps without the need for GPU virtualization (vGPU).
• A GPU can be assigned to the Windows Server virtual machine in either full pass-through or virtual GPU
(vGPU) modes.
• Bare-metal deployments on physical Windows Server machines are also supported.
• Scalability using GPU Sharing depends on several factors:
• The application being run
• The amount of video RAM they consume
N
• The graphics card’s processing power
ot
• GPU Acceleration for Single-Session OS VDAs
fo
• Using GPU Passthrough, you can create VMs with exclusive access to dedicated graphics processing
hardware. You can install multiple GPUs on the hypervisor and assign VMs to each of these GPUs on a
rr
one-to-one basis.
es
• HDX 3D Pro supports physical host computers and GPU Passthrough and GPU virtualization
al
technologies.
• For Single-Session OS machines, HDX 3D Pro supports user devices with up to four monitors. Users
e
can arrange their monitors in any configuration and can mix monitors with different resolutions and
or
orientations. The number of monitors is limited by the capabilities of the host computer GPU, the user
di
device, and the available bandwidth.
• Reviewing the HCL is also important for designing Advanced Graphics capabilities as many vendors (Citrix
s tri
included) will only fully support vetted host and GPU configurations.
but
io
• GPU acceleration for Windows multi-session OS: https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops/1912-ltsr/graphics/hdx-3d-pro/gpu-acceleration-server.html
n
• GPU acceleration for Windows single-session OS: https://docs.citrix.com/en-us/citrix-virtual-apps-
desktops/1912-ltsr/graphics/hdx-3d-pro/gpu-acceleration-desktop.html

Traditional Big 3
Hypervisor
Considerations
Hyper-V Key Selection Criteria:
N
• In-house expertise
ot
vSphere • Feature set
fo
rr
• Price
Citrix Hypervisor
es
• Limitations
al
• Multi-hypervisor strategy
e
or
di
s tri
but
io
n
Key Notes:
• Many customers chose to use the same hypervisor for their Citrix Virtual Apps and Desktops solutions as they use for the
rest of their business, typically the biggest driver for this is the in-house expertise the customer already has on a given
hypervisor.
• All the big 3 hypervisors has plenty of features to support a Citrix Virtual Apps and Desktops environment, but many
customers purchase a hypervisor that has more features than they need for their VDA workloads.
• Both Microsoft and VMWare offer a free hypervisor but these free versions will not work with the Citrix Virtual Apps and

Desktops integrations such as: MCS, Citrix Provisioning, VM power management etc.
• Citrix Hypervisor is free and fully licensed to use out of the box with Citrix Virtual Apps and Desktops licensing.
• Multi-hypervisor strategies are used by some customers, allowing them to use Citrix Hypervisor to run their
VDA workloads on an inexpensive hypervisor and spending the money on better hardware. The control layer
and the rest of their infrastructure would in term run on another more expensive hypervisor with more features,
such as SAN connectivity, disaster recovery and advanced networking.
• The support hypervisors are dependent upon the version of Citrix Virtual Apps and Desktops/Citrix
N
Provisioning being used (see Additional Resources section for more details).
ot
fo
• Supported Hypervisors for Citrix Virtual Desktops and Citrix Provisioning:
rr
es
al
e
or
di
s tri
b ut
io
n

Hyper-Converged
Infrastructure
Considerations
Products:
N
Everything in one box, fast • Nutanix Acropolis
ot
deployment, less
administrative overhead, • Cisco HyperFlex for Citrix Cloud Services
fo
lower price per user, pay as
rr
• Dell EMC XC Core
you grow.
es
• Flexxible|SmartWorkspaces for Citrix Cloud
al
• Automation for HPE SimpliVity and Citrix Cloud
e
• Lenovo ThinkAgile HX Series
or
di
stri
but
io
n
Key Notes:
• An alternative to standard design across hypervisor hosts, with peripherals and many moving pieces to manage, is Hyper-
Convergence.
• HyperConverged Infrastructure (HCI) solutions help reduce complexity and cost at the hardware and storage layers,
particularly for the mid-market enterprises.
• Citrix Virtual Apps and Desktops fully supports select Hyper-Converged partner products for deployment such as Nutanix
Acropolis, Atlantis HyperScale, Cisco HyperFlex, HPE Moonshot and HC380, Dell EMC XC Core

• Citrix, Nutanix & Cerner Bring Hyperconvergence to Healthcare: https://www.citrix.com/blogs/2016/11/11/citrix-
nutanix-cerner-bring-hyperconvergence-to-healthcare/
• Nutanix Acropolis Hypervisor Support in Citrix Virtual Apps and Desktops :
• Atlantis HyperScale VDI Reference Architecture with Citrix XenDesktop :
N
https://citrixready.citrix.com/content/dam/ready/partners/lo/login-vsi/login-vsi/Atlantis-RA-HyperScale-
ot
XenDesktop-20150603.pdf
fo
• Citrix XenDesktop HPE Moonshot Provisioning Wizard V2: https://www.citrix.com/blogs/2016/03/11/citrix-
rr
xendesktop-hpe-moonshot-provisioning-wizard-v2/
es
• Citrix and HPE Discover 2018 Hybrid Cloud your way: https://www.citrix.com/blogs/2018/06/14/citrix-and-hpe-
discover-2018-hybrid-cloud-your-way/
al
• Citrix Hyperconverged Infrastructure Blogs: https://www.citrix.com/blogs/tag/hyperconverged-infrastructure/
e
• Citrix Ready HCI Workspace Appliance Program: https://citrixready.citrix.com/program/hci-workspace-
or
appliance-program.html
di
s tri
but
io
n

N
ot
fo
In which situations would a hyper converged
infrastructure fit well into a hardware design?
rr
es
Hyper converged infrastructure is typically deployed
when a customer is looking for the following benefits:
al
• Fast deployment
e
• Less administrative overhead
or
• Lower price per user
• Pay as you grow
di
s
tri
b
ut
io
n

N
ot
Cluster / Resource Pool Design
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n
Key Notes:

Separating
Workloads on
Resource Pools
Pool 1 Pool 2 Pool 3
Site Infrastructure Single-Session OS VDA Multi-Session OS VDA
Possible drivers to separate
N
workloads:
ot
• Boot storms
Site Database StoreFront
• Logon storms
fo
• Image updates
• Administrative permissions
rr
• Compliance Delivery Controller File Server
es
al
e
Active Directory Server Mail Server
or
di
s
tri
b
ut
io
n
Key Notes:
• Although the term “resource pools” is used within Citrix Hypervisor, the equivalent term is “cluster” for VMware vSphere
and Microsoft Hyper-V.
• Citrix leading practice is to dedicate a resource pool:
• 1 for the Infrastructure
• 1 for each VDA workload type.
• For example, have a separate cluster for Multi-Session OS and another for Single-Session OS.

• When creating dedicated clusters for VDAs, the following baselines can be used. As always, testing is
recommended to validate these numbers on the hardware used:
• Citrix Hypervisor max 64 hosts per pool (if using XenServer 7.1.2 LTSR, it is 16 hosts)
• Citrix Virtual Apps and Desktops 8-12 hosts per cluster recommended
• vSphere max 64 hosts per cluster
• Citrix Virtual Desktops 8-16 hosts per cluster recommended
• Citrix Virtual Apps 24-32 hosts per cluster recommended
N
• Hyper-V max 64 hosts per failover cluster
ot
fo
• Hosts and resource pools: https://docs.citrix.com/en-us/citrix-hypervisor/hosts-pools.html
rr
• Clustered Pools: https://docs.citrix.com/en-us/citrix-hypervisor/hosts-pools/clustered-pools.html
es
al
e
or
di
s tri
but
io
n

Separating Workloads Between Hypervisor Vendors
Citrix Virtual Apps and Desktops are hypervisor agnostic
• Your Citrix Virtual Apps and Desktops deployment can use one or more hypervisor choices.
• The design leading practice remains the same - separate your workloads into different Resource Pools.
N
ot
Citrix Hypervisor Hyper-V Citrix Hypervisor
fo
rr
Pool 2 Pool 3 Pool 2 Pool 3
Pool 1 Pool 1
Single-Session OS Multi-Session OS Single-Session OS Multi-Session OS
Site Architecture
es
Site Infrastructure
VDAs VDAs VDAs VDAs
The Citrix
al
Virtual Apps
e
Site Database StoreFront Site Database StoreFront
and
Desktops
or
Delivery
Controller
File Server Deployment Delivery
Controller
File Server
di
Active Directory Mail Server Active Directory Mail Server
s
Server Server
tri
b ut
io
n
Key Notes:
• The Citrix Virtual Apps and Desktops deployment can be hosted on Citrix Hypervisor or other 3rd party vendor products,
such as Microsoft Hyper-V or VMware ESX.
• The following are example scenarios:
• During the design, it may be assessed that the existing company hypervisor solution can be used to host the Citrix
Virtual Apps and Desktops infrastructure components (See the figure on the right).
• During the design, it may be assessed that the existing company hypervisor solution does not meet the needs of the

new Citrix Virtual Apps and Desktops deployment, so a choice needs to be made.
• We can host the entire Citrix Virtual Apps and Desktops deployment across a single Hypervisor choice.
• We can host select Resource Pools (Clusters) of pieces of the Citrix Virtual Apps and Desktops deployment
across multiple Hypervisor choices.
• Another method often seen in the field is that deployments are built to have one Hypervisor product for
servers and another one for the guest virtual machines.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Virtual Machine
Motion Typical VM motion candidates:
• Infrastructure servers
• Persistent VDAs
Considerations when
N
deploying different VDA types
ot
fo
rr
es
Not typically VM motion candidates:
• Non-persistent VDAs
al
• HDX3D Pro VDAs
e
• VDAs using local storage
or
di
s tri
b ut
io
n
Key Notes:
• VM Motion allows you to move a running VM from one host to another.
• VM Motion is referred as:
• VM Migration for Citrix Hypervisor (previously known as XenMotion)
• Vmotion for Vmware\VSphere
• Live Migration for Hyper-V\SCVMM
• Citrix Hypervisor supports both VM Migration for VMs and Storage Live Migration, however Storage Live Migration is not

recommended with Citrix Virtual Desktops deployments. Consider the following:
• VM performance is reduced during migration.
• Time to complete VM migration is dependent on the memory footprint of the VM and current VM activity.
• Virtual GPU and GPU pass-through are not compatible with VM Migration, Storage Live Migration or VM
Suspend.
N
• Migrate Virtual Machines: https://docs.citrix.com/en-us/xencenter/current-release/vms-relocate.html
ot
• XenMotion Support for NVIDIA GPUs Released! Agility for All VMs is Here!:
fo
https://www.citrix.com/blogs/2018/03/27/xenmotion-support-for-nvidia-gpus-released-agility-for-all-vms-is-here/
rr
es
al
e
or
di
s tri
b ut
io
n

High Availability
Considerations
Citrix Hypervisor • Shared storage
N
• Static IP addresses for all hosts
ot
• Dedicated bonded interface as the high availability management
fo
network
rr
• VM Specifics:
es
• Must have its virtual disks on shared storage.
al
• Can use live migration.
e
• Does not have a connection to a local DVD drive configured.
or
• Has its virtual network interfaces on pool-wide networks.
di
s tri
but
io
n
Key Notes:
• As previously mentioned, Citrix recommends using separate resource pools for different workloads. In doing so, this also
allows separate high availability configurations for different VM types.
• For maximum reliability, Citrix recommend that you use a dedicated NFS or iSCSI storage repository as your high
availability heartbeat disk. Do not use this storage repository for any other purpose.
• Assign static IP addresses for all hosts. If the IP address of a server changes while high availability is enabled, high
availability assumes that the host’s network has failed.

• For maximum reliability, we recommend that you use a dedicated bonded interface as the high availability
management network.
• For a VM to be protected by high availability, it must be agile. It means the VM:
• Must have its virtual disks on shared storage. You can use any type of shared storage. iSCSI, NFS, or
Fibre Channel LUN is only required for the storage heartbeat and can be used for virtual disk storage.
• Can use live migration
• Does not have a connection to a local DVD drive configured
N
• Has its virtual network interfaces on pool-wide networks
ot
fo
• High availability: https://docs.citrix.com/en-us/citrix-hypervisor/high-availability.html
rr
es
al
e
or
di
s tri
but
io
n

HA in Public Cloud
AWS High Availability
N
Azure High Availability
ot
• Availability Zones • Availability Sets
fo
rr
• Placement Group • Fault Domains
• Update Domains
es
• Scale Sets
al
• Availability Zones
e
• High availability offering that protects applications
or
Public Cloud
HA Terminology and data from datacenter failures.
di
• Azure services that support Availability Zones fall
s
into two categories:
tri
• Zonal services
b
• Zone-redundant services
ut
io
n
Key Notes:
• Citrix consultants should familiarize themselves with Public Cloud providers and their high availability features.
• Public cloud providers such as Azure and AWS provide tools to implement high availability functionality.
• Public Cloud high availability can be implemented across a single region such as Availability Zones or geographical
regions.

• Manage the availability of Windows virtual machines in Azure: https://docs.microsoft.com/en-us/azure/virtual-
machines/windows/manage-availability#configure-multiple-virtual-machines-in-an-availability-set-for-
redundancy
• Create a Windows virtual machine in an availability zone with the Azure portal: https://docs.microsoft.com/en-
us/azure/virtual-machines/windows/create-portal-availability-zone
• Availability Zones in Azure: https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
fo
Why should you separate workloads on different
resource pools?
rr
es
• To protect infrastructure servers from login storms
and boot storms on VDI / VDA pools.
al
e
• Use a less expensive hypervisor and/or storage
or
solution for non-persistent VDAs.
di
s
tri
b
ut
io
n

N
Hardware/ Compute Layer
ot
Sizing
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify the appropriate hardware sizing and
N
scalability for a given Hypervisor host.
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Identify the appropriate hardware sizing and scalability for a given Hypervisor host.

Determining VMs per Host
VDA VDA VDA VDA VDA
VDA VDA VDA VDA VDA

The optimal number of virtual machines per physical
N
server will depend on:
ot
• Physical CPUs and Cores
VDA VDA VDA VDA VDA
• Hyper-threading usage
fo
• Microprocessor architecture
• RAM size
rr
• HDD size (local caching)
es
• Storage
al
e
or
di
stri
Hypervisor
but
io
n
Key Notes:
• Consider the following to begin assessing the resource requirements per VM:
• OS Recommended Specs
• Any Apps and their Recommended Specs
• Determining VMs per Host:
• Physical CPUs and Cores
• Single-Session OS VDA workloads typically starts with two or more vCPUs per VM.

• Multi-Session OS VDA workloads have a different approach and rely on the type of architecture of the
processors (NUMA or mesh).
• Hyper-threading usage
• The allocation of more than one vCPU per VM enables multiple threads to be executed simultaneously.
• For the most part, modern apps are multi-threaded.
• Hyper-threading virtually increases the number of vCPUs available to allocate to the VMs.
• Don’t forget to assess your company’s CPU over-commitment policy and factor in hyper-threading.
N
• Microprocessor Architecture
ot
• NUMA node size
fo
• Remember not to allocate more vCPU than the NUMA node contains or you will see a performance
hit.
rr
• Mesh architecture
es
• Start with 1.5 to 2.0 CPU oversubscription based on hardware model.
al
• RAM size
• Other than the Operating System recommended configuration, the amount of memory required is very
e
dependent on the user’s expected workload and whether shared workloads will be used.
or
• Typically, Ram is the bottleneck for Multi-Session OS Workloads.
di
• HDD Size (local caching)
• Similarly to Ram, the VM storage requirements vary dependent on the workload.
s tri
• Storage
b
• Consider the storage needs for Citrix Hypervisor and XenServer and take into consideration snapshotting
ut
on the SR. Block based storage snapshots take up more space than thin provisioned.
io
• There is no one-size-fits-all mathematical equation for sizing VM allocation. There are examples from real
world experiences that contribute to Citrix documentation, but all equations should be tested.
n
• For Example, a hypothetical company is deploying apps across Multi-Session OS VDA workloads and is
has purchased new hypervisor hardware, with two processors and twelve cores each. Just reviewing
what we learned above: how could we approach sizing by vCPU?
• 2 processors with 12 cores each is 24 cores total.
• We could then factor in Hyper-threading (assuming compatible with the environment and tested) and

double the cores to 48 cores.
• Next are we allowed to overcommit? Yes. Let’s use a conservative approach at 1 ½ (again for Multi-
Session OS) which gives us 72 cores.
• Previous testing determined the expected performance required 8 cores per Multi-Session OS VDA
VM.
• 72 / 8 = 9.
• There are a lot of assumptions here. This is not Citrix Leading Practice, but rather a hypothetical
N
example.
ot
fo
• XenApp Scalability v2017: https://www.citrix.com/blogs/2017/11/22/xenapp-scalability-v2017/
rr
• Citrix Scalability — The Rule of 5 and 10: https://www.citrix.com/blogs/2017/03/20/citrix-scalability-the-rule-of-
es
5-and-10/
al
e
or
di
s tri
but
io
n

Determining Hosts
per Pool
N
• Hypervisor reservations
ot
• Total number of VMs
fo
• Sizing per VM
rr
• CPU overcommit ratio
es
• +1 for maintenance / overhead capacity
al
e
or
di
s tri
b
ut
io
n
Key Notes:
• As previously mentioned, Citrix Hypervisor 8.x supports up to 64 hosts per resource pool. However, this standard can vary
depending on the type of workload that is running in a given Citrix Hypervisor environment:
• Machine Creation Services (MCS) issues numerous commands to the Citrix Hypervisor Pool Master
• Citrix recommends limiting the number of hosts in a Resource Pool to 8 when using MCS
• Citrix Provisioning allows for a higher host capacity in a resource pool than MCS, because several runtime
operations are not performed by the hypervisor

• Citrix recommends limiting the number of hosts in a resource pool to 12 when using Citrix Provisioning.
• Citrix Hypervisor offers a Thin-Provisioned Block Storage called GFS2 that allows for the flexibility of Thin
Provisioning with the leverage of Block Storage
• Separate virtualization pools allow for the high availability features of the hypervisor to be tailored to the
specific requirements of either desktops or servers. Another reason why multiple resource pools are created is
to use different hardware specifications. For example infrastructure resource pools typically have much lower
memory requirements than a resource pool that is used for hosting of VDI desktops.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Hypervisor
Scalability
Citrix Hypervisor 8.2 Scalability Example:
Item Limit
Logical processors per host 488
When planning a new
Concurrent VMs per host 1000
N
hypervisor deployment,
ot
consider the scalability of the RAM per host 6 TB
hypervisor choice pursued
fo
Concurrent active virtual disks per host 2048
and determine if it will meet
rr
the needs of the new design. Physical NICs per host 16
es
Virtual NICs per host 512
al
Hosts per pool 64
e
VMs per pool 2400
or
di
s tri
b ut
io
n
Key Notes:
• When planning a new hypervisor deployment, consider the scalability of the hypervisor and determine if the scalability will
meet the needs of the new design.
• Factors such as hardware and environment can affect the configuration limitations.
• The maximum amount of logical physical processors supported differs by CPU. Please consult the Citrix Hypervisor
Hardware Compatibility List for more details on the maximum amount of logical cores supported per vendor and CPU.

• Hypervisor Hardware Compatibility List: http://hcl.vmd.citrix.com/?_ga=2.68585171.332082052.1603726780-
1010463171.1583866223&_gac=1.247140016.1602770920.EAIaIQobChMI7cr08eK27AIVi4taBR03cQfLEAAY
ASAAEgLou_D_BwE
• Citrix Hypervisor 8.2 Configuration Limits: https://docs.citrix.com/en-us/citrix-hypervisor/system-
requirements/configuration-limits.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Citrix Hypervisor Scalability
Sizing with Advanced Graphics Options
Max vGPU Per Graphics Graphics Memory Total Graphics

Graphics Board Max Resolution
Graphics Board Memory Profiles Cores
NVIDIA Tesla M10 64 32 0.5 – 8GB 4096×2160 2560
N
ot
NVIDIA Tesla M60 32 16 0.5 – 8GB 4096×2160 4096
fo
NVIDIA Tesla P40 24 24 1 – 24GB 2560x1600 3840
rr
NVIDIA Tesla M6 16 8 0.5 – 16GB 4096×2160 1536
es
NVIDIA Tesla P6 16 16 1 – 16GB 2560x1600 2048
al
AMD FirePro S7150 16 8 0.5 – 8GB 2560x1600 2048
e
or
AMD FirePro
32 16 0.5 – 8GB 2560x1600 4096
S7150x2
di
Intel Iris Pro Xeon E3 16 from 2560x1600
s
7 1 N/A
tri
1285 v4 Server RAM
b ut
io
n
Key Notes:
• When advanced graphics is involved, it is important to factor in the best way to scale an environment for the specific
vendor you choose.
• Remember, each GPU can be slides into smaller vGPUs. The smaller you slice the vGPUs, the lower your performance
per vGPU will be.

• NVIDIA Virtual GPU Software Documentation: https://docs.nvidia.com/grid/latest/grid-vgpu-user-
guide/index.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
When designing and sizing the resource pools,
fo
why would it be a good idea to add an extra host to
each pool?
rr
es
Adding an extra host to each pool allows you to retain
full capacity during host maintenance or in the event of
al
a single host failure.
e
or
di
s
tri
utb
io
n

N
ot
Storage
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Differentiate the different storage solutions and how
N
to optimize IOPS.
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Differentiate the different storage solutions and how to optimize IOPS.

Storage Tier Considerations
Storage Properties Local DAS NAS SAN
Implementation costs Low Medium Medium High
N
Administration Low Medium Medium High
ot
Performance High (SSD) Med - High Med - High High
fo
Redundancy Low - Med Medium Med - High High
rr
Scalability Low Low - Med Med - High High
es
Small to medium Small to medium Small to medium Medium to large
Typical customer production and test production production production
al
environments environments. environments. environments.
e
Non-persistent catalogs Non-persistent Persistent catalogs
or
Best use case Persistent catalogs
Caching catalogs
di
Use with Citrix
Network and storage Cost per VM can be
s
Considerations Provisioning or MCS Not widely used
performance high
tri
Intellicache
b ut
io
n
Key Notes:
• Local storage is best suited for storing virtual machines which do not have high availability requirements or persistent data
attached such as random (pooled) desktops or hosted shared desktops.
• Local and DAS is suited for storing user data and home directory files. If using Machine Creation Services, master images
as well as any updates must be replicated to each server.
• NAS and SAN storage is best suited for infrastructure servers supporting the Citrix Virtual Desktops environment, and
virtual machines with persistent data such as static (dedicated) desktops.

• Storage Architectures
• Local Storage - Uses hard disks directly attached to the computer system. The disks cannot be shared
with other computer systems, but if the computer is hosting pooled or hosted shared desktops, a shared
storage solution is not necessary. In many cases local storage can perform as well as shared storage.
Scalability is limited to the number of drive bays available in the computer system. Many blade servers
for example have just two drive bays, so using local storage to support a Citrix Virtual Desktops
deployment may not be optimal.
N
• DAS - Storage sub-system directly attached to a server or workstation using a cable. It uses block-level
ot
storage and can be a hard disk local to the computer system or a disk shelf with multiple disks attached
fo
by means of external cabling. Unlike local disks, disk shelves require separate management. Storage
shelves can be connected to multiple servers so the data or disks can be shared.
rr
• NAS - Provides file-level storage to computer systems through network file shares. The NAS operates as
es
a file server, and NAS systems are networked appliances which contain one or more hard drives, often
al
arranged into logical, redundant storage containers or RAID arrays. Access is typically provided using
standard Ethernet and network file sharing protocols such as NFS, SMB/CIFS, or AFP.
e
• SAN - Dedicated storage network that provides access to consolidated, block-level storage. SANs allow
or
computers to connect to different storage devices, so no server has ownership of the storage subsystem
di
enabling data to be shared among multiple computers. A SAN will typically have its own dedicated
network of storage devices that are generally not accessible through the network by standard means. In
s tri
order to connect a device to the SAN network a specialized adapter called the Host Bus Adapter (HBA) is
b
required. SANs are highly scalable with no noticeable change in performance as more storage and
ut
devices are connected. SANs can be a costly investment both in terms of capital and the time required to
io
learn, deploy and manage the technology.

I/O Characteristics
Based on Workload
Storage IOPS Storage IOPS
User Workload Operating System (without RAM- (with RAM-Based
Based Cache) Cache)
Windows 10 12 IOPS 1 IOPS
N
Light Windows 2012R2 3 IOPS 0.5 IOPS
ot
fo
Windows 10 20 IOPS 1.5 IOPS
rr
Medium Windows 2012R2 4 IOPS 0.5 IOPS
es
al
e
or
Heavy Windows 2012R2 5 IOPS 0.5 IOPS
di
stri
but
io
n
Key Notes:
• The following table provides guidance on the number of storage IOPS generated per user based on workload and
operating system. Example: The average percentage of IOPS decreases when using RAM vs without RAM cache,
because “light” workload does not mean the same for all customers.
• The data in this table is a good place to start from.
• To ensure accuracy in your design, be sure to test fully built POC machines that mimic production design.
• Storage IO activity will be higher during user logon/logoff.

I/O Load
Deployment Method Read IOPS Write IOPS
N
ot
• Multi-Session VDA vs Single- • Read IOPS Master image • Write IOPS Persistent VDAs
fo
Session VDA
• Optimize with Provisioning • Optimize with SAN horsepower
rr
• MCS vs Citrix Provisioning Server RAM or Intellicache
• Write IOPS Writecache /
es
• Persistent vs non-persistent • Read IOPS Writecache / Deltadisk
al
Deltadisk
• Optimize with RAM caching
e
• Optimize with RAM caching and/or Local SSD
or
and/or Local SSD
di
s tri
but
io
n
Key Notes:
• It’s important to analyze the IOPS load for the complete machine workload in the design.
• Provisioning Services or Machine Creation Services (2016 Edition): https://www.citrix.com/blogs/2016/06/28/provisioning-
services-or-machine-creation-services-2016-edition/

601
• Use IntelliCache for Citrix Hypervisor connections: https://docs.citrix.com/en-us/xenapp-and-xendesktop/current-
release/manage-deployment/connections.html#par_anchortitle_2f89
• Size Matters: PVS RAM Cache Overflow Sizing: https://www.citrix.com/blogs/2015/01/19/size-matters-pvs-
ram-cache-overflow-sizing/
• Turbo Charging your IOPS with the new PVS Cache in RAM with Disk Overflow Feature! – Part One:
https://www.citrix.com/blogs/2014/04/18/turbo-charging-your-iops-with-the-new-pvs-cache-in-ram-with-disk-
overflow-feature-part-one/
• Turbo Charging your IOPS with the new PVS Cache in RAM with Disk Overflow Feature! – Part Two:
N
https://www.citrix.com/blogs/2014/07/07/turbo-charging-your-iops-with-the-new-pvs-cache-in-ram-with-disk-
ot
overflow-feature-part-two/
fo
rr
es
al
e
or
di
s tri
but
io
n

Storage
Considerations
Storage Architecture
Evaluate storage architecture • Thin provisioning
N
and features
• Data de-duplication
ot
• Storage tiering
fo
rr
• Read caching
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Storage capacity and speed are important, but there’s more to design.
• The architecture of the storage solution must be assessed.
• Thin provisioning allows more storage space to be presented to the virtual machines than is actually available on the
storage repository.
• This lowers storage costs by allowing virtual machines access to disk space that is often unused.
• This is particularly beneficial to Machine Creation Services which uses a linked-clone approach to provisioning virtual

machines.
• Thin provisioning minimizes the storage space required for the master image copies used to build virtual
machines.
• Thin provisioning is possible at the physical storage layer, a feature usually available with most SAN
solutions, and at the virtual layer.
• NFS based storage solutions will usually have thin provisioning enabled by default.
• Data de-duplication is a data compression technique whereby duplicate data is replaced with pointers to a
N
single copy of the original item.
ot
• This reduces storage requirements and costs by improving storage utilization, however it can impact
fo
storage performance.
• The use of storage tiers provides an effective mechanism for offering a range of different storage options
rr
differentiated by performance, scalability, redundancy and cost.
es
• In this way, different virtual workloads with similar storage requirements can be grouped together and a
al
similar cost model applied.
• Read Caching is a storage technology that temporarily keeps data in memory or flash for quick read access.
e
• IntelliCache and Provisioning Cache in RAM are technologies that use read caching.
or
di
s tri
but
io
n

Storage Considerations
RAID & Disk Type
N
Read Minimum #
ot
RAID Capacity Fault Tolerance Write performance
Performance of disks
fo
0 100% None Very High High (Write Penalty 1) 2
rr
1 50% Single-drive failure Very High Medium (Write Penalty 2) 2
es
5 67-94% Single-drive failure High Low (Write Penalty 4) 3
al
6 50-88% Dual-drive failure High Low (Write Penalty 6) 4
e
Single-drive failure
or
10 50% Very High Medium (Write Penalty 2) 4
in each sub array
di
s tri
utb
io
n
Key Notes:
• To choose the optimal RAID level, it is necessary to consider the IOPS and read/write ratio generated by a given
application or workload in combination with the individual capabilities of a RAID level.
• For hosting read intensive workloads, such as the Citrix Provisioning vDisk store, RAID levels that are optimized for read
operations such as RAID 1, 5, 6, 10 are optimal.
• This is because these RAID levels allow read operations to be spread across all disks within the RAID set simultaneously.
• For hosting write intensive workloads, such as Citrix Provisioning write cache and Machine Creation Services differencing

disks, RAID levels such as RAID 1 or 10 are optimal, as these are optimized for writes and have a low write
penalty.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Storage Sizing
LUNs
Software connected storage
N
Block based storage
ot
fo
Considerations: Considerations:
rr
• Includes NFS and iSCSI • LUN Locking / SCSI reservations
es
• Network congestion • Queuing
al
• Up to 100 Gbit dependent upon hardware • Optimistic locking
e
• Duplex • Rule of thumb 20-30 VMs per LUN
or
• No real limit on VMs per LUN • With vSphere VAAI 50-70 VMs per LUN
di
• iSCSI LUN must be 512 bytes
s
• Size appropriately
tri
but
io
n
Key Notes:
• Citrix Hypervisor supports shared SRs on iSCSI LUNs.
• LUNS can use either block-based or software-based storage.
• Software based storage
• Network congestion
• Up to 100 Gbit dependent upon hardware support
• Duplex

•
No real limit on VMs per LUN
•
The block size of an iSCSI LUN must be 512 bytes.
•
It is easy to overcommit the storage; if you run out of space, it will severely impact production.
•
Storage performance improvements Storage performance is significantly improved when I/O is
performed in block sizes larger than 64 KiB on an NFS SR.
• Follow storage best practices for storage dedicated network.
• Block based storage
N
• LUN locking / SCSI reservations
ot
• Queuing
fo
• Optimistic locking
• Rule of thumb 20-30 VMs per LUN
rr
• With vSphere VAAI 50-70 VMs per LUN
es
• To fulfill capacity requirements, you may need to add capacity to the storage array to increase the size of the
al
LUN provisioned to the Citrix Hypervisor server. Live LUN Expansion allows to you to increase the size of the
LUN without any VM downtime.
e
or
di
• Storage: https://docs.citrix.com/en-us/citrix-hypervisor/storage.html
• Storage Repository Formats: https://docs.citrix.com/en-us/citrix-hypervisor/storage/format.html
s tri
• Live LUN Expansion: https://docs.citrix.com/en-us/citrix-hypervisor/storage/manage.html#live-lun-expansion
but
io
n

Storage Sizing
Storage Bandwidth
Technology Rate (Mbit/s)
iSCSI over Fast Ethernet 100
N
Ultra-2 wide SCSI 640
ot
iSCSI over Gigabit Ethernet 1,000
fo
SATA rev 3 6,000
rr
SAS 3 9,600
es
al
FCoE over 10GbE 10,000
e
SATA rev 3.2 – SATA Express 16,000
or
iSCSI over Infiniband 32,000
di
s tri
b ut
io
n
Key Notes:
• Different implementations of this technology are available on the market, which differ in terms of performance, cost and
reliability.
• Serial ATA (SATA) disk transmit data serially over two pairs of conductors. One pair is for differential transmission of
data, and the other pair is for differential receiving of data. SATA drives are widely found in consumer desktop and
laptop computers. Typical SATA drives have transfer speeds ranging from 1500 – 6000Mbps and support hot-
swapping by design.

• Small Computer Systems Interface (SCSI) disks use a buffered, peer to peer interface that uses
handshake signals between devices. Many SCSI devices require a SCSI initiator to initiate SCSI
transactions between the host and SCSI target. SCSI disks are common in workstations and servers and
have throughputs ranging from 40 – 5120Mbps. iSCSI (Internet Small Computer System Interface) is a
mapping of the regular SCSI protocol over TCP/IP, more commonly over Gigabit Ethernet.
• Fibre Channel (FC) disk is the successor to the parallel SCSI disk and is common in SAN storage
devices. Fibre Channel signals can run on an electrical interface or fibre-optic cables. Throughput can
N
range from 1 – 20Gbps, and connections are hot-pluggable.
ot
• Serial Attached SCSI (SAS) disk uses a new generation serial communication protocol to allow for higher
fo
speed data transfers than SATA disks. Throughput can range from 2400 – 9600Mbps.
• Remember, the Citrix Virtual Apps and Desktops deployment size could help you to rule out Storage
rr
Bandwidth technology by the bandwidth limitations.
es
al
e
or
di
s tri
but
io
n

Storage
Public Cloud Considerations
Azure
N
AWS
ot
fo
• Managed Disks vs Unmanaged Disks Elastic Block Store (EBS):
rr
• Premium Storage vs Standard Storage • General Purpose SSD (gp2)
es
• Provisioned IOPS SSD (io1)
al
• Throughput Optimized HDD (st1)
e
or
di
Azure AWS
s tri
but
io
n
Key Notes:
• There are two ways to create standard disks for Azure VMs:
• Unmanaged disks: This is the original method where you manage the storage accounts used to store the VHD files
that correspond to the VM disks. VHD files are stored as page blobs in storage accounts. Unmanaged disks can be
attached to any Azure VM size, including the VMs that primarily use Premium Storage, such as the DSv2 and GS
series. Azure VMs support attaching several standard disks, allowing up to 256 TB of storage per VM.
• Azure Managed Disks: This feature manages the storage accounts used for the VM disks for you. You specify the

type (Premium or Standard) and size of disk you need, and Azure creates and manages the disk for you.
You don't have to worry about placing the disks across multiple storage accounts in order to ensure you
stay within the scalability limits for the storage accounts.
• Azure Premium Storage delivers high-performance, low-latency disk support for virtual machines (VMs) with
input/output (I/O)-intensive workloads. VM disks that use Premium Storage store data on solid-state drives
(SSDs).
• For AWS, you can create EBS General Purpose SSD (gp2), Provisioned IOPS SSD (io1), Throughput
N
Optimized HDD (st1), and Cold HDD (sc1) volumes. You can mount these volumes as devices on your
ot
Amazon EC2 instances. You can mount multiple volumes on the same instance, but each volume can be
fo
attached to only one instance at a time. You can dynamically change the configuration of a volume attached to
an instance.
rr
es
al
• High-performance Premium Storage and Managed Disks for VMs: https://docs.microsoft.com/en-
us/azure/storage/common/storage-premium-storage?toc=%2fazure%2fstorage%2fblobs%2ftoc.json
e
• Amazon Elastic Block Store (Amazon EBS):
or
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html#w2ab1c25c29c15
di
s tri
but
io
n

N
ot
What is one of the concerns with designing a
fo
solution that involves a thin provisioned storage
system?
rr
es
Possibility of running out of physical disk space and
causing a severe outage.
al
e
or
di
s
tri
b
ut
io
n

N
ot
Datacenter Networking
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Examine datacenter networking and leading
N
practices.
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n
Key Notes:
• Examine datacenter networking and leading practices.

Networking
Considerations
Teaming, Bonding and

LACP
• NIC teaming / bonding
N
• Advantages:
ot
• Redundancy – In case of link failure all traffic can be
moved to the remaining NIC(s).
fo
• Aggregation – It is usually more cost-effective to
rr
bundle a multiple 1 Gbps NICs than to upgrade to 10
es
Gbps NICs.
al
• Active / Passive
e
• Active / Active
or
• LACP Link Aggregation
di
s tri
b ut
io
n
Key Notes:
• NIC teaming / bonding is a technique where two or more network cards are configured together in order to logically
function as one network card.
• Active / Passive: Only one NIC is active. The inactive NIC becomes active only if the active NIC fails, providing a hot-
standby capacity.
• (details) An Active-passive bond does not require switch support for IEEE standard 802.3ad, does not move network traffic
move between different NICs, can be configured with one fast path and one slow path for cost saving.

• Active-Active mode (SLB): Active-active mode is sometimes described as Source Load Balancing (SLB)
bonding as Citrix Hypervisor uses SLB to share load across bonded network interfaces.
• SLB is derived from the open-source Adaptive Load Balancing (ALB) mode and reuses the ALB
functionality to rebalance load across NICs dynamically.
• It is important to make sure that the switches are configured as a single switch. This is called logical or
stacked.
• LACP Link Aggregation: Active and stand-by NICs are negotiated between the switch and the server.
N
• Multiple NICs are active (maximum 4). Requires set-up on the switch side as well; switch must support
ot
IEEE standard 802.3ad.
fo
• Citrix Hypervisor supports two LACP bonding hashing types. The term hashing describes how the NICs
and the switch distribute the traffic— (1) load balancing based on IP and port of source and destination
rr
addresses and (2) load balancing based on source MAC address.
es
• “load balancing based on IP and port of source and destination” is the default hashing algorithm for
al
LACP, it uses five factors to spread traffic across the NICs: the source IP address, source port number,
destination IP address, destination port number, and source MAC address. If a virtual machine is running
e
several applications with different IP or port numbers, this hashing type distributes traffic over several
or
links. Distributing the traffic gives the guest the possibility of using the aggregate throughput. It lets one
di
guest use the whole throughput of multiple NICs.
• It is beneficial when you want to balance the traffic of two different applications on the same VM.
s tri
b
ut
• NIC Bonds in Citrix Hypervisor: https://docs.citrix.com/en-us/citrix-hypervisor/networking.html#nic-bonds
io
• LACP Bonding in Citrix Hypervisor - Configuration and Troubleshooting:
n
• How to Check the Bond Status with OpenVswitch: https://support.citrix.com/article/CTX217646

Networking Considerations
Physical vs. Software Defined Network Separation
N
ot
NIC1 NIC1
Storage
fo
Management
VLAN
Bond
rr
NIC3 Switch 1 NIC2 Switch 1
Physical Software
es
Storage Bond1
defined defined VLAN
al
network network
NIC2 NIC3
e
VM
Bond VM
or
VLAN
NIC4 NIC4
Switch 2 Switch 2
di
stri
but
io
n
Key Notes:
• Consider physically separated networks to ensure different workloads does not interfere with each other.
• Many customers chose to keep their storage networks physically separated.
• For Citrix Hypervisor and XenServer, the physical bond happens on the host; past that it is called port teaming and that is
done on the switch side. It is much more preferable to bond from the host side.
• For Active/Active the switch must be stacked meaning that it shares a single ARP table between the switches.

Ports and Firewalls
External DMZ Infrastructure Servers

Users
N
Mail Server License Server Site Database Active Directory
Server
ot
fo
File Server Delivery Controller Cloud StoreFront Citrix Gateway
Connector
Load Balancer
rr
es
Citrix
Endpoint Firewall Firewall Firewall Firewall
Gateway
al
e
Internal Users Resources
or
di
Provisioning
s
Firewall VDA Single-Session
Endpoints Server OS VDA
tri
b ut
io
n
Key Notes:
• The diagram depicts an example of how firewalls can be placed in the networks to strengthen the security.
• Additionally software firewalls can be used to protect the individual computers on the network.
• Common Citrix Communications ports:
• Citrix Receiver - 80/443
• ICA/HDX – 1494/2598
• ICA/HDX over SSL – 443

• Active Directory – 389/636
• Delivery Controller – 80/443/389/636/1433/2700/7279
• SQL Server – 1433
• Hypervisor – 80/443
• License Server – 2700/7279
• StoreFront – 80/443/389/636
• For a full list of required ports, please refer to the article under additional resources.
N
ot
fo
• Communication Ports Used by Citrix Technologies: https://support.citrix.com/article/CTX101810
rr
es
al
e
or
di
s tri
b ut
io
n

Network High
Availability Aggregation Switch Aggregation Switch
• Each rack has two Top of
N
Rack (TOR) switches. Server Rack A Server Rack B Server Rack C
ot
• All hosts are connected to
both TOR switches.
fo
• Each TOR switch is
rr
connected to two
es
aggregation switches to
al
achieve full HA on the
e
network stack.
or
di
s tri
b ut
io
n
Key Notes:
• Citrix leading practice is to configure a highly available network.
• Most enterprise customers have this in place and can assist the Citrix team in compliance.
• The graphic depicts an example of network high availability related to other networking equipment and vendors that are
included in the datacenter networking design.

• Install the Hardware: https://docs.citrix.com/en-us/citrix-hardware-platforms/sdx/installing-the-hardware.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Networking
Considerations
In Public Clouds
• Express route / VPN
N
• Direct
ot
• Inter-region Connections
fo
• Virtual Networks / Subnets
rr
• Network Security Groups
es
• Load balancer / Traffic manager
al
e
or
di
s tri
but
io
n
Key Notes:
• Microsoft Azure:
• Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many
types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the
internet, and on-premises networks. VNet is similar to a traditional network that you'd operate in your own data
center, but brings with it additional benefits of Azure's infrastructure such as scale, availability, and isolation.
• VNet concepts

• Address space: When creating a VNet, you must specify a custom private IP address space using public
and private (RFC 1918) addresses. Azure assigns resources in a virtual network a private IP address
from the address space that you assign. For example, if you deploy a VM in a VNet with address space,
10.0.0.0/16, the VM will be assigned a private IP like 10.0.0.4.
• Subnets: Subnets enable you to segment the virtual network into one or more sub-networks and allocate
a portion of the virtual network's address space to each subnet. You can then deploy Azure resources in
a specific subnet. Just like in a traditional network, subnets allow you to segment your VNet address
N
space into segments that are appropriate for the organization's internal network. This also improves
ot
address allocation efficiency. You can secure resources within subnets using Network Security Groups.
fo
For more information, see Security groups.
• Regions: VNet is scoped to a single region/location; however, multiple virtual networks from different
rr
regions can be connected together using Virtual Network Peering.
es
• Subscription: VNet is scoped to a subscription. You can implement multiple virtual networks within each
al
Azure subscriptionand Azure region.
• AWS:
e
• A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated
or
from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon
di
EC2 instances, into your VPC. You can specify an IP address range for the VPC, add subnets, associate
security groups, and configure route tables.
s tri
• A subnet is a range of IP addresses in your VPC. You can launch AWS resources into a specified subnet.
b
Use a public subnet for resources that must be connected to the internet, and a private subnet for
ut
resources that won't be connected to the internet. For more information about public and private subnets,
io
see VPC and Subnet Basics.
• To protect the AWS resources in each subnet, you can use multiple layers of security, including security
n
groups and network access control lists (ACL). For more information, see Security.
• Supported Platforms
• The original release of Amazon EC2 supported a single, flat network that's shared with other customers
called the EC2-Classic platform. Earlier AWS accounts still support this platform and can launch
instances into either EC2-Classic or a VPC. Accounts created after 2013-12-04 support EC2-VPC only.

For more information, see Detecting Your Supported Platforms and Whether You Have a Default VPC.
• Virtual Network Documentation for Azure: https://docs.microsoft.com/en-us/azure/virtual-network/
• Virtual Private Cloud Documentation for AWS: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-
amazon-vpc.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
When segmenting a network with firewalls
ot
between VDAs and servers, where would you
fo
typically recommend to place the Citrix
Provisioning servers?
rr
es
Typically Provisioning servers would be placed in the
same network as the VDAs or a separate network
al
would be defined for streaming.
e
or
This is to ensure that firewalls are not scanning and
delaying the Provisioning traffic.
di
s
tri
b
ut
io
n

N
ot
Security
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify how to meet the security objectives and
N
leading practices in a Citrix Virtual Apps and
ot
Desktops environment.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Identify how to meet the security objectives and leading practices in a Citrix Virtual Apps and Desktops environment.

Securing Hypervisor
Administrative Access
Virtual Machines
Citrix Hypervisor:
N
• By default, uses a self-signed certificate created
ot
during installation to encrypt communication via
SSH and XAPI or HTTPS.
fo
Delivery Controller Hypervisor
• To trust this certificate, verify its fingerprint to the
rr
HTTPS
one shown on its physical console (xsconsole /
es
status display).
al
• The certificate can also be exchanged for a HTTPS
e
certificate issued from a trusted corporate certificate
or
authority.
di
Admin
s tri
XenCenter
Console
b ut
io
n
Key Notes:
• To secure the Controller connection:
• Citrix Hypervisor and vSphere should be configured to use TLS encryption
• Hyper-V will automatically leverage WCF protocol
• Always use trusted certificates connecting to Citrix Hypervisor Hosts
• Host connections should use HTTPS
• If you have Hyper-V, the Controller will automatically leverage the WCF protocol to secure the traffic:

• Add certificate to Pool Master, SCVMM or vCenter
• Configure host connection to use HTTPS
• To reduce the attack surface, do not connect your Citrix Hypervisor Host’s management LAN directly to the
internet.
• Security Recommendations When Deploying XenServer:
N
https://www.citrix.com/content/dam/citrix/en_us/documents/white-paper/security-recommendations-when-
ot
deploying-citrix-xenserver.pdf
fo
rr
es
al
e
or
di
s tri
but
io
n

Securing the Physical Network and Hosts
It is important to secure all the components of the physical network to protect the
infrastructure from hostile entities or traffic.
N
ot
12 12
fo
rr
es
al
Host NICs should be Designate specific ports Erase all previous
e
configured for the same for specific types of configurations when you
or
networks across all hosts traffic. reuse physical switches.
in a resource pool. Existing passwords or
di
configurations could expose
s
your environment to attack
tri
but
io
n
Key Notes:
• Take steps to limit physical access to systems, as a number of different functions may be running in a virtual environment
at a specific physical location.
• If you require support for hardware features that enable remote administration on the host (for example, Dell DRAC or HP
iLO), ensure that access is secured in accordance with your organization’s security policy for these features. Otherwise,
these features should be disabled.
• Consider the type of traffic (for example, untrusted guest VM traffic) on a network, when enabling remote administration on

an interface on that network.
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Securing Resource Pools/Clusters
Create pools that contain hosts in one physical location when a

specific level of physical security is required.
Physical Site A Physical Site B (VLAN)
N
ot
10.10.20.x 10.10.20.x
fo
rr
Pool Host Servers Pool Host Servers
es
Management Network Management Network 10.10.20.x
al
e
or
• Physical SiteLocal
Corporate A LAN • Physical Site B (VLAN)
Network 10.10.30.x 10.10.40.x
di
VLAN
Pool Host Switch Pool Host
s
10.10.20.x Servers Servers
tri
Pool Host Servers Pool Host Servers
b ut
io
n
Key Notes:
• All Management traffic should be physically (or logically ) isolated from other non-management traffic.
• VLANs can be used to logically isolate management traffic.
• Create pools that contain all hosts in one physical location (if possible).
• Routers can be configured to tag all traffic from the management interfaces in the pool with a VLAN tag.
• Create pools that contain hosts in one physical location when a specific level of physical security is required. (do not
design a pool that contains hosts in one physical location that is less secure than another physical location).

Protecting
Virtualized Storage
• Virtualized storage can simultaneously reside in multiple physical
N
locations.
ot
• Place all physical drives in a location where they are not physically at risk.
fo
• NFS: Configure target and host authentication to protect data.
rr
• ISCSI: LUN Zoning and LUN Masking to limit which hosts can access the
es
storage repositories.
al
e
or
di
s tri
but
io
n
Key Notes:
• An example of virtualized storage is when one physical storage device is presented to users as one or more virtualized
storage devices. Or, conversely when multiple physical devices are presented as one virtual disk.
• With multiple Citrix Hypervisor pools, there should not be shared SMB or iSCSI storage networks between pools
containing differing levels of trust.
• Both MS Hyper-V and VMware vSphere Clusters can utilize virtualized storage. Both support NFS with it. Additionally,
Hyper-V can utilize SMB and vSphere can use its own Vstorage manager.

• For NFS - it is recommended ensuring that, because the VHD is not an encrypted file format, only authorized
Citrix Hypervisor hosts and authorized administrators can mount the file system. This can be done by ensuring
only the correct Citrix Hypervisor hosts can mount the file system by limiting the export to specific IP
addresses.
• Limiting export is typically done when setting up the NFS storage system. It is ensuring that the storage
interfaces of the remote storage device are not visible outside of the dedicated storage network.
• When using IP-based storage devices the storage traffic also flows through the Citrix Hypervisor control
N
domain.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Isolating the Management Network
and Separating Other Networks
Subnet A
Firewall
Management Internet
Network
• By default, Citrix Hypervisor uses the management
N
interface for all three types of network traffic
ot
(management, storage, and guest), which can
result in vulnerabilities to the infrastructure. Subnet B
fo
• Separating management from other traffic types is
rr
Host Hypervisor
considered a leading security practice for Citrix Storage Network
es
Hypervisor and other hypervisors.
al
e
or
di
Network
s
Switch Virtual Machines
tri
Guest Network
b ut
io
n
Key Notes:
• Citrix Hypervisor has three distinct categories of network traffic: (a) management traffic, (b)storage traffic, and (c) VM
(guest operating system) traffic. You should physically or “logically” separate the management, storage, and guest
networks.
• The three categories of Citrix Hypervisor network traffic can be configured to travel over separate or shared networks.
• Citrix Hypervisor management interfaces can be separated using various hardware and media, such as NICs, cables,
switches, or ports.

• Storage network must be placed on a different subnet from the management traffic; the storage subnet must
be a separate IP subnet that is not “routable” from the management interface. If the physical or logical
configuration does not enforce the traffic separation, then Citrix Hypervisor may direct storage traffic over the
management interface after a host reboot, due to the order in which Citrix Hypervisor initializes NICs.
• All VMs should be configured using guest networks; isolate VM guest traffic by connecting the NIC to a switch
port used for VM traffic only. In situations where hosts only have one NIC dedicated to guest traffic, separate
traffic into separate logical networks.
N
• Isolate production networks from staging, testing and development networks.
ot
• To reduce the attack surface, do not connect your Citrix Hypervisor Host’s management LAN directly to
fo
the internet.
• Use a dedicated, highly available management vLAN.
rr
• Ensure that no VM is connected to the management LAN or networks used for storage (such as iSCSI or
es
NFS).
al
e
• Security Recommendations When Deploying XenServer (page 14):
or
https://www.citrix.com/content/dam/citrix/en_us/documents/white-paper/security-recommendations-when-
di
deploying-citrix-xenserver.pdf
s tri
b ut
io
n

Managing
Snapshots,
Backups and
Archives
• Security issues and sensitive data should be considered when planning or
N
performing backups, archives or disaster recovery actions on VMs.
ot
• Be aware of the storage array’s security level, physical security, and who
can access it.
fo
rr
• If VM snapshots include sensitive data, apply the same level of security to
all aspects of the archival or backup process as you would to the VM.
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Always consider if there is potentially sensitive data on the VM before configuring VM snapshots, backups, archives, or
disaster recovery.
• Be aware of all administrators that have permissions to access the snapshots and mirrored Disaster Recovery site.
• Any administrator assigned an RBAC role of Pool Admin, Pool Operator, or VM Power Admin can start a snapshot taken
from any VM in the pool.
• When backing up copies of VMs for storage, ensure VMs containing sensitive information are backed up in a location with

sufficient logical and physical security.
• Avoid simultaneous virus scans on VMs. Running simultaneous security scans on multiple VMs on a host can
cause unnecessary spikes in resource usage.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Hypervisor-Level Security
Considerations
RING 3 (User Applications)
• Citrix Hypervisor introduces a security feature RING 1 & 2
N
containing multiple rings (levels) of protection.
ot
• Hypervisor Introspection operates at the hypervisor
(minus 1) ring level of privilege (underneath the
fo
tools installed in-guest). RING 0 (OS Layer)
rr
es
al
RING (-1) HVI
e
or
di
s tri
but
io
n
Key Notes:
• Citrix Hypervisor introduces a security feature containing multiple rings (levels) of protection.
• Using Citrix Hypervisor and Bitdefender’s Hypervisor Introspection (HVI) offers real-time memory scanning and monitoring
for virtual machines.
• Citrix & Bitdefender Prevent Another Zero-day Vulnerability with Hypervisor Introspection:

https://www.citrix.com/blogs/2018/04/11/citrix-bitdefender-prevent-another-zero-day-vulnerability-with-
hypervisor-introspection/
• Bitdefender Hypervisor Introspection: https://citrixready.citrix.com/bitdefender/bitdefender-hypervisor-
introspection.html
• Secure Browsing – powered by Citrix Virtual Apps, Citrix Hypervisor Direct Inspect APIs and Bitdefender HVI:
https://www.citrix.com/content/dam/citrix/en_us/documents/white-paper/secure-remote-browser.pdf
N
• Announcing the First-Ever Hypervisor Security Layer Only Available with XenServer:
ot
https://www.citrix.com/blogs/2017/02/09/announcing-the-first-ever-hypervisor-security-layer-only-available-
with-xenserver/
fo
rr
es
al
e
or
di
s tri
but
io
n

Public Cloud
Hosting Security
Considerations
• Avoid exposing VMs to the Internet.
N
• Configure Network Security Groups to protect VMs.
ot
• Don’t assign VMs public IP addresses.
fo
• Deploy a secure double hop jump station strategy if needed.
rr
• Implement a VPN or Express Route to secure traffic.
es
• Route cloud Internet traffic back through on-premises proxy / firewall for
al
scanning.
e
or
di
s tri
b ut
io
n
Key Notes:
• As a reminder, when we talk about public clouds, we mean services like Microsoft Azure and Amazon Web Services.
• Avoid exposing VMs to the Internet.
• Configure Network Security Groups to protect VMs.
• Don’t assign VMs public IP addresses.
• Deploy a secure double hop jump station strategy if needed.
• Implement a VPN or Express Route to secure traffic.

• Route cloud Internet traffic back through on-premises proxy / firewall for scanning.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
ot
When using Citrix Hypervisor, why is it important
fo
to connect the networks identically across the
different hosts in a pool?
rr
es
Citrix Hypervisor requires the network settings across
all pool members to be identical, otherwise VM
al
Migration, High Availability and Workload Balancing
e
will fail.
or
di
s
tri
b
ut
io
n

Exercise 7-1: Calculate
Hardware Requirements
Workspace Lab has informed your team that they
N
need an estimate of the hardware needed for the
ot
planned environment.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 7-1A:
Review Design Requirements
Task:
N
• Review Design Requirements Document.
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 7-1B:
Update Sizing Spreadsheet
[30 minutes]
Task:
N
• Using the Design Requirements and sizing
ot
guidelines covered in the course, update the sizing
spreadsheet to develop an estimate for the
fo
hardware requirements of the environment.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 7-1C:
Update Detailed Design Document
[30 minutes]
Task:
N
• Based on the numbers obtained from the sizing
ot
spreadsheet, update the Detailed Design
Document.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Sizing Spreadsheet – Answer Key
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Sizing Spreadsheet – Answer Key (Continued)
N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

General
Each datacenter must be able to support the entire user population in the event of an outage (6000 maximum
Hardware-1 High
N
concurrent users are expected).
ot
Hardware-2 High Within a chassis, N+1 host redundancy must be present.
fo
Include sufficient hosts to support the designed use cases:
rr
 3500 users: Hosted Apps on a Windows Server 2012 R2 image
es
o Users typically open 1-2 office productivity apps.
 2000 users: Hosted Shared Desktop on a Windows Server 2016 image
Hardware-3 High
al
o User typically launch 5-10 office productivity apps within the desktop, and occasionally view multimedia.
e
 500 users: Hosted VDI (Random/Non-Persistent) on a Windows 10 image
o Users require dedicated resources for intense multimedia or data processing tasks.
or
 All three images will be provisioned using PVS.
di
Hardware-4 Medium Avoid over-provisioning resources where possible to avoid unnecessary costs to the project.
s tri
Hardware-5 Medium Account for Antivirus and Monitoring CPU overhead during sizing
b ut
io
n

General
Hardware-6 Medium Align with recommended baselines for CPU & memory oversubscription, as well as hyperthreading.
N
ot
Hardware-7 High Provide a summary of the overall resources needed for each datacenter.
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Site
Server Model Cisco UCS B200 M4 Blade Server Model selected by Workspace Lab.
N
Two-socket x 12 cores per socket: 24
Host CPU CPU selected by Workspace Lab.
ot
physical cores
Minimizes unused RAM on hosts while accounting for
fo
Host RAM 320 GBs
component requirements and host overhead.
rr
Host Storage Location SAN Storage Determined by Workspace Lab.
es
al
e
or
di
s tri
utb
io
n

Detailed Design – Answer Key (continued)
Sizing Calculation Assumptions

Expected peak concurrent usage from Workspace Labs
Total Concurrent Users 6,000
which must be accommodated by each datacenter.
Server OS VDA vCPUs 4 Aligns with NUMA node size.
N
Hosted Apps VDAs: 8
Server OS VDA Memory (GB) Aligns with recommended baselines.
ot
Hosted Shared Desktops VDAs: 20
Hosted Apps VMs: 40
Server OS VDA Disk (GB) Aligns with recommended baselines.
fo
rr
Desktop OS VDA vCPUs 4 Aligns with recommended baseline for heavy workload users.
Within recommended baseline range for heavy workload
es
Desktop OS VDA Memory (GB) 6 users. (7-8 GBs per VDA would also be acceptable, but
al
increases the RAM required per host, increasing costs).
e
Desktop OS VDA Disk (GB) 20 Aligns with recommended baseline for heavy workload users.
or
Users per Desktop OS VDA 1 Each VDA is dedicated to a single user at a time.
Starting baseline, performance should be validated during
di
Server OS VDAs: 1.5x rollout. (Different overcommit ratios are acceptable as long as
CPU Overcommit Ratio
s
Desktop OS VDAs: 6x they are justified, for example to reduce costs or to use each
tri
host more efficiently).
b
Enabled, assuming 10% performance
Hyperthreading Recommended by Citrix.
ut
increase.
io
n

Resource Layer Requirements per Datacenter (summary)

Hosted Apps VDAs: 9
Total Hosts required Based on sizing spreadsheet.
Hosted VDI VDAs: 14
Overall: 33
N
Max concurrent users for each use case / number of hosts
ot
Hosted Apps VDAs: 388 per use case
fo
Users per physical host
Hosted VDI VDAs: 35 Note: The “users per VDA” numbers need to be validated by
rr
Workspace Lab. As shown in the calculations, if this number
changes, the total hosts required
es
al
e
or
di
s tri
b
ut
io
n

Exercise 7-2: Calculate
Network Requirements
Your team completed an interview with the
N
Workspacelab IT team regarding the current network
ot
configuration and architecture including the
requirements they have for the new design and
fo
solution.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 7-2A:
Task:
N
• Review Meeting Notes and Design Requirement
ot
document.
fo
rr
• Copy and update Meeting Notes and Design
es
Requirement document to show which requirements
met by design.
al
e
or
di
s
tri
utb
io
n

Exercise 7-2B:
Update Detailed Design Document
[20 minutes]
Task:
N
ot
requirements met.
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Security

There are firewalls between the DMZ vLAN and the Internet,
and between the DMZ vLAN and the internal vLANs.
N
VLAN security Meet Network-8 requirement
All VLANs must be passed through a firewall to allow packet
ot
inspection and port blockings in order to strengthen the security.
fo
rr
A new redundant firewall pair should be deployed in each
Firewall Meet Network-8 requirement
es
datacenter, consult with vendor on model details.
al
Citrix ADC is deployed in one-arm mode.
e
or
Citrix ADC
Citrix ADC should be deployed in two arm mode so internal and Meet Network-10 requirement
deployment
DMZ services can be hosted on separate networks and will not
di
have to traverse the firewall.
s tri
b ut
io
n

Hypervisors
All new hypervisors should have three network teams/bonds in

Hypervisor Meet Network-11 and network 12
place. Each network bond will have a separate function:
N
networking requirement
Management, Storage and Guest traffic.
ot
fo
Hypervisor
New hardware should rely on 10 Gbps NICs. Meet Network-13 requirement
rr
networking
es
al
Repurposed
e
Upgrade all repurposed hardware to have six 10 Gbps NICs Meet Network-14 requirement
hypervisors
or
di
stri
b ut
io
n

Switches

One Top of Rack switch is deployed in each rack with 1 GB
connections available.
N
Switch Meet Network-15 and network 16
Two Top of Rack switches should be deployed in each rack,
ot
deployment requirement
ToR switches should have enough 10 Gbps ports to support all
fo
hardware in the rack. All NIC bonds should be split between the
rr
two ToR switches to eliminate single points of failure.
es
Two high performance aggregation switches with fiber modules
Aggregation
should be deployed to handle the ToR aggregation, each ToR Meet Network-17 requirement
al
switch
switch should be connected to both aggregation switches.
e
or
General fault
All network equipment including routers and firewalls should be
tolerance and Meet Network-18 requirement
di
connected to two switches.
cabling
s tri
b ut
io
n

VLANS
N
ot
Configure a new VLAN to support VDA deployment, enable appropriate port
VDA VLAN Meet Network-19 requirement
fo
openings in the firewall between this and other VLANs
rr
es
IP Addresses and DHCP
al
e
The existing Server vLANs will be used in the NYC and SFO datacenters.
or
Server IP segment Meet Network-20 requirement
The server VLAN should be extended to support extra IP addresses, suggest
di
a /23 network in both NYC and SFO datacenter
s tri
A new IP range should be defined on the DHCP servers in both NYC and
VDA IP segment SFO, a DHCP helper option should be configured on the VLAN to allow the Meet Network-22 requirement
b ut
VDAs to receive DHCP addresses from the Server VLAN.
io
n

Key Takeaways
• The most important factors when sizing hardware
N
are processor and memory.
ot
• Citrix Hypervisor supports 64 hosts per pool, but for
Citrix Virtual Apps and Desktops the
fo
recommendation is 8-12 hosts per cluster.
rr
• Cloud hosted VDA workloads are typically sized
es
smaller than on-premises to reduce cost.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• The most important factors when sizing hardware are processor and memory.
• Citrix Hypervisor supports 64 hosts per pool, but for Citrix Virtual Apps and Desktops the recommendation is 8-12 hosts
per cluster.
• Cloud hosted VDA workloads are typically sized smaller than on-premises to reduce cost.

Key Takeaways
• A design should include methods to reduce IOPS on
N
shared storage, such as in memory write caching
ot
for Citrix Provisioning or MCS.
• Ensure that the datacenter network has proper
fo
bandwidth and fault tolerance to support your
rr
design.
es
• Include security in all aspects of your design even
al
down to the hypervisors and networks.
e
or
di
s tri
but
io
n
Key Notes:
• A design should include methods to reduce IOPS on shared storage, such as in memory write caching for Citrix
Provisioning or MCS.
• Ensure that the datacenter network has proper bandwidth and fault tolerance to support your design.
• Include security in all aspects of your design even down to the hypervisors and networks.

N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

Assessment, Design, and Advanced
Configuration
N
ot
Multiple Location Considerations
fo
rr
es
al
e
Module 8
or
di
s tri
but
io
n
Key Notes:
• Welcome to the Multiple Location Considerations module. This is the eighth module in the Citrix Virtual Apps and
Desktops 7 Assessment, Design and Advanced Configuration course.
• Throughout this module, we will review the difference between redundancy, fault tolerance and high availability and
explain how the Citrix Virtual Apps and Desktops architecture can support multiple locations. Determine how features such
as GSLB and optimal gateway routing can be used to support a multi location design. Identify how PVS, MCS and App
Layering will work in a multi-Site environment and present the considerations of image replication between the Sites.

Discuss the limitations of user profiles and cover the considerations about user and application data in multi-
Site environments. Present the different options for mapping printers and identify which options can reduce
print footprint in a multi-Site environment and examine zone considerations, VDA registrations and multi-
domain/forest support and advanced authentication methods such as ADFS and SAML.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Learning Objectives
• Identify multi-location architecture requirements and
N
business considerations.
ot
• Determine the access options in a multi-location
fo
rr
• Identify the considerations for image management
across multiple locations.
es
• Describe the requirements of handling data and
al
profiles across multiple locations.
e
or
• Identify the appropriate strategy to support printing
in a multi-location solution.
di
• Examine Zone configurations and Active Directory
s tri
considerations in a multi-location deployment.
but
io
n
Key Notes:
• Identify multi-location architecture requirements and business considerations.
• Determine the access options in a multi-location Citrix Virtual Apps and Desktops deployment.
• Identify the considerations for image management across multiple locations.
• Describe the requirements of handling data and profiles across multiple locations.
• Identify the appropriate strategy to support printing in a multi-location solution.

• Examine Zone configurations and Active Directory considerations in a multi-location deployment.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

N
Introduction to Multiple Location
ot
Considerations
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify multi-location architecture requirements and
N
business considerations.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Identify multi-location architecture requirements and business considerations.

Redundancy vs. Fault Tolerance vs. High Availability
Redundancy Fault Tolerance High Availability
N
ot
fo
rr
Citrix Gateway Citrix Gateway
es
Load Balancer Load Balancer
StoreFront StoreFront
al
e
or
di
Delivery Delivery
s
Controller Controller
tri
Delivery Delivery
b ut
io
n
Key Notes:
• Redundancy – involves having duplicate components available, so that the component isn’t a single point of failure. This
can be applied on a case-by-case basis for each component.
• Fault tolerance – similar to redundancy in that a fault tolerant system can withstand the failure of any single component.
However, it is a higher standard than redundancy, because it requires all components within a system to be redundant
enough to withstand any component failure. For example if you implemented redundant Delivery Controllers, but still had a
single StoreFront server, the environment is not fault tolerant because the StoreFront failure could still cause an outage.

• High Availability – applies when systems are not only redundant and fault tolerant but are always available to
end users through the use of automatic failover between components. So implementing redundancy in a
component or systems does not necessarily mean that the system is highly available.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Multi-Location Architecture Options in Citrix Virtual Apps and Desktops
Global Site Structure
Site 1
Data Center 2 / Satellite Zone 1
N
• Concurrent users: 5,000
Data Center 1 / Primary Zone • Applications: 3
ot
• Location: England
• Concurrent users: 20.000
• Applications: 56
fo
• Location: USA West
rr
es
al
e
• Concurrent users: 200
• Applications: 1
or
• Applications: 1
• Location: USA Central • Location: Germany
di
stri
b ut
io
n
Key Notes:
• A Citrix Virtual Apps and Desktops Site groups desktops and applications together to form a single architectural and
management entity. All persistent and dynamic data for the Site, including Site configuration, desktop assignments, and
session state, is stored in a Site’s database.
• A Site can be contained within a single location, span across multiple locations or be a partial location. Through rigorous
testing, a single Citrix Virtual Apps and Desktops Site can support 40,000 or more concurrent sessions.
• Zones subdivide single Sites, often associated with geographical locations. There are several factors to consider when

determining the overall topology of the Citrix Virtual Apps and Desktops solution:
• Risk Tolerance
• Security
• Administrative Boundaries
• Geographical Connectivity
• A Global Site structure uses a single Citrix Virtual Apps and Desktops Site with multiple zones.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Regional Site Structure
Site 1 Site 2
Data Center 2 / Primary Zone
N
ot
• Applications: 3
• Concurrent users: 20.000
• Location: England
fo
rr
es
al
e
• Applications: 1
or
• Location: USA Central • Concurrent users: 150
• Applications: 1
• Location: Germany
di
s tri
b ut
io
n
Key Notes:
• A Regional Site structure has one Site per region, in this case one for North America and one for Europe.
• This may be desirable for organizations with regional IT teams or sub-organizations that want a dedicated environment.

Functional/Organizational Site Structure
Site 3 Site 1 Site 2
N
Data Center 1 / Data Center 1 / Primary Zone
Primary Zone
ot
• Concurrent users: 20.000 • Applications: 3
• Applications: 56 • Location: England
• Concurrent users: • Location: USA West
fo
20.000
rr
es
al
e
• Applications: 1
or
• Location: USA Central • Concurrent users: 150
• Applications: 1
• Location: Germany
di
s tri
utb
io
n
Key Notes:
• The Functional/Organizational Site structure further sub-divides the environment into more Citrix Virtual Apps and
Desktops Sites. In this case, different divisions of the company may wish to manage their own environment, even if they
are in the same geographic area.

Multi-Site Architecture Considerations
Business Requirements
Risk Tolerance Security
A large bank hosts 10,000 desktops from a single A retail organization required complete separation for
N
datacenter. To reduce risk, it was decided that no Site employees responsible for managing financial data. To meet
ot
should exceed 5,000 desktops. Therefore, despite the this requirement, two separate Sites were created within the
desktops being connected by a fast and redundant network, same datacenter – one for financial employees and a
fo
two Sites were created. second for all other employees.
rr
es
User Locations Application and Data Locations
al
e
A manufacturing company in the Germany hosts a Site in A research institution maintains several research stations
or
Frankfurt that is accessed by employees. However, after the around the globe. Experiments at each station generate
acquisition of a large factory in Japan, the company decided large amounts of data which are stored locally. The
di
to create a new Site in Tokyo to ensure that the new institution decided to implement a single-site, multi-zone
employees would have a similar-quality experience to those architecture to keep its published applications and data in
s
in Germany. close proximity.
tri
b ut
io
n
Key Notes:
• Create multiple Citrix Virtual Apps and Desktops Sites to minimize the impact from a site-wide outage. For example,
corruption of the Site database could affect site-wide availability. For many organizations, the decreased risk from
implementing multiple Sites outweighs the additional management overhead and supporting infrastructure required.
• Although delegated administration is available, high-security organizations may require complete separation between
environments to demonstrate compliance with specific service level agreements.
• Due to billing/charge back requirements or how IT is structured, multiple Sites might be required to separate administrative

boundaries.
• Each identified user group should be assigned to a primary datacenter based on their location. Ideally, the
assigned datacenter should have local access to the users’ profiles and needed applications.
• In order to be effective, users must access their data. The data must be in close proximity to the application
for the user to have a good experience.
• As the distance between the application and data increases, latency also increases, which slows down any file
operation (opening, saving, modifying).
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Multi-Location Architecture
Zones and Geographical Connectivity Example: Multi-Zone Networking Infrastructure
Site 1
Data Center 1 Data Center 2
Zones allow a single Site to span across Concurrent users: 3,000

Concurrent users: 10,000
N
geographical locations, but there must be sufficient Applications: 55 Applications: 5
Location: Primary Zone Location: Satetellite Zone
ot
bandwidth between satellite zone(s) and the primary USA West England
zone for efficient session performance.
fo
rr
Zone Networking Requirements
es
Data Center 4 Data Center 3
al
Session Count Max Concurrent Min Site-to-Site
(Concurrent Users) Session Launches Bandwidth
e
Less than 50 20 1 Mbps
or
50 to 500 25 1.5 Mbps Concurrent users: 150 Concurrent users: 25
Applications: 2 Applications: 1
di
500 to 1,000 30 2 Mbps Location: Satetellite Zone Location: Satetellite Zone
Germany USA Central
s
1,000 to 3,000 60 8 Mbps
tri
Over 3,000 60 8 Mbps
b ut
io
n
Key Notes:
• Citrix Virtual Apps and Desktops can handle tolerate latencies of up to 250 ms between zones. As a result, the primary
remaining constraint is ensuring that there is sufficient bandwidth between locations to handle the expected traffic.
• When the network latency of your zones is more than 250 ms, we recommend that you deploy multiple Sites instead of
zones.

• Zones: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-deployment/zones.html
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n


Desktops solution for a large bank. The bank has
two main offices, each with over 3000 users and an
N
average of 60 ms latency between the two Sites.
ot
The CIO is asking for recommendations on
fo
whether to deploy one Site with two zones or two
separate Sites, what do you tell him?
rr
es
al
Both solutions are technically feasible with the latest
e
versions of Citrix Virtual Apps and Desktops.
or
Ask the CIO some follow-up questions about the
di
disaster recovery, fault tolerance, security, and
s
organizational requirements, which can collectively be
tri
used to choose the appropriate setup for the bank.
b
ut
io
n

N
ot
Access
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the access options in a multi-location
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the access options in a multi-location Citrix Virtual Apps and Desktops deployment.

Global Server Load New York Datacenter San Francisco Datacenter
Balancing (GSLB)
Router Router
Connect.work
spacelab.com
Firewall Firewall
GSLB is a Citrix Gateway
N
feature that:
ot
Switch Switch Switch Switch
• Balances load across data
Endpoint
centers.
fo
rr
• Directs client requests to the
closest or best performing GSLB
es
Citrix Gateway Citrix Gateway Citrix Gateway Citrix Gateway
data center.
al
• Can direct client requests to
e
responsive data centers only
or
in a disaster recovery
StoreFront StoreFront StoreFront StoreFront
di
scenario.
s tri
b ut
Delivery Controller Delivery Controller Delivery Controller Delivery Controller
io
n
Key Notes:
• Today many enterprises operate multiple data centers, which can be spread across the globe. The Citrix Gateway GSLB
feature ensures continuous availability and recovery of applications deployed at multiple data center locations.
• This feature can be used in conjunction with multiple Citrix Virtual Apps and Desktops Sites to direct users to a particular
data center. Requests can be redirected based on dynamic changes in global network performance, Site connectivity and
availability.
• Server location, load and many other factors determine the optimal server to use.

• Deployment Methods:
• Active-active site deployment: to ensure that data is consistently available and client requests are load
balanced across each active data center.
• Active-passive site deployment: to enable smooth failover in the even of a disaster by configuring an
active and passive data center.
• Parent-child topology deployment: to redirect users to the closest datacenter resources with the best
performance and meet the legal obligations by using the Metric Exchange Protocol (MEP).
N
• Use Cases of Global Server Load Balancing:
ot
• Disaster recovery - providing an alternate location for accessing resources in the event of failure, or a
fo
means of shifting traffic easily to simplify maintenance (or both)
• Load sharing - distributing traffic between multiple locations to:
rr
• Minimize bandwidth costs
es
• Limit the capacity used at a given location
al
• Limit exposure to various issues, including outages, geographic disruption, etc.
• Performance - to position content closer to users, which enhances the user’s experience
e
• Legal Obligations - present users with different versions of resources based on political location
or
di
• Global Server Load Balancing: https://docs.citrix.com/en-us/citrix-adc/current-release/global-server-load-
s tri
balancing.html
b
• Citrix Application Delivery Controller (ADC) Global Server Load Balancing (GSLB): https://docs.citrix.com/en-
ut
us/tech-zone/design/reference-architectures/adc-gslb.html
io
• GSLB deployment types: https://docs.citrix.com/en-us/citrix-adc/current-release/global-server-load-
balancing/deployment-types.html
n
• StoreFront and Citrix Gateway GSLB Considerations: https://www.citrix.com/blogs/2018/05/25/storefront-and-
citrix-gateway-gslb-considerations/

Optimal Gateway
Routing New York Datacenter
HDX
Citrix Gateway
Word 2016
N
ot
fo
StoreFront Delivery Controller VDA
rr
Endpoints
es
al
San Francisco Datacenter
e
or
HTTP(S)
di
Citrix Gateway StoreFront Delivery Controller
s tri
but
io
n
Key Notes:
• StoreFront enables you to define the optimal appliance for users to access each of the deployments providing resources
for a store. For example, if you create a store that aggregates resources from two geographical locations, each with a
Citrix Gateway appliance, users connecting through an appliance in one location can start a desktop or application in the
other location.
• However, by default, the connection to the resource is then routed through the appliance to which the user originally
connected and must therefore traverse the corporate WAN.

• Optimal Citrix Gateway routing can also be used in the special case where local users on the internal network
are required to log on to Citrix Gateway for endpoint analysis. With this configuration, users connect to the
store through the Citrix Gateway appliance, but there is no need to route the connection to the resource
through the appliance as the user is on the internal network.
• In this case, you enable optimal routing, but do not specify an appliance for the deployment, so user
connections to desktops and applications are routed directly and not through Citrix Gateway.
N
ot
• Optimal Citrix Gateway routing: https://docs.citrix.com/en-us/storefront/1912-ltsr/plan/high-availability-and-
fo
multi-site-configuration.html#optimal-citrix-gateway-routing
rr
es
al
e
or
di
s tri
b ut
io
n

Zone Preference
and Failover
Delivery Zone-NYC
Group
NYC-VDA
Launch applications close to
N
their associated resources,
ot
such as: Zone-SFO
• Close to their home location.
fo
rr
• Close to the user's home StoreFront Delivery Controller SFO-VDA
Outlook Outlook
data. Endpoint
es
• Where user’s current
al
location is, or where the
e
Zone-MIA
Citrix Workspace app is
or
located.
di
MIA-VDA
stri
b ut
io
n
Key Notes:
• In a multi-zone Site, zone preference provides administrators more flexibility to control which VDA is used to launch an
application or desktop.
• The default priority order for selecting the preferred zone is application home > user home > user location.
• You associate a user or application with a zone by configuring a home zone for the user or application. A user or an
application can have only one home zone at a time.
• The three forms of zone preference are:

• Application home: Where the application’s data is stored.
• User home: The location of the user’s home data, such as a profile or home share.
• User location: The user’s current location (where Citrix Workspace app is running).
• Tailoring zone preference: As administrator can further restrict how zone preference is (or is not) used:
• Mandatory user home zone use – An administrator can specify to only launch a session in the user’s
home zone. Which means if the user does not have a home zone, there will be no failover to another
zone. In other words, you would rather deny a session launch than launch the session in a different zone.
N
• Mandatory application home zone use - An administrator can specify to only launch a session in the
ot
application home zone. Which means if there are no available application resources in the home zone,
fo
there will be no failover to another zone.
• No application home zone and ignore configured user home zone - If you do not specify a home zone for
rr
an application, you can also specify “do not consider any configured user zones when launching that
es
application.
al
• How preferred zones affect session use: When a user launches an application or desktop, the broker prefers
using the preferred zone rather than using an existing session.
e
or
di
• Zone Preference: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-
deployment/zones.html#tailoring-zone-preference
s tri
b ut
io
n

StoreFront NYC Site
Resource
Aggregation Receiver for Aggregation
Outlook
Web Group
NYC-DC
Allows for the grouping of
N
different Citrix Virtual Apps Outlook SFO Site
ot
and Desktops deployments
publishing identical resources
fo
(desktops or applications), so Outlook
rr
they can be aggregated for
es
users. Endpoint
Outlook Outlook StoreFront
SFO DC
al
• Load balance resources
across controllers.
e
MIA Site
or
• Resources must have the
Outlook
same name and path on
di
Outlook
each server to be
s
aggregated.
tri
b
MIA DC
ut
io
n
Key Notes:
• By default, StoreFront enumerates all the deployments providing desktops and applications for a store and treats all those
resources as distinct. So, the same resource that is made available from several deployments will result in users seeing
multiple icons for that resource upon enumeration.
• When you set up highly available multi-site configurations, you can group Citrix Virtual Apps and Desktops
deployments that deliver the same desktop or application so that identical resources can be aggregated for users.
• Grouped deployments do not need to be identical, but resources must have the same name and path on each server

to be aggregated.
• With Resource Aggregation, any desktop or application that is available from multiple Citrix Virtual Apps
and Desktops deployments, and configured for a particular store, will result in StoreFront presenting just
a single icon.
• When a user starts an aggregated resource, StoreFront determines the most appropriate instance of that
resource for the user on the basis of server availability, whether the user already has an active session, and
the ordering you specified in your configuration.
N
• The resource aggregation settings available in the console are accessible through the Manage Delivery
ot
Controllers option in the Action pane of the Store. If you define more than two Farms/Sites, the “Configure”
fo
option at the bottom of the window will automatically become enabled.
• If choose to “Configure,” you will see a window prompting you to configure user Farm mapping and/or
rr
resource aggregation. Here you will define user groups and map those user groups to Delivery Controllers.
es
• Once you have defined a user group that this configuration should apply to, select the aggregate resources
al
link and you will then be able to select which Sites will be configured for aggregation.
• Two options become available:
e
• Controllers publish identical resources: This setting places the Farms in the same “equivalent Farm set.”
or
No new functionality here.
di
• Load balance resources across controllers: This setting either load balances sessions across the Farms
or configures them for failover order. The ability to do this without requiring the two Farms/Sites to be
s tri
100% identical is a new feature of 3.6 that was a significant limitation before.
b
• Previously, if two Sites were non-identical but with some overlapping resources, configuring them for
ut
aggregation meant that the aggregated resources were automatically launched in failover order. Load
io
balancing was limited to identical Sites.
n
• Resource aggregation: https://docs.citrix.com/en-us/storefront/1912-ltsr/plan/high-availability-and-multi-site-
configuration.html#resource-aggregation

StoreFront NYC Site
Subscription Sync
Win10 Word Excel Outlook
StoreFront NYC-DC
Two options for subscriptions:
N
• Synchronizing subscriptions SFO Site
ot
Receiver for
between StoreFront server Web
groups.
fo
rr
• Share subscription database
Win10
between multiple stores.
es
StoreFront NYC-DC
Endpoint
al
e
Word
NYC Site
or
di
stri
b
StoreFront NYC-DC
ut
io
n
Key Notes:
• There are two ways to keep user’s subscriptions in sync for multi-location environments:
• Synchronizing subscriptions between StoreFront server groups:
• To provide a seamless experience for users moving between separate StoreFront deployments, you can
configure periodic synchronization of users’ application subscriptions between stores in different server groups.
• When establishing your subscription synchronization, note that the configured Delivery Controllers must be
named identically between the synchronized Stores and that the Delivery Controller names are case sensitive.

Failing to duplicate the Delivery Controller names exactly may lead to users having different
subscriptions across the synchronized Stores. If you synchronizing subscriptions from aggregated
resources, the name of the aggregation groups used by both Stores must also match.
• Share subscription database between multiple stores:
• It is common for administrators to configure multiple StoreFront stores when users are accessing
published resources both externally and internally on the corporate LAN. Configuring the two stores to
share a common subscription database improves and simplifies the roaming experience when users
N
access the same resource from inside or outside the corporate network. With a shared subscription
ot
datastore it does not matter whether they use the “external” or “internal” store when they initially
fo
subscribe to a new resource.
• Note: The Citrix Virtual Apps and Desktops controllers configured on each store must match exactly;
rr
otherwise, an inconsistent set of resource subscriptions on one store compared to another might
es
occur. Sharing a datastore is supported only when the two stores reside on the same StoreFront
al
server or server group deployment.
e
or
• Subscription synchronization: https://docs.citrix.com/en-us/storefront/1912-ltsr/plan/high-availability-and-multi-
di
site-configuration.html#subscription-synchronization
• Configure subscription synchronization: https://docs.citrix.com/en-us/storefront/1912-ltsr/set-up-highly-
s tri
available-multi-site-stores.html#configure-subscription-synchronization
b
• Configure two StoreFront stores to share a common subscription datastore: https://docs.citrix.com/en-
ut
us/storefront/1912-ltsr/configure-manage-stores/configure-two-stores-share-datastore.html
io
n

Access in a Hybrid Environment
Hybrid Options
Extend On-premises Deployment Citrix Cloud as Single Site w/ Public

Citrix Cloud as Secondary Site
to Public Cloud Cloud and On-premises Resources
N
ot
Access/HDX Access/HDX Access/HDX Access/HDX Access/
HDX HDX
Endpoints Endpoints Endpoints
fo
New York Azure East US San Francisco Citrix Cloud Citrix Cloud
Datacenter Datacenter Datacenter (Site 2)
rr
(Site 1)
(Site 1) (Site 2) (Site 1)
es
Citrix Gateway Service
al
Citrix Gateway Service
Citrix Gateway
e
Workspace Delivery Workspace Delivery
or
Service Controller Service Controller
StoreFront StoreFront StoreFront
di
Dallas Datacenter Azure South Central
s
Delivery Controller
US
Delivery Controller Delivery Controller
tri
Cloud VDA
b
Cloud VDA Citrix Cloud VDA
Connector
VDA VDA VDA Connector Gateway Connector
ut
io
n
Key Notes:
• Treat Citrix Cloud as a separate Site.
• Citrix Cloud is hosting its own Site infrastructure components, so it cannot be directly integrated with zones that are
not Citrix Cloud-managed.
• Consider StoreFront and Citrix Gateway placement.
• Remember that Cloud StoreFront and Cloud Citrix Gateway does not include all features nor customization options
(for more on this, refer to the Access Layer module).

• Deploy StoreFront and Citrix Gateway in the resource locations.
• This can provide more features and options when they are used for environment access. Additionally,
Citrix Gateway can be used as a reverse ICA proxy only at the resource location to minimize the number
of network hops needed to transfer HDX data.
• Use GSLB, Optimal Gateway routing and Multi-Site aggregation to achieve full hybrid integration.
• These features can still be used in a hybrid environment, provided that on-prem or public cloud-based
Citrix Gateway are being used.
N
ot
fo
• Azure Resource Manager, Citrix Cloud & Hybrid Deployment: https://www.citrix.com/blogs/2016/07/26/azure-
resource-manager-citrix-cloud-hybrid-deployment-oh-my/
rr
es
al
e
or
di
s tri
but
io
n

You are designing an active/active multi-site Citrix

Virtual Apps and Desktops deployment for a global
N
enterprise. One of the design goals are to ensure
ot
that a user always connects to the datacenter
closest to their location.
fo
Which GSLB mode should you consider?
rr
es
You should consider using the Parent-child topology
deployment in Global Server Load Balancing.
al
e
Make sure that your profile design can support this
or
connectivity design.
di
s tri
but
io
n
Key Notes:
• To review, the proximity setup redirects users to the closest datacenter resources with the best performance.
• In an upcoming lesson, we will review profile design for a multi-location environment.

N
ot
Image Management
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify the considerations for image management
N
across multiple locations.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Identify the considerations for image management across multiple locations.

Citrix Provisioning Architecture Across Sites
New York Datacenter New Jersey Datacenter
Provisioning
Farm
N
Provisioning Database
ot
Citrix Provisioning Site Provisioning Site
fo
VHD
rr
Replication
es
VHD VHD
Provisioning Server1 Site Store Provisioning Server2 Provisioning Server3 Site Store Provisioning Server4
al
Device Collection Device Collection
e
or
di
VDA VDA VDA VDA
s tri
utb
io
n
Key Notes:
• There are factors that must be considered when determining the overall Citrix Provisioning topology:
• Network - Provisioning servers are constantly communicating with the Farm database to retrieve system
configuration settings. Therefore, separate Farms should be created for each physical location where target devices
reside, unless they are connected to the database server by a fast and robust connection.
• Administration – Organizations may need to maintain the separation of administrative duties at a departmental,
regional or countrywide basis. Additional Citrix Provisioning Farms will add some complexity to the management of

the environment. However, this overhead is typically limited to initial configuration, desktop creation and
image updates.
• Organization – A practical reason for building multiple Sites is due to organizational changes. For
example, two companies may have recently merged through acquisition, but need to keep resources
separate while integration takes place.
• Configuring the organization to use separate Sites is one way to keep the businesses separate but
managed centrally through the Citrix Provisioning console.
N
• Only create additional Sites if the business requirements warrant it. A single Site per Farm is easier to
ot
manage and requires no additional configuration.
fo
• In the diagram shown, we see a single-farm, multiple Site architecture. Why might the organization decide to
use this topology?
rr
• Perhaps they have two well-connected datacenters and wish to minimize the administrative overhead
es
associated with managing the Provisioning infrastructure.
al
e
• Best Practices for Deployment PVS in multi-geo environments: https://support.citrix.com/article/CTX220651
or
di
s tri
b ut
io
n

Citrix Provisioning Networking Considerations Across Sites
1
• Stream only on high-performance networks.
N
• Subnet affinity to control load balancing.
ot
• Various factors can negatively impact Citrix Provisioning performance:
fo
• Latency between Provisioning servers and target devices.
rr
• Router hops between Provisioning servers and target devices.
• Firewalls between Provisioning servers and target devices.
es
• Packet or antivirus scanning of the Provisioning stream traffic.
al
• Spanning Tree on Provisioning server or target device ports.
• Large Send Offload on the Provisioning server and target devices.
e
• Auto Negotiation on Provisioning server and target devices NICs and switch ports.
or
di
s
tri
b ut
io
n
Key Notes:
• Provisioning servers are constantly communicating with the Farm database to retrieve system configuration settings.
Therefore, separate Farms should be created for each physical location where target devices reside, unless they are
connected to the database server by a fast and robust connection.
• When we talk about “high-performance networks”, what do we mean? A 10 Gbps network is recommended for use with
Citrix Provisioning. If a 10 Gbps network is not available, consider link aggregation to provide additional bandwidth to the
Citrix Provisioning Servers, or a dedicated physical streaming network.

• Overall, each target device booting from a vDisk will require some boot data, which varies by operating
system. Determine how much time will be required to boot the target devices can be estimated using the
following formula:
• Seconds to boot = (Number of targets * MB Usage) / Network Throughput
• The Citrix Provisioning Subnet Affinity is a load balancing algorithm that helps to ensure target devices are
connected to the most appropriate provisioning server. When configuring subnet affinity, the following options
are available:
N
• None – Ignore subnets; uses the least busy server.
ot
• Best Effort - Uses the least busy server/NIC combination from within the same subnet. If no server/NIC
fo
combination is available within the subnet, select the least busy server from outside the subnet. If more
than one server is available within the selected subnet, perform load balancing between those servers.
rr
This is the default setting.
es
• Fixed - Use the least busy server/NIC combination from within the same subnet. Perform load balancing
al
between servers within that subnet. If no server/NIC combination exists in the same subnet, do not boot
target devices assigned to this vDisk.
e
• Overall, anything that negatively impacts the connectivity between the Provisioning servers and target devices
or
will affect the performance of the latter.
di
• For example, firewalls can add latency and create bandwidth bottlenecks in Citrix Provisioning
environments. If the use of firewalls cannot be avoided, be sure to implement firewall rules allowing the
s tri
ports needed for Provisioning.
b
• Ideally, Provisioning should be designed so that Provisioning servers and target devices are located on
ut
hosts that are within the same rack or chassis.
io
• In a switching environment the Spanning Tree Protocol (STP) places ports into a blocked state while it
transmits Bridged Protocol Data Units (BPDUs) and listens to ensure the BPDUs are not in a loopback
n
configuration. The port is not placed in a forwarding state until the network converges, which depending on the
size of the network, may incur enough time to cause Preboot Execution Environment (PXE) timeouts.
• To eliminate this issue, disable STP on edge-ports connected to clients or enable PortFast.
• Offloading I/O tasks to the network interface reduces CPU usage and improves overall system performance,
however, Provisioning Streaming Services can be negatively impacted when Large Send Offload is enabled

due to the extra work placed on the network adapter.
• Many network adapters will have Large Send Offload and TCP checksum offload enabled by default.
• If Large Send Offload is enabled and the switch that the traffic is passing through does not support the
frame size sent by the Large Send Offload engine, the switch will drop the frame causing data
retransmission. When retransmitting, the operating system will segment the frames instead of the
network adapter, which can lead to severe performance degradation.
• Auto-Negotiation requires network devices and its switch to negotiate a speed before communication begins.
N
This can cause long starting times and PXE timeouts, especially when starting multiple target devices with
ot
different NIC speeds.
fo
• Citrix recommends hard coding all Provisioning Server ports (server and client) on the NIC and on the switch.
Be sure to sync-up with your networking team to find out the link speed and duplex settings on the network
rr
switches, and then matching those settings on the Provisioning servers and targets.
es
• The method used to configure the NIC speed and duplex settings will vary depending on whether the target
al
devices are physical or virtual, and if virtual, which hypervisor is hosting them.
e
or
• Best Practices for Configuring Provisioning Services Server on a Network:
di
• Understanding Subnet Affinity and Auto Rebalance: https://support.citrix.com/article/CTX138933
s tri
b ut
io
n

Citrix Provisioning vDisks and Storage Considerations
NYC Datacenter SFO Datacenter
RoboCopy or
vDisk Replicator
Provisioning Provisioning Tool Provisioning Provisioning
N
Server1 Server2 Server3 Server4
ot
fo
rr
DFS-R
es
Provisioning File Server Provisioning Provisioning File Server Provisioning
al
e
or
SAN
di
Replication
s
Provisioning Provisioning Provisioning Provisioning
tri
utb
io
n
Key Notes:
• The vDisk Replicator Tool is designed to replicate vDisks and versions from local storage on a Provisioning server to local
storage on other Provisioning servers in another Site. The “source” and “destination” Sites may reside in the same Farm,
but they must not share a Store. The vDisk Replicator Tool does not support vDisk stores that reside on shared storage.
• The vDisk Replicator Utility provides automation to help manage Provisioning replication using a DevOps methodology.
The scripts behind the utility can be run on a schedule to keep Provisioning stores in-sync between Provisioning Servers
in the same Site, different Sites, or even different Farms.

• New features with Release version 3.5 of the vDisk Replicator Tool:
• Deleting/removing vDisks. Now, the vDisk Replicator Utility has add, change, and delete capabilities.
• Script addition that contains a new status tab displaying how much disk space is available on all of the
Provisioning stores. (If you don’t have monitoring set up for Provisioning store disk usage this can be
used)
• Script now contains command “GetStoreSpace.ps1” for this functionality.
• Under the Setup tab you can now define warning and critical percent full amounts; using colors to which
N
those lines will be changed for the status page.
ot
• The ability to replicate between stores on the same Provisioning server. To use this functionality you will
fo
have to configure the stores using the manual store-matching feature of the stores tab.
• When configuring Citrix Provisioning for HA (feature of Citrix Virtual Desktops you first need to decide on the
rr
type of storage you will use to host your VHD images. Provisioning provides active-active HA meaning each
es
server will need to have access to the same set of VHDs simultaneously. NTFS will not tolerate multiple
al
servers accessing the same LUN in a read-write mode, even if you are not actively making changes from the
other servers.
e
• A lot of our customers have typically leaned toward the distributed model of local storage or LUN-per-server
or
because of simplicity, cost and scalability. This model does not require a SAN or clustered file system and it
di
works on virtual as well as physical Provisioning server Farms.
• It does comes with some additional administrative overhead requiring the administrator to copy new VHDs to
s tri
all Provisioning servers in the Farm and also making sure not to do it in the middle of production hours.
b ut
io
• The vDisk Replicator Utility is finally finished!: https://www.citrix.com/blogs/2019/06/04/the-vdisk-replicator-
utility-is-finally-finished/
n
• vDisk Replicator Tool: https://www.citrix.com/blogs/2017/04/12/vdisk-replicator-tool/
• Configuring for High Availability with Shared Storage: https://docs.citrix.com/en-us/provisioning/1912-
ltsr/advanced-concepts/managing-high-availability/ha-shared-store-config.html

Machine Creation Services Architecture Across Sites
N
ot
Master
SAN NYC SAN SFO
fo
M Mc Mc
rr
es
al
VDA VDA VDA VDA
I D I D
e
I D I D
or
Hypervisor NYC Hypervisor SFO
di
s
Delivery Controller
tri
b
ut
io
n
Key Notes:
• During catalog creation, MCS will automatically copy the Master image (M) to each Storage LUN (Mc) defined in the host
connection used for catalog creation.
• For each VM created in the catalog, an identity disk (I) and a delta disk(D) will be created.
• When deploying MCS in multiple data centers, the key consideration is how the master images will be replicated between
locations during normal operations.
• With Machine Creation Services, the hypervisor (or public cloud interface) must be used to export/import the master

image to the different Sites and resource pools.
• The time required for replication can be calculated using the following formula:
• (Time to deploy first VM) + (Time to replicate VM * Number of storage repositories)
• These variables can vary depending on the storage repository locations, as well as the hypervisor
and storage settings used. Features such as vSphere’s Storage APIs Array Integration (VAAI) and
Nutanix’s Shadow Clones can help to speed these processes.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

App Layering Multi-Site Considerations
Import to ELM2
N
ot
User Layer VDA User Layer
fo
Application Layer Application Layer
rr
Platform Layer Platform Layer
es
Elastic layers OS Layer Image Elastic layers OS Layer
Template
al
Export to
fileserver
ELM
e
or
File Server ELM Server1 File Server ELM Server2
di
s
Hypervisor NYC SAN NYC DFS-R Hypervisor SFO
tri
utb
io
n
Key Notes:
• Layers can be shared across composite images (so long as the underlying OS is consistent). It is possible to export all
your layers from one ELM appliance to a Windows share, and then import them to another appliance. This process could
be used to keep two appliances in separate physical Sites in sync.
• Elastic layers are attached to the OS layer they were created on. A new version of an OS layer is still the same OS layer,
so it will still work with the existing application layers. The reason is that Windows uses dynamic creation of some GUIDs,
short folder names, short file names, etc. Applications remember those, so we need to keep them consistent. Updating OS

layers by creating a new version of the layer (as opposed to importing a new OS image) is therefore
recommended.
• Enterprise Architect TechTalk: Citrix App Layering FAQ: https://www.citrix.com/blogs/2017/08/07/enterprise-
architect-techtalk-citrix-app-layering-faq/
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n


Desktops multi-site solution for a large corporation
that does multiple application updates every week.
The CIO has expressed concerns that there is not
N
enough WAN bandwidth to replicate the complete
ot
images and image replication should not occur
during production hours.
fo
Which image strategies should you consider?
rr
es
MCS might not be the right fit for this use case.
Consider one of the following options:
al
e
• Citrix Provisioning; replicate versions across the
or
WAN link using a scheduled task.
• App Layering; replicate the application layers during
di
non-production hours.
s
tri
b
ut
io
n

N
ot
Profiles and Data
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Describe the requirements of handling data and
N
profiles across multiple locations.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Describe the requirements of handling data and profiles across multiple locations.

Managing Roaming Profiles and Citrix Workspace App
Configurations Across Devices
• Workspace app configuration is stored in the user profile.
N
• Option to exclude Workspace app configuration and cached shortcuts from profile include:
ot
• Registry exclude:
fo
• Software\Citrix\Dazzle
rr
• Software\Citrix\Receiver
es
• Software\Microsoft\Windows\CurrentVersion\Uninstall
al
• Folder exclude:
e
• AppData\Local\Citrix
or
• File exclude:
di
• AppData\Roaming\Microsoft\Windows\Start Menu\Programs\*.lnk
s tri
utb
io
n
Key Notes:
• Native Citrix Workspace app caches account information in the user profile as well as application shortcut data, which
complicates the ability to seamlessly roam across machines with different StoreFront accounts, because information from
the last configuration is still present in the profile.
• Note that all of this complexity is dependent on the user profile being shared across these different machines; if user
profiles are not roaming across these devices, then these various Citrix Workspace app configurations will remain
independent.

• Windows Receiver Configuration and the User Profile: https://www.citrix.com/blogs/2016/12/12/windows-
receiver-configuration-and-the-user-profile/
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Profile Management Multi-Site NYC Datacenter
Replication Considerations
VDA
• Windows profiles cannot be active in two
N
datacenters at one time.
ot
One-way
• Use active/passive replication for redundancy and NYC FileServer1 replication NYC FileServer2
failover purposes.
fo
rr
• Alternatively, have a user profile per datacenter.
One-way
es
replication
al
e
or
VDA
di
s
SFO FileServer1 SFO FileServer2
tri
b
SFO Datacenter
ut
io
n
Key Notes:
• For redundancy and failover purposes, user data such as Windows profiles and documents should be synchronized
between datacenters. Although it is recommended to replicate user data between datacenters, the replication would be an
active/passive configuration; meaning the data can only be actively consumed from a single datacenter.
• The reason for this limitation is the distributed file locking method inside Windows that only allows a single user to actively
write to a file. Therefore, active/active replication of user data is not supported. Any supported configuration consists of a
one-way replication of data that is active in a single datacenter at any point in time.

Folder Redirections NYC Datacenter
and Other User Data

in a Multi-Location
Environment File Server
‘‘‘““‘‘‘ SFO Datacenter

• In this example, a user in
N
New York connects to a
ot
fo
machine in their local ‘‘‘““‘‘‘
rr
datacenter. Laptop VDA VDA
Router
es
• Most user data is located in
the NYC datacenter and can
al
be accessed within the LAN.
e
or
• Some data is also accessed
• Roaming profile
from Citrix Content • Network drives
di
Collaboration. • Folder redirection
s
• Client drive mapping
tri
• Citrix Content
Citrix Content
b
Collaboration Collaboration
ut
io
n
Key Notes:
• In environments with users who do not typically roam, handling data is relatively simple. All users are mapped to their
home datacenter, and their HDX session can access the profile, redirected folders, network drives, etc. within that
datacenter.
• Both the internal endpoint and Virtual Delivery Agent machine are able to access the data.
• In this example, Citrix Content Collaboration is being used as a cloud-based data storage location.
• Some vendors (including Citrix Content Collaboration) have storage connector features, where a single agent

consolidates storage repositories from numerous cloud-hosted and on-premises providers into a single
folder structure. This can help simplify the user experience even when accessing data from a variety of
locations.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Folder Redirections NYC Datacenter SFO Datacenter
and Other User Data
• Latency
in a Multi-Location • Bandwidth
• Packet-loss
Environment File Server
• Now, the user has traveled
N
to another part of the
ot
country and is accessing an
fo
HDX session through the
Laptop
rr
VDA VDA
SFO datacenter. Router
es
• Now, most of the user data
must be accessed over the
al
WAN.
e
• Roaming profile
• Network drives
or
• Some data can still be • Folder redirection
accessed as usual from the • Client drive mapping
di
local endpoint and Citrix • Citrix Content
s
Content Collaboration. Collaboration
tri
Citrix Content
Collaboration
b ut
io
n
Key Notes:
• If users roam and subsequently connect to an alternative Citrix Virtual Apps and Desktops environment, and user data has
not been replicated, many forms of data will need to traverse a WAN connection to be accessible within the HDX session.
• This can introduce latency and packet-loss, which can result in slowness when transferring or working with data in
redirected folders.
• It can also increase the bandwidth usage on the WAN connection which could impact other network traffic if large
numbers of users are roaming.

• If local client drive access is enabled, users can use their endpoints as a way to easily access data while
roaming. However, this may be unacceptable to some organizations from a security and fault tolerance
perspective, because the endpoint could be lost, stolen or otherwise compromised.
• Citrix Content Collaboration and other cloud-based storage solutions can provide another way of easily
enabling access to data regardless of user or VDA location.
• Note that the endpoint could access the data directly as long as it is in part of the corporate network but may
have similar performance issues as the VDA.
N
• However, this is a valid approach that is present in many environments today. It is a good fit for organizations
ot
where users rarely roam, have few or no personalization requirements, or if the various datacenters are
fo
relatively close to each other and/or have good connectivity.
rr
es
al
e
or
di
s tri
b ut
io
n

Folder Redirections NYC Datacenter SFO Datacenter
and Other User Data
in a Multi-Location
Environment File Server File Server
• In theory, an ideal solution Data
N
replication
would be to periodically
ot
replicate users’ data between
fo
datacenters, so it can be
Laptop
rr
VDA VDA
accessed locally when users Router
roam. However, there are
es
considerations here:
al
• How often and how much data
e
• Roaming profile
must be replicated?
• Network drives
or
• How to ensure a user does not • Folder redirection
inadvertently lose data while • Client drive mapping
di
roaming, or due to a lingering • Citrix Content
s
disconnected session in an Collaboration
tri
Citrix Content
alternate datacenter? Collaboration
b ut
io
n
Key Notes:
• If a significant number of users are expected to roam frequently as part of their workflow, or if disaster recovery
requirements dictate that certain types of data be available from a secondary location, it may make sense to design for the
replication of user data.
• This is especially true in an active-passive datacenter scenario, where the secondary datacenter will not be used
unless the primary datacenter becomes unavailable. This scenario will be discussed further in the next module on
disaster recovery.

• Active/active data access is currently not supported by Citrix or Microsoft. As a rule of thumb, never plan to
have multiple access points to the same data by the same user.
• In theory, it is possible to perform periodic data replication using Microsoft DFS-R and other storage
technologies in support of an active-active datacenter environment. However, when implementing such
strategies, consider:
• How often will replication occur?
• Which types of data should be replicated?
N
• How quickly will users roam between datacenters? If random assignment is used, users could switch
ot
datacenters in a matter of seconds, but if proximity is used as the determining factor, it may take hours or
fo
days. This will greatly impact the feasibility of a true active-active scenario.
• How will the organization ensure data is not lost when users roam? For example, a user may disconnect
rr
from an HDX session, roam to another location, and launch a new session from an alternate datacenter.
es
• Because the first session is still in a disconnected state, changes to the profile, for example, may not
al
have been written back to the profile store, and subsequently included in a replication to the alternate
datacenter.
e
or
di
s tri
but
io
n

Application Data Considerations
Determine if applications can operate
N
Identify where applications store data
in a distributed environment
ot
fo
• Backend databases • SQL replication / SQL mirror
rr
• Fileservers • DFS-R
es
• Webservers • Application compatibility scripting
al
• User profile • Double-hop design
e
or
• Redirected folders
di
• Windows temp
s tri
but
io
n
Key Notes:
• A key component of any virtualization project is the integration of the applications that will be accessed through the Citrix
Virtual Apps and Desktops environment. One consideration that becomes very important when designing a multi-location
environment concerns how the applications use data.
• The location where an application stores data will greatly impact whether that data can be accessible and provide a good
experience from multiple locations. Thus, if it is clear that the business requires multiple locations, the data storage
location for the applications must be identified.

• Based on the location of the data, strategies for operating within a distributed environment will differ.
• For example, applications using backend SQL databases can use SQL replication and high availability
technologies to make the data available in multiple locations.
• Data stored in file servers, user profiles, or redirected folders can be replicated using DFS-R.
• Data stored in local Windows temporary folders may not be able to be replicated easily. In some cases,
application compatibility scripting may be necessary to redirect the app data to another location that can
be replicated.
N
• For security reasons, application data may be stored in a siloed part of the network (for example
ot
individuals’ health or financial data). In these situations, a double-hop design may be necessary to meet
fo
the security requirements for the organization.
• Regardless of the method used, ensure that the application can handle a distributed environment before
rr
proceeding. Some applications may not support multiple copies of the data, or the data being modified from
es
multiple locations simultaneously.
al
• As a rule of thumb, always try to keep the applications and their data close to each other. Many applications
have not been designed to optimize backend data going over a WAN connection, for example. Instead, where
e
necessary, allow the HDX connection to do most of the “traveling” so that it can access the application
or
wherever it can perform the best.
di
s tri
b ut
io
n

Cloud-Based Storage Replication Options
Microsoft Azure
N
Read-access
Locally- Geo-zone-
ot
Replication Zone-redundant Geo-redundant geo-redundant
redundant redundant
strategy storage (ZRS) storage (GRS) storage (RA-
storage (LRS) storage (GZRS)
fo
GRS)
rr
Data is replicated
es
across multiple No Yes Yes Yes Yes
datacenters.
al
Data can be read from
e
a secondary location
No No No No Yes
or
as well as the primary
location.
di
Number of copies of
s
data maintained on 3 3 6 3 6
tri
separate nodes.
b ut
io
n
Key Notes:
• The data in a Microsoft Azure storage account is always replicated to ensure durability and high availability. Replication
copies data, either within the same datacenter, or to a second datacenter, depending on which replication option is
chosen. Replication protects data and preserves application up-times in the event of transient hardware failures. If the
data is replicated to a second datacenter, it's protected from a catastrophic failure in the primary location.
• Replication options:
• Locally redundant storage (LRS)

• This storage type is designed to increase the durability of the assigned data by replicating it within a
storage scale unit, which is hosted in a datacenter in the region in which the storage account was
created. A storage scale unit is a collection of racks of storage nodes.
• LRS is the lowest cost option, but offers the least durability compared to other options. In the event of
a datacenter level disaster (fire, flooding etc.) all replicas might be lost or unrecoverable.
• Benefits of LRS
• Highest maximum bandwidth of all replication options.
N
• Appropriate for data that can easily be reconstructed.
ot
• Appropriate for data that can only be replicated within a country due to data governance
fo
requirements.
• Zone-redundant storage (ZRS)
rr
• This storage type is designed to increase the durability of assigned data by replicating data
es
asynchronously across datacenters within one or two regions, thus providing a higher durability than
al
LRS. Data stored in ZRS is durable even if the primary datacenter is unavailable or unrecoverable.
• Considerations for ZRS:
e
• ZRS is only available for block blobs in general-purpose storage accounts, and is supported only
or
in storage service versions 2014-02-14 and later.
di
• Due to the nature of asynchronous replication, it is possible for data loss to occur if changes to
the data have not be replicated to the secondary location when the primary datacenter goes
s tri
offline.
b
• There will be a delay in access to the replica data while Microsoft initiates a failover to the
ut
secondary location.
io
• ZRS accounts cannot be converted to LRS or GRS accounts (and vice-versa).
• No metrics or logging capability.
n
• Geo-redundant storage (GRS):
• This storage type is designed to increase the durability of assigned data by replicating data to a
secondary region that is hundreds of miles away from the primary region. If a storage account has
GRS enabled, then data is durable even in the case of a complete regional outage or a disaster in
which the primary region is not recoverable. For a storage account with GRS enabled, an update is

first committed to the primary region. Then the update is replicated asynchronously to the secondary
region, where it is also replicated.
• Considerations for GRS:
• Due to the nature of asynchronous replication, it is possible for data loss to occur if changes to
the data have not be replicated to the secondary region in the event of a regional disaster.
• There will be a delay in access to the replica data while Microsoft initiates a failover to the
secondary region.
N
• If an application wants to read from the secondary region, the user should enable RA-GRS.
ot
• When a storage account is created, the primary region is selected for the account. The
fo
secondary region is determined based on the primary region, and cannot be changed.
• See the Additional Resource link for a chart showing the primary and secondary region pairings.
rr
• Geo-zone-redundant storage (GZRS):
es
• This storage copies the data synchronously across three Azure availability zones in the primary
al
region using ZRS. Then it copies the data asynchronously to a single physical location in the
secondary region.
e
• Read-access geo-redundant storage (RA-GRS)
or
• Read-access geo-redundant storage (RA-GRS) maximizes availability for a storage account, by
di
providing read-only access to the data in the secondary location, in addition to the replication across
two regions provided by GRS.
s tri
• Considerations
b
• RA-GRS has the same considerations as GRS, plus a few additional ones.
ut
• The application has to manage which endpoint it is interacting with when using RA-GRS.
io
• RA-GRS is intended for high-availability purposes. For scalability guidance, please review the
Azure Storage Performance and Scalability Checklist (link available in Additional Resources).
n
• Azure Storage replication: https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy
• Microsoft Azure Storage Performance and Scalability Checklist: https://docs.microsoft.com/en-
us/azure/storage/common/storage-performance-checklist

Cloud-Based Storage Replication Options
Amazon Web Services
N
AWS Amazon Elastic Block Store (EBS) EBS Data Availability
ot
fo
• Durable, block-level storage device • Availability Zone – (zone redundant storage)
rr
• Can be attached to a single Amazon Elastic • Multi Availability Zone
es
Compute Cloud (Amazon EC2) • Snapshots
al
• Distributed Replicated Block Device / Multiversion
e
Asynchronous Replicated Storage
or
• Application-level replication
di
• 3rd Party Cross-region replication service
s tri
b ut
io
n
Key Notes:
• When you create an EBS volume in an Availability Zone, it is automatically replicated within that zone to prevent data loss
due to failure of any single hardware component. After you create a volume, you can attach it to any EC2 instance in the
same Availability Zone.
• After you attach a volume, it appears as a native block device similar to a hard drive or other physical device. At that point,
the instance can interact with the volume just as it would with a local drive. The instance can format the EBS volume with
a file system, such as ext3, and then install applications.

• An EBS volume can be attached to only one instance at a time within the same Availability Zone. However,
multiple volumes can be attached to a single instance.
• If you attach multiple volumes to a device that you have named, you can stripe data across the volumes for
increased I/O and throughput performance.
• Amazon EBS Volumes: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumes.html
N
• Regions and Zones: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-
ot
zones.html
fo
rr
es
al
e
or
di
s tri
but
io
n

N
ot
What should you investigate before starting any
fo
active/active Citrix Virtual Apps and Desktops
design?
rr
es
You should investigate if the backend applications and
databases will support a multi-site configuration and
al
whether your WAN links can support any replication
e
needed.
or
di
s
tri
utb
io
n

N
ot
Printing
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Identify the appropriate strategy to support printing
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Identify the appropriate strategy to support printing in a multi-location solution.

Multi-Location
Headquarters
Printing
Considerations
Desktop
Printer
N
ot
Printer Print Server VDA Printer
fo
rr
Home Office Branch Office
es
al
e
or
Desktop
Desktop Print Server
• Endpoint attached printers
di
• Endpoint mapped printers
• VDA mapped printers
s tri
• VDA attached printers
b
Printer
Printer Printer
ut
io
n
Key Notes:
• Even in a single-site environment, printers from home offices and branch offices must often be integrated, so the
considerations in a multi-site environment do not change much. One must still consider the location of the print servers or
printers, the endpoint location, and the optimal way to route the print jobs.
• A few key points to consider:
• Route print jobs through the HDX channel to get compression and quality of service (QoS) inside the session.
• Use multi-port HDX and QoS on routers for controlling multiple HDX sessions on the same WAN link.

• Citrix SD-WAN or other WAN optimization devices can be used when network printing is required across
WAN links.
apps-desktops/1912-ltsr/printing.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Multi-Location Headquarters
Printing Example
Desktop
N
ot
Printer Citrix Universal
VDA
Print Server
fo
rr
Branch Office Regional Office
es
al
e
Desktop Desktop
or
Citrix Universal
Print Server Printer
• Endpoint attached printers
di
• Endpoint mapped printers
• VDA mapped printers
s tri
• VDA attached printers
Printer
b
VDA
ut
io
n
Key Notes:
• In this example, a print media company has a Citrix Virtual Apps and Desktops Site at headquarters, another Site at its
regional office, and another branch office which connects to the Headquarters Site.
• Headquarters leverages thin clients and Windows-based workstations. Network based printers are placed throughout
the building (one per floor). Windows print servers reside in the datacenter and manage the network printers.
• A Citrix Universal Print Server is used for printing within the Citrix Virtual Apps and Desktops session. Native print
drivers are not required on the Windows based workstations.

• A session printer policy is configured per floor which connects the floor printer as the default printer.
The policies are filtered based on the subnet of the thin client for proximity printing.
• Quality of Service (QoS) policies are implemented. Inbound and outbound network traffic on ports
TCP 1494 and TCP 2598 are prioritized over all other network traffic. This will prevent HDX user
sessions from being impacted by large print jobs.
• The regional office has numerous Windows, Linux and Mac endpoints with VDA mapped printers.
• A Universal Print Server is deployed within the regional office. The print job uses the Universal Print
N
Driver and is compressed and delivered from the user’s session to the Universal Print Server, across
ot
the WAN. The job is then sent to the network-attached printer in the office.
fo
• A remote branch office has a few Windows workstations with endpoint attached printers.
• Since all branch users work on Windows based workstations, auto-created client printers in
rr
conjunction with the Citrix Universal Printer Driver are used. Since the print job is delivered over the
es
HDX protocol, the print data is compressed, which saves bandwidth. The Citrix Universal Printer
al
Driver ensures all printers connected to the client can be used within the Citrix Virtual Apps and
Desktops session without concern of the printer model used.
e
or
di
• Tech Zone: Experience from the field: https://docs.citrix.com/en-us/tech-zone/design/design-
decisions/baseline-printing-design.html#experience-from-the-field
s tri
but
io
n

Printing from
the Cloud
• VDAs in public clouds are • Deploy print servers in corporate offices – not in public cloud.
N
far away from printers, so
• Large network print jobs may impact user experience.
ot
focus on the design.
• Treat all corporate offices • Consider HDX routed print over network print.
fo
like branch offices.
rr
• Ensure sufficient bandwidth to public cloud.
es
al
e
or
di
stri
but
io
n


Desktops environment for a company that has a
large number of satellite offices. Each office has 10
to 20 users and typically connect to the main office
N
via a 2 Mbps WAN link. Each satellite office has
ot
their own print server and AD controller.
fo
How would you recommend to route the print job
to the satellite offices?
rr
es
• Consider routing the printers via the HDX protocol.
al
• Use multiport HDX if the network equipment supports
e
QoS.
or
• Use HDX bandwidth policies as an alternative to
multiport HDX.
di
s
tri
b
ut
io
n

N
ot
Control Layer
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine how to design a Site with zones to
N
ensure users have continuous access to resources
ot
• Assess Active Directory considerations across multi-
fo
location environments.
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine how to design a Site with zones to ensure users have continuous access to resources in a multi-location
solution.
• Assess Active Directory considerations across multi-location environments.

Zone Considerations
• Citrix Cloud - Each resource location functions as a zone. Each zone is treated equally and must have one or
more Cloud Connectors to communicate with the Delivery Controllers which only exist within the Citrix Cloud.
• On-Prem - Contains Primary and Satellite zone(s). The Primary zone contains the Site database, Studio,
Director, Citrix StoreFront, Citrix License Server, and Citrix Gateway. The Satellite zone(s) contain one or more
N
VDAs, Controllers, StoreFront servers, and Citrix Gateway servers.
ot
fo
rr
On-Prem Zone Citrix Cloud Zone
es
Primary Zone
Resource Location
al
Delivery Controller License Server A (Zone) Delivery Controller
Cloud Connector
e
or
di
Satellite Zone Satellite Zone
Resource Location
s
(Optional) B (Zone)
tri
Delivery Controller
VDA VDA Cloud Connector
Delivery Controller Delivery Controller
b ut
io
n
Key Notes:
• Although zones are becoming more widely used as the feature has matured, some organizations do choose to stay with
multiple individual Citrix Virtual Apps and Desktops Sites instead of a single-site, multi-zone architecture.
• For example, health care organizations who utilize Epic Hyperspace as their electronic health record (EHR) system
are recommended to use multiple Sites.
• This is mainly to reduce the failure domain of the environment, maintain uptime during Citrix Virtual Apps and
Desktops version upgrades, and faster failovers in the event of an outage at one of the datacenters.

• Ultimately, this is a business decision weighing risk against cost. However, healthcare organizations (and
others) that prioritize the availability and security of patient data typically take an approach that will
minimize risk, even if costs or administrative effort is higher.
• With Citrix Cloud zones:
• Citrix Cloud treats zones different than on-premises environments. Each resource location (e.g. location
hosting Virtual Delivery Agent machines) is treated as a zone.
• Instead of primary and satellite zones, each zone is treated equally, and must have one or more Cloud
N
Connectors to communicate with the Citrix Cloud-hosted Delivery Controllers.
ot
• Cloud Connectors has higher latency tolerance than Delivery Controllers.
fo
• With On-Prem zones:
• A Site can have satellite zones of different configurations, based on your unique needs and environment.
rr
• Primary zone should have at least two Controllers.
es
• A satellite zone does not require having controllers however it is recommended.
al
• VDAs in a satellite zone can register with DDCs in primary zone.
• Zones in a single Site should be limited to 50.
e
• Latency and SQL Blocking Query improvements
or
• If latency is higher than 250 ms RTT, deploy a new Site instead of a zone.
di
s tri
• Brokering with latency improvements: https://docs.citrix.com/en-
b
us/categories/solution_content/implementation_guides/xenapp-and-xendesktop-latency-and-sql-blocking-
ut
query-improvements.html
io
• XenApp 7.15 LTSR – Now Target Platform for Epic Hyperspace (discussion on why some organizations
choose to use multiple individual XenApp and XenDesktop Sites instead of zones):
n
https://www.citrix.com/blogs/2017/12/21/xenapp-7-15-ltsr-now-target-platform-for-epic-hyperspace/
• Zones: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/manage-deployment/zones.html

Active Directory -
Multiple Domains/Forests
Supported in
Trust type Transitivity Direction
this release
Parent and
Transitive Two-way Yes
• Citrix Virtual Apps and Desktops supports trust child
N
deployments:
ot
Tree-root Transitive Two-way Yes
• With user and computer accounts in domains in a
single Active Directory forest.
fo
One-way or
External Nontransitive Yes
rr
• With user accounts in an Active Directory forest two-way
different from the AD forest containing the controllers
es
One-way or
and virtual desktops computer accounts. Forest Transitive Yes
two-way
al
• Where the computer accounts for Controllers exist in
One-way or
e
an Active Directory forest different from one or more Shortcut Transitive Yes
two-way
additional AD forests containing the computer
or
accounts of the virtual desktops. Transitive or One-way or
Realm No
di
nontransitive two-way
s
tri
b ut
io
n
Key Notes:
• Citrix Virtual Apps and Desktops supports:
• Deployments in which the user accounts and computer accounts exist in domains in a single Active Directory forest.
• Deployments in which user accounts exist in an Active Directory forest that is different from the Active Directory
forest containing the computer accounts of the controllers and virtual desktops.
• Deployments in which the computer accounts for Controllers exist in an Active Directory forest that is different from
one or more additional Active Directory forests that contain the computer accounts of the virtual desktops.

• Writable domain controllers. Read-only domain controllers are not supported.
• The “SupportMultipleForest” key is necessary if the VDA and Controller are in separate forests. The
SupportMultipleForest key is only necessary on the VDA
• DNS:
• In an Active Directory environment with multiple forests, if one-way or two-way trusts are in place, you
can use DNS forwarders for name lookup and registration.
• Use DNS forwarders for name lookup and registration.
N
• Reverse DNS zones are not necessary if forwarders are in place.
ot
• Reverse DNS necessary if your DNS namespace is different than that of Active Directory.
fo
• External trusts:
• ListOfSIDs registry key.
rr
• Edit brokeragentconfig.exe.config to allowNtlm="true“.
es
al
• Active Directory: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/1912-ltsr/technical-overview/active-
e
directory.html
or
di
s tri
b ut
io
n

Public Cloud Considerations - Azure Active Directory
• Azure Active Directory Domain Services required for integration with Citrix
N
Virtual Apps and Desktops and/or Citrix Cloud.
ot
• Azure AD DS can synchronize with Azure AD or on-premises AD.
fo
• Azure AD is only identity and authentication, missing group policy and
rr
Kerberos/LDAP to fully support Citrix Virtual Apps and Desktops.
es
al
e
or
MS Azure
di
s tri
but
io
n
Key Notes:
• When using Azure as a Resource Location, Azure Active Directory also has a role to play:
• Azure Active Directory must always be configured as the holder of an application service account for the Citrix
service. This account is used by Citrix Cloud or Studio to perform machine lifecycle events within the Azure Tenant.
• Azure Active Directory can be used as a more general repository of accounts for administrators and users.
Depending on the configuration and type of service, using Azure Active Directory for this role may be optional.
• Deployment options include:

• In Cloud only:
• One Azure Active Directory
• More than one Azure Active Directory
• Domain Controller synced with Active Directory user accounts
• Hybrid:
• One Azure Active Directory
• More than one Azure Active Directory
N
• Amazon Web Services (AWS) currently offers the Amazon Directory Service, but this is not currently
ot
supported for cloud or on-premises Citrix Virtual Apps and Desktops deployments. To integrate an AWS
fo
resource location, the access keys for the associated AWS account would be used (API key and secret key
values).
rr
es
al
• Azure Active Directory and Citrix XenApp and XenDesktop:
https://support.citrix.com/article/CTX224111#InCloudUserAccounts
e
• XenApp & XenDesktop Services Support Azure AD Domain Services:
or
https://www.citrix.com/blogs/2017/04/11/xenapp-xendesktop-services-support-azure-ad-domain-services/
di
• Amazon Web Services virtualization environments: https://docs.citrix.com/en-us/xenapp-and-
s
xendesktop/service/install-configure/resource-location/aws-host.html
tri
b ut
io
n

N
ot
If you have two datacenters with more than 250 ms
fo
latency between them, should you deploy a zone
or a new Site in the secondary datacenter?
rr
es
The best option would be a secondary Site.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• At this point in time Citrix recommends deploying a new Citrix Virtual Apps and Desktops Site because we have not
validated brokering and registration performance above 250 ms.

Exercise 8-1: Configure Multi-
Datacenter High Availability
Key project stakeholders have secured additional
N
funding for multi-datacenter high availability. You have
ot
been asked to configure and test multi-datacenter
high availability in the Design Verification lab.
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Exercise 8-1 User Layer New York
PVS
StoreFront Delivery Controller Server VDA

Active Directory Server PVS Server
NYC-STF-001 NYC-XDC-001 NYC-SRV-MAN-001
NYC-ADS-001 NYC-PVS-001
192.168.10.31 192.168.10.46 DHCP
192.168.10.11 192.168.10.51
• Connect to lab through HDX
N
connection over port 443.
ot
Citrix Gateway Database Server File Server Server VDA
NYC-VNS-001 NYC-SRV-001
• Do not launch lab before you 192.168.10.100
NYC-SQL-001
192.168.10.21
NYC-FSR-001
192.168.10.17 DHCP
need it.
fo
rr
• Labs are per module and User Endpoint
NYC-WRK-001 San Francisco
DHCP
decommission after the
es
allotted time expires.
al
PVS
• Labs cannot be launched
e
Delivery Controller PVS Server Server VDA
multiple times. Citrix Gateway
or
SFO-VNS-001 SFO-XDC-001 SFO-PVS-001 SFO-SRV-MAN-001
192.168.11.100 192.168.11.46 192.168.11.51 DHCP
di
s
Database Server File Server Server VDA
StoreFront
tri
SFO-SQL-001 SFO-FSR-001 SFO-SRV-001
SFO-STF-001
192.168.11.21 192.168.11.17 DHCP
192.168.11.31
b ut
io
n

Exercise 8-1
[70 minutes]
Task:
N
• Configure multi-datacenter high availability in the
ot
Design Verification lab:
• Configure DFSR for vDisk Store and user profiles.
fo
• Setup GSLB
rr
es
al
e
or
di
s
tri
b
ut
io
n

Key Takeaways
• High availability typically involves more layers of
N
redundancy and fault tolerance.
ot
• GSLB allows users to connect to multiple
datacenter through the same access URL.
fo
rr
• Citrix Provisioning supports multiple Sites in one
Farm but Citrix recommends to deploy separate
es
Farms in geographically disbursed datacenters.
al
• A user profile cannot be active in two datacenters at
e
the same time.
or
di
s tri
but
io
n
Key Notes:
• High availability typically involves more layers of redundancy and fault tolerance.
• GSLB allows users to connect to multiple datacenter through the same access URL.
• Citrix Provisioning supports multiple Sites in one Farm but Citrix recommends to deploy separate Farms in
geographically disbursed datacenters.
• A user profile cannot be active in two datacenters at the same time.

Key Takeaways
• A print design should allow users enough bandwidth
N
to work while others are printing.
ot
• Citrix Cloud and on-premises environments treat
zones differently; with Citrix Cloud each resource
fo
location is treated as an equal zone, compared to
rr
an on-premises that utilizes hierarchy of primary
es
and satellite zones.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• A print design should allow users enough bandwidth to work while others are printing.
• Citrix Cloud and on-premises environments treat zones differently; with Citrix Cloud each resource location is treated as
an equal zone, compared to an on-premises that utilizes hierarchy of primary and satellite zones.

Assessment, Design, and
N
ot
Disaster Recovery
fo
rr
es
al
e
Module 9
or
di
s tri
but
io
n
Key Notes:
• Welcome to the Disaster Recovery module. This is the ninth module in the Citrix Virtual Apps and Desktops 7
• Throughout this module, we will discuss the seven levels of disaster recovery and the differences between them; discuss
the various strategies for disaster recovery, and review the Business Continuity Planning process.

Learning Objectives
• Explain the seven levels of disaster recovery.
N
• Determine the strategy for disaster recovery, for
ot
both active/passive and active/active scenarios
fo
• Identify the process of creating a disaster recovery
rr
plan.
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Explain the seven levels of disaster recovery.
• Determine the strategy for disaster recovery, for both active/passive and active/active scenarios
• Identify the process of creating a disaster recovery plan.

N
ot
Disaster Recovery Levels
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Describe different levels of service availability that
N
can be achieved during a disaster recovery
ot
situation.
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Describe different levels of service availability that can be achieved during a disaster recovery situation.

Seven Tiers of Disaster Recovery
N
Tier 7
ot
Tier 6 • Highly
automated,
fo
• Zero or near- business
Tier 5 integrated
rr
zero data loss
• Transaction solution
Tier 4
es
integrity
Tier 3 • Point-in-time
copies
al
Tier 2 • Electronic
e
vaulting
Tier 1 • Data backup
or
with a hot site
Tier 0 • Data backup
with no hot
di
• No off-site site
data –
s
Possibly no
tri
recovery
b ut
io
n
Key Notes:
• Tier classifications for DR are an important aspect of an organizations DR strategy as it provides clarity into application or
service criticality which in turn dictates the RTO (Recovery Time Objective) (and thus costs for accomplishing that level of
recovery). Generally, the shorter the RTO, the higher the DR solution cost. Being able to break down various inter-
dependencies into different classifications (based on business criticality and RTO) can help optimize cost-sensitive DR
cases.
• Tier classification is important for Citrix in order to help decide how critical the Citrix infrastructure is to business

operations and identify the use cases or core business applications which Citrix hosts.
• When establishing a DR design for Citrix, bringing the discussion beyond the scope of Citrix itself is useful to
set expectations to business units.
• These tiers describe different levels of service availability that can be achieved with regards to disaster
recovery.
N
• Seven Tiers of Disaster Recovery: https://en.wikipedia.org/wiki/Seven_tiers_of_disaster_recovery
ot
• Disaster Recovery Tier Classifications: https://docs.citrix.com/en-us/tech-zone/design/design-decisions/cvad-
fo
disaster-recovery.html#disaster-recovery-tier-classifications
rr
es
al
e
or
di
s tri
but
io
n

Tier 0
Tier Zero
0: No Disaster Recovery File Server License Server
N
ot
fo
StoreFront Site Database
rr
Apps and
es
Data Storage
Citrix Gateway Delivery Controller
al
e
or
VDA VDI
di
s tri
b ut
io
n
Key Notes:
• Businesses with a Tier 0 business continuity solution have no business continuity plan. There is no saved information, no
documentation, no backup hardware, and no contingency plan.
• The time necessary to recover in this instance is unpredictable. In fact, it may not be possible to recover at all.

Tiers 1-3 Tier One
Active-Passive
Apps and
VDA File Server License Server Data Storage
VDI StoreFront Site Database Citrix Gateway Delivery Controller

1: Data backup with no hot site
N
Tier Two
2: Data backup with a hot site
ot
3: Electronic vaulting
fo
Apps and
Data
rr
VDA File Server License Server Storage
Manual
es
Restore
al
Tier Three
e
or
Apps
di
VDA File Server License Server and Data Storage
WAN
s tri
Backup
VDI StoreFront Site Database Citrix Gateway Delivery Controller Vault
b ut
io
n
Key Notes:
• Businesses that use Tier 1 continuity solutions back up their data and send these backups to an off-site storage facility.
The method of transporting these backups is often referred to as "PTAM" - the "Pick-up Truck Access Method."
• Depending on how often backups are created and shipped, these organizations must be prepared to accept several
days to weeks of data loss, but their backups are secure off-site. However, this tier lacks the systems on which to
restore data.
• Businesses using Tier 2 business continuity solutions make regular backups on tape. This is combined with an off-site

facility and infrastructure (known as a hot site) in which to restore systems from those tapes in the event of a
disaster.
• This solution will still result in the need to recreate several hours or even days' worth of data, but the
recovery time is more predictable.
• Tier 3 solutions build on the components of Tier 2. Additionally, some mission critical data is electronically
vaulted. This electronically vaulted data is typically more current than that which is shipped via PTAM.
• As a result there is less data recreation or loss after a disaster occurs. The facilities for providing
N
Electronic Remote Vaulting consists of high-speed communication circuits, some form of channel
ot
extension equipment and either physical or a virtual tape library and an automated tape library at the
fo
remote site. IBM's Peer-to-Peer VTS and Oracle StorageTek Virtual Storage Manager (VSM) Clustering
are two examples of this type implementation.
rr
• In a Citrix Virtual Apps and Desktops environment, Tiers 1-3 are represented by a single datacenter, single
es
Site environment with various levels of data backup and restore functionality. At Tier 3, a standby DR Site may
al
also be in place.
e
or
di
s tri
but
io
n

Tiers 4-6 Tier Four
Traditional Active-Passive
Apps and
VDA File Server License Server Data Storage
Snapshots
Storage
4: Point-in-time copies
N
Tier Five
5: Transaction integrity
ot
6: Zero or near-zero data loss
fo
Apps and 1010101
Data Data
rr
VDA File Server License Server Storage
Replication
Apps and
es
Data
al
Tier Six
e
or
Apps
di
VDA File Server License Server and Data Mirroring, Apps Storage
Storage
Clustering and
s
Data
tri
b ut
io
n
Key Notes:
• Tier 4 solutions are used by businesses that require both greater data currency and faster recovery than users of lower
tiers. Rather than relying largely on shipping tape, as is common on the lower tiers, Tier 4 solutions begin to incorporate
more disk-based solutions. Several hours of data loss is still possible, but it is easier to make such point-in-time (PiT)
copies with greater frequency than tape backups even when electronically vaulted.
• Tier 5 solutions are used by businesses with a requirement for consistency of data between the production data center
and the recovery data centers. There is little to no data loss in such solutions; however, the presence of this functionality is

entirely dependent on the application in use.
• Tier 6 business continuity solutions maintain the highest levels of data currency. They are used by businesses
with little or no tolerance for data loss and who need to restore data to applications rapidly. These solutions
have no dependence on the applications or applications staffs to provide data consistency.
• Tier 6 solutions often require some form of Disk mirroring. There are various synchronous and
asynchronous solutions available from the mainframe storage vendors. Each solution is somewhat
different, offering different capabilities and providing different Recovery Point and Recovery Time
N
objectives.
ot
• Often some form of automated tape solution is also required. However, this can vary somewhat
fo
depending on the amount and type of data residing on tape.
• In a Citrix Virtual Apps and Desktops environment, these Tiers require a secondary DR Site to be in place. The
rr
speed and ease of a failover to the DR Site would depend on how much and how current the data replication
es
is between Sites.
al
e
or
di
s tri
but
io
n

Tier 7
Active-Active with highly
automated failover
Tier Seven
File Server License Server License Server File Server

7: Highly automated, business
N
integrated solution.
ot
Apps Apps
and Data and Data Site Database
StoreFront Site Database StoreFront
fo
rr
es
Citrix Gateway Delivery Delivery Citrix Gateway
al
Storage Storage
e
or
VDA VDI VDI VDA
GSLB GSLB
di
s tri
b ut
io
n
Key Notes:
• Recovery of the applications is automated, allowing for restoration of systems and applications much faster and more
reliably than would be possible through manual business continuity procedures.
• Use great caution when designing an automated failover solution, it is always recommended to have a human interaction
involved in the failover to avoid false positives.

N
ot
Which tier would you typically chose when
fo
designing a disaster recovery site for a customers
Citrix Virtual Apps and Desktops site?
rr
es
You would typically choose tier 5 or 6, depending on
the applications and data that need to be synchronized
al
and the bandwidth available between the sites.
e
or
di
s
tri
utb
io
n

N
ot
Disaster Recovery - Strategy
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

• Determine the appropriate Disaster Recovery
N
Strategy for a given environment.
ot
fo
rr
es
al
e
or
di
s tri
but
io
n
Key Notes:
• Determine the appropriate Disaster Recovery Strategy for a given environment.

Disaster Recovery
Considerations
Determining Level Required
• Which components must be recoverable?
N
• How much capacity is required in DR site?
ot
• Which applications should be available?
fo
• Does applications support disaster recovery?
rr
• What are the application recovery procedures?
es
• How long will a failover take?
al
e
• Can the failover be automated?
or
di
s tri
b ut
io
n
Key Notes:
• These questions are examples of typical assessment questions that can be used to determine the Disaster Recover
considerations for a deployment design.
• These questions are dependent on key design plans already in place.
• For example: Which components must be recoverable?
• To answer this, we must have already defined in the design the type and quantity of each component, defined by
layers and attributes. Moving forward, we then address, in the even of a failure, which components are identified

as mission critical and must be recovered or are all components critical to the design.
• Dig into GSLB DNS problems with Citrix ADC: https://www.citrix.com/blogs/2019/05/31/dig-into-gslb-dns-
problems-with-citrix-adc-no-shovel-required/
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Disaster Recovery
Considerations Datacenter 1 Datacenter 2
Full Disaster Recovery

Capacity Example User User User User User User User User
N
ot
VDI VDI VDI VDI VDI VDI VDI VDI
fo
ll ll ll ll ll ll ll ll
rr
VDI VDI VDI VDI VDI VDI VDI VDI
es
ll ll
al
e
ll ll
SAN SAN SAN SAN
or
Hypervisor Hypervisor Hypervisor Hypervisor
di
Key
s tri
= Datacenter 1 User resources = Datacenter 2 User resources ll = Standby resources
b ut
io
n
Key Notes:
• One of the foremost considerations when creating a disaster recovery plan is to identify how much capacity is needed for
disaster operations and whether this capacity can be used for other purposes during normal operations.
• The graphic depicts a full-blown disaster recovery scenario where we double the capacity in each datacenter to allow for
all users to be hosted out of one datacenter. This is a costly way of configuring DR.
• In this example, instead of deploying a large number of unused Single-Session OS VDAs to support full failover, smaller,
resource-constrained customers could choose to deploy less resource intensive Multi-Session OS VDA-based desktops or

limit the capacity to support only select business critical user groups, apps and data.
Citrix Virtual Apps and Desktops – Disaster Recovery Planning: https://docs.citrix.com/en-us/tech-
zone/design/design-decisions/cvad-disaster-recovery.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Disaster Recovery
Considerations
Access During a DR Event
• Same URL vs. separate URL
N
• Automatic failover vs manual failover
ot
• Single Site vs Multi-Site
fo
• Zone preference and failover vs StoreFront Multi-Site aggregation
rr
• StoreFront subscription sync
es
al
e
or
di
s tri
b
ut
io
n
Key Notes:
• When considering a disaster recovery plan, access for users must be determined in the even of an outage/ failover.
• Same URL vs. separate URL
• Consider if there is at least one StoreFront server in each location, how many stores were built for the same set of
users?
• Are users connecting in normal parameters to one Store and in an outage to another store?
• Automatic failover vs manual failover

• Are Citrix Gateway’s deployed with and Active GSLB configuration, or is it HA.
• What about non-Citrix components that Citrix Virtual Apps and Desktop relies on, such as File Storage:
Are the user profiles stored in each location, and is the synchronization manual or automatic?
• Single Site vs Multi-Site
• Is each location managed independently through separate Citrix Virtual Apps and Desktops Sites? This
will require more effort upfront in configuration, but could closely mimic the Pod Architecture presented
earlier in the course, where if a Site or Site component goes down, another Site is still available.
N
• Are Zones in use?
ot
• Is it a Single Site, where now we have to ensure redundancy for the components?
fo
• Zone preference and failover vs StoreFront Multi-Site aggregation
• If Zones are in use, are there any User Home or Application Home settings that could interfere with a
rr
datacenter failover?
es
• Is Citrix Gateway an option to aggregate StoreFront Access?
al
• StoreFront subscription sync
• Is StoreFront in more than one location in the deployment?
e
• Citrix leading practice in multi-StoreFront deployments is to join a server group; but across a WAN, what
or
is the impact to store synchronization and can the bandwidth handle it?
di
s tri
b ut
io
n

Disaster Recovery
Considerations
Data and Apps
• Data loss acceptance vs cost
N
• Importance of applications and data
ot
• Application and backend database failover
fo
• User profile failover vs new profile
rr
• Home drive and redirected folders
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• If you plan to implement an active/active datacenter, focus on the user data first before making any further plans. If you
cannot find a satisfying answer for this problem, a truly and purely active/active implementation is probably not the right
solution for you.
• An Active/active design is relatively simple as long as users do not have any personalization requirements, do not need to
retain application settings, and do not need to create documents or other persistent data.
• In practice, most use cases will require at least some of these items. However, active/active replication for profile

data is not supported by Microsoft (specifically, with their DFS-R solution) or Citrix (regarding Citrix
Profile Management when using DFS for replication).
• Any supported scenarios assume that you’re using only one-way profile replication and that only one
copy of the profile will ever be active at any point in time. In order to support active/active replication, you
would need to have distributed file locking, which is not available with DFS-R.
• As a rule of a thumb – never plan to have multiple access points to the same data by the same user.
N
ot
• Multiple folder targets and replication (with Citrix Profile Management): https://docs.citrix.com/en-us/profile-
fo
management/current-release/plan/high-availability-disaster-recovery-scenario-2.html
• Disaster recovery (for Citrix Profile Management): https://docs.citrix.com/en-us/profile-management/current-
rr
release/plan/high-availability-disaster-recovery-scenario-3.html
es
• Dig into GSLB DNS problems with Citrix ADC: https://www.citrix.com/blogs/2019/05/31/dig-into-gslb-dns-
al
problems-with-citrix-adc-no-shovel-required/
e
or
di
s tri
b ut
io
n

Disaster Recovery
Considerations
Citrix Cloud-Based DR
• Citrix Cloud supports multiple resource locations / zones.
N
• Deploy resources in on-premises datacenters or public cloud.
ot
• Zone preference, StoreFront optimal gateway & GSLB to connect users.
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Remember, for Citrix Cloud customers, the Control Layer is redundant and hosted in Citrix Cloud.
• This includes the Delivery Controller(s), the Site database, the Studio management console and optionally other
services, such as Citrix Gateway or StoreFront.
• The Disaster Recovery plan for customers subscribed to apps and/or desktops in Citrix Cloud only includes the
components not within Citrix Cloud, such as the Single-Session OS or Multi-Session OS machines running the VDA
hosting sessions, and the possible Citrix Gateway/Citrix Gateway or StoreFront servers.

Public Cloud DR
Options
ll
• Public Cloud platforms offer
an ease of transition to Cloud File Server License Server License Server File Server
based solutions, because:
N
• You only pay for what you ll
ot
Apps and Apps and
consume. Data Data
StoreFront Site Database Site Database StoreFront
fo
• Accessible from anywhere
and at any time.
rr
ll ll
• You can stand up a near-dark
es
DR online. Citrix Gateway Delivery Controller Delivery Controller Citrix Gateway
al
• Public Cloud DR Options
e
include: Storage
ll ll
or
• Active / Passive VDA VDI VDA
VDI
di
• Active / Active Citrix Gateway Citrix Gateway
GSLB GSLB
s tri
b ut
io
n
Key Notes:
• Public cloud disaster recovery entails storing critical data and applications in a cloud storage location, and then failing over
to a secondary site in case of a disaster.
• Public clouds platforms for recovery include, AWS, Azure or Google Cloud Platform.
• Disaster recovery of resources can be restored from the cloud back to their original locations; regardless if they are
located on-premises or the within the cloud.
• Cloud disaster recovery is primarily an infrastructure as a service (IaaS) type of solution

• Provides updated recovery point objective (RPO), as well as recovery time objective (RTO) in case of
a disaster or system restore. (AKA) cloud DR or cloud DRP.
• Considerations:
• All businesses must consider the physical distance and latency challenges that are present, with
whatever cloud DR provider they choose to use. If the DR is too close to the business geographic
location, then there is a risk of shared physical disaster,
• At the same time, if the DR is too far away, it can increase the risk of latency and network congestion;
N
thus making it more difficult to access DR content.
ot
• It is also possible to reserve resources from public cloud, thus making it cheaper to run them. This should
fo
be considered if you need to run any machines all around the clock.
rr
es
al
e
or
di
s tri
b ut
io
n

If you design an active/passive Citrix Virtual Apps
N
and Desktops implementation that is capable of
ot
serving all users with a normal user experience in
fo
the event of disaster, what typically happens to the
cost of the deployment?
rr
es
The cost typically doubles for the Citrix Virtual Apps
and Desktops implementation.
al
e
or
di
s
tri
b
ut
io
n

N
ot
Disaster Recovery - Process
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

 Create and test a business continuity plan in the
N
event a disaster recovery occurs.
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n
Key Notes:
• Create and test a business continuity plan in the event a disaster recovery occurs.

Business Continuity Planning
Failing Over to a DR Environment
N
ot
fo
Block Access Terminate Enable
rr
Go / No-Go Complete Revert
to Primary Existing Access in DR
Decision Replication Replication
es
Environment Sessions Datacenter
al
e
or
di
s
tri
b ut
io
n
Key Notes:
• Business Continuity Planning is a critical part in the design process. Life events are unpredictable and in a time of
uncertainty, it is important for a business to be able to overcome any potential threats and continue business as usual.
• When failing over to a DR environment, the time required for each of these steps can differ. For example you might decide
to force termination of existing sessions, but you’re risking that users will lose their data. Or you might decide for a more
gentle approach, notify users to finish their work and let them finish their sessions.
• There are few associated decisions – for example do you want to block access for all users, or do you plan to drain

existing users?
• Once the datacenter doesn’t have any active connections and user data is either properly replicated or you’ve
decided to cut them off, it’s possible to proceed with the second part of the failover, activating access to the
backup datacenter.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Business Continuity
Planning
Disaster Recovery User

Onboarding Strategy
• How many users and apps should be migrated?
N
• How will users be notified about DR availability/limitations?
ot
Create a plan for onboarding/
fo
migrating users to the DR
rr
(Disaster Recovery) site. • Considerations:
• Prioritize business critical users and apps.
es
• Avoid boot/login storms.
al
• Monitor load on VDAs and backend servers.
e
• Load evaluators to ensure VDAs are not overloaded.
or
di
s tri
but
io
n
Key Notes:
• Most organizations have defined business continuity plans. The success of a business continuity plan is based on how
much it impacts the user experience, how well it scales to overcome global issues, and how well it maintains corporate
security policies.
• There are some key factors to identify when creating a plan for migrating users to a DR Site:
• How many users and apps should be migrated?
• How will users be notified about DR availability and any limitations they may have?

• It is important to prioritize business critical users and apps which will limit possible boot/login storms during the
failover.
• Monitor the load on the VDAs and backend servers to ensure resources are not maximized.
• Use load evaluators to ensure VDAs are not overloaded, degrading the user experience.
• Business Continuity: https://docs.citrix.com/en-us/tech-zone/learn/tech-briefs/business-continuity.html
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Business Continuity Planning
Returning to Normal Operations
N
ot
fo
Terminate
Determine Complete Resume Enable
Block Access Existing
rr
stability in Replication to Replication to Access in
to DR Sessions in
Primary Primary DR Primary
es
Datacenter DR
Datacenter Datacenter Datacenter Datacenter
Datacenter
al
e
or
di
stri
b ut
io
n
Key Notes:
• Just like failing over to the DR Site, the time required for each of these steps can differ in order to return to normal
operations.
• The same decisions will apply on how to migrate users back to the production environment:
• For example you might decide to force termination of existing sessions, but you’re risking that users will lose their
data. Or you might decide for a more gentle approach, notify users to finish their work and let them finish their
sessions.

Business Continuity
Testing
• Use a staging environment to test and verify failover procedures.
N
• Monitor the time to failover each application and data set.
ot
• Perform simulated outages as you add new applications and
fo
complexity to the environment.
rr
es
• Update business continuity plans with findings and timings.
al
e
or
di
s tri
b ut
io
n
Key Notes:
• It is important for each company to not only have a Business Continuity plan in place, but to have a plan in place to test its
effectiveness.
• It is a good idea for a company to create a fake scenario that affects the business – whether it’s setting off fire alarms,
outages or announcing another disaster. Employees should be put in a situation where they must act as though the
scenario is genuine and refer to their duties in the business continuity plan, going through it step by step.
• Evaluation: After the business continuity plan is put to test, gather employees to discuss the plan’s overall
performance.
Citrix Standard of Business
Continuity Business
Continuity
Team Structure Team
Structure
• Secure executive buy-in.

Employee
N
• Form core business continuity teams: Business
Safety and
ot
Continuity
• Emergency response Awareness
Plans
• Communications Programs
fo
• Campus response
rr
• Business readiness
es
al
e
Disaster
or
Crisis
Communications
Recover and
BC Testing
di
s tri
but
io
n
Key Notes:
• The goal of the Citrix Standard of Business Continuity is to protect the business from disruptions, and keep workforce
productive, wherever they are. In order for this process to be successful, it is important to create a structure of teams,
each with different responsibilities.
• Emergency response – leads business continuity planning efforts; makes final recommendations to the executive
management committee; provides overall direction for preparation, response and recovery.
• Communications – provides communication to all parties including employees, vendors, public service agencies and

customers.
• Campus response – prepares property and equipment for the impending disaster event; performs post-
event assessment of damage and its impact on continuing operations; assists with insurance claims;
secures buildings and grounds.
• Business readiness – acts as a liaison with individual business unit teams; makes arrangements to
implement disaster business operations for each unit; provides tactical response and business direction.
N
ot
• Guidelines for Maintaining Business Continuity:
fo
https://www.citrix.com/content/dam/citrix/en_us/documents/oth/guidelines-for-maintaining-business-continuity-
for-your-organization.pdf
rr
es
al
e
or
di
s tri
but
io
n

Continuity Business
Continuity
Business Continuity Planning Team
Structure
• Create business analysis team.

Employee
N
• Develop disaster scenarios. Business
Safety and
ot
Continuity
Awareness
• Define decision-making hierarchies. Plans
Programs
fo
• Prioritize recovery per business considerations.
rr
• Map recovery goals to dependencies.
es
• Develop datacenter continuity strategy.
al
e
• Develop workforce continuity strategy.
Disaster
or
Crisis
Communications
Recover and
BC Testing
di
s tri
b ut
io
n
Key Notes:
• At a high level, a business continuity plan should identify potential business disruptions that can affect any of an
organization’s locations, such as power outages, epidemics and fires, as well as those that are specific to individual
locations, such as earthquakes and tsunamis in a seismically active region or civil unrest in politically unstable areas.
• It won’t always be possible to maintain normal operations in an emergency situation. To mitigate the impact of reduced
capacity, the team should identify which operations are most essential, who will perform them, and how work will be
redirected if necessary.

• At Citrix, this is handled by a team of business unit owners with a business continuity analyst. This group
works together to rank the criticality of various business processes in terms of revenue, customer-facing and
brand image concerns, regulatory implications and other business considerations, then map dependencies
onto these processes in terms of the applications, people, facilities and equipment required to support them.
• Based on this analysis, the group can identify recovery strategies and costs around continuing each process.
For IT, this data provides a framework for making sure that critical applications will be available to the
business within an established recovery time objective (RTO) and recovery point objective (RPO).
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Continuity Business
Continuity
Disaster Recovery and BC Testing Team
Structure
• Annual updates of a business continuity plan.

Employee
N
• Annual full emergency simulations. Business
Safety and
ot
Continuity
Awareness
• Quarterly business continuity and recoverability Plans
Programs
fo
testing for all mission-critical applications.
rr
es
al
e
Disaster
or
Crisis
Communications
Recover and
BC Testing
di
s tri
b ut
io
n
Key Notes:
• A business continuity plan is only as good as you keep it. Without an ongoing focus on preparedness, an organization can
find in a time of emergency that its plan is no longer relevant to its business or operations, and find itself grappling with an
ad hoc response made worse by a false sense of security.
• Best practices call for annual updates of a business continuity plan to reflect changes in the criticality and dependency of
applications, business priorities, risk management, business locations, operations and other considerations. At Citrix,
business continuity personnel track and note such changes throughout the year to supplement this annual review. .

• Full emergency simulations should be conducted at least annually as well. These guidelines should be
considered the minimum; in addition to an annual review of all plans, as well as crisis communications testing.
• Citrix performs quarterly business continuity and recoverability testing for all mission-critical applications.
Tabletop exercises introduce new twists to ensure the flexibility of the plans in place and give team members
experience responding to the unexpected.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

Continuity Business
Continuity
Citrix Communications Team
Structure
• Establish formal crisis communication program.

Employee
N
• Identify all the stakeholders for emergency Business
Safety and
ot
Continuity
Communications. Awareness
Plans
Programs
fo
• Crisis Communication toolkit should include internal
rr
and external resources, such as telecom, email,
public address, intranet, IM, texting and the
es
company website.
al
• Convey consistent messages.
e
Disaster
or
• Draft sample emergency messages in advance. Crisis
Communications
Recover and
BC Testing
di
s tri
but
io
n
Key Notes:
• A formal crisis communications program can make the difference between panic and smooth emergency response. The
plan should identify all the stakeholders for emergency communications, including employees, contractors, clients,
vendors, media and executive management.
• The organization’s communications toolkit should include internal and external resources such as telecom, email, public
address, intranet, IM, texting and the company website. The communications team should work to convey a consistent
message on the company’s behalf via external channels such as press releases, social media updates and interviews with

spokespeople.
• Sample emergency messages can be drafted in advance, tailored to specific audiences and modes of
communication; these can be updated quickly during an actual emergency to reflect current conditions.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

Continuity Business
Continuity
Employee Safety Team
Structure
• Develop programs through tabletop exercises and

Employee
N
emergency response training by local agencies. Business
Safety and
ot
Continuity
• Incorporate safety and awareness into new Awareness
Plans
Programs
employee orientation.
fo
rr
• Review and test emergency evacuation procedures.
es
al
e
Disaster
or
Crisis
Communications
Recover and
BC Testing
di
s tri
b ut
io
n
Key Notes:
• Keeping people safe should be the top priority in any emergency response. There are many ways to develop an employee
safety program.
• Local agencies such as the Red Cross, fire department, police department and federal entities, such as the FEMA
Community Emergency Response Teams (CERT) in the United States, can provide training and guidance for your
program.
• Tabletop exercises can help you develop and refine the right procedures to fit your workforce, facilities and locations.

Once your program is in place, it should be included in new employee orientation and reviewed regularly with
all employees.
• Emergency evacuation procedures should be reviewed and tested frequently, and employees should know
where to find business continuity documentation. During an emergency, pay careful attention to peoples’
stress levels and make sure they are allowed ample time to sleep, eat and relax.
N
ot
fo
rr
es
al
e
or
di
s tri
b ut
io
n

N
ot
fo
What is the first step in returning to normal
operations after a disaster recovery event?
rr
es
Determine stability in the primary datacenter.
al
e
or
di
s
tri
utb
io
n

Lab Exercise 9-1: Test the Failover
Process Between Datacenters
You have helped to configure two highly available
N
datacenters. You have been asked to test the failover
ot
process between datacenters in a disaster recovery
scenario where the one of the datacenters is no
fo
longer accessible.
rr
es
al
e
or
di
s
tri
b
ut
io
n

Exercise 9-1: Test the Failover
Process Between Datacenters
[30 Minutes]
Task:
N
• Test the disaster recovery failover process.
ot
fo
rr
es
al
e
or
di
s
tri
utb
io
n

Key Takeaways
• Tier 7 is the highest level of disaster recovery, but it

can both be costly and involve a lot of risk to
automate everything.
N
ot
• Consider using the same URL for disaster recovery
connectivity to optimize the user experience.
fo
rr
• Always terminate all sessions before completing
data replication to ensure data consistency and
es
avoid profile corruptions.
al
• Every business needs a strong Business Continuity
e
Plan in place, to include testing and evaluation of
or
the process.
di
s tri
b ut
io
n
Key Notes:
• Tier 7 is the highest level of disaster recovery, but it can both be costly and involve a lot of risk to automate
everything.
• Consider using the same URL for disaster recovery connectivity to optimize the user experience.
• Always terminate all sessions before completing data replication to ensure data consistency and avoid profile
corruptions.

• Every business needs a strong Business Continuity Plan in place, to include testing and evaluation of the
process.
N
ot
fo
rr
es
al
e
or
di
s tri
but
io
n

End of course survey
Your opinion matters!

Now is a great time to provide
N
ot
feedback on your experience.
fo
rr
Help shape the next course.
es
al
Tell us what you liked!
e
or
What can we do better?
di
s
tri
utb
io
n

Citrix Measures your Feedback with NPS
How is Net Promoter Score Calculated?
N
Not at all How likely is it you would recommend Citrix Courses to a friend? Extremely
ot
Likely Likely
0 1 2 3 4 5 6 7 8 9 10
fo
rr
es
\/
al
e
or
di
Detractor Passive Promoter
s
tri
but
io
n

Training you might also like
• CNS-420: Citrix Networking Assessment, Design, and

• This class will cover advanced networking and Citrix
ADC concepts and configurations; i.e. multi-site and
N
multitenant deployments, advanced authentication and
ot
load balancing, and automation and orchestration, and
advanced troubleshooting.
fo
rr
• CXD-252: Moving to the Citrix Virtual Apps and
es
Desktops Service on Citrix Cloud and Microsoft Azure
• This class will cover the move from an on-premises
al
environment into Citrix Cloud or Azure. Learn the
e
architecture, communications, and management of
or
Citrix Cloud and the Citrix Virtual Apps and Desktops
Service; to include machine deployment with MCS and
di
configuring the Access Layer.
s
tri
utb
io
n
• Citrix Education: https://training.citrix.com/learning/landing

N
ot
fo
rr
es
al
e
or
di
s
tri
b
ut
io
n

CWS 415 2I en StudentManual v02

Uploaded by

Document Information

Original Title

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

CWS 415 2I en StudentManual v02

Uploaded by

Copyright:

Available Formats

N

Module 0 - Course Overview.....................................................................................................................................................................2

2 © 2021 Citrix Authorized Content

• Review the Citrix methodology and the different

3 © 2021 Citrix Authorized Content

• Investigate the differences between the available

4 © 2021 Citrix Authorized Content

Drive digital transformation

5 © 2021 Citrix Authorized Content

6 © 2021 Citrix Authorized Content

• Introduce yourself to the class.

7 © 2021 Citrix Authorized Content

• Parking and transportation information

8 © 2021 Citrix Authorized Content

• This course requires extensive experience with

9 © 2021 Citrix Authorized Content

• Module 0: Course Introduction

10 © 2021 Citrix Authorized Content

• Module 3: Access Layer

11 © 2021 Citrix Authorized Content

• Module 4: Resource Layer – Images

12 © 2021 Citrix Authorized Content

• Module 6: Control Layer

13 © 2021 Citrix Authorized Content

• Module 8: Multiple Location Considerations

14 © 2021 Citrix Authorized Content

• This course has the following material:

15 © 2021 Citrix Authorized Content

All lab exercises are grouped and performed together

16 © 2021 Citrix Authorized Content

17 © 2021 Citrix Authorized Content

ZIP archive containing:

18 © 2021 Citrix Authorized Content

1. Login with your MyCitrix

19 © 2021 Citrix Authorized Content

Download the Lab Guide to complete the

20 © 2021 Citrix Authorized Content

Take notice of the Lab Time counter, this

21 © 2021 Citrix Authorized Content

22 © 2021 Citrix Authorized Content

User Layer Access Layer Control Layer Resource Layer

StoreFront Delivery Controller Server VDA

23 © 2021 Citrix Authorized Content

• Remote Desktop Connection

24 © 2021 Citrix Authorized Content

• Use the Remote Desktop

25 © 2021 Citrix Authorized Content

• Manage virtual machines

26 © 2021 Citrix Authorized Content

• Manage Hyper-V clusters

27 © 2021 Citrix Authorized Content

28 © 2021 Citrix Authorized Content

• You can download, save, and print electronic

29 © 2021 Citrix Authorized Content

Your opinion matters!

30 © 2021 Citrix Authorized Content

31 © 2021 Citrix Authorized Content

32 © 2021 Citrix Authorized Content

Special thanks you to all who contributed to the

33 © 2021 Citrix Authorized Content

34 © 2021 Citrix Authorized Content

• Describe the Citrix Methodology and identify

35 © 2021 Citrix Authorized Content