PROOF-OF-CONCEPT PILOT PROGRAM

In Chapter 4 we discussed setting up a proof-of-concept pilot program as an important element in the design of an enterprise Citrix Access Suite deployment. The pilot is also the first step in an enterprise rollout. It serves as a basic test of application performance using Terminal Services.

At first, the pilot program should be a nonproduction system designed to ensure that the desired applications perform together adequately over Citrix Presentation Server and Terminal Server. The next step is to expand the nonproduction pilot to a small production pilot with carefully selected participants running specific applications.

Note 

The pilot is also a great opportunity to validate the assumptions made in the project ROI analysis (discussed in Appendix B). These include metrics such as the number of applications run under Citrix Presentation Server, the number of users per server, and the bandwidth required per session.

Pilot Platform

The pilot hardware should be representative of the hardware that will eventually be used in the data center to support the enterprise rollout. The pilot program should not be constrained by any difficulties or limitations in the existing network infrastructure. For instance, if the network backbone is causing latency issues, the pilot should be set up on a separate backbone. If a data line to a remote office frequently fails, then the remote office should not be part of the pilot program.

Application Selection

The objective is to load all applications to be hosted under Presentation Server as part of the proof-of-concept, nonproduction pilot program. That being said, most organizations have far too many applications to reasonably host together in a Presentation Server environment. During the infrastructure assessment and project plan design process, the appropriate applications are studied in great detail and are carefully selected for deployment over Presentation Server. Since the pilot takes place before this assessment begins, you can pare down the applications to be hosted in this environment by following a few rules of thumb:

  • Use representative samples. Applications should be a representative sample of the production suite.

  • Eliminate duplications. Although Citrix Presentation Server 4's new Application Isolation Environment enables you to run disparate applications on the same server, it's still a good idea to utilize the Citrix Access Suite deployment as an opportunity to pare down the number of disparate software packages. The best way to do this is to simply look over the list of all applications to eliminate obvious duplications. For instance, if 90 percent of projected Presentation Server users run Microsoft Office and 10 percent run Corel WordPerfect Office, it is reasonable to enforce MS Office as the new corporate standard.

  • Develop selection criteria. Create a list with "must-have" and "should-have" features to help pare down the applications in the pilot program. For instance, a must-have feature would be that an application be stable under standard NT workstation. A should-have feature would be that the application be 32 bit.

Testing

The performance, stability, and interaction of the various applications individually and collectively under Terminal Services must be tested and evaluated. One way to do this is by using test lists.

The application information gathered during the infrastructure assessment can be used to prepare the test lists. The lists should include the attributes to be tested along with the expected outcomes . Record the actual outcome for each test and whether it passed or failed. In Chapter 13 we discuss application testing in some detail.

Expanding to a Production Pilot Program

Start with a prepilot survey geared to recording the current state of user performance, reliability, and satisfaction in a fat-client environment. Use the survey results to set expectations for the users about the performance under Presentation Server. Be sure they are prepared for the inevitable problems that the new environment will precipitate, as well as for any differences they are likely to encounter by running their applications in a Citrix Presentation Server environment.

It is acceptable to ask "leading" questions in the survey to set expectations, but they should strive for quantifiable answers where practical. For example, instead of asking, "Does your PC crash frequently?" you can ask, "How often does your PC need to be rebooted?" The results should be tabulated and published to the users who participated. A good way to do this is by using an intranet site. If such a site is already available, consider doing the survey online rather than with paper forms.

Selecting Applications

The objective of the pilot program is to prove the value of hosting applications over Citrix Presentation Server. Misbehaving, but not crucial, applications should not be included as part of the production pilot. They can be tested further for inclusion as part of the beta if their problems can be solved or isolated using a two- tier server farm, as discussed in Chapter 13.

Tip 

You can use batch files or WSH (Windows Scripting Host) to remove or move icons from applications that are currently run locally on a user's PC. This allows for a quick rollback in the event that the pilot program does not succeed.

The following are some minimum requirements for running an application in a production pilot program. These are suggestions to help get you started on your own list:

  • The application is stable in the current distributed environment.

  • If it is a DOS application, it does not extensively poll the keyboard. This can cause huge CPU utilization on Citrix Presentation Server. You should seriously consider replacing any DOS application with a 32-bit Windows version if possible.

  • If it is an older or custom application, make sure it doesn't use hard-coded path - names for files. Since most paths need to be user specific in a multiuser environment, this can cause major headaches .

  • The application represents the most users possible. Using our previous example, we would want to test MS Office and not WordPerfect Office because the former represents 90 percent of the users.

  • Applications with back-end integration requirements (such as database or terminal session connectivity) have upgraded to the latest version. We have found that many applications that fit this description, such as IBM Client Access or various reporting packages, work fine in a multiuser environment but only if you use the latest version.

Testing and Evaluation

Start with the test lists defined in the pilot program for component and system testing, and layer in tests aimed at the production environment. Such tests would include a larger number of users running the applications, competing network traffic, reconnec-tion to a user session, use of shadowing to support an application, and the effect on applications of backing up and restoring data.

Determine what performance data needs to be collected and how to collect it. System management tools such as Citrix Resource Manager can be useful here, as well as user surveys. One of the best testing methods at this stage is simply saturation: let the users pound away at the applications, and see what they come up with.

Selecting the Participants

The production pilot program should include a larger sample of users than the nonpro-duction pilot, but the number should remain relatively small. The exact number will be based on the size of your organization and the complexity of your application environment. Ideally, the users selected should be representative of the users who will participate in the access platform, but they should also be friendly to the project. We have found that keeping the number of participants in the production pilot between 5 and 10 users, and no more than 50 for large companies, seems to work best.

Choose which categories of users will participate in the pilot, keeping in mind that you are looking for a representative mix of the ultimate access platform participants. A small pilot, therefore, might still include thin-client only, mobile, and hybrid users. We recommend including at least one Windows terminal as part of the pilot, if possible, in order to get across the point that this is a new way of delivering applications. Of course, a Windows terminal can only be used when all required applications for a user or group are accessible over Citrix Presentation Server.

Location of users is also important. If users in remote offices will be part of the pilot program, the network's wide-area infrastructure needs to be very sound. As discussed in Chapter 4, remote office users should be trained ahead of time not to engage in excessive bandwidth utilization practices such as copying data from a local hard drive back to the data center server, or downloading MP3 files from the Internet connection via the Citrix Presentation Server farm. Alternatively, you should have a method to limit the bandwidth available to users. We've already discussed TCP rate control and custom queuing as two common methods. We've summarized these and other requirements as follows :

  • Choose a small but representative mix of users. The users selected should access different groups of applications from different types of clients .

  • Use this opportunity to test key parts of your infrastructure with Citrix Access Suite. Choose users in major regional offices, telecommuters, and VPN users.

  • Choose users who are open to the access platform concept. Demanding users are fine as long as the demands are reasonable, but avoid high-maintenance users.

  • At this stage, choose users who are computer literate and can make the "paradigm shift" necessary to participate fully. We are not saying they have to be programmers or system administrators, just experienced users who have some command of their current desktop.

Customer Care During the Pilot

We discussed customer care in detail earlier in this chapter. It is crucial to alert the help desk and to put special mechanisms in place for expediting any problems users encounter. A sour experience during the pilot program, even among friendly users, could end up poisoning the entire Citrix Access Suite project. On the other hand, if users receive fast and competent responses to issues that arise, they are more likely to start an early, strong, favorable buzz about the new technology. A good technique is to have a "triage" process in which the help desk can quickly categorize a pilot call from a normal production call and route it appropriately. After a call is identified and routed to the first tier of support, it should go directly to the pilot implementation team. This is an excellent method for keeping the team in tune with the users and making continuous, incremental improvements to the pilot environment.

Training Techniques

It is important for the ultimate success of the project to formulate a training plan for all employees involved, including users, help desk technicians (all levels), and administrators. Here are some suggestions:

  • Users If your organization, like many, is already using a Windows desktop environment, moving to Citrix will not represent a large functional difference to users. Training a large number of users is also very expensive. We recommend integrating a short orientation, perhaps 15 to 30 minutes, into the user migration process. The user should be oriented, the data migrated , the client installed, and the client device configured all during the same visit by a deployment technician.

  • Help desk The people fielding technical support and administrative requests must not only understand the basics of on-demand access, but they must also be trained in how to do whatever they do now in the new environment. Creating users, adding them to groups, and giving them access to file storage and applications are different tasks in Citrix Presentation Server and must be the subject of training. The deployment team is a good source of targeted information on these operations, so build time in the schedule to have them give input into the training plan.

  • System administrators These individuals usually represent the smallest group and need the most training. They will eventually receive calls from other groups and are responsible for solving problems in production. You should build money into the budget for the training programs offered by Citrix and Microsoft. Specifically, the Citrix Certified Enterprise Administrator (CCEA) and Microsoft Certified System Engineer (MCSE) should be considered for administrators.

Controlling the Pilot Program

A carefully implemented pilot program is likely to be successful, but this very success leads to quick requests for enhancements. It is important not to cave into pressure from users to introduce new variables , such as additional applications, as part of the pilot. Do not stray from your pilot plan until after the initial testing is complete. If adjustments such as adding applications must be made before a beta implementation, the initial proof-of-concept testing offline should be repeated and then the new server image introduced to the users. Don't assume that, since the production pilot worked with ten applications, it is acceptable to add an eleventh. Everything must be tested before being deployed. Also realize that your deployment team is limited. If you are forced to spend a lot of time testing new applications or features at the last minute, it is likely to have an impact on the schedule.

Creating a Variance Process Define a variance process before the pilot that defines the handling of scope creep. You can publish this process as part of the user survey or other communication given to the pilot users. Decide who needs to approve requests for additional applications or pilot participants, and have a mechanism ready to handle this process. We've found such requests often come from management members who outrank the deployment team. If you must implement a change, be ready to clearly and concisely communicate the impact it will have on the deployment schedule, resources, and cost.

Handling Objections to On-Demand Access Despite careful pilot participant selection, some users may still object to the concept. Be prepared to do a quick sales job that shows them both the personal and corporate benefits of migrating to an on-demand access environment. If you run into unreasonable or unfounded objections, be ready to pass them to the proper management members. The executive sponsor for the pilot is an excellent choice to help handle objections. Another important tool is to have the facts at hand regarding any objection. We've found that users sometimes couch objections in terms sympathetic to their case that do not always reflect the facts. For example, a user may go to his manager and say, "The pilot team says I can't have the printer on my desk anymore." In reality, the pilot team published a list of compatible printers, and this user's printer wasn't on it. Be ready to tell this user and his manager how they can get a compatible printer or what to do as a work-around .

Assessing Performance

Document your expectations of the pilot program before you begin. Decide up front upon the success metrics for the pilot. Take measurements of application performance in the current distributed environment, and compare these to performance under Citrix Presentation Server. For example, the time it takes to launch Microsoft Word can be measured in both environments. (It should be faster under Citrix.) Other examples include the time it takes to print a certain document or to open a specific file.

In addition to the user-oriented metrics mentioned, include system and cost metrics. An example of a system metric is the time it currently takes to support a regional file server when it fails as compared to the time it takes to fix a file server in the data center. An example of a cost metric would be the cost of flying a technician to the site where a problem is occurring as opposed to having a technician handle the problem at the data center.

After the pilot, create a report on whether success metrics were met. Document any problems encountered along with their solutions. Document any open issues or new questions raised by the pilot, along with the actions being taken to resolve them.



Citrix Access Suite 4 for Windows Server 2003. The Official Guide
Citrix Access Suite 4 for Windows Server 2003: The Official Guide, Third Edition
ISBN: 0072262893
EAN: 2147483647
Year: 2004
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net