The Proof-of-Concept Pilot Program

Applications are the driving force behind server-based computing, and it makes little sense to go through the expense and trouble of planning for an enterprise implementation until you know that your organization's applications will run adequately within this environment. An inexpensive proof-of-concept pilot program enables you to test application compatibility both individually and when running on Terminal Services. It also enables you to measure performance and to more accurately gauge the server resources required to implement an enterprise server-based computing environment.

Starting with a Non-Production Pilot Program

Although you may ultimately wish to run all of your organization's applications under SBC, the decision to implement server-based computing generally depends upon successfully running a small number of critical applications. These are the applications that should first be loaded on a server running Terminal Services and MetaFrame XP Presentation Server offline. If the results are not acceptable, adjustments to the applications or operating system may be required. Once the crucial applications are running well on MetaFrame XP Presentation Server, other less-crucial applications can be added, if desired. If SBC users will be using foreign-language versions of Terminal Services and MetaFrame XP Presentation Server, a separate proof-of-concept pilot program should be set up for each language since different hotfixes and patches are often required.

Expanding to a Production Pilot Program

Once the offline pilot program is stable, you can expand it to include a small number of pilot users. Great care, though, should go into the selection of these participants. A natural inclination of IT people is to choose from two types of users. The first type is a user who has an immediate computing need that the pilot program will solve, such as a requirement for an upgraded PC. The second type of user is someone who is known to be difficult because he is particularly demanding or requires constant help. The thinking here is that if server-based computing can make a difficult user happy, it can make anyone happy. Using these selection criteria, though, is toying with disaster. A pilot program is likely to have some bugs that need to be worked out. The wrong participant may loudly complain about the problems of working with Terminal Services. If the complaint reaches the ears of an executive, the whole on-demand enterprise (ODE) initiative could be killed. The organization might then lose the opportunity to reap the benefits and savings of server-based computing simply because of poor selection of participants.

Pilot users should be a representative sample of those who will ultimately use Terminal Services, but they should be friendly to the concept and understanding about the likelihood of encountering initial problems until IT works them out. Avoid choosing people for any reason other than testing the server-based computing concept.

Goals of the production pilot include measuring the time it takes for loading the various applications, reviewing methods for performance tuning, and focusing on user issues such as usability and functionality.

Capacity Planning

Most organizations do not convert their entire infrastructure to an on-demand enterprise at once. Almost inevitably, though, SBC becomes increasingly utilized once implemented and as the benefits of the on-demand enterprise begin to manifest themselves. It is important, therefore, to adequately plan for growth and to implement a system that is scalable. A pilot deployment is a great opportunity to gather capacity metrics in a controlled environment with actual users. It also allows administrators to monitor all components of the implementation such as server capacity, bandwidth utilizations, Directory Services integrations, peripherals, and file storage. A good practice is to build a pilot environment that contains 30 to 40 percent more capacity than the expected user load for the pilot. The extra capacity gives the administrator an adequate buffer for unexpected bottlenecks that may arise during testing. When the pilot is converted to a beta, the additional resources will undoubtedly be used. Therefore, resources are not wasted.

Hybrids or Pure Thin Clients

Operating in a hybrid mode occurs when a user continues to run one or more applications on his or her local PC. If pilot participants will be operating in hybrid mode, make sure their desktops are configured so that they know whether they are in a local session or in a MetaFrame session. This can be accomplished using application publishing (as explained in Chapter 13).

Even if Windows terminals are not in your organization's on-demand enterprise plans, we recommend securing one for the pilot program. Since a Windows terminal is completely dependent upon server-based computing to operate, installing one contributes to a deeper understanding of the new ODE. You may find that the Windows terminal "brick" has uses that you hadn't previously considered, such as serving as an employee's home "PC."

Caution

If you are going to have pilot users run legacy PCs, make sure the PCs are high-quality, reliable models (though they do not need to be powerful machines). In one of the authors' projects, a teacher became frustrated because her extremely cheap PC's keyboard broke when she was made a pilot MetaFrame user. Unfortunately, she had grown attached to her low-end keyboard, and despite our best efforts, we could not convince her that her keyboard's failure had nothing to do with Terminal Services. She ended up poisoning the entire project by warning the other teachers not to let Citrix into their classrooms "because it breaks keyboards."

Headquarters and/or Remote Office Users

If you have hybrid pilot users in a remote office who are connected by limited bandwidth, it is essential that you instruct them in proper usage. You do not want them, for instance, to back up files from their local hard drives to the MetaFrame server at headquarters. This will chew up bandwidth and may cause performance degradation for other users in the remote office. As discussed in Chapters 6 and 17, you might also consider setting up bandwidth management as part of your pilot program in order to ensure adequate WAN performance.

Tip

Even if you have no intention of putting headquarters users onto Terminal Services, you should consider setting up at least one corporate IT person as part of the pilot program. Again, this will help to foster understanding of the server-based computing concept and enable your IT staff to experience it firsthand.

Change Control

Many organizations really struggle with how to keep up with change control. It is important for the success of the pilot that a focus is made on maintaining a stable environment, on consolidating and scheduling updates, on obtaining sign-off authority for changes, on proper regression testing, and on maintaining a detailed rollback plan in the event that new applications disrupt the pilot. Implementation support is extremely difficult when too many people or teams have their hands in the pot. It is also very difficult to monitor the systems when servers are frequently down for maintenance.

If you don't have change control procedures in place for IT infrastructure changes, we recommend creating a simple Excel spreadsheet with a tab for each server. On that tab you can have columns for date, change, changed by, and approved by. Another option is to create a mail-enabled public folder in Exchange. Allowing administrators to e-mail any change to an address, such as <[e-mail]>, would then make the changes easily available for review.

Documenting Performance

Document your expectations of the pilot program before you begin. Decide up-front what success will look like and how it will be measured, and after the pilot program, create a report on whether the success metrics were met. Document any problems encountered along with their solutions. Document any open issues along with the actions being taken to resolve them.

Pilot Server(s)

Ideally, two load-balanced servers will be utilized for the production pilot program in order to provide redundancy. In most cases, though, organizations will probably use only one server in order to keep expenses lower during the proof-of-concept phase. Organizations can generally use a single server for testing load balancing by utilizing a product such as VMWare or Microsoft Virtual Server. The server should still be close enough to your expected production rollout model to make the results meaningful. For instance, using a Hewlett-Packard server with only two CPUs and half the RAM of your ultimate intended Hewlett-Packard MetaFrame server is probably OK. Using a different brand with different CPU and memory configurations is not a good idea.

Applications

If you are running anything other than 32-bit applications, be prepared for less than optimal performance. Make users aware of what they can expect from various applications. Use products such as the resource manager (RM) component of MetaFrame Presentation Server to test application performance results under simulated greater usage and for providing an audit trail in case of application failure. If performance is less than expected, try removing questionable applications to see if a particular product is causing problems.