ENTERPRISE ROLLOUT

All contingencies must be completed before the start of the enterprise rollout. Data centers and network upgrades should be complete. Equipment staging should be ready. Rollout teams should be ready to be deployed.

User Training During Rollout

Ensure high attendance for training sessions through management e- mails and user incentives. Be creative. Include project marketing along with the training sessions in order to reinforce initial project acceptance. Use rainbow packets, desk-side orientation, and videos . If your help desk charges users per incident, establish a grace period for free support during the conversion. As discussed previously, the amount of training necessary is likely to be limited to a short orientation to the new environment. Of much greater importance is effective marketing to get the users to embrace the change as something positive.

Expanding Service Level Agreements

Beta SLAs should be expanded to fit the conditions appropriate to a production rollout. For example, you may want to intentionally set the help desk response to a short periodsay, one hour for newly converted users, to make sure any initial problems are solved quickly.

Creating a Deployment Guide

For a large enterprise conversion to on-demand access, creating a deployment guide can be very helpful in making the process go smoothly. This is particularly important if you have a large number of remote offices requiring multiple implementation teams. Though the audience for such a guide is technically proficient, it is important to have a guide for reasons of consistency. If deployment technicians are allowed to carry out the migration their own way, it will be that much more difficult to troubleshoot problems as they arise. The deployment guide should include the following sections:

• – User communication FAQ Arm the deployment technician with answers to common questions encountered during the pilot and beta stages. This type of FAQ will help tremendously with conflict resolution and will help maintain a professional image for the technician.

• – Contact information List the appropriate contacts and phone extensions for IT staff to support specific issues, including desktop migration, printer setups, wide area network problems, and Windows terminals. The escalation paths for different types of problems should be clear.

• – Data migration procedure Spell out the specific steps for migrating data. Figure 10-4 shows a copy of the data migration procedure that ABM Industries used for their remote offices.

  
  Figure 10-4: ABM's data migration procedure guidelines

• – Client installations The deployment guide should include detailed instructions for installing each type of ICA client you intend to deploy. Each installation method should include a checklist and any relevant screen shots to make the procedure clear.

  Tip 

  Using Presentation Server Web Interface to deploy applications or a published desktop will automatically deploy the ICA client and keep it current with the latest release.

• Desktop device configuration Include a table showing all categories of users and their associated devices, such as hybrid PCs, laptops, and Windows terminals. Include a list of the appropriate equipment for each category of user, such as a monitor or network card. Include IP and DNS setup as well as things like how to set up LPD printing on Windows terminals.

• – Shadowing users Support personnel can use shadowing to take control of users' PCs or Windows terminals for troubleshooting purposes. Show how to set up shadowing, including screen prints for each step.

• – VPN or Internet dial-up connectivity Citrix Access Gateway (included with Citrix Access Suite) provides the ultimate in both security and remote access ease. If, however, remote users are connecting to the data center through a separate VPN, explain how to set up the VPN client software on a PC, configure the Windows terminal's SecureICA functions, or whatever is appropriate to your environment.

• – Printing Recap which printers are supported and which ones will work with bandwidth management devices, if appropriate. Although Citrix Presentation Server 4's printer support and generic print driver provide far more ubiquitous support than previous versions, all printing environments should still be thoroughly tested . If printers are not supported, include instructions about the proper procedures to take when such a printer is encountered during deployment.

• – IP address scheme A workable IP addressing scheme needs to be implemented if it hasn't been already. If DHCP is to be used, explain how to configure the client to take advantage of it. Document any use of Presentation Server Virtual IP Addresses.

• – General migration issues Include answers to problems that the implementation team may encounter, such as what to do if a user scheduled for migration is absent or if a user's PC is not operating properly under Citrix.

Creating Migration Databases

A large migration involves a large number of employees , all requiring current information. Developing databases to sort and track this information will significantly enhance the process. Making this database available in some ubiquitous fashion, such as Web publishing, will help assure its adoption and currency. Next we offer some ideas for different aspects of the deployment process that you should consider tracking in this way.

Locations Database

List every location and pertinent information, including current status, data connectivity status, number of users, type of users, and the implementation team assigned. The implementation, WAN, and procurement teams should update this database as part of their normal process. For example, after a user is installed, the deployment team member can connect to the locations database from the user's new client and enter the information that the user has been installed and any asset information on the equipment assigned to that user.

Change-Management Database

Track everything that changes at the data center, including new applications, printer drivers, and all unscheduled downtime. This enables much better troubleshooting of modifications causing problems. Significant changes in the field, such as large bandwidth increases , premise router changes, and the like, can also be entered here for all to see.

Survey Databases

User surveys taken at the various deployment stages can be entered and the results tracked here.

Migrating Headquarters

Converting users at headquarters to an on-demand access environment is much easier than migrating remote offices. The planning design document should cover most of the contingencies you are likely to run up against when migrating headquarters. The close proximity of these users to IT and the lack of bandwidth variables make it relatively easy to identify and remedy problems. For these reasons, it is generally advisable to migrate headquarters before migrating users at remote offices, even though the latter may have the greater need. As always, new users should be added to the Citrix environment in layers in order to minimize disruptions caused by unexpected problems.

User Training for Headquarters Migration

If IT is unable to bring users to headquarters for training before migration, they will have to rely on videos and other media such as documentation for much of the access platform orientation. A quick training procedure should be developed for the implementation team to use when they are at the site doing the conversion.

Client Operating System Upgrades

Although the Citrix Presentation Server client will operate with nearly any client, from DOS to Windows XP to LINUX, some organizations prefer to standardize on one operating system platform to make administration easier. In this case, the operating system can be migrated as part of the implementation process. Since the result will be users accessing their applications from the corporate data center, individual PC issues are a minor concern in terms of project success.

User Data Migration

It is possible to write scripts to migrate data off users' local PCs and transfer it to a centralized file server. This can be accomplished through batch files or with WSH (Windows Scripting Host).

Desktop Application Migration

In the pilot program, we recommended leaving local applications in place and moving, or removing, icons. In a production environment, we recommend eliminating applications wherever reasonable from local PCs altogether in order to ensure that users operate only in the intended on-demand access environment. There are many methods for uninstall-ing applications. Microsoft SMS has this capability or you can "roll your own," using scripting tools such as WSH and ADSI, as mentioned in Chapter 13.

Planning for Remote Office Migration

The project design document will almost certainly focus on the corporate data center and users at headquarters. Although remote offices and their users can be categorized in broad terms, the project plan is not likely to encompass specific implementation details if a large number of remote facilities are part of the project. In these cases, we recommend creating a separate implementation plan for the actual Citrix Access Suite rollout.

Assess Remote Office Infrastructure

Completing a detailed assessment of the remote office networks and environments enables much better planning and, consequently, a much smoother implementation. A good tool for this is a site survey. You can assess the infrastructure, the number of users, equipment, and any other special needs in the survey. As we will discuss later in the chapter, you will have several teams available for doing field deployments. During the inevitable periods when the team members are not in the field due to scheduling, have them perform the surveys.

Note 

You may already have a tool in place, such as Microsoft SMS, that is capable of doing hardware inventory across the WAN. This is useful but is not a substitute for a site survey. Use the polling results from SMS during the survey as part of the discussion with the people on-site, but don't treat it as gospel. Not all hardware you are interested in will respond to a poll, and you need to be as accurate as possible.

Determine Time Constraints

Since implementing Citrix is usually very economically advantageous, time is often the biggest project constraint. Establish guidelines to ensure that project timelines are met. Communicate these time limits to users before the implementation in order to help gain their support in making the migration successful. Make the time limits part of the SLA for the implementation team, and manage them. This means accurate collection of the data and publishing the results to the team. Then discuss what can be done to improve problem times.

Implementation Team Follow-Up Create a way for the implementation teams to check on the status of each time-critical item remotely. One method to accomplish this follow-up is to create an intranet site that can be accessed once the user is online.

System Implementation Time Limit Set a maximum amount of time that an implementation team member can spend on any single system to ensure that an office can be migrated in a reasonable amount of time. For instance, you may determine that converting a user to run in a Citrix Access Suite environment should take no more than an hour. If a conversion runs over an hour, the user is given a Windows terminal, and her existing data is not migrated to the data center. Though this is obviously not ideal, it will keep the project on track and only inconvenience the user in question.

PC Preparation Time Limit Set a limit, tied to the conversion time limit, on how much time to spend preparing a PC for migration. For instance, if the conversion time limit for a PC is an hour, you may wish to set a 30-minute time limit on preparing the PC.

Communication Lines If a new or upgraded WAN was put into place, confirm that the line was installed, and test connectivity before the implementation team's arrival at a remote office. Do not, under any circumstances, rely on the telecommunication provider's word that the line is in and working. Test it yourself.

User Accounts Set up user accounts in NT a minimum of one day before the installation. The help desk, in cooperation with the field deployment teams, should do the setup.

Remote Office Data Migration

In a typical conversion from client-centric to on-demand access, data will be migrated from PCs and remote office servers back to the corporate data center. Remember that the migration process can take longer than planned due to unexpected problems such as delays in the WAN implementations , conflicts in employee work schedules, and delayed shipments of hardware.

User Training for Remote Office Migration

Users should first be exposed to preliminary marketing materials and videos so that they know what to expect. The implementation team's responsibilities should include a brief user training session. Users should sign forms indicating that they have received training prior to the implementation team's departure .

In some organizations, the ability of Citrix to deliver computing capabilities inexpensively means that it will sometimes be a user's first experience with networking services, or even with using a computer. In these cases, extra thought needs to go into the training to use the PC, applications, and network in order to save the help desk from a deluge of calls.

Desktop Data Migration

There are many techniques for migrating data from PCs back to the data center, depending upon the infrastructure and service level agreements. It is important to come up with a universal method where possible. In a local area network environment, the bandwidth should be sufficient to copy the data directly to the servers. If a wide area network has sufficient bandwidth to copy files to the data center, this methodology will be the easiest to use. Your first impulse might be to copy the user data over the network to the data center. In a large, distributed organization with many offices, this could quickly cripple the network. Sometimes simple methods are the best ones. After trying many sophisticated methods, we've found the following works well:

1. Tell the users that they will have access to their current working files immediately, and the rest of the data on their hard disks in 48 hours, as part of the deployment SLA.

2. Make sure the users' accounts and logon environment are ready.

3. From the users' desktops, copy their working files across the network to the data center. The data allowance for this copy should be smallperhaps 5MB to 10MB maximum. Most users will have far less data than this.

4. Using a prepared boot disk and a parallel-attached backup device, reboot the PC and copy the contents to the removable media.

   Note 

   There are many options when deciding what to copy to the media in such an operation. If users have been using Windows for a while, most of their data is probably in the My Documents folder. Rather than guess, it is better to copy all data except the Windows directory. Program files, of course, should not be copied .

5. Send the removable media via overnight shipping to the data center.

6. Provide a brief orientation. When users log on, they should immediately have access to their working files and new applications.

7. Within 48 hours, load the removable media at the data center and copy the files into the users' directories.

Note 

If minimal filtering was done when copying the data from the client, filtering should be done when restoring the media at the data center. Consider a simple script that copies files by extension (*.XLS, *.DOC, *.WRI, etc.) to the users' new home directories. It will catch most of the data they need. If anything is missed, you still have the removable media to refer to. Store this media long enough to be sure users won't be likely to need another restore.

At ABM Industries, our engineers worked in conjunction with personnel to form six migration teams. We used Jaz drives to back up data from PCs, and tape drives to back up data from servers. We sent the drives and tapes back to the data center by overnight delivery, where they were restored to ABM's Network Appliance Filer. We had an SLA in place that guaranteed users access to their information within 48 hours of conversion to the new environment.

Migration of Server Data Data can be moved to the data center before the rollout via backup tapes. Anything that changes after that date can be moved over the WAN. Any modern backup program can do backups based on the "archive bit" of the file that is set each time a file is written to tape. A full backup of the server can be done and sent to the data center before the deployment team arrives. After all the users at that site have been converted, a differential backup (only changed files) is run and sent via overnight delivery to the data center. Those files are then restored as soon as possible. This scheme works because any file the user is currently working on is copied to the data center over the WAN for immediate access as part of that user's migration process.

Rogue Applications

Even the best planning often does not prepare implementation teams for what they face in the field. When unexpected applications are discovered , the project manager should be immediately notified, particularly if the users are scheduled to be converted to run in thin-client mode only. A decision can then be made about whether to allow access to the applications locally, or to halt the rollout and do the preparatory testing required to host the applications over Citrix Presentation Server. One technique is to migrate what you can at that office but leave one or two PCs and the local file server just for running the problem application. Establish a "sunset period" after which the equipment will be removed and the application will no longer be available or supported.

Remote Office Migration Teams

A project with many remote offices will likely require several teams to ensure a successful migration within a reasonable time period. These might include one or more implementation teams, a WAN team, and a procurement team.

Implementation Teams

Enough implementation teams should be chosen to meet the timelines for data migration. An implementation team completes the appropriate remote site surveys and submits them (online preferably) to the WAN team. The WAN team can then make sure that adequate communication lines are ordered and installed before the field team's arrival.

Choosing Team Members Desirable qualities for team members include both technical skills and training capabilities. Personality and training skills generally outweigh technical skills. Making the implementation process very simple can compensate for the lack of technical skills in implementers. On the other hand, superior technical skills do not compensate for the lack of interpersonal skills. When implementers do a good job explaining the on-demand access system, the users are more understanding when inevitable problems occur. The individual team member should be armed with skills for conflict resolution and must be familiar with the support and escalation process. Team members must also be people that the users will trust and want to work with.

Consultant/IT Staff Mix If using a consulting company to help with your migration, we recommend using a mix of internal and external consultants on each team. This provides expertise and objectivity combined with internal IT and organizational knowledge. It also provides a good, informal method of transferring knowledge from external experts to internal staff.

Facilitating Effective Teamwork It is important that the implementation teams work together and share their experiences in order to avoid making the same mistake twice. Facilitate this practice by giving each team member a cell phone and a two-way radio, by giving each member access to the corporate e-mail system, and by having members of the project management team join each implementation team for part of their trips. Scheduling weekly teleconferences for all members can be particularly useful in helping to avoid making repetitive mistakes and for sharing ways to improve the implementation process among all teams and members. These conferences can also be a forum for sharing good news and quickly improving methods when problems occur.

The Road Kit The material that each deployment team member will carry makes up the road kit. It should be well stocked, and the procedures for replenishing it should be simple and understood by team members before they visit the first site. Using our example methods described in the chapter, a road kit might contain a boot disk, a CD-RW drive, a laptop, overnight courier materials, Ethernet cables, cross-over cables, and an extra floppy drive.

WAN Team

The WAN team orders data connections and bandwidth upgrades. They confirm the installation of these lines. They order and ship any required routers or bandwidth management devices to remote sites before the implementation, or make sure the telecommunication provider does so.

Procurement Team

Responsible for the overall logistics of the project, the procurement team orders and ships the equipment. They should check to ensure receipt of the equipment at least one week before installation. The procurement team also updates the remote office surveys to reflect the new equipment and properly tracks the asset on the company's books after it has been installed. They should also process equipment returns and have the ability to quickly respond to mistakes and make sure the deployment team and the site have the equipment they need.

Deployment Challenges

Every on-demand access implementation will face unique challenges depending upon the existing environment, project scope, and technology utilized. Some issues will be impossible to anticipate. Others are fairly common and include travel, printing, local file sharing, CD-ROM sharing, and access to legacy systems from remote locations.

Tip 

Do not make assumptions. When replacing a user's PC with a Windows terminal for one of our clients , the implementation team encountered a particularly irate user. The implementation team member could not get the new terminal to communicate with the existing monitor despite hours of troubleshooting. After a second day of lost productivity, the team leader finally discovered that the monitor had never worked. The user neglected to tell the installer because he wanted to see if the new Windows terminal could fix it.

Travel

Extensive remote office implementations require dealing with issues such as travel arrangements and scheduling. Covering large geographical regions may necessitate a great deal of travel, which may in turn limit the number of willing participants on implementation teams. In addition, last-minute scheduling changes can quickly eat up the travel budget. Careful planning and control are essential in managing this project cost.

Bad Tapes or Backups

It is best not to rely on existing backup tapes. The safest procedure is not to wipe out any hard drives or recycle existing PCs until you are sure that all required data is off the PCs and on the new servers, and that the users have had the opportunity to confirm this and sign off on the operation.

Printing

Printing is covered extensively in Chapter 18. In general, try to standardize as much as possible on the printers used. In particular, try to limit the print drivers to those supported natively by Windows Server 2003. Some older printers simply will not run well under Terminal Server. Replacing these printers before the migration will eliminate the added pressure on the implementation teams of ordering new ones on-site.

Data Line Procurement

Anticipate problems in getting WAN connectivity completed according to installation promises. Plan to do more work up front in order to ensure that the data connectivity is complete before installation. Even when a local exchange carrier (LEC) confirms that a data connection is complete, take the time to test it yourself. We've seen miscommunica-tion between an LEC and a national telecommunication carrier cost a project weeks of time and thousands of dollars.

PCs

Using Presentation Server Web Interface automatically deploys and keeps the ICA client current. Otherwise, even the easy task of installing the Citrix Presentation Server client can become arduous when migrating thousands of users. In this case, the easier migration may be to simply give users a Windows terminal.

Inaccurate Site Surveys

Most organizations depend on user surveys to determine the type and state of equipment in remote offices. Impress upon the survey respondents how crucial it is for them to report this information accurately in order to avoid costly implementation delays and potential downtime. If your organization already has a tool in place that does hardware inventories, such as Microsoft SMS or HP OpenView, make sure the data is current. If possible, confirm critical items shown in the inventory, such as site routers or servers, with a phone call.