This article is about architecting a Citrix environment from
Architects perspective. There are 2 parts to it:
1) Assessment
2) Design
Assessment is further divided into
· User Community
· Operating System
Delievery
· Application Delivery
· Server Virtualization
· Infrastructure
· Security and
personalization
· Operation and Support
· Conceptual
Architecture
Design is further
divided into
· Application Delievery
design
· Desktop Delivery
design
· Operating System
Provisioning design
· Virtualization
Infrastructure Design
· Access Design
· Delivery Optimization
In this blog, we will discuss assessment of user community.
Each topic will be covered in separate blog.
User Community:
We
have to explore the user experience as related to applications, connectivity,
usability and stability. It will help the architect to understand and document
the issues affecting users, as well as recommend potential improvements and
solutions.
Representatives
from each user group should be interviewed to get the information. Users will
sometimes voice concerns and issues, but often they do not. In addition, help
desk representatives should be interviewed to learn about common complaints and
issues.
User Requirements
Understanding
user requirements, including their location and concurrency, is extremely
helpful to an architect when developing a virtualization solution. Architects
should be aware that each user group or community will have specific
requirements that might dictate their workflows. Also, the standards for each
group are often different from other groups because of personalization and
differences in the application set.
User
requirements should include current user issues and frustrations and solutions
to address those issues. Architects should ask about common user complaints,
challenges and errors.
User Groups
When
assessing the user community, a general understanding of the users is required
and separate them into different groups. If user groups are not well-defined,
architects should identify that as a risk. Groups should be created so
applications and desktops can be delivered based on user groups, not individual
users. One way to organize the user groups is by department or job title. For
example:
- Call center agents
- Support
- Human Resources
Another
method is to categorize users by their job function and the applications they
use. For example:
- Task-based users (single
application-focused or those who use a small number of applications on a
constant basis)
- Knowledge workers (user of a
wide variety of applications who can install and remove applications;
usually includes subject matter experts, researchers, developers)
- Power users (includes users
with above-average application skills, yet who may not capable of advanced
technical tasks--for example, an accountant who is proficient with MS
Excel macros)
- High graphics users, such as
AutoCad users
A combination of user categorization approaches could be
used, based on the organization involved in the assessment. It is important to
document the number or percentage of users who fall into the categories the
architect defines. When categorizing the users, the applications they use are a
key factor.
User Groups Determination
Defining
user groups is a significant task in a virtualization assessment and provides a
starting point for the design. The decisions are based on user requirements and
user tasks.
Architects
should ask the following questions:
- What is the user's role or job
function in the organization?
- Which kinds of technical
requirements, such as applications and speciality hardware, do these users
require to do their jobs?
- In addition to the required
items, are there any non-essential technical items--for example,
productivity software or specialty hardware--that would be helpful to
these users while helping the company achieve its business goals?
- Do the applications they use
follow a specific criteria?
- Which operating system do they
use?
- Where are the users
located--for example, headquarters, regional office, branch office,
remote.
Answers
to these questions help the architect gain a deeper understanding about the
users in the environment. This knowledge will be leveraged in the design phase
to choose the right solution for each user group
User Types
Assessing
user types is an important aspect of a desktop virtualization project.
Architects should assess whether the current environment accommodates all types
of users in an organization, that the appropriate tools and processes are used
to meet the needs of each user type, and if any planned configuration changes
could impact various user types.
Questions
an architect typically asks when assessing user types include the following:
- Do users need to roam to
another location?
- Do users require special or
unique needs?
- Are there any planned
customizations to the environment?
Defining Your User Groups
and Types
- What is the user's role or job
function in the organization?
- Which kinds of technical
requirements, such as applications and speciality hardware, do these users
require to do their jobs?
- In addition to the required
items, are there any non-essential technical items--for example,
productivity software or specialty hardware--that would be helpful to
these users while helping the company achieve its business goals?
- Do the applications they use
follow a specific criteria?
- Which operating system do they
use?
- Where are the users
located--for example, headquarters, regional office, branch office,
remote.
Segmenting Users
A
best practice for desktop virtualization is segmenting the users. Segmenting
users accommodates the different requirements of workers in a variety of roles.
This practice also allows for the delivery of either a physical or virtual
desktop and simple customization of resources by role and access scenario for
each delivery type.
When
segmenting users, architects need to fully understand user requirements by
talking to the users about what is not working with the current environment and
which functionalities they desire. Segmenting users and discovering their
particular issues helps the architect better understand which solution they
should recommend to the organization. The table below contains an example
scenario for segmenting users.
User Group
|
Location
|
Requirements
|
Challenges
|
Requests
|
Business Analysts
|
Corporate offices, remote offices
|
Customizable environment, ability
to manipulate information, dynamic work habits, remote access
|
IT locks down desktop to disallow
customization, unable to get latest tools
|
Need latest tool versions, require
customization, add "non-IT" tools, require fast access to data,
allow for working remotely
|
User Habits and Workflows
A
significant task in designing a virtualization solution is to identify user
habits, how users access resources and how they interact with their systems.
Architects should aim to understand user habits and workflow from logon to
logoff. During this portion of the assessment, architects should ask the
following questions:
- How many users connect to
servers from the LAN? Over the WAN?
- Which resources do users
primarily access and how?
- What are the differences
between how users access resources?
- Which file shares exist and
where are they located?
- Which printers are used?
- Which intranet and Internet web
sites are primarily accessed?
User
workflows can help determine the use case for virtualization later on during
the project. Assessing user workflows can also uncover the causes of user
frustration or user issues. While it may be possible to resolve some issues
within the current environment, these issues should still be noted as a risk in
the assessment documentation.
User Locations
User
locations are crucial to a virtualization solution. During the assessment,
architects should ask the following questions:
- Which datacenter do users
connect to?
- What are the primary and
secondary datacenters?
- Where do branch offices exist?
How many users are at those locations?
- Do WAN links exist?
It
is helpful to take a look at a diagram or map of geographic locations.
- Is a disaster recovery site
in-place, and where is it located?
Some
organizations may not provide the location of their disaster recovery site.
Diagram of Locations
Information
about user locations assists the architect in understanding the current
environment and the geographical scope of users who require resources. It is
helpful to take a look at a diagram or map of locations.
Remote Users
Important
user groups, especially for a virtualization solution, are the remote and
mobile user groups. More and more users are requesting the ability to access
applications from home or other locations outside of the internal network.
Architects
should ask the following questions:
- Which type of security measures
exist for remote users?
- Is user session monitoring set
up for remote users? Does the organization use Citrix EdgeSight?
- How do remote users connect? Do
they go through an Access Gateway?
- What is the percentage of
remote users in the organization? Is there an exact number of remote
users?
Many
organizations require employees to go through an approval process before
gaining remote access. If remote access is only granted to employees using endpoint
devices issued by the employer, an architect should identify that as a risk and
may recommend implementing Secure Remote Access to provide users access from
any device.
Answers
to questions about remote users help architects become more aware of the types
of users, percentage of remote users, special requirements and the methods used
to remotely access resources. The data will be used when designing the
environment to accommodate remote users.
Endpoints
Once
the different types of users have been identified, the architect must assess
the hardware devices (endpoints) being utilized by the users. It is critical to
remember that users receiving only virtualized applications still require a
device/desktop in order to view the applications. The capability of the device
plays a significant role in where and how an application or desktop is
delivered.
During the assessment, an architect
should ask the following questions:
- How many corporate/managed
devices are in the environment? Non-corporate/unmanaged devices?
- Are non-corporate devices such
as a home PC or kiosk allowed to connect to internal resources?
- What is the age of specific
groups of endpoints?
For
example, the age of the device may determine later whether it receives a
streamed image or the type of virtual desktop it receives.
- What is the process for
implementing new endpoints? Any common issues?
- What are the refresh cycles for
devices?
- What is the general hardware
level of devices?
- Which devices are planned for
purchase?
Endpoint Operating System
Architects
should also assess the endpoint operating systems in the environment. For
example, if users have the expectation that 64-bit Windows operating systems
will be deployed and some corporate applications cannot support these systems,
this risk must be identified in the assessment process.
When
assessing the endpoint operating systems, architects should ask the following
questions:
- Which operating systems are
currently in use?
- Are there plans to upgrade the
currently provided operating systems?
- Will several operating systems
need to be provided?
- What are the
characteristics--including service pack level and Windows Update status
(enabled/disabled)--of the current desktops?
- How are Citrix plugins
currently deployed?
- Are the plugins embedded in
images?
- Which browsers are currently in
use?
Endpoint Classification
Each
endpoint has a direct impact on the scalability, architecture and delivery of
the virtualization solution. It is recommended that architects assess the
endpoint devices that currently exist in the environment. Architects are
encouraged to think about how they could be used in the final solution. Some
common classifications and considerations for endpoints include the following:
- Replaced endpoints are
endpoints that cannot function due to hardware failures, generally caused
by the age of the device. Replaced endpoints may also have insufficient
CPU, memory and hard disk space to meet current and future needs. Organizations
may choose to replace them with new desktop hardware, which can be costly,
or with a desktop appliance. With the desktop appliance, the user
authenticates at startup and automatically launches an approved virtual
desktop hosted in the datacenter. However, the main reason for replacing
an endpoint that will run a hosted virtual desktop is to provide a simple
and fast user experience.
- Repurposed endpoints are
devices that are becoming obsolete and have limited usability.
Organizations can extend their lifetime by repurposing the devices as
desktop appliances. Repurposed endpoints are typically locked down and
configured to only access a hosted virtual desktop in a Citrix
virtualization environment, because this requires significantly less
management and maintenance than using the endpoint natively. Repurposed
endpoints are useful because they can easily run clients and connect to a
virtual desktop.
When
assessing endpoints, architects should keep in mind ways they can repurpose
devices with limited usability. Architects should ask the following questions:
- Are devices in use becoming
obsolete or have limited use?
- How are these endpoints being
managed? Are they being repurposed?
- Reused endpoints are
workstations that have recently been refreshed. They contain powerful
processors, larger amounts of RAM and more hard drive space than endpoints
that are typically replaced or repurposed. Endpoints that are designated
as reused are generally capable of running the most up-to-date operating
system and applications. Running a hosted desktop on a reused endpoint
could be a waste of the reused endpoint's hardware, and of the
organization's hardware investment. Therefore, an option is to deploy a
provisioned desktop image, because it provides the reused endpoint with an
operating system through a desktop image, but utilizes the local hardware.
However, an endpoint in this category could be used to run a XenDesktop
image for 3-D applications. During the assessment, architects should think
about how they might want to recommend endpoints for reuse in a
virtualization environment, once the design phase is reached.
·
Endpoint Device Management Risks and
Recommendations
·
The following table identifies
examples of risks and recommendations.
Risk
|
Recommendation
|
Managed devices cannot be easily
identified.
|
A registry key or domain
membership should be used to confirm devices the organization manages.
|
Unmanaged devices and devices with
an expired warranty exist in the environment.
|
Organizational standards and
processes should be established regarding the devices put into service in
order to be able to provide support.
|
Users can access from any device
on an "at your own risk" basis, potentially introducing a
compromised device into the corporate environment.
|
IT is responsible for helping
users access resources, despite an "at your own risk" policy. The
organization should make a concerted effort to identify supported devices.
|
Citrix plugin is not up-to-date.
|
Install the latest Citrix plugin
on all endpoints.
|
A strategy does not exist for
updating endpoints.
|
Document a standard process and
strategy for updating endpoints.
|
Too many print devices are mapped,
causing a degradation in the user experience.
|
Optimize the printing solution to
give users only what they need.
|
Smart phones, TWAIN devices and
microphones are having a significant impact on network utilization.
|
Only sync smart phones when
necessary, and only use TWAIN devices or microphones when necessary.
|
tomorrow, i will cover the topic Operating System Delievery
No comments:
Post a Comment