Chapter 2 - Planning a CATIA UNIX to Windows Migration

On This Page

Overview
Planning Installation
Planning for Windows Version
Planning Hardware
Planning for Data Migration
Planning for Support Services
Planning Custom Application and Script Migration
Choosing Interoperability Solutions
Summary

Overview

CATIA V5 is the first version of the application that can run on Microsoft Windows as well as UNIX. This guide aims to help those considering upgrading from V4 or moving from a UNIX operating system environment to Windows.

Your existing CATIA system may be of a small scale, with fewer than 10 users and a small number of product designs. Such environments are likely to be comparatively easy to migrate and may encounter only a few of the obstacles outlined in this guide. If, however, you have hundreds or thousands of CATIA users, large quantities of data, and a distributed network with many desktop computers and servers, your migration project is likely to take longer, be more complex, and experience technical challenges.

In both cases, however, administrators or developers who have responsibility for completing migration projects can gain an advantage with thorough preparation. Before you make any change to the actual environment, it is strongly recommended that you create a detailed plan describing every phase of the project. If you do not plan well, you may make mistakes that are costly and time consuming to repair and you may have a detrimental impact on the productivity of your designers. In the worst case scenario, you might have to resort to disaster recovery in order to return your system to a usable state.

This guide is structured in such a way as to encourage you to plan as much as possible before any practical action is taken. To this end, the step-by-step procedures needed to perform the migration are not described until after the concepts and design decisions relevant to those procedures have been covered.

It is strongly recommended that you document your migration plan fully from the earliest stages to the final revisions, and that the IT Department consult end users prior to finalizing the plan. For more information regarding process phases and roles, see the UNIX Migration Project Guide.

Planning Installation

The first issue to consider when planning a CATIA migration is your approach to installation. Two major strategies are possible:

• Local Installation. CATIA is installed on every workstation where it will be used.

• Code Server Installation. CATIA is installed on a centralized server and shared. A user at a workstation connects to the server to run the application.

A detailed examination of these two methods appears in the following sections.

Features of a Local Installation

This style of installation is very much like that of a traditional office application such as Microsoft Word or Excel. The installation must be performed at each computer by an administrator or a user with sufficient knowledge to answer the questions in the installation wizard correctly. After this has been done, CATIA has all the resources it needs to run on the local computer. CATIA data files can be saved to, and opened from, a file server, so that there is a centralized repository for data.

CATIA is not a lightweight application, and an installation typically requires one to two gigabytes of disk space, not including the space required to store working data. However, as workstations continue to advance, disk space becomes more freely available, so this problem is typically less acute with up-to-date computers.

Installation takes time and, with local installation, must be performed on every CATIA workstation. If you have a large number of computers, you may consider this load to be prohibitive. Bear in mind, however, that this installation can be automated using a variety of tools, some of which are from Microsoft, and some others from third parties.

Advantages of Local Installation:

• CATIA starts up rapidly and performs well because all the CATIA executable files are on the local computer,

• CATIA can be run without generating any network traffic at all. Of course, if data files are stored on file servers, opening and saving files does generate traffic, but this will typically be less than that generated with a code server installation.

Disadvantages of Local Installation:

• A large amount of disk space, between one and two gigabytes, on each workstation is devoted to CATIA executables.

• A lengthy installation must be performed on every workstation. This may require a great deal of administrative time with a medium or large user base.

• Although local installation can be automated, automation involves installation across the network, which can generate a significant amount of network traffic.

• Any service pack or hotfix to CATIA must be deployed to all workstations in the same manner as the initial installation. This process can also, however, be automated.

The above disadvantages usually become more acute as the size of your environment increases. With only 10 users, manual installation is practical and simple. With 100 users, local installation may still be considered practical if it is automated. When you have a user base of hundreds or thousands, consider a code server installation carefully.

Features of a Code Server Installation

In this configuration, the installation is performed not on each workstation, but on a central server. When a user runs CATIA, he or she connects to the code server, downloads the executables into local memory, and runs them there. You can serve code to 20 or 30 workstations from a single server, depending on the performance of the server and network.

Code serving clearly reduces the work necessary to set up the system because a single installation is sufficient for many users. It does, however, have drawbacks, such as the greater network traffic often generated when CATIA is started. A small setup is required on each workstation, including components such as shortcuts and fonts.

Advantages of Code Server Installation:

• Installation time is reduced, particularly in large environments with many users.

• Administration is reduced because the configuration is stored once on the code server and not on each workstation.

• The deployment of service packs and upgrades is eased because they have to be installed only on the code server.

• Little or no network traffic is generated during the installation.

• Users can easily use a previous version of CATIA by connecting to a different share.

Disadvantages of Code Server Installation:

• Network traffic is increased, particularly because CATIA is started by users.

• When serving a significant number of users, the load placed on the server is high. Thus it should be a dedicated server, separate from those for file serving, authentication, and other functions.

• If the code server is unavailable, CATIA will not run.

The network traffic generated by code serving can be alleviated using Offline Folders. This built-in feature of Windows 2000 and later was originally intended to allow laptop users to work on a cached copy of shared files while offline and to automatically upload their changes to the file server on reconnection. When used with a code server, this local cache of executable files can be used to run CATIA with much less network traffic than is otherwise necessary. This also improves the speed with which CATIA starts and allows the performance to rival that of a local installation.

The workstations must clearly connect to the code server in order to run CATIA. If the server fails, problems ensue. However, by using the Distributed File System (Dfs)—a Windows 2000 feature—the system can be made resilient to such failures. With Dfs, workstations automatically locate a code server to run the application. Should one fail, clients are automatically redirected to another. This configuration also allows some load balancing between code servers, and this improves scalability.

You will find a thorough examination of the behavior of a code server CATIA system in the Appendix. With a combination of Offline Folders and Dfs, the performance of this configuration can be improved to the point where it compares well with local installation. This configuration is recommended for all but the smallest CATIA environments.

The Use of Packaging and Deployment Tools

In local installation, a large and lengthy installation must be performed manually on each workstation. Automating the installation is of great importance and is strongly recommended. Even with a code server installation, a small number of components must be installed on workstations, and so automation is still helpful.

Automated installation techniques share a common methodology. A package containing all the components and configurations of the application is created. It may also contain other applications, or even the workstation operating system itself. The package is made available from a file server and is distributed to client workstations where the installation proceeds with no interaction from the local user.

A detailed discussion of automated packaging and deployment tools is found in Chapter 3, CATIA Local Installation. A brief summary of common tools appears in the following list.

• Unattended Installation of CATIA. A model installation is done to create an answer file to be used in subsequent unattended installations. These can be triggered with a script run at user logon.

• SYSDIFF. This Microsoft tool can be used to record the differences that CATIA installation makes to a workstation. These differences can be included in an unattended installation of Windows.

• MSI Files. These packages are used by the Windows installer service to set up applications. However, because they are provided with CATIA, you must create them with a third party tool such as OnDemand WinINSTALL or InstallShield AdminStudio. Once they are created, Group Policy, a feature of Active Directory, can be used to easily roll them out.

• Symantec Ghost. This application allows you to take and store snapshots of a computer and its software. A Ghost image includes both operating system and applications such as CATIA. A Ghost AutoInstall package includes only applications and can be added to a workstation after the operating system is installed. Symantec Ghost includes the Ghost Console, an application that automates the deployment of these files to workstations.

When deploying packages, be careful about network traffic. If many users are installing CATIA simultaneously, the load placed on the network and the file servers can be huge. Ensure that the package is deployed in phases to small groups of users. This also allows you to test carefully and detect problems when they affect only a small number of users.

Planning for Windows Version

One of the factors to be considered while migrating to Windows is to choose the proper version of the operating system. CATIA can be installed on either Windows XP or Windows 2000 or Windows NT 4.0. The minimum requirement for CATIA V5 Release 11 is Windows 2000 SP2.

When using CATIA V5, the features provided by Windows XP and Windows 2000 include:

• Windows XP supports a maximum of 3GB of memory space allocation to any Windows application, including CATIA; Windows 2000 supports a maximum of 2GB memory.

• Windows XP provides good support for laptops.

• Windows XP provides features, such as remote desktop and remote assistance, that help in remotely accessing the desktop from any location within the corporate network or from home with VPN connectivity.

• Corporate standard of Windows version can be used for running CATIA.

• Existing hardware can be reused.

Planning Hardware

Before deploying CATIA, be aware of the load it is likely to place on your hardware. With this knowledge you can ensure that the system responds rapidly to user requests and does not become swamped.

Workstations in a Local Installation

If you have selected the local installation configuration already described, the load is placed largely on workstation computers. The following is the recommended hardware specification:

Workstations:

CATIA uses significant CPU and memory resources, particularly with complex projects or many simultaneous tasks. The minimum free disk space required for installation is two gigabytes, but keep in mind that a similar amount is used by the operating system, and other applications and data files also have demands.

Workstations and Code Servers

In a code server installation, disk space on the workstations is less important than for a local installation. However local disk space will be used if you have enabled Offline Folders for the performance improvements it offers. CPU and memory are heavily used, just as in a local installation, because the executables are run on the workstation. A fast network card will help performance greatly:

Workstations:

A great deal of load is placed on all aspects of the code servers hardware. The following configuration, however, should scale to at least 24 clients before network traffic becomes a limiting factor:

Code Servers:

These recommendations should only be used as rules of thumb because the behavior of users can vary significantly. You can obtain further guidance by observing the behaviour of your existing system. Once the migration is complete, monitor the performance of your servers and workstations to be sure that performance is optimized.

For details of the tests performed on code serving that produced these guidelines, see the Appendix.

Planning for Data Migration

Two major factors must be considered when migrating from a CATIA V4 system running UNIX to a V5 system on Windows:

• There are differences between the way UNIX and Windows store data. This factor includes the issue of file names, which are case sensitive in UNIX and insensitive in Windows.

• There are differences in the data files used by CATIA V4 and V5. The upgrade process requires data to be in CATIA version 4.1.8 or later. Because file storage has changed significantly in V5, certain file types can take several stages to upgrade smoothly.

Note: V4 data has to be upgraded to V5 format only if changes are to be made to the data. CATIA V5 can read all V4 data.

Planning for Support Services

Three supporting services may be necessary to support a CATIA V5 migrated environment, and you should consider them when creating your project plan. First, you must plan the method for tracking licenses and ensuring legal operation. IBMs License Use Management (LUM) tool is helpful for this.

The second supporting system is a scalable printing and plotting solution. CATIA provides the advanced Product Life cycle Management (PLM) environment for this.

Finally, with a large and distributed user base, a good set of collaboration tools is necessary to help designers communicate with and assist one another. Microsoft NetMeeting, for example, is a video and data conferencing tool that can achieve this.

For more detailed information about planning these services, see Chapter 5, Setting Up Supporting Services.

Planning Custom Application and Script Migration

Many existing CATIA systems include some form of customization. Unusual requirements or methods used by your organization can be automated and modeled by adding your own custom code to the application.

This code takes time and investment to develop, so it is often preferable to avoid discarding it and beginning from scratch after a CATIA migration.

If your code is written in a compiled language, such as C or C++, it can be migrated by simply recompiling it for the Windows platform. This is called a quick port. However, most complex UNIX applications will need some adaptation or rewriting in order to work properly on Windows. This process is called a full port. A quick port is often the first step used to indicate which areas of the application function incorrectly and to direct developers to problems.

Although porting code is comparatively quick and convenient, a complete rewrite can bring great benefits. Because this code is written explicitly for Windows, it can make use of features exclusive to the Windows development environment. This code frequently performs better than ported code. When planning compiled code migration, consider the importance of the application: How frequently is it used? How many users use it? Is the application involved in mission-critical processes?

If your customizations are in the form of scripts (non-compiled text files in various languages), you can frequently move them to Windows with little or no rewriting. This is because many popular scripting languages in UNIX, including Perl, php, and many shell scripts, can be supported in Windows. Support for some of these languages, such as JavaScript, is included in Windows as part of the Windows Scripting Host. Other languages can be supported by installing a third party script interpreter, such as ActiveStates ActivePerl.

The Microsoft Interix environment included with Microsoft Services for UNIX 3.0 can help with both compiled and script code. It provides an environment that simulates UNIX on Windows and allows code to be run with little or no rewriting.

When planning for the migration of custom applications, be sure to include an extensive phase of testing and troubleshooting to avoid impacting productivity on the production system. All aspects of the application should have been successfully tested before it is made available to users.

Choosing Interoperability Solutions

CATIA V4 runs only on UNIX, and CATIA V5 runs on both UNIX and Windows. If you are migrating to CATIA V5 and do not plan to discard your old system and data entirely, it is essential that UNIX and Windows are able to communicate with each other. Even with a small and simple system, some communication is needed to copy data from UNIX to Windows. With larger systems, the migration may take months or, when you have other uses for UNIX, the two operating systems may need to exist side by side indefinitely.

There are three main areas of interoperability between these two operating systems:

• Connectivity. This is the ability to connect from UNIX to Windows (or the other way around) for the purposes of running a command or program. If you wish to run a command line program, this can be done with a simple text-based system such as telnet. Running a full version of CATIA on the remote system, however, requires a graphical user interface (GUI). Such remote GUIs can be provided by X Windows, Terminal Services, or third-party tools.

• Authentication and Authorization. Both UNIX and Windows have security systems to identify users and restrict their activities. If these systems are not integrated properly, large security loopholes can arise.

• Resource Sharing. The two operating systems protocols used in file serving are complementary but incompatible. Therefore, you must plan to access a UNIX file server from Windows and a Windows file server from UNIX. Common Internet File System (CIFS), also known as Server Message Block (SMB), is the native Windows file sharing protocol; its equivalent in UNIX is Network File System (NFS). The Samba CIFS server can be run on UNIX, and there are NFS Servers, such as Microsoft Services for UNIX 3.0 (SFU), which run on Windows.

The following section provides an overview of possible strategies and discusses factors that may influence your design decisions.

For example, an administrator might decide that users require only telnet access to the UNIX servers from their Windows-based computers to run a script that manipulates CATIA data files. However, one specific X Windows application might need to be referenced during the migration. In this case, a limited tactical implementation of X Windows servers for specific users might be appropriate, even though it is not in the strategic plan. To help you prepare for contingencies such as this, the following list presents major strategic considerations to address in your plan.

• Ease of use. The solution should be as easy to use as possible. The importance of this factor depends on the skills of target users.

• Ease of administration. The solution should be easy to administer. When administrative tasks are relatively few, the system will be more cost-effective.

• Transparency in the target environment (Windows). This issue is closely linked to ease of use. Because the target environment is Windows, the interoperability solution should preferably have the look and feel of Windows.

• Lifetime of the UNIX environment. The UNIX environment does not disappear overnight. In some migrations, a cross-platform, heterogeneous environment may continue for years. In others, the UNIX environment phases out after the migration is complete. The level of integration required for short-term or long-term interoperability is quite different.

• Cost. A cost-benefit analysis is always needed. Be sure to include costs for administration and configuration, which even freeware solutions such as Samba will incur.

• Functionality. The technical features of an interoperability solution must meet the requirements of the users.

These considerations will inform your decision regarding your target environment.

Summary

More detailed design decisions are covered in subsequent chapters.

In all aspects of planning, the principal factors that affect your decisions include the following:

• Budget. For example, any method of automating repetitive tasks should save time and therefore money.

• User numbers. For example, local installation is usually only practical with a small user base.

• Distribution of users. For example, if your design department is spread across the country or globe, you must ensure that CATIA is accessible wherever it is needed.

• Network traffic. For example, code serving can generate large volumes of network traffic. Offline Folders, however, can be used to alleviate the problem.

A thorough and carefully considered planning phase of your migration project will pay. Mistakes should be few, expenses can be predicted, and the impact on productivity will be minimized.

Disclaimer and Copyright Information

CATIA is a registered trademark of Dassault Systemes SA. The names of other actual companies and products mentioned herein may be the trademarks of their respective owners.