Friday, July 11, 2014

Architecting a Citrix Virtualization solution-Assessment: User community

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
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.
 Information about primary and secondary datacenter locations aids in the design when sizing the overall solution. The secondary datacenter information helps the architect determine levels of fault tolerance and any extra capacity required for backup.
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.
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.
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

Featured Post

Amazon Route 53

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service.Route 53  perform three main functions in any...