This section outlines concepts related to the migration of the actual MetaFrame servers. After you design your migration plan and strategy, at some point you will physically need to transform old MetaFrame 1.8 servers into new MetaFrame XP servers.
Migrating a MetaFrame 1.8 server to MetaFrame XP is fairly straightforward. When you run the MetaFrame XP installation program, it will automatically recognize the existing installation of MetaFrame 1.8. The installation program proceeds just like a new installation, with user input for the server farm, farm mode, and data store. There is only one real step (the last step) that needs to be considered carefully-when you are asked:
Do you want to migrate published applications?
Throughout this chapter we have reviewed the benefits and challenges to automatically migrating published applications. It is important to remember that it is possible to automatically migrate a server from MetaFrame 1.8 to MetaFrame XP without migrating any of the published applications. If no published applications are migrated, the applications do remain installed on the MetaFrame server. You must then manually republish the applications with the CMC after the migration is complete. It's also possible to not migrate applications, manually republish them in XP, and still have them load-balance with identically named applications on MetaFrame 1.8 servers.
Other than the application migration question, all of the standard server migration best practices apply, including:
- Making sure you have a good backup of the server before you start anything.
- Ensuring that you have plenty of room in the Windows event logs.
- Verifying that you have recent service packs and any necessary hotfixes installed.
- Disabling logons.
You need to ensure that your source environment is a supported migration path. You can only migrate from MetaFrame 1.8 to MetaFrame XP. If you still have MetaFrame 1.0 in your environment, you will need to do a clean install of MetaFrame XP. Even so, you should not have to reinstall all of your applications. You will simply need to republish them and reconfigure security.
You also need to ensure that your target environment is a supported migration path. Remember that Feature Release 1 and 2 for MetaFrame XP cannot operate in a mixed mode farm with MetaFrame 1.8.
When performing the actual MetaFrame server migration, if server drive letters were remapped during the initial installation of MetaFrame 1.8, you should not allow MetaFrame XP to remap the drive letters (unless you want to break things).
If you're migrating the underlying operating system in addition to MetaFrame, you should upgrade the operating system first. After the operating system upgrade, perform the MetaFrame XP migration. Of course, during this migration, all users should be logged off and all Citrix management tools should be closed.
Ideally, in a mixed mode migration, you will migrate the ICA master browser first. Once that server migration is complete, it will become the ICA master browser and the zone data collector. If the zone data collector will not be the server that was the old ICA master browser, then migrate the server you want to be the zone data collector first. Basically, the first MetaFrame XP server will create whatever it needs to support a MetaFrame XP server farm. This all can be changed at a later time, but you can save configuration down the road by migrating your servers in the proper order.
If a MetaFrame 1.8 server that is set to "always attempt to become master browser" is on same subnet as a MetaFrame XP server that has a zone data collector "Most Preferred" setting, elections will occur continuously (because they will both fight each other). This is a "feature" that has been corrected in Service Pack 1 for MetaFrame XP.
Farm Migration Strategies
There are dozens of MetaFrame migration methodologies and strategies. Some are better than others and none are absolutely right or wrong.
There are many books and white papers that go through different MetaFrame migration case studies and scenarios, but these case studies always seem to be "a little too perfect" to be found in the real world. Usually they just "happen" to be an exact fit to the illustrated migration methodology.
Another problem with many of the published recommended methodologies is that most of the readers work for companies that have their own internal methodologies that must be used. There are so many different methodologies floating around. Microsoft recommends their Microsoft Solution Framework. Citrix Consulting Services has written multiple white papers touting their field-proven MetaFrame migration strategies. Online virtual support groups such as The THIN List are full of postings from people in the real world advocating different migration strategies.
In this book, rather than focusing on specific migration methodologies, we will study the elements that need to be considered for successful MetaFrame XP migrations. Remember, we are looking at this from a technical standpoint. If you are not familiar with methodologies, check into some of the resources previously mentioned.
Some people try to break down MetaFrame migrations into broad types or categories and then present the details of each migration type. For the most part, these broad migration types aren't significant. What is important is that you have a solid understanding of the technology, both from where you are in your MetaFrame 1.8 environment and where you are going in your MetaFrame XP environment. You must also understand how these two environments can work together. You need a good technical understanding of your options as well as the advantages and disadvantages of each. From there, you can develop your migration strategy based on sound technical expertise.
That being said, when looking at MetaFrame XP migrations from a technical standpoint, there are really just a few issues that need to be considered when migrating from MetaFrame 1.8 to MetaFrame XP. These issues are:
- Target XP Farm Operating Mode. Are you going to build a temporary mixed mode farm or are you going to create a new MetaFrame XP native farm, managed separately, until all 1.8 servers have been migrated?
- Users Access. What are you going to do with the users during the migration? How will they connect to the new environment?
- Farm Consolidation. Do you have multiple MetaFrame 1.8 server farms that you will consolidate into fewer XP server farms, now that XP farms have much better scalability than 1.8?
- Other Upgrades. Are you going to upgrade the operating systems of your MetaFrame servers along with the MetaFrame migration? How about Active Directory?
- Server Migration. Are you getting all new servers for XP? If not, are you going to upgrade the existing servers or wipe them clean and install XP from scratch?
- Published Application Migration. Based on the technical details and challenges presented in this chapter, are you going to migrate published applications or republish them from scratch in the new environment?
Let's examine each of these issues separately, beginning with the new MetaFrame XP server farm operating mode.
Target XP Farm Operating Mode
By now you are fully aware of the two operating modes of MetaFrame XP server farms and the advantages and disadvantages of each.
What are the Target XP Farm Operating Mode Options?
There are two main options to consider when selecting the operating mode of the new farm:
- Create a new native mode MetaFrame XP farm. Bring new XP servers into that farm as they are brought online.
- Integrate new MetaFrame XP servers into the existing MetaFrame 1.8 farm by configuring the new MetaFrame XP servers to operate in mixed mode.
Option 1. Create a new native mode MetaFrame XP farm.
Building a new MetaFrame XP environment involves creating a new MetaFrame XP server farm operating in native mode built right alongside the old farm.
Advantages of Creating a New Native MetaFrame XP Farm
- Mixed mode is not used.
- No published application migrations.
- NFuse can provide seamless client access.
- Great opportunity to overhaul your environment (spring cleaning).
Disadvantages of Creating a New Native MetaFrame XP Farm
- User access must be addressed if users are to simultaneously access both farms.
- The entire environment must be reconfigured.
- If Citrix licenses are to be upgraded, users cannot simultaneously access both farms.
Option 2. Integrate new XP servers into the existing 1.8 farm.
Other than the technology benefits discussed previously in this chapter, the following advantages and disadvantages apply to the migration method itself.
Advantages of Integrating New XP Servers into the Existing 1.8 Farm
- Licenses are pooled.
- Published applications can be load balanced across both platforms.
- The XP migration can be phased over time.
Disadvantages of Integrating New XP Servers into the Existing Farm
- Published applications cannot be modified until all servers are MetaFrame XP.
- The MetaFrame XP farm must operate in mixed mode.
- Published applications can be easily broken, due to the quirks associated with their migration.
What Factors Affect This Decision?
- Load Balanced Applications. If you have published applications that will need to be load balanced across both MetaFrame 1.8 and MetaFrame XP servers during the migration process, you must integrate new servers into the existing farm by configuring the XP servers to operate in mixed mode. If you can arrange to migrate servers in groups so that you do not need to have the same application load balanced to both platforms, then you can build a separate, new XP farm operating in native mode.
- Size of the Source Server Farm. If the source MetaFrame 1.8 server farm is large, it may not be possible to migrate all of one published application's servers at the same time. If this is the case, you must allow the new XP servers to interoperate with the existing 1.8 server farm.
- Migration Timeframe. If the migration can be done all at once, then the MetaFrame XP servers can operate in native mode because there will not be any legacy MetaFrame 1.8 servers.
- Frequency of Changes to Published Applications. Published applications cannot be added, altered, or modified if some of the servers they are published to have been migrated to XP while others have not, even if the new XP farm is operating in mixed mode. If you will need to modify or add published applications during the migration process, then you must create a new, unrelated MetaFrame XP farm and manually modify the applications in each separate environment.
- Licensing. If you intend to create a new native XP farm that does not integrate into the existing farm, users accessing published applications from both platforms will require two Citrix licenses - one for the 1.8 environment and one for the XP environment. This can be avoided by building a mixed mode XP farm or by signing a volume licensing agreement with Citrix.
User Access during the Migration
When adopting a new MetaFrame XP environment, it's important that the people using the system are not forgotten. Are the users going to need to access two different server farms during the migration? How will the users' ICA clients be configured to access the new MetaFrame XP environment?
What are the User Access Options during the Migration?
- Use NFuse.
- Use the Traditional ICA Client.
Option 1. Use NFuse
NFuse can be used to provide simultaneous access to both the source farms and the new target farms for MetaFrame migrations. Because NFuse runs on servers, NFuse web pages can be easily changed to provide access to different or multiple server farms. This can have the effect of migrating thousands of clients just by changing the farm configuration parameter of one NFuse server. NFuse web pages can be customized to fit any environment, even providing quick and easy user access to multiple, totally unrelated server farms.
Advantages of Using NFuse During the Migration
- Single point of configuration for all users.
- Provides seamless access to multiple server farms.
- Allows for quick transition to a new farm environment.
Disadvantages of Using NFuse During the Migration
- Learning curve (for users and administrators) if it is not currently in use.
- Requires MetaFrame 1.8 Feature Release 1 in order to use it for source 1.8 farms.
Option 2. Use the Traditional ICA Client
Many companies today use the traditional ICA client to access MetaFrame servers. While the ICA client is popular, the fact that a local copy of it exists on each and every client device can make it a nightmare to reconfigure on an enterprise basis. Many companies resort to sending out email attachments with scripts that change local .INI files. It is also difficult to use when connecting to more than one server farm. Through Program Neighborhood, a user is forced to back out of one application set and to enter another when looking for an application that resides on a different server farm.
Advantages of Using the Traditional ICA Client During the Migration
- Most users are familiar with it.
Disadvantages of Using the Traditional ICA Client During the Migration
- Users must access different farms via multiple Application Sets.
- Complex or manual configuration.
What Factors Affect this Decision?
- User Access during the Migration. If users will not need to simultaneously access both the new and the old farms, there are no additional design concerns. However, if users will need to access both the new and the old environments, considerations must be made.
- XP Target Farm Mode of Operation. If the XP target farm will operate in mixed mode along with the old farm during the migration, users will only need to access one application set. However, if the new XP server farm is configured for native mode, then users will need to be able to access the old farm and the new farm at the same time.
- Current User Access to the MetaFrame 1.8 Servers. Are users currently using NFuse or traditional clients? If everyone currently uses traditional clients and you want them to use NFuse, then NFuse must be built and configured. The end users also must be trained to use it.
- Planned User Access to the MetaFrame XP Servers. Will users be using NFuse or will they access the servers via the traditional ICA client? The method used during the migration should match what they're used to in the current environment, or what is planned for the new environment.
Many current environments in which MetaFrame is in use consist of several small, non-connected MetaFrame 1.8 server farms. Often these farms are owned and controlled by different groups within the company. Time and money is wasted administering multiple, unnecessary server farms. When migrating to MetaFrame XP, companies often decide to consolidate MetaFrame server farms. This does not mean that they eliminate MetaFrame servers, nor does it mean that they physically consolidate the servers into fewer locations. It simply means that companies understand that MetaFrame XP server farms can scale much larger than MetaFrame 1.8 server farms. Certain economies of scale can be attained by creating larger server farms that include all of the servers.
What are the Server Farm Consolidation Options?
- Consolidate server farms.
- Create multiple XP server farms, one for each 1.8 farm.
Option 1. Consolidate Server Farms
Consolidating server farms might save money by not requiring that users have multiple licenses to access multiple farms, but fewer farms can mean less flexibility as well. Because farms are essentially managed together as one unit, individual MetaFrame options are not as freely applied to specific servers. MetaFrame XP server farms can scale to support hundreds of servers worldwide, but rarely in the real world would such an environment be managed by one group. More likely, companies will create multiple farms that can be individually managed by local administrators.
Advantages of Consolidating Server Farms During the Migration
- Fewer farms to administer.
- Fewer ICA connection licenses required.
- Since you are touching all of the servers anyway, it's a good time to change their farm configuration.
Disadvantages of Consolidating Server Farms During the Migration
- Administration cannot be granular.
- Less flexible.
Option 2. Create Multiple XP Farms
Creating multiple XP server farms allows for a flexible, supportable environment-but one that could get expensive to keep legal. The politics of many organizations force them to adopt a server farm model that allows for local administration of servers, and in the MetaFrame XP world, that means creating multiple server farms. While this allows local administrators to have the autonomy that they desire, it also increases the chances that work efforts are being duplicated within the organization. This model also does not allow the enforcement of corporate standards in MetaFrame implementation.
Advantages of Creating Multiple XP Farms in the New Environment
- Administration can be distributed.
- The old MetaFrame XP farm boundaries will remain the same.
Disadvantages of Creating Multiple XP Farms in the New Environment
- More administrative overhead.
- Individual licenses must be used for each farm.
- Access methods must allow for the seamless access to multiple farms.
- Difficult to enforce corporate standards.
Real World Hidden Option 3. Hybrid Approach
In the real world, many organizations adopt a hybrid approach to the migration of server farms. They choose to consolidate many similar farms into one "corporate wide applications" farm, while allowing local farms to exist with custom applications. An NFuse interface can provide seamless access to all farms for all users.
What Factors Affect this Decision?
- MetaFrame Server Management. How are the current server farms managed? If they're all managed by one group, server farm consolidation is extremely attractive. On the other hand, if different departments or different business units each manage their own server farms, consolidation is probably not the answer, especially considering that MetaFrame XP server farm administration is "all or nothing" for the entire farm.
- Application Scopes. Will end users need to access applications from many different server farms or do end users only access their own local server farms?
- Licensing. Citrix ICA connection licenses used in MetaFrame XP are not valid for servers in multiple server farms. That is, one user connecting to two servers from separate farms requires two licenses. If users will need to access many applications from multiple farms, consolidation may save licensing costs. Of course, many companies are signing Enterprise Agreements with Citrix, eliminating the licensing issue.
Other Product Upgrades / Migrations
Often, when performing a major migration, such as MetaFrame 1.8 to MetaFrame XP, organizations decide to upgrade other components at the same time. These components are sometimes required by or related to the core product migration and are sometimes totally unrelated. A good example of this is that many companies' source environments in MetaFrame migrations are built on Windows NT 4.0; they decide to upgrade to Windows 2000 as part of the MetaFrame XP migration.
What are the Options for Upgrading Other Products?
- Migrate, update, repair, patch, fix, or otherwise change additional, non-Citrix, non-MetaFrame XP-related components.
- Perform the MetaFrame XP migration without updating anything else.
Option 1. Migrate Other Components with MetaFrame.
This refers to other, non-MetaFrame components. For example, many companies choose to upgrade the underlying MetaFrame server operating system from Windows NT 4 to Windows 2000 when they adopt MetaFrame XP. Some companies choose to begin using Active Directory at this time, and others will begin using a new network segment or switch.
Migrating other server components along with MetaFrame can efficiently use the server downtime that is already planned. It also can allow the MetaFrame XP environment to significantly impact end users, by having other components upgraded that further enhance the user experience.
The main downside to many of these tertiary migrations is that they are outside the scope of the core MetaFrame environment. Can the MetaFrame XP migration afford to be slowed down by upgrading other server components? What happens if there is a failure involving the other, non-MetaFrame components? Will the MetaFrame XP migration be perceived as a failure because the Active Directory team didn't prepare well enough, and just the Active Directory failed?
Advantages of Migrating Other Components with MetaFrame
- Efficient use of server downtime that is already planned.
- Allows the addition of other components that may positively impact end users' experience.
Disadvantages of Migrating Other Components with MetaFrame
- May increase time needed to perform the MetaFrame migration.
- Increased risk of a failed component of the update.
Option 2. Migrate MetaFrame Only.
Pure and simple, you can choose to migrate the MetaFrame components of the servers only. This is a good option for large organizations in which different people or groups own different parts of the environment. For example, the person doing the MetaFrame migration is probably responsible only for MetaFrame-someone else maintains the server operating system, a different group maintains the applications, etc.
Advantages of Migrating MetaFrame Only
- Fastest migration times.
- Least risk.
Disadvantages of Migrating MetaFrame Only
Missed opportunities for other product updates.
What Factors Affect Other Product Upgrade Decisions?
- Political Impact. Are there any political advantages or disadvantages to upgrading non-Citrix components? Is one group going to be offended if you don't follow its recommendations for some components of the MetaFrame XP servers?
- Risk. What happens if one of the non-MetaFrame components breaks the server or causes extended migration times? Will people look to the MetaFrame XP server as the culprit? Or a failure?
- Is it broken now? The old adage "if it ain't broke, don't fix it" applies here. Should you take on new or updated components if there were no problems with the old environment?
When considering strategies to migrate to MetaFrame XP, at some point you must convert the actual servers from MetaFrame 1.8 to MetaFrame XP.
What are the Server Migration Options?
There are two different methods that can be used to migrate MetaFrame 1.8 servers to MetaFrame XP.
- Upgrade the current software to MetaFrame XP.
- Reformat the hard drive and start over, installing the operating system and MetaFrame XP from scratch.
Option 1. Upgrade to MetaFrame XP.
Performing an upgrade from MetaFrame 1.8 to MetaFrame XP takes the least amount of effort. Your upgraded MetaFrame XP server will maintain all of the applications, settings, and configurations of the old environment. Of course, it will also maintain all of the quirks, misconfigurations, and history of the old environment.
Advantages of Performing a MetaFrame Upgrade
- Maintains previous environment.
Disadvantages of Performing a MetaFrame Upgrade
- Maintains previous environment.
Option 2. Install MetaFrame XP from Scratch.
Installing MetaFrame XP from scratch on new servers will yield the most pristine environment. This does not mean that you need to physically procure new servers. Many companies pull existing servers out of the rotation, wipe them clean, and install everything anew. Your environment will be configured perfectly the way you want it, but you will pay for that with the time and effort it takes to perform the reinstallation.
Advantages of Installing MetaFrame XP from Scratch
- Fresh install.
Disadvantages of Installing MetaFrame XP from Scratch
- Everything must be reconfigured.
- Time consuming.
What Factors Affect this Decision?
- Current Server Standards. Do server standards exist for the server environment? These standards might include partition sizes, drive letters, and naming conventions.
- Server / Standards Alignment. Assuming that you have server standards, how closely does the server in question line up with those standards?
- Server Stability. Is the current server stable or are there quirks? It may not be worth taking the time to reinstall everything if the current server works well.
Published Application Migration
When you upgrade servers from MetaFrame 1.8 to MetaFrame XP, you have the choice as to whether you will migrate the existing published applications or republish them manually in the new environment.
What are the Published Application Migration Options?
- Migrate published applications to XP.
- Manually republish applications in XP.
Option 1. Migrate Applications.
Migrating published applications is a way to save time when migrating a server to MetaFrame XP. Problems can arise; however, if your entire farm migration is scheduled to take some time and you need to modify or add any published applications after the first server has been migrated but before the last. In this case, it's better to not migrate any published applications and just manage them separately on each platform. Remember, just because you don't migrate an application doesn't mean that you can't load balance it across new and old servers. You can always republish an application manually in the new server farm with the same name as the application in the old farm, which will cause it to load balance between the two.
Advantages of Migrating Applications
- Applications do not need to be reconfigured in the new farm.
Disadvantages of Migrating Applications
- Migrated applications cannot be modified until all servers have been migrated.
Option 2. Do Not Migrate Applications.
Choosing not to automatically migrate any published applications is the conservative, safest approach. Migrating applications does not really save too much time unless you have a long, complex user access list.
Advantages of not Migrating Applications
- Low risk of breaking applications.
Disadvantages of not Migrating Applications
- Applications must be manually republished in the new farm.
What Factors Affect this Decision?
- Target Farm Operability Mode. If the target farm is operating in native mode, you won't have to worry about your published applications because they won't interact with the old MetaFrame 1.8 anyway.
- Migration Timeframe. If the timeframe of your migration is short, you don't have to worry about trying to manage your applications during the migration; you can choose to automatically migrate the applications. If your migration is planned to take awhile, then you need to consider whether or not you'll need to modify or add any published applications.