Expanding the Pilot Program to a Beta


A beta deployment, while conceptually still a pilot, should represent users and environments that will be part of the enterprise rollout. The beta will be invaluable as a mechanism for discovering and resolving major performance issues before going to enterprise production. It should not be implemented until after the design for the enterprise rollout is well underway and the funds for the entire project have been justified. Even so, a poorly performing beta could end up killing the project; therefore, it is essential the beta be implemented with the same high level of diligence used in the pilot phases. You should also try to make the beta implementation as nondisruptive to the current production environment as possible by running as many services in parallel as allowable. For example, if you intend to run a new network backplane and a new enterprise-class file server for the SBC implementation, leave the old systems online as you bring up the new systems. Users can then move from the old to the new system incrementally. This also serves the purpose of "leaving yourself an out." The smooth running of your business is more important than this project. If something doesn't go right, be able to go back to a known, reliable state.

Customer Care During Beta

As with the pilot program, responsiveness to users' problems will greatly influence their opinions about the project. Enhance the help desk and call center staff for quicker turn-around.

In the spirit of having no secrets from the user community, a published outage log should be created for users via an intranet web site or through an internal electronic forms application such as Microsoft Exchange or Lotus Notes. Encourage users to let IT know about any system outages or problems. Also provide a forum for beta participants to offer feedback unrelated to problems. This can help increase user satisfaction.

Now is the time to refine the support process and be ready for production. Help desk personnel, along with system administrators, should be trained and ready for the demand. If you intend to deploy system management servers or a network management framework tool that integrates with your help desk system, they should go through final implementation at this point.

Maintenance Window

As with a mainframe environment, a maintenance window should be scheduled once a production server-based computing environment is in place. During this time, the deployment team and system administrators will perform tasks that require a significant portion of the infrastructure to be offline. Such activities include hardware and software upgrades, switching over network connections or carrier lines, or troubleshooting and correcting problems before they cause a production outage.

The maintenance window should be scheduled during the least disruptive time. If an organization is international in scope or works 24/7, it may be difficult to set aside a regular time slot, but it should be done if possible. During the implementation process of both the beta and the enterprise deployment, the maintenance window will likely need to occur more frequently than after project completion. It is important to user acceptance to avoid unscheduled downtime whenever possible. Since SBC users are completely dependent on the network for their processing, unscheduled downtime will create unhappiness and loss of productivity.

Unscheduled Nonemergency Maintenance

Some organizations might not be able to, or may not wish to, have a regularly scheduled maintenance window. In these situations, carefully created procedures should still be utilized to ensure minimal disruption to the organization. For instance, the policy may be to give users at least three days notice before nonemergency maintenance will be performed. Scripting can be created to send out initial e-mails to the affected parties explaining the nature of the maintenance, the likely effects, and the projected duration. A reminder e-mail might be sent again a few hours before the maintenance begins.

Emergency Maintenance

Sometimes, with or without regular maintenance windows, emergency maintenance procedures will need to take place. Again, policies should be developed ahead of time to let affected users know about the maintenance with as much time as possible in order to minimize work disruption. Keep in mind that the maintenance can potentially affect the work of hundreds or thousands of SBC users.

The rigorous testing done in the pilot and beta phases is intended to keep unscheduled downtime to an absolute minimum. In cases where it does happen, make sure the help desk has emergency response procedures in place. One option is to include a recorded message explaining the situation, the expected resolution, and the projected service restoration time. The idea is to avoid burdening the help desk or technicians with a lot of user calls reporting the same, known problem when they should be concentrating their efforts on restoring service.

Infrastructure Assessment

The beta should utilize the same hardware slated to be part of the enterprise rollout. The network infrastructure now plays a crucial role. A network problem that goes unnoticed or is tolerated under a PC-based computing environment is likely to be amplified many times under a server-based computing environment. For example, one organization we worked with had Novell servers with malfunctioning routing. Users did not notice it when running in fat-client mode. When they became completely dependent upon MetaFrame servers, the routing problems quickly became intolerable.

One intended outcome of the infrastructure assessment is to identify any network or infrastructure issues and resolve them before a beta rollout. Some problems, though, are likely to be missed. IT should be prepared to resolve them quickly as they show up. Users should understand that a beta is still an expanded pilot and that bugs will have to be worked out.

Adequate Bandwidth

Ensure that bandwidth will be adequate to remote offices where users will be part of the beta. User counts should be verified. Bandwidth management tools that actually shape WAN traffic such as Packeteer PacketShapers should be utilized, if possible. Take into consideration any additional traffic required during the transition period, and order the bandwidth accordingly.

Local Legacy System Access

In an enterprise server-based computing rollout, we recommend putting databases adjacent to the MetaFrame XP server farm. During the beta, though, this may not always be possible. Remote users may require access to local servers or host systems, but their sessions are now running on the MetaFrame XP server farm at headquarters. As Figure 10-5 shows, this means that users are accessing local servers across the WAN. Depending upon the databases and WAN bandwidth, they may experience much slower performance than they are used to. The beta participants should have their expectations set accordingly, along with the knowledge that it is a temporary problem that will be eliminated once the enterprise rollout takes place.

click to expand
Figure 10-5: Accessing legacy servers across the WAN

The other reason that legacy systems need focused attention is that they tend to be expensive or special purpose and cannot easily be run in parallel as the server-based computing project plan may dictate. These systems usually need to be "cut over" rather abruptly as they move from the old to the new environment. A separate, detailed project plan to accomplish this is required, as is a separate project team to address the special needs of these systems.

Local File Sharing

During the beta, remote users may still be allowed to share files locally. During the enterprise rollout, this practice should be eliminated wherever possible. The beta is the perfect time to start making the transition.

CD-ROM Sharing

If users at a site need to share CD-ROMs, this can be done using a small CD-ROM server or even a PC with sharing enabled. We recommend against this if it can be avoided because it is difficult to support centrally. If CD-ROMs must be shared, place a CD-ROM server at the data center nearest the user, and use groups and scripting to give the user access to the volumes as part of the login process.

Application Considerations During Beta

Make sure that all of the applications to be run via server-based computing are part of the beta. Some selection criteria include

  • The total number of people who need to run the application

  • How often the users require access to the application

  • How many users would have to remain on PCs instead of Windows terminals if you do not migrate the application

Some applications may have exhibited troublesome signs during the pilot, but it might take a beta to see how they really perform under a production environment. In this case, the problematic applications should be layered into the beta one at a time in order to minimize disruption to other applications and to users' perceptions of the SBC environment's reliability.

Apply the same rigor for testing these new applications before deploying them as part of the beta as you would if deploying them in your enterprise production environment. The beta is your last chance to work the kinks out of the testing and deployment process before going live.

User Selection During Beta

The beta should be a microcosm of the ultimate enterprise SBC environment. As with the pilot phases, users should be friendly to the concept of server-based computing. Users can be layered into the beta until all categories and groups of users are represented.

Also, be sure to get an accurate count for the number of users in remote offices. If the number is too low, the bandwidth ordered will not be sufficient. As with the production pilot, users should also be aware that they will be participating in a beta and are likely to have some performance and reliability issues come up.

Properly documenting and testing key procedures during the beta process is one of the fundamental elements to a successful large-scale SBC deployment. The documents Westaff developed were an indispensable tool, which allowed us to efficiently create over 1100 user accounts for over 260 locations. It also enabled us to maintain consistency among all accounts and helped us complete our rollout one month ahead of schedule.

—Rob Hutter,
Systems Engineering Manager, Westaff

Testing During Beta

The test lists prepared for the pilot program should be updated for the beta and utilized again. In addition, appropriate infrastructure tests for bandwidth and redundancy should be performed, and their results evaluated. The beta period is the time to hone a healthy intolerance for error. If a system is not performing as expected, it should be fixed immediately. After all, garbage doesn't smell better with age.

Service Level Agreements

Earlier in this chapter, we introduced the concept of a service level agreement (SLA) and how to use SLAs for the enterprise SBC environment. You can also apply SLAs effectively to the deployment process. They can be used to provide the pilot and beta users with the proper expectations for system stability, performance, and help desk response times, for example. It is important both to set service level agreements and to manage them. For instance, a beta user may have a problem with her newly installed ICA client. This affects her ability to participate in the beta, but it does not affect her ability to do work. The associated SLA for help desk response should reflect this by allowing enough time for over-burdened technicians to respond to more critical problems first.

Incorporating What You Learned from the Pilot Program

Now is the time to review the information collected during the pilot. Help desk call logs, user requests and comments, performance metrics, application changes performed, and system administration logs all provide a wealth of information and a platform for improvement during the beta phase.

Beta Assessment

IT must honestly assess whether the beta environment meets the production scope requirements. If not, adjustments must be made either to the technology or to the scope. Sometimes, the beta will have outcomes exceeding expectations that might also lead to scope reevaluations. For example, an organization originally intending to deploy only a couple of applications may determine that users are eager to run all of their applications in the new way. If this is the case, the beta should reflect any changes before the enterprise rollout occurs.




Citrix Metaframe Access Suite for Windows Server 2003(c) The Official Guide
Citrix Access Suite 4 for Windows Server 2003: The Official Guide, Third Edition
ISBN: 0072262893
EAN: 2147483647
Year: 2003
Pages: 158

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