Solution Accelerator for UNIX Migration

Solution Guide for

CATIA Migration from UNIX to Windows

Version 1.0

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part
of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for
informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS
DOCUMENT.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and
events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place or event is intended or should be interred.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not
give you any license to these patents, trademarks, copyrights, or other intellectual property.

2003 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BackOffice, Biztalk, Network Applicance, Visual Basic, Visual SourceSafe, Visual Studio, Windows, and
Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
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.

Table of Contents
Chapter 1: Introduction .................................................................................................................... 1
Overview ...................................................................................................................................... 1
About CATIA V5 ....................................................................................................................... 1
CATIA V5 on Windows............................................................................................................. 2
Audience ...................................................................................................................................... 3
What You Must Know .................................................................................................................. 4
How to Use This Guide ................................................................................................................ 5
How This Guide Is Organized ...................................................................................................... 6
Chapter 2: Planning a CATIA UNIX to Windows Migration............................................................. 7
Planning Installation..................................................................................................................... 8
Features of a Local Installation ................................................................................................ 8
Features of a Code Server Installation..................................................................................... 9
The Use of Packaging and Deployment Tools....................................................................... 10
Planning for Windows Version ................................................................................................... 11
Planning Hardware .................................................................................................................... 12
Workstations in a Local Installation ........................................................................................ 12
Workstations and Code Servers............................................................................................. 12
Planning for Data Migration ....................................................................................................... 14
Planning Custom Application and Script Migration.................................................................... 15
Choosing Interoperability Solutions ........................................................................................... 16
Summary.................................................................................................................................... 18
Chapter 3: CATIA Local Installation .............................................................................................. 19
Preparing for Local Installation .................................................................................................. 20
Need for Packaging................................................................................................................ 20
A Comparison of Packaging Tools......................................................................................... 20
A Comparison of Deployment Techniques............................................................................. 24
Deployment of Service Packs, Hotfixes, and Rollbacks ........................................................ 27
Methodologies............................................................................................................................ 28
Single Workstation Installation ............................................................................................... 28
Packaging Options ................................................................................................................. 28
Deployment Options............................................................................................................... 37
Installation Validation ............................................................................................................. 48
Summary.................................................................................................................................... 49
Chapter 4: CATIA Code Server Installation................................................................................... 51
Preparing for Code Server Installation....................................................................................... 52
General Architecture .............................................................................................................. 52
Server-side Installation........................................................................................................... 53
Client-side Installation ............................................................................................................ 54
Client-side MSI Package Creation ......................................................................................... 55
Deployment of MSI Packages ................................................................................................ 56
Multiple Releases of CATIA V5 on the Same Workstation .................................................... 56
Rollback of CATIA V5............................................................................................................. 57
Offline Folders ........................................................................................................................ 57
Using Multiple Code Servers with Dfs.................................................................................... 58
Performance of Code Serving ................................................................................................ 58
Methodologies............................................................................................................................ 59
Server-side Installation Process............................................................................................. 59

Client-side Installation Process .............................................................................................. 61

Client-side MSI Package Creation Process ........................................................................... 63
Offline Folders ........................................................................................................................ 70
Multiple Code Serving with Dfs .............................................................................................. 71
Installation Validation ................................................................................................................. 74
Offline Folders ........................................................................................................................ 74
CATIA V5................................................................................................................................ 74
Summary.................................................................................................................................... 77
Chapter 5: Setting up Supporting Services ................................................................................... 79
Preparing for Supporting Services............................................................................................. 80
License Management ............................................................................................................. 80
Printer / Plotter Configuration ................................................................................................. 81
Collaboration .......................................................................................................................... 81
Methodologies............................................................................................................................ 84
License Management ............................................................................................................. 84
Collaboration .......................................................................................................................... 85
Installation Validation ............................................................................................................. 85
Summary.................................................................................................................................... 87
Chapter 6: CATIA Data Migration.................................................................................................. 89
Preparing for CATIA Data Migration .......................................................................................... 90
Version ................................................................................................................................... 90
File Naming Conventions ....................................................................................................... 91
Project Files (PRJ Files)......................................................................................................... 92
Cleaning and Checking Models.............................................................................................. 93
CAD Geometries .................................................................................................................... 95
Libraries/Standard Parts....................................................................................................... 102
Methodologies.......................................................................................................................... 104
Project Files.......................................................................................................................... 104
Cleaning and Checking Models............................................................................................ 107
CAD Geometries .................................................................................................................. 109
Libraries / Standard Parts..................................................................................................... 113
Summary.................................................................................................................................. 117
Chapter 7: Migrating Custom Applications and Scripts ............................................................... 119
Compiled Code Application Migration...................................................................................... 120
Options ................................................................................................................................. 120
A Mix of All Strategies .......................................................................................................... 122
UNIX Script Migration .............................................................................................................. 123
Interix.................................................................................................................................... 123
ActivePerl ............................................................................................................................. 123
Windows Scripting Host (WSH)............................................................................................ 124
Summary.................................................................................................................................. 125
Chapter 8: Windows-UNIX Interoperability and Data Sharing .................................................... 127
Windows to UNIX Connectivity ................................................................................................ 129
Terminal Emulation and Command Line Connectivity ......................................................... 129
Remote Graphical User Interfaces....................................................................................... 131
User Authentication and Authorization .................................................................................... 133
Authentication and Authorization in UNIX ............................................................................ 133
Authentication and Authorization in Windows ...................................................................... 134
Integrating UNIX and Windows Security .............................................................................. 135
Resource and Data Sharing..................................................................................................... 139
UNIX Data Sharing Environment.......................................................................................... 139
Windows Data Sharing Environment ................................................................................... 140

Network File System Interoperability.................................................................................... 140

NFS for Data Sharing ........................................................................................................... 142
Microsoft Windows Powered NAS Solution ......................................................................... 144
Summary.................................................................................................................................. 151
Chapter 9: Conclusion ................................................................................................................. 153
Appendix: Scalability, Performance, and Capacity Testing......................................................... 155
Introduction .............................................................................................................................. 155
Testing Methodology................................................................................................................ 157
Objective............................................................................................................................... 157
Configuration of Macros and Scripts .................................................................................... 157
Configuring CATIA for Tests ................................................................................................ 157
Test Environment..................................................................................................................... 159
Network Schematic Diagram................................................................................................ 160
Hardware and Software Components .................................................................................. 160
Testing Tools ........................................................................................................................ 161
Test Configuration Summary ................................................................................................... 162
Test Plan .................................................................................................................................. 163
Hardware and Software Details for Tests ................................................................................ 164
Test Results and Analysis........................................................................................................ 166
Key Statistics for Analysis .................................................................................................... 166
Scalability Test Results ........................................................................................................ 167
Analysis of Network Utilization in Tests ............................................................................... 180
Key Findings ............................................................................................................................ 182
Recommendations for Capacity Planning................................................................................ 183
Conclusion ............................................................................................................................... 184
References .................................................................................................................................. 185
UNIX and Windows Interoperability ......................................................................................... 185
Application/Script Migration from UNIX to Windows................................................................ 185
Remote Management/Resource Management........................................................................ 185
Microsoft Windows Installer ..................................................................................................... 186
Microsoft Windows 2000 Server .............................................................................................. 186
Microsoft Distributed File System ............................................................................................ 186
Microsoft Offline Folders .......................................................................................................... 186
High Performance Computing (HPC) ...................................................................................... 186
CATIA Application (Dassault Systemes 3D PLM solution) ..................................................... 187

1
Introduction
Overview
Welcome to the CATIA Migration from UNIX to Windows Guide. This guide is designed to
provide CATIA administrators, network managers, and operating system administrators
the best information available on issues that they are likely to face while planning or
implementing CATIA version 5 in Microsoft Windows operating system environments.
In addition, a significant portion of this document provides the detailed instructions to
deploy CATIA in a large engineering environment and administer it remotely and
efficiently.

About CATIA V5
CATIA version 5 is a process-centric computer-aided design/computer-assisted
manufacturing/computer-aided engineering (CAD/CAM/CAE) system that fully uses next
generation object technologies and leading edge industry standards. Seamlessly
integrated with Dassault Systemes Product Lifecycle Management (PLM) solutions, it
enables users to simulate the entire range of industrial design processes from initial
concept to product design, analysis, assembly, and maintenance. The CATIA V5 product
line covers mechanical and shape design, styling, product synthesis, equipment and
systems engineering, NC manufacturing, analysis and simulation, and industrial plant
design. In addition, CATIA Knowledgeware enables broad communities of users to easily
capture and share know-how, rules, and other intellectual property (IP) assets.
CATIA V5 builds on powerful smart modeling and morphing concepts to enable the
capture and reuse of process specifications and intelligence. The result is an easily
scaleable, Web-enabled system that covers all user requirements within the digital
extended enterprise, from the simplest design to the most complex processes. This
capability allows optimization of the entire product development process while controlling
change propagation. CATIA V5 moves beyond traditional parametric or variational
approaches, accelerating the design process and helping designers, engineers, and
manufacturers increase their speed and productivity.
CATIA V5 has an innovative and intuitive user interface that unleashes the designer's
creativity. Context-sensitive integrated workbenches provide engineers with the tools
they need for the task at hand, and they are beneficial for multi-discipline integration. The
workbenches have powerful keyboard-free direct object manipulators that maximize user
productivity.

CATIA V5 applications are based on a hybrid modeling technology. These applications

provide expanded digital product definitions, process definitions, and review functions
capable of operating on projects with any degree of design complexity. CATIA V5 has
produced domain-specific applications that have addressed global digital enterprise
requirements that span the areas of mock-up, manufacturing, plant, and operations.
CATIA V5 expands scalability across processes, functions, and platforms to deliver the
right solution to the desktop of each team member in the product development chain.
Tailored solutions meet the needs of a broad range of users, from a small supplier shop
to a large multinational corporation.

CATIA V5 on Windows
This is the first version of CATIA that can be run on either UNIX or Windows. You can
select an operating system to match your corporate IT strategy. For example, if your
other office and technical applications all run on Windows, you can move CATIA to that
environment and eliminate the need for UNIX. This system will be more convenient to
use because users can access all applications from a single workstation, and it will be
easier to administer because the integration of UNIX and Windows is no longer
necessary.
If you choose to run CATIA V5 on Windows, a number of key questions and issues will
occur: How should the installation be configured? Which Windows services will need to
be configured? How can the administrative effort involved be minimized? If you have
been running CATIA V4 on UNIX, you must consider the migration of your existing data
to the new environment and the communication between UNIX and Windows during the
migration. These are the questions and issues this guide was written to address.
The information included in this guide is gathered from consultants working in the field,
tests carried out to prove the concepts, and from customer issues that have already been
confronted and solved during migration. The amalgamation of this experience constitutes
current best practices.

Audience
This guide is intended for those companies considering, or committed to, running CATIA
V5 on Windows. Its content will interest both the Information Technology (IT) department
and, to a lesser extent, the design department.
Heads of IT, senior systems administrators, and system architects will be interested in
the design decisions involved in the entire migration process. These include both large
scale decisions, such as the choice of where to install CATIA, and more detailed choices,
such as how to migrate a particular type of CATIA data file. Design managers and senior
CATIA design engineers should help inform these decisions because of their end user
expertise, and so portions of this guide are also of interest to them. Once the project plan
has been completed, other administrators will find the step-by-step procedures helpful.

What You Must Know

Some knowledge of Windows and UNIX has been assumed. You should be aware of the
basic differences between the two environments, such as path syntax, file name
conventions, the storage of configuration information, and network communication
protocols.
Chapter 6, CATIA Data Migration, requires a detailed knowledge of CATIA V4 data files
and a little of V5. Chapter 7, Migration Custom Applications and Scripts, provides an
introduction to methods for moving customized UNIX-based code to Windows. This
chapter can be read by those with little or no development experience, although expert
coders are required to perform the migration.

How to Use This Guide

The move to CATIA V5 is likely to be a complex process, presenting many challenges,
even in a relatively small organization. With this in mind, the importance of thoroughly
planning your project before executing it cannot be over-emphasized. The guide has
been structured to discuss concepts before procedures so that you gain a thorough
understanding of all the issues to be evaluated prior to the actual migration. This should
prevent costly errors that may take great effort to correct.
Chapter 2, Planning a CATIA Unix to Windows Migration, begins with a discussion of
the top level decisions that will determine the overall flow of your migration project and
the general design of the resulting system. The design decisions made in this chapter will
affect the relevance of the content in later chapters. For example, Chapter 3, CATIA
Local Installation, will be less relevant if a decision was made after reading Chapter 2 to
use a code server installation. Each of Chapters 38 are structured so that design issues
are discussed at the beginning, followed by detailed procedural information collected in
sections titled Methodologies."
The Appendix presents extensive tests that have been performed in a laboratory
environment on a CATIA code server installation. You can use these test results to plan
hardware and software configurations that will respond quickly to user requests and to
avoid bottlenecks. The model presented in the Appendix should be consulted prior to
finalizing the migration project plan.

How This Guide Is Organized

Chapter 1 Introduction. The current chapter gives a brief overview of CATIA and
describes the purpose of this document.

Chapter 2 Planning a CATIA UNIX to Windows Migration. This chapter

discusses the major architectures that you can use to implement CATIA. The
concepts described can have far-reaching effects on the resulting system.

Chapter 3 CATIA Local Installation. If you have decided to install CATIA on

each workstation, this chapter is important. It gives further details on the
installation process and includes discussions of tools that can be used to automate
the process. These tools can save you a great deal of time if you have many
workstations.

Chapter 4 CATIA Code Server Installation. This chapter is relevant if you have
chosen to install CATIA on a centralized server to which clients will connect to run
it. The special configurations required on both server and client are described.
Methods of optimizing the performance of such a configuration are also included.

Chapter 5 Setting Up Supporting Services. Services necessary to support

CATIA operations, including license use management, printers, and conferencing
tools, are described in this chapter.

Chapter 6 CATIA Data Migration. If you have existing CATIA data files, you will
probably need to move them from UNIX to Windows and from CATIA V4 to V5.
This chapter details this migration.

Chapter 7 Migrating Custom Applications and Scripts. Techniques to migrate

custom applications and scripts are described in this chapter.

Chapter 8 UNIX-Windows Interoperability and Data Sharing. This chapter

describes the techniques you can use to communicate between the two operating
systems. You will need this information for the migration and for the longer term if
you wish both UNIX and Windows to remain in place.

Chapter 9 Conclusions. This chapter reviews key points.

Appendix Scalability, Performance, and Capacity Testing. Extensive tests

have been performed against a CATIA V5 code server system. The details and
results, presented here, can be used to correctly size your system and ensure it
can cope with user load easily.

2
Planning a CATIA UNIX to
Windows Migration
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 featurethe 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.

10

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.

11

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:
1x Intel Pentium 4 processor, 2.6 GHz (Single Processor)
512 MB RAM
1x Maxtor 6L020J1 IDE HD, 20GB, 7.2krpm
ATI Fire GL 8800 graphic adapter
t

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:
1x Intel Pentium 4 processor, 2.6 GHz (Single Processor)
512 MB RAM
100 Megabit/s network adapter
1x Maxtor 6L020J1 IDE HD, 10GB, 7.2krpm
ATI Fire GL 8800 graphic adapter

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:
Intel Xeon processors, 2.0 GHz
2 GB RAM
1 Gigabit/s network adapter
ICP Vortex GDT8523RZ RAID Controller
SCSI HD, 73GB, 10krpm (1x single, 4x RAID5)

12

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.

13

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.
If you have large quantities of data to migrate, a situation which is likely in a large implementation

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.

14

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.

15

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.

16

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.

17

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.

18

3
CATIA Local Installation
If you have chosen to install CATIA V5 software locally, you must set up the software
on each workstation where design will take place. You have the advantage that CATIA
will run quickly because all of its code is located on the local computer and CATIA will
generate relatively little network traffic. However, many local installations may increase
the administrative overhead of a CATIA system. See Chapter 2, Planning a CATIA UNIX
to Windows Migration, for a detailed discussion of these issues.
There are a number of techniques to choose from that can speed and automate local
installations, and each is described in this chapter. In addition to installation, the
management of CATIA V5 software involves upgrades, rollbacks, and sometimes running
more than one version of CATIA on the same workstation. These topics are also
described.
The chapter is divided into two major sections. Use the first, Preparing for Local
Installation, to select the techniques to use and to plan your approach. Then find stepby-step example procedures for the tool you have selected in the "Methodologies"
section.

19

Preparing for Local Installation

Need for Packaging
If your organization is small, or CATIA is used by a small number of your workers, it is
practical to install CATIA manually. Up to 10 computers can be reasonably managed this
way, but the repetitive nature of the setup and subsequent administration may persuade
you to use a packaging and distribution approach. If you decide on manual installation,
see Single Workstation Installation in the "Methodologies" section for a walk-through of
the process.
In a large organization, manually installing CATIA V5 on all workstations is not practical.
Either users must perform their own installations at the risk of incorrectly configuring
the system or the administrator has to install the product on each workstation.
A better solution is to automate installation of the product from a server, without any user
intervention. To achieve this, the CATIA installation must be packaged to create a
manageable unit for installing onto client computers. Such a package includes all CATIA
files and instructions for installation and configuration. Tools for creating packages are
described in the following section.
Once you have created a package it must be deployed to users workstations. The
methods available are covered in the section titled A Comparison of Deployment
Techniques.

A Comparison of Packaging Tools

Several tools for creating a CATIA package are described below. When making your
choice, consider the following:

20

Budget. SYSDIFF, WinINSTALL LE, and MSITool are free, and Silent Installation,
or Unattended installation, is a feature of CATIA itself. However, if you also require
advanced management features or have large numbers of workstations, you will
also need Symantec Ghost or Microsoft SMS.

Installation Time. Several of the tools described, such as Symantec Ghost,

decrease the time that is needed for installation. Installation time will be important if
you need to install CATIA on many workstations.

Server Disk Space. Any package that includes CATIA will require a large amount
of disk space to store. If the package includes an operating system as well, the
problem is compounded.

Convenience. Although SYSDIFF, for example, is free, it requires a fairly complex

setup with many command line steps. The equivalent procedure in SMS or Ghost
AutoInstall is less complicated and includes a GUI to help you.

Other Applications. You may wish to roll out other applications along with CATIA.
Many of the tools allow you to create a package containing multiple applications,
but Silent Installation, or Unattended installation, can be used only for CATIA.

Hardware. If an image includes a computers hardware drivers and configuration,

the target computers must have the same hardware as the computer of which the
image was created. A Ghost image, for example, can be deployed only to
computers with identical hardware.

Silent Installation/Unattended Installation

CATIA V5 setup supports Silent Installation (based on Installshield) until R10, and it is
replaced by use of the StartB batch installation command beginning with R11. In the
Silent Installation approach, an installation of CATIA on a client computer is automated
by providing an answer file that contains information on the desired configuration.
Because this file answers the questions usually asked during installation, the process can
proceed without being monitored by an administrator.
The process has two stages: In the first, the CATIA Setup program is run with r option.
This runs the usual installation wizard but stores the users answers in a file called, by
default, Setup.iss. In the second stage, performed on many computers around the
network, Setup is invoked again with a switch to point to Setup.iss. This setup runs
without requiring any input from an administrator.
With the Unattended installation approach using the StartB installation command,
CATIA can be installed without the graphical user interface. In the first stage, the
software is copied to a folder in the source computer, or the CDROM is simply made
available in the network. In the second stage, setup is invoked in client computers using
the StartB batch command with the required switches. This process installs the
application without user intervention.
Prerequisites
The package needs to be kept in a shared folder so that the files are available to many
client computers.

SYSDIFF
SYSDIFF.exe is one of the deployment tools provided in the Windows Resource Kit
and as a download from the Microsoft Web site. You can use it to include an application,
such as CATIA, in the installation of a desktop operating system. It can be used with
Microsoft Windows NT 4.0 and Windows 2000.
The process is as follows: The Windows installation files (the i386 directory from the
Windows CD) are copied to a shared folder on a server, known as the Distribution
Server. A desktop computer, known as the Master System, has Windows installed on it.
SYSDIFF.exe is used to create a difference file that records the changes made to the
Master System by the installation of desktop applications, which may include CATIA.
SYSDIFF.exe is then used to apply these changes to the shared installation files on
the Distribution Server. When unattended installations of Windows are later run from the
Distribution Server, they will automatically include the applications originally installed on
the Master System.
This tool is normally used to distribute CATIA only on to newly installed desktop
computers and only if the installed operating system configuration matches the OS
configuration of the Master System. However, it can automate the installation of all the
applications to be installed on desktop computers in one operation.
Prerequisites:

A master system with Windows NT 4.0 or Windows 2000 installed.

A share on the Distribution Server for the Windows i386 installation directory, the
difference file, and auxiliary files. This share must have sufficient space for all the
applications to be installed.

21

Symantec Ghost Disk Imaging

Symantecs Ghost application clones a disk drive or partition on a master system. This
can be stored in an image" that you can copy to other desktop computers known as
target computers. The image includes the operating system, all installed applications, and
configuration information. Imaging speeds the installation of the operating system and
removes the need for separate application installations. By installing CATIA on the
master system before the image is taken, you can distribute CATIA with the other
applications.
Symantec also provides the Ghost Console administrative application, which is a tool that
allows centralized control of image distribution. See the discussion of this tool in the
Deployment Options section that follows.
Prerequisites:

One clean personal computer with a hardware configuration that is identical to the
client's hardware configuration and that has CATIA V5 installed. This will be the
master computer.

At least one server and one client computer

A Symantec Ghost Server Console on the server

Symantec Ghost AI Packaging

AutoInstall (AI) is a tool provided with Symantec Ghost, as described earlier. It allows you
to create a package to distribute one or more applications, including CATIA, onto existing
operating systems. This package can then be distributed with the Ghost Console just as
images are distributed.
AI packaging can be used to distribute application updates. Once installed, these
packages can be removed quickly using the Ghost Console application.
The process involves taking snapshots of the system before and after installing the
application. The recorded differences constitute the package.
Prerequisites:

The AI packager needs Symantec Ghost Console for deployment across the
network.

AI Builder and AI Snapshot must be installed on a model computer.

The model computer should have a configuration similar to those that will receive
the finished AI package.

WinINSTALL
In Windows 2000 and later, the preferred method for installing applications is with .msi
files and the Windows Installer Service. This service finds instructions for installation
within the .msi files. Applications installed from .msi files can be automatically repaired
and smoothly removed by the service.
The Windows Installer Service can be invoked by simply double-clicking on an .msi file,
or Group Policy can be used (see Deployment Options later in this chapter).
Unfortunately, CATIA does not include an .msi file for installation. However WinINSTALL
is an application that can create these using a snapshot procedure. Now owned by
OnDemand Software, WinINSTALL was previously a VERITAS product. A free version,
WinINSTALL LE, ships with the Windows 2000 Advanced Server CD. Fully featured
versions are obtainable from OnDemand.

22

Prerequisites:

A server or workstation that contains the Discover program (part of WinINSTALL).

A minimum of 15 MB of free hard disk space on the server or workstation for the
installation of WinINSTALL.

Additional hard disk space for the application that is repackaged.

A workstation to create the package. The ideal reference computer (where the
package will be created) is a clean machine, that is, one with only the operating
system installed.

These two computers must be part of the same network.

WinINSTALL cannot create .msi files for an installation of more than 32,767 files.
Therefore, some options, like AL2 in CATIA, cannot be made into a package
properly.

MSITool Packaging
MSITool, provided by Microsoft, can be used to create Windows installer packages and is
thus a similar approach to WinINSTALL.
This tool creates a Microsoft Windows Installer (MSI) database for a single feature install.
By pointing this tool at a desired directory and following a few easy steps, you can
produce an .msi file, which may then be used to perform installations. Having installed
CATIA on one computer, you can then use the tool to create an .msi file from the CATIA
directory.
MSITool supports a sophisticated system that allows environment variables, registry
entries, and product properties to be set during an installation. MSITool provides an XMLbased method for setting up these capabilities. With an ASCII editor such as Notepad,
you can edit the example XML files provided with the tool to implement these capabilities.
A package created in this way can then be easily fine-tuned by using an MSI database
editor such as Orca.exe. This editor, downloadable from the Microsoft Web site, displays
and edits the instructions contained in an .msi file and can also validate the database.
To get the latest MSITool, contact the Application Development Service Line in the U.S.
National Practices through your local Microsoft Consulting Services practice at
http://www.microsoft.com/business/services/mcs.asp, or contact Infosys at
catiasupport@infosys.com.

Systems Management Server

Microsoft Systems Management Server (SMS) was designed as Microsofts primary tool
for software distribution. SMS can significantly reduce the time and complexity of
maintaining and upgrading software for organizations with distributed networks. You can
use SMS to install software and upgrade and configure each computer from either a
central location or from multiple locations. Individual software files or software application
suites can be scheduled and distributed to specific computers. SMS even enables
initiation of automated, unattended software distribution to selected computers.

23

Systems Management Server 2.0 offers greater control and flexibility in software
distribution than its previous versions. Built-in functionality includes the option to force a
package to run using a specified account with administrative rights on the target
computer. This is necessary when distributing to clients who either are not logged on or
when the logged on user does not have local Administrator rights on the computer.
SMS includes its own packaging tools that can be used to package an entire operating
system image, including applications such as CATIA. Alternatively, it can create
packages containing just CATIA, similar to a Ghost AI package. If you use SMS to create
a CATIA package, you must also use SMS as the deployment technique.
In addition to its software distribution features, SMS has advanced asset management
that allows you to catalog and track software and hardware and troubleshoot remotely.

A Comparison of Deployment Techniques

After you have created a package, the next step is to deploy it onto desktop computers.
Below are detailed descriptions of the distribution techniques. When selecting one,
consider the following:

Packaging Tool. Some packages require the use of their associated deployment
tools. For example, a Ghost AI package should be deployed with the Ghost
Console.

Convenience. Rshmsisvc (described later in this chapter) requires several setup

stages on the destination computers, knowledge of batch files, and knowledge of
command line techniques. SMS, by contrast, has a simple client setup and a GUI
for ease of use.

Versatility. Group Policy (described later in this chapter), for example, allows you
to define a small number of computers out of your entire enterprise and to
determine where CATIA will be installed, all from a centralized administrative
interface.

Active Directory/Group Policy

Microsoft Active Directory is a part of the Windows 2000 network architecture. It
provides a directory service designed for distributed networking environments. Active
Directory provides efficient sharing and management of information about network
resources and users. It also acts as the central authority for network security, letting the
operating system readily verify a user's identity and control their access to network
resources.
Windows 2000 (and later versions) and Active Directory provide a tool named Group
Policy that can deploy applications. By using Group Policy, you can assign software to
users and computers based on their location in the directory (for example, organizational
units, sites, or domains). The requirements to deploy software with these components
are:

24

Microsoft Windows 2000 or Windows XP clients. The Group Policy

infrastructure is available only on these two operating systems from Microsoft.
Earlier Microsoft operating systems cannot use software that uses this technology.

Active Directory. To assign software throughout the enterprise, Group Policy

settings within Active Directory need to be configured.

Group Policy is highly flexible and can roll out software to closely controlled groups of
users or computers. It is not suitable for deploying SYSDIFF installations, Ghost Images,
or Ghost AI Packages.
Group Policy is easiest to use in conjunction with an .msi file. Because CATIA does not
include an .msi file, you must create one using WinINSTALL. If this is not possible, you
could create a batch file to perform a Silent Installation or Unattended installation of
CATIA. Group Policy can be used to run such a batch file on users computers.

Remote Installation Services

The Remote Installation Service (RIS) is one of the new enhancements in Windows 2000
that provides a means to install pre-configured client workstations across the network.
RIS distributes images of operating systems and installed applications, on to client
computers and, thus, is a similar approach to the Symantec Ghost Console. It cannot be
used to deploy .msi files, Ghost Images, or Ghost AI packages because it uses its own
images. RIS can only be used to install Windows 2000 Professional or Windows XP
images.
RIS requires several other services that are also shipped as part of the Windows 2000
Server. These services can be installed on individual servers or on a single server,
depending on the network design:

Domain Name Service (DNS) Server. Remote installation relies on DNS for
locating the directory service and client computer accounts. Any Windows 2000
Active Directory service-compliant DNS server or the DNS server provided with
Windows 2000 Server can be used.

Dynamic Host Configuration Protocol (DHCP) Server. RIS requires a DHCP

server to be present and active on the network. The remote boot-enabled client
computers receive an IP address from the DHCP server before contacting RIS.

Active Directory. RIS relies on Windows 2000 Active Directory for locating
existing client computers as well as existing RIS servers. RIS must be installed on
a Windows 2000-based server that has access to Active Directory. This can be a
domain controller or a server that is a member of a domain with access to the
Active Directory.

Shared Folder Space. The drive on the server where RIS is installed must be
formatted with the NTFS file system. RIS requires a significant amount of disk
space and cannot be installed on the same drive or partition on which
Windows 2000 Server is installed.

25

Symantec Ghost Console Server

Symantec Ghost Console is used principally to deploy Ghost Images and Ghost AI
Packages, although it can also distribute files or run commands on remote computers.
The use of such images and packages makes it possible for companies to do remote
management of all networked computers effectively. Using the Symantec Ghost Console,
you can perform a number of tasks to manage computers. From the Console server, it is
possible to:

Roll out software.

Upgrade operating systems.

Migrate user settings.

Perform backups.

Execute commands remotely.

An administrator can efficiently manage the networked users by grouping them within
Symantec Ghost Console.
If you have created a Ghost image or AI Package that includes CATIA, this is the
preferred method of deployment to the desktop.

Systems Management Server

SMS includes advanced and versatile options for the deployment of packages. If you
decide to use the SMS packaging tool for CATIA, it must also be used for deployment. It
can, however, be used to deploy MSI packages, such as a CATIA package created with
WinINSTALL.

Rshmsisvc
The Rshmsisvc is a service developed by Microsoft that assists in the deployment of
software and subsequent updates. The service resides on client computers and can be
installed by using Active Directory. (The installation can be done during startup). The
service possesses administrative privileges and executes commands based on a
triggering event. The triggering event is generated by the update of a specified text file
(trigger script) that resides locally on the clients.
Rshmsisvc can be used to distribute .msi packages or to run a silent CATIA installation.
To get the latest RshMSISvc, contact the Application Development Service Line in the
U.S. National Practices through your local Microsoft Consulting Services practice at
http://www.microsoft.com/business/services/mcs.asp, or contact Infosys at
catiasupport@infosys.com.

26

Deployment of Service Packs, Hotfixes, and Rollbacks

When CATIA is installed locally on workstations, any Service Pack or hotfix must be
applied to all those computers, much like the initial installation. Again, if you have a small
number of computers, you can install the Service Pack or hotfix manually on each. In
larger enterprises, you can roll out the update by using the same package and
deployment method you used to install the application.
Note: The rollout of an entire operating system image to many computers just to apply
a small incremental hotfix is impractical. A very large amount of network traffic would
be created, and the process may take many hours to complete for all clients. Those
solutions that can package just the update, such as WinINSTALL, Ghost AI, or SMS
packaging, are much more appropriate.
Rollback is the removal of CATIA, perhaps because of a change in a users role,
licensing requirements, or strategy. When CATIA is locally installed, the user must use
the software management tool provided with CATIA V5 on the workstation, or
Add/Remove Programs from the Control Panel. If the software has been installed with a
Ghost AI package, however, the Ghost Console can be used to remove it.

27

Methodologies
Single Workstation Installation
! The following step-by-step procedure describes the desktop computer
installation of CATIA V5R10.
On each workstation:

1. Browse the CATIA CD-ROM.

2. Start Setup.exe.
3. Select the language in the drop-down list.
4. In the Welcome dialog box, click Next.
5. In the CATIA V5R10 License dialog box, click Next.
6. Select the destination directory in the Choose Destination Location dialog box
and click Next.
7. Select the location for the environment file and click Next.
8. Select Complete or Custom setup and click Next.
9. Select the required languages and click Next.
10. If you chose to implement a custom configuration in the Setup Type dialog box,
then select the desired configuration and click Next.
11. Retain the default configuration values presented in the Choose Orbix
Configuration dialog box and click Next.
12. Retain the default configuration values presented in the Set Up Communication
Ports dialog box and click Next.
13. Select Online Documentation if you need to install it, and then click Next.
14. Review the configuration parameters presented in the Start Copying Files dialog
box and click Next.
15. Click Finish when the Setup Complete screen appears.
Note: If you are installing CATIA V5 for the first time, the system may need to be
restarted.

Packaging Options
Packaging options include Silent Installation/Unattended installation, Symantec Ghost
and WinINSTALL. This section also includes a discussion of SYSDIFF as an option to
capture "before" and "after" snapshots. The following sections describe the procedures
for each.

28

Silent Installation/Unattended Installation

A silent installation package, which is supported until CATIA V5R10, creates a Setup.iss
file along with the usual setup files provided by the application. This file can be used to
automate later installations of CATIA.
! The detailed steps to create the silent installation package are as follows:
1. Copy the CATIA V5R10 code to one workstation or server (for example, in
c:\CATIA V5R10Code).
2. Run the installation with the r option:
Setup.exe r
The installation proceeds automatically and the results are the same as those
achieved in a manual installation when the default options are chosen.
This automatically generates a silent installation file or a response file, which is a
record of the installation inputs, located by default in the Windows folder (in
Windows 2000 it is C:\Winnt). The default name of the file is: Setup.iss.
An alternate location can also be specified, for which the response file can be
created using the following command:
Setup.exe -r -f1path_name\ResponseFile
where path_name is the pathname of the folder containing the response file, and
ResponseFile is the name of the response file, which in this case is Setup.iss.
3. Copy the response file from the Windows folder to the folder where the
Setup.exe file resides.
4. Locate the Setup.ini file in the setup folder, edit the file, and change the line
EnableLangDlg = Y

to
EnableLangDlg = N

This will ensure that the installation runs in silent mode without invoking the
graphic user interface. This step completes the creation of the package.

29

5. To install the package, create a batch file in the same folder (for example, CATIA
V5R10Install.bat), containing the following command:
Setup.exe -s -f2path_name\LogFile -f1path_name\ResponseFile
where path_name (after -f2) is the pathname of the folder and LogFile is the
name of a file for logging the installation. The path_name and ResponseFile
variables after f1 are the values determined earlier in this procedure. The default
log file name is Setup.log. This file will be used by the Setup.exe program when
distributing CATIA V5 to other computers. You can change the destination folder
for installation by modifying the Setup.iss file.
In CATIA V5 R11, Silent Installation is replaced by the StartB batch installation
command. Note that Online documentation cannot be installed using this
approach. The detailed steps to create the StartB installation package are as
follows:
Copy the software to the source computer and share it in the network, or simply
make the CD-ROM available in the network
In the computer where you want to install CATIA, connect over the network to the
source computer containing the software using Explorer and map a network drive
to the shared folder.
At the command prompt, from the INTEL folder run the following batch command:
StartB
Use the appropriate arguments:
-u "unload_dir"
Specifies the unload directory; make sure the directory path is enclosed like
this: "unload dir" if the directory name contains spaces; the default unload
directory is:
C:\Program Files\Dassault Systemes\B11
-ident IDENT
Creates an identifier used for differentiating multiple versions of the same
release installed in different locations on the same computer.
-newdir
Creates the unload directory if it doesn't exist.
-D env_dir
Specifies the environment directory; the default environment directory is:
C:\Documents and Settings\All Users\Application
Data\DassaultSystemes\CATEnv
-lic "pathname.lic"
Specifies the path and name of the nodelock license certificate to import.
-exe
Runs a Version 5 session at the end of the installation.
-orbixport port1
Specifies the Orbix daemon port number.

30

-orbixbase port2
Specifies the starting port number for daemon-run servers.
-orbixrange
Specifies the range for daemon-run servers.
-AddUserPrivilegesForOrbix
Adds required privileges for Orbix for current user if they are missing.
-backbonePorts port3 port4
Specifies the ports reserved for the communication backbone; default values
are 6666 and 6667.
-VRPort port5
Specifies the port reserved for processing events when using peripheral
devices (spaceball, spacemouse, joystick); the default port for the peripheral
device broker is 6668.
-noSetupPorts
Specifies you do not want to set up any communication ports.
-CatiaV5Info/-CatiaV5Path Path -CatiaV5EnvPath Path CatiaV5EnvName EnvName
Options for CATIA V5 ENOVIA V5 LCA interoperability.
-CatiaV5Info/
Used alone, setup takes default values for other parameters.
-CatiaV5Path Path
Specifies CATIA V5 Installation path.
-CatiaV5EnvPath Path
Specifies CATIA V5 Environment path.
-CatiaV5EnvName EnvName
Specifies environment file for CATIA V5.
-v
Verbose mode.
-h
Displays help.
-list
Lists the configurations and products on the CD-ROM.
-all
Unloads all the configurations and the products on the CD-ROM

31

-l "list_to_unload"
Specifies the list of configurations and/or products to unload. You have to type
the list of configurations and/or products, which you can obtain by running the
command using the list argument. In the list, configuration names look like
this: ME2.slt, and product names look like this: KIN.prd. These are the
names you must type. Separate the names using a space.
The arguments -list, -all and -l "list_to_unload" are mutually exclusive.
-noLang "fr ge it jp ch"/-noLang all
Specifies user doesn't want to install language user interface files for French,
German, Italian, Japanese, Simplified Chinese.
-noFonts
Specifies user does not want to install language-indexed fonts.
-noreboot
The system will not be restarted if needed.
-DLL
Updates the system DLLs if needed; your computer will be rebooted if the
system DLLs are updated.
-UpdateServices
If used without arguments, it updates the file
C:\WINNT\system32\drivers\etc\services with the default
communication port numbers, even if the lines already exist in the file; if used
with arguments, it can also be used to specify other port numbers.
VBA is not installed automatically by using the StartB batch command. To install
VBA, run the following command:
msiexec /q /i pathcdrom\VBA\VBA6.msi
where pathcdrom is the path of the shared folder in the source computer.

32

SYSDIFF
This tool can be used to include the installation of CATIA and other applications during
the installation of the operating system on a desktop computer.
! Follow this procedure to use SYSDIFF:
1. Install Windows on the master system. Wait to install applications until step 5.
2. On the master system, map a drive letter to a share on the server (for example,
map X:\ to D:\BIN).
3. At the server, copy the SYSDIFF.exe and SYSDIFF.inf files in the
Support\Deptools\Platform directory on the CD-ROM to D:\BIN.
4. At the master system, run the SYSDIFF.exe application:
SYSDIFF /SNAP X:\before.img
where before.img is the snapshot file name (it can be any 32-bit valid filename).
This command takes a snapshot of the system, files, and settings. After the
snapshot is completed, SYSDIFF.exe displays the message "Snapshot
complete."
5. Install CATIA V5 on the master system.
6. Configure the CATIA V5 application by, for example, setting default directories,
toolbars, and preferences.
Note: Before performing the next step to create the difference file, reboot the
master system to ensure that all functions relating to the application installation are
completed and all files are closed.
7. Run the following command on the master system:
SYSDIFF /DIFF X:\before.img X:\after.img
where before.img is the snapshot file, after.img is the name of the difference file
to be created, and X is the shared drive.
SYSDIFF.exe takes a snapshot of the entire system again, compares the new
snapshot with the old one, and writes the difference file.
The difference file includes the changes in directories, files, Registry, and .ini files.
After the difference file has been written to the disk, SYSDIFF.exe displays the
message "Diff complete."
8. On the target system, map the path of the snapshot difference file (D:\BIN folder
on the server) to, say, the U drive.
9. To apply the difference file to the target system, run the command:
SYSDIFF/m/apply U:\after.img
where U:\after.img is the difference path and file name.
SYSDIFF.exe copies all the files to the target system and then makes the
necessary changes in the Registry and .ini files.

33

Symantec Ghost Disk Imaging

! The following procedure explains the use of Ghost to create an image for
subsequent distribution.
On the server computer:

Note: The user should have administrative rights for the domain selected.
1. To open the Ghost Console on the server computer, click Start, point to
Programs, point to Symantec Ghost, and then click Ghost Console.
2. Select Remote Client Install from the Tools menu.
3. In the Remote Client Install dialog box, select the client computer on which to
install the remote client and click Install. The remote client needs to be installed on
the source computer used for disk imaging.
4. An authentication window appears. Enter the required User name and Password.
The remote client will be installed on the client computer.
5. From the File menu, point to New and select Image Dump.
6. Enter a name for the task in the Properties for New Task dialog box.
7. To enter the name of the client computer in the Properties for New Task dialog
box, click Browse in the Source machine area. Browse for the folder where image
file will be saved and enter the name of the image file. Keep the other default
values presented in this dialog box and click OK.
8. A new task with the name you assigned it is created under Tasks. Right-click the
name of the task you created and click Execute task.
9. A confirmation window appears. Click Yes.
10. A message box indicating the start of the task appears. Click OK.
The source computer will reboot and will enter into the Ghost Imaging mode.
The progress of this process is shown on the progress bar at the bottom of the
window on the server.
When the task is finished, the image is stored in the location identified in Step 7.

Symantec Ghost AutoInstall Packager

Symantec Ghost AutoInstall (AI) has two components to help create and customize AI
packages. AI Snapshot creates an installation script that records the changes to a model
computer when the software is installed. AI Builder uses the installation script to create a
package that duplicates the changes made by the software installation. It also customizes
the package according to users' needs while packaging. Once created, packages can
also be modified.

34

! Follow these steps to create the package.

1. Ensure that no programs are running. To select AI Snapshot, click Start, point to
Programs, and then click Symantec Ghost.
2. In the Symantec Ghost AI Snapshot dialog box, click Next.
3. Select the drives to be scanned (in this case, the drive where CATIA will be
installed and the Windows drive) and click OK. The AI Snapshot will proceed
through the system checks.
4. After the system check, the wizard prompts for the setup program of the application
that needs to be installed (in this case, CATIA). Assuming the installation is done
from a CD-ROM, click Next. Insert the CD-ROM and go through the installation of
CATIA.
5. After the installation is complete, enter a name for the CATIA package to be
created. (In this example, it is CATIA V5R10.) Then click Compare, which starts
the second system check.
6. After completing the system check, the tool indicates successful creation of the
configuration file. This configuration file, if needed, can be changed later using AI
Builder. Click OK.
7. Click Build in the Ready to Build dialog box.
8. The package will be built in the path specified. Click Finish.
This package, if needed, can be customized using the AI Builder now.

WinINSTALL
The following procedure describes the process for creating an .msi file using
WinINSTALL.
Note: The procedure describes the VERITAS version of WinINSTALL. The VERITAS
WinInstall tool was recently purchased by OnDemand Software.
Install WinINSTALL LE. However, do not install the application on the personal computer
that is going to act as the package creation computer in case the program itself affects
the installation of the applications.
! Perform the following procedure to create the 'Before' Snapshot prior to
installing the application.
1. Log on as an Administrator to the reference computer.
2. Run the Discover Wizard from the distribution server (do not map a drive and do
not use the Run dialog or Network Neighborhood):
\\WINSERVER\Program Files\Veritas\Winstall\DiscoZ.exe
3. When the wizard starts, click Next.
4. Enter a name for the package (the name of the software for which the package is
being created), specify a path for the .msi file (make sure it is on a drive other than
one that forms part of the package, and select a new empty directory), and click
Next.
5. Select a drive for the temporary files and click Next.

35

6. Select and then add the drives that the Discover program should scan and then
click Next. Several drives can be selected, but each drive is time-sensitive, and so
it is better to select only those drives where changes are expected. For example, if
CATIA V5 is installed in the D drive, select the D drive (where the application is
installed) and the C Drive (where the operating system is loaded).
7. Select the files and directories to be excluded from the scan and click Next. This
has to be done for all drives selected for scanning.
8. In the WinINSTALL Discover dialog box, check the Enhanced Registry Scan
option and click Next. The WinINSTALL LE Discover program will then start.
9. After the program is completed, the Launch Application Setup Program wizard
appears. It prompts for a setup program to run. This is the legacy CATIA V5
application for which an .msi file must be created. Click OK.
10. Browse through the Explorer window, select the setup program to run, and click
Open.
11. Continue the application setup as per the normal local installation procedure.
! The following procedure describes taking the 'After' Snapshot (after the
application is installed).
1. Log on to the reference computer as an Administrator.
2. Run the Discover wizard from the distribution server (do not map a drive or use
the Run dialog or Network Neighborhood):
\\WINSERVER\ Program Files\veritas\Winstall\DiscoZ.exe"
3. The wizard detects that a 'Before' Snapshot exists and displays the application and
path of the .msi file. Check the Perform the After' snapshot now option and click
Next. The check will begin on both the registry and the file system.
4. Potential problems, if any, will be displayed. Click OK.
5. After the check is completed, a wizard displaying the message The After
snapshot is complete will appear. Click OK.
6. If the conversion of the .nai file to MSI package is not successful, follow steps 7-10
to convert the .nai file to MSI package.
7. From the Start menu, point to Programs, point to Veritas Software, and then click
Veritas Software Console.
8. Right-click Windows Installer Package Editor and select Convert NAI to MSI.
9. In the NAI to MSI Converter wizard, select the .nai file (a CATIA file) to be
converted and enter the name for the .msi file to be created.
10. It is possible to fine-tune the created package using the Seagate Software Console
Microsoft Management Console (MMC) snap-in. From this application, select Open
from the File menu to change and view the files and registry components. Click
Save after any changes.
11. After you have finished this process, place not only the .msi file but also all files
and subdirectories in the directory chosen for the .msi file in the distribution server.

36

Systems Management Server

! Follow this procedure to create a package with SMS Installer, available with
SMS.
1. Set up a clean reference computer.
2. Install SMS Installer.
3. From the Start menu, point to Programs, and then click SMS Installer.
a. The SMS Installer dialog box opens to let you select installation attributes. The
dialog box lists them on the left. Each installation attribute has several
configuration options. The icons on the right side of the dialog box represent
these options. Click Repackage.
b. In the Repackage Installation dialog box, specify the setup program you want
to run. You can supply command-line options for the installation.
Before the installation starts, SMS Installer takes a snapshot of the reference
system's hard disk. The Repackage Installation dialog box lets you tell the
program which disks to scan. Even if you plan to install the software on the D
drive, make sure to also scan the drive that holds your OS files because many
programs dump files into the OS directory. Scanning all the subdirectories is
optional, but it's a good idea. You can exclude parts of the Registry from the
scan.
c. Click Next to start the setup process. The scan process starts immediately.
SMS Installer scans the directory structure, then the Registry,
d. After the scan is complete, SMS Installer automatically begins the setup
process.
e. Install the application. When the installation finishes, the Repackage
Installation dialog box reappears.
f. Complete the repackage. You might want to start the application and configure
some of the user options. After you make your changes, click Next in the
Repackage Installation dialog box to initiate rescanning of the directories and
Registry.
g. To start building the installation file, click Compile in the SMS Installer dialog
box. The file will be large because it contains all the differences between your
before and after snapshots, including the .exe files, .dlls, runtime support, and
Registry changes. SMS Installer compresses the file.

Deployment Options
Active Directory Group Policy
The Active Directory Group Policy Object (GPO) can be used in two ways depending on
the type of package used.
If you have an .msi file for CATIA (perhaps created with WinINSTALL), follow the first
procedure. Otherwise, use the second procedure, which uses a batch file to run a Silent
Installation or Unattended installation of CATIA:

37

Steps for Deployment of CATIA MSI Package

! The following procedure assumes the CATIA MSI package is named CATIA
V5R10.msi
1. In the Active Directory window, click on the Active Directory Users and
Computers icon.
2. Open the Group Properties window.
Before a group policy can be applied, a group must be defined (for example, Sales,
Admin, etc.). A group can consist of systems, users, and other groups. These
groups are called Organizational Units (OU) within Active Directory.
3. Create a group if one does not exist. In this example, the OU name is assumed to
be CATIADeploy.
4. Right-click the group name (CATIADeploy) and select Properties to open the
groups properties window.
5. Create a Group Policy for an OU:
a. Select the Group Policy tab.
b. Click New to create a new (and empty) group policy. A name can be given at
this point, or the default name can be kept.
c. Click Edit to open the Group Policy properties window.
6. Before creating a new package, ensure that CATIA V5R10.msi installation file is
located on a shared network drive. This is important because the client's computer
still needs to have access to the installation files. The Group Policy just gives the
location.
a. Expand the folders by clicking User Configuration Settings and then
Software Installation.
b. Right-click Software Installation and point to New and then click Package.
c. Locate the CATIA V5R10.msi file when prompted and click OK.
7. Select Assigned from the Deploy Software dialog box and click OK. The CATIA
V5R10 MSI package comes under software installation pane.
8. Perform the following test. Log on to another personal computer as a user who
belongs to the OU defined above. After logon, the CATIA icon should appear in the
Start menu. The first time a user clicks on this icon, the CATIA program will
automatically be installed without showing any user interface.
Steps for Deployment of CATIA Non-MSI Setup Packages
! If you do not have an .msi file, use the following procedure for deploying
other setups.
1. Create a batch file/script file and name it CATIA V5R10Install.bat, Use this file to
run Setup.exe of CATIA V5 from a network share. Use a universal naming
convention (UNC) name for the network share.
\\CATSERVER\CATIA V5R10Code\Setup.exe
2. In the Active Directory window, click on the Active Directory Users and
Computers icon.
3. Open the Group Properties window.
4. Right-click the group name and select Properties to open the Group Properties
window.

38

5. Create a Group Policy for the OU:

a. Select the Group Policy tab.
b. Click New to create a new (and empty) Group Policy. A name can be given at
this point or the default name can be kept.
c. Click Edit to open the Group Policy Properties window.
6. Create new logon script following the same procedures detailed in Step 1.
a. As mentioned in the script file, ensure that the executable and other necessary
files are in the network share.
b. Expand the folder User Configuration Settings in the Tree window pane by
clicking Windows Settings and then Scripts (Logon/Logoff).
c. Click Logon to enter logon properties. Click Add to add the script file. Ensure
a UNC name for the script path.
7. Perform the following test. Log on to another computer as a user that belongs to
the OU defined above. After logon, the CATIA application is automatically installed.

Remote Installation Services

Remote Installation Services (RIS) can be used to install the image of the operating
system along with the required applications. RIS uses the Remote Installation
Preparation wizard (RIPrep.exe) to create these images and copy them to the
distribution server.
RIPrep.exe prepares a Windows 2000 Professional image, including locally installed
applications and specific configuration settings, and replicates that image to an available
RIS server on the network.
! Follow this procedure to run RIPrep.exe:
1. Install the base Windows 2000 Professional OS from an available RIS server on to
a supported client computer.
2. Install the CATIA V5 application locally on the client computer.
3. Connect to the RIS server where this image has to be replicated by following these
steps:
From the Start menu, click Run and type the following command in the Open text
box:
\\RISservername\Reminst\Admin\I386\RIPrep.exe
where RISservername is the computer name of the destination RIS server.
Reminst is the Remote Installation Share that is created when the RIS service is
installed on the server. Admin\I386 is the directory that contains RIPrep.exe
and that launches the remote installation.
4. At this point, the Remote Installation Preparation wizard starts and presents a
welcome screen that describes its features and its functionality. Click Next.
5. Enter the name of the RIS server where the contents of the client hard disk have to
be replicated. By default, the RIS server that the wizard (RIPrep.exe) is being
run from is automatically filled in. Click Next.

39

6. Provide the name of the directory on the RIS server where this image will be
copied. The image is created under the \RemoteInstall\setup\OS
Language\Images directory. Click Next.
7. Provide a description and help text describing this image. The description and help
text are displayed to users of the Client Installation wizard during OS image
selection. Provide enough information for a user to distinguish between images.
Click Next.
8. The wizard displays a summary screen of the selections. After review, click Next.
The image preparation and replication process begins. The system is prepared and files
are copied to the specified RIS server. Once the replication of the image completes, any
remote boot-enabled client computer can select the image for a local installation.

Installing the Image

1. Reboot the client computer from either the remote floppy or the PXE boot ROM.
When prompted, press the F12 key to start downloading the Client Installation
wizard.
2. Click Enter on the welcome screen.
3. Type the user name. Press the Tab key twice. For this instruction set, the
password is left blank and the domain name should be entered as reskit.com.
Click Enter to continue.
4. A warning message that "all data on the client computer hard drive will be deleted"
is displayed. To continue, click Enter.
5. A computer account and a global unique ID for this workstation are displayed. Click
Enter to begin setup. The Windows 2000 Setup program begins.
6. If prompted, type the Product Key (found on the back of the Windows 2000
Professional CD case) and click Next.
Note: This step can be avoided by specifying the product key in the .sif file.
After the installation is complete, the user is prompted to log on to the network with
an existing user account, password, and logon domain.

Symantec Ghost Console Server

Deployment of CATIA V5 can be done in two ways:
1. Image deploymentdeploying an image of a computer that has CATIA V5
installed.
2. Package deploymentdeploying AI Package of CATIA V5.
Symantec Ghost Console Server can be used for either method. Both methods require
the creation of tasks, which is done using the Ghost Console application.
These tasks can be used to:

40

Deploy a Symantec Ghost image of a computer.

Deploy a package created using Symantec Ghost AI.

Deploy a file.

Run a command.

Deploying an Image of a Computer that already has CATIA Installed

The steps to make an image of a computer that has CATIA V5 installed are detailed in
the section devoted to packaging that appears earlier in this document.
! Use the following procedure to deploy an image. Here, it is assumed that such
an image has already been obtained.
1. To open Ghost Enterprise Console:
a. From the Start menu, point to Programs, point to Symantec Ghost, and then
click Ghost Console.
b. Type the user ID and password for Symantec Ghost Console Server, and then
click OK. This opens the Symantec Ghost Console Wizard.
2. To add an image definition for a previously created image file:
a. Click Add a previously created image to the console, and then click Next.
b. Type the title for this image definition.
c. Click Browse to locate the clone image that was created previously.
d. Click OK.
3. To create a new Machine Groups folder:
a. Double-click Machine Groups.
b. Click File, point to New, and click Folder.
c. Right-click the New Folder icon.
d. Select Rename and type a new name for the Machine Group. Any name can
be used here.
e. Copy individual computers from the default folder or other folders under
Machine Groups and paste them into the new folder.
4. To create a configuration template:
a. From the File menu, point to New and then click Configuration. This opens
the Properties for New Configuration Set window.
b. Type a name for the new template in the Name box.
c. Check the Allow template settings option and click OK. This allows
modification of this template so that it can be used for more than one
computer.
d. Click User Name on the tree-listing and type the user name to use as the
default. Click Ok.
e. Click Identification.
f. Type a word followed by two asterisks in the Apply Computer Name box,
such as Work**. The asterisks are wild cards that Ghost will replace with
numbers on the client computers, for example, Work01, Work02. Click OK.

41

g. Click TCP/IP Settings. The default selection is DHCP. If the network that the
client computers are on does not have a DHCP server, select Target
computer has static IP address, and then fill out the rest of the TCP/IP
settings that are indicated on the left pane.

h. Click OK. A new configuration is created.

5. To create a new task:
a. From the File menu, point to New and click Task. This opens the Properties
for New Task window.
b. Configure the General tab:

42

Type a name for the new task in the Name box.

Check the Clone and the Configuration options.

Click Browse, select the client computers to be written over, and click OK.

6. Configure the Clone tab:

a. Click Clone.
b. Select the drive to be written over on the client computers in the Destination
Drive box.
c. Click Browse, double-click Images, click the image file of the model computer,
and then click OK.
d. To write to a single partition instead of the entire drive, check Partition Load
and fill out the Source Partition information.
e. To roll out a Windows NT image, click SID change.
f. For Windows 2000, click SID Change only if SysPrep has not been run on
the source computer before creating the image file (SysPrep is useful in
eliminating computer specific details like security identification [SID]).
7. Configure the Configuration tab:
a. Click Configuration.
b. Click Template, and then click Browse.
c. Double-click Configurations and then click the configuration template that this
task needs to use.
d. Click OK. This saves the task.
8. To run the task:
a. Click Tasks.
b. Right-click the icon for the Task that has to be run.
c. Click Execute Task. This displays a confirmation message.
d. Click Yes. Ghost now executes all operations specified on the General tab of
this task.

Deploying AI Package of CATIA

The steps to make an AI Package of CATIA V5 are given in detail in the packaging
section.
! Follow this procedure to deploy an AI package of CATIA. For this example, it
is assumed that such a package has been already obtained and is named
CATIA V5R10.exe.
1. Install Ghost at the computer to be used as a server. This is the Ghost server
computer. During installation, choose the Console installation type.
2. Install the remote client on each computer where the package needs to be
deployed.
a. On the Tools menu, select Remote Client Install.
b. Select the machine or the domain on which to install the remote client.
c. Fill out the domain administrator password and click OK. This will install the
remote client on the specified computers.
3. Open Ghost Console at the Ghost server computer:
a. From the Start menu, point to Programs, point to Symantec Ghost, and then
click Ghost Console.
b. Click Cancel. This closes the Console Wizard.

43

4. Create an AI Package:
a. From the File menu, point to New and then click AI Package. This opens the
Properties for New AI Package window.
b. Type a name for this package in the Name box.
c. Click Browse.
d. Locate and click the name of the application package and click Open. This
copies the path and name of the application package to the Location box on
the Properties for new AI Package window.
e. Click OK.
5. Create a new task:
a. From the File menu point to New and then click Task. This opens the
Properties for New Task window to the General tab.
b. Type a name for this task in the Name box.
c. Uncheck all Task Steps except Deploy AI Package.
d. Click Browse and select one or more computers. These are the client
computers where the CATIA application package will be installed.
e. Click the Deploy AI Package tab.
f. Then click Browse.
g. This window has two Browse buttons. Click the top Browse button, next to the
Install packages box.
h. Select CatiaV5R10 under AI Packages. The application package is a file that
uses the filename format CATIA V5R10.exe. This step adds the application
package to the Install packages box described in Step g.
i. Click OK.
6. To distribute and run the application package, execute the following procedure:
a. Click the task name.
b. Click File and then click Execute task.
7. When Execute Task is clicked, this process copies the application package file to
the incoming folder on each client computer and runs the file. Running the file
installs the programs that are included in the application package.
Clients will restart after successful installation of the package.

Systems Management Server

Before creating an SMS package, you must set up the system by using the following
procedure.
! To specify the account for software distribution to use when clients are not
logged on, perform these steps on the site server:
1. From the Start menu, point to Programs, point to System Management Server,
and then double-click SMS Administrator Console. This starts Microsoft
Management Console (MMC).
2. In the left pane, expand the Site Database tree and then expand the Site
Hierarchy node under Site Database.

44

3. Right-click the Site and then click Properties.

4. On the Accounts tab, click the Set option next to the SMS Client Remote
Installation Account box. Specify the account, to be used to perform the software
installation. The account needs to have domain Administrator rights as well as local
Administrator rights on the workstations. The Remote Client Installation component
primarily uses this account, but software distribution also uses the account to run
packages on computers that are not logged on to the network.
! Create the Systems Management Server 2.0 package for deployment by using
the following procedure. This is the actual package that Systems
Management Server uses for distribution.
1. On the General tab, provide values for the following attributes:
Name. The name of the package, up to 50 characters (for example,
"CatiaV5R10"). This field is required.
Version. The version number of the software package, up to 32 characters. (For
example, "1.0")
Publisher. The name of the software publisher, up to 32 characters. (For example,
Dassault Systemes")
Language. The language version of the software, up to 32 characters. ("English")
Comment. Optional text about the package, such as a description, up to 127
characters.
2. On the Data Source tab, click to select the This Package Contains Source Files
check box, and then click Set.
3. Under Source Directory Location, click the type of connection to the set up files in
the source directory, and then click OK.
4. On the Distribution Settings tab, in the Sending Priority box, click High, and
then click OK. The package should now appear under the Packages node of the
site tree within the console.
5. Expand the package under the Packages node.
6. Right-click Distribution points, click New/Distribution Points, and then click Next
to begin choosing distribution points.
7. Click to select the check box by the server or servers that will be the distribution
points for this package, and then click Finish. Return back to the Site tree.
8. Right-click Programs under this package, click New/Program, and then type a
name for the program.

45

9. In the Command Line box, type the full path to CATIA executable file, or click
Browse to locate the file. Add these switches:
- s for silent mode
- SMS or SMS (This switch is case sensitive.)
10. On the Environment tab, click to clear the User Input Required check box.
11. Click to select the Run with Administrative rights check box, and then click OK.
12. The Packages window now reappears and the newly created Systems
Management Server package is displayed.
To distribute a package created in SMS, you must advertise it in order to offer it to clients.
! The following procedure describes creating the Advertisement.
1. Create a collection of clients that are targeted to receive the distribution. The
collection can be based on a query or direct membership rules.
2. Right-click the collection that will receive the package and then click All
Tasks/Distribute Software.
3. The Distribute Software wizard starts. Click Next.
4. Click Distribute an existing package, click the Internet Explorer package, and
then click Next.
5. Make sure the distribution point is selected, and then click Next.
6. Click the program to install, and then click Next.
7. Fill in the advertisement name if appropriate, and then click Next.
8. Specify any sub-collections that should also receive this advertisement, and then
click Next.
9. Confirm or change the time the advertisement is offered and specify if the
advertisement should expire and when.
10. On the Assign Program page, click Yes to assign the program.
11. Click Next, and then click Finish.

46

Rshmsisvc
The installation process of the Rshmsisvc on the clients requires the sharing of the folder
containing the trigger script to enable remote updates to the script. Appropriate security
permissions are assigned to this folder to prevent updates from unauthorized users.
The following diagram shows that you use Rshmsisvc by writing batch commands into
the trigger script file. These commands could, for example, install CATIA by referencing
an .msi file created with WinINSTALL or by running a silent installation.

Figure 3.1
Schematic Representation of Rshmsisvc Execution

The following two descriptions of stages detail the deployment strategies using
Rshmsisvc

Stage I
Distribution of the Application software bundle and the unattended installation script to all
the clients. During Stage I, the Application software bundle and the unattended
installation script are remotely copied from a network location to all the clients. The
remote copy process should be done in a staggered manner for optimal use of the
network. The process can be automated using batch files.
The distribution process helps to initiate the simultaneous installation of the software at a
later time, on all the clients, without affecting the network.

47

Stage II
Installation of the Application software on all the clients. In Stage II, the installation of the
Application software bundle (available locally in the clients after Stage I) is initiated in the
clients by remotely copying the trigger script to all the clients from the server. The copy
process could be carried out using the same batch files discussed in Stage I.
The trigger script refers to the unattended installation script that is available as a part of
the software bundle in the clients. The Rshmsisvc service at the clients begins execution
of the installation script as soon as the trigger script is updated.
Note: The batch files used for the distribution (Stage I) and installation (Stage II) can
be scheduled for execution during off hours.

Installation Validation
After CATIA V5 has been installed using the methods discussed above, it becomes
imperative to check whether the installation was successful.
! Follow this process for validating installation.
1. From the Start menu, point to Programs, point to CATIA, point to Tools, and click
on Software Management B10. Or, from the Start menu, point to Find, and then
click Files or Folders and search for CATSoftwareMgt.exe in the Local Hard
drives.
2. Click the Check Integrity tab.
3. Select Level 3 and click Check.
The message Check Integrity Level 3 is OK confirms that there is no integrity
problem. But if the message Check Integrity Level 3 is KO appears, then the
installation has been corrupted (for example, some files are missing). This
message will be followed by troubleshooting information to identify and solve the
problem.

48

Summary
The packaging and deployment technique you choose will depend on many factors,
including the size of your organization, the project budget, and whether an operating
system is already in place on the desktop computers.
Having deployed CATIA, you will later have Service Packs and hotfixes to distribute, and
these can frequently be rolled out with the same tool that you used for the installation.
Network traffic is intense during the installation of CATIA and later Service Packs and
hotfixes, and the distribution server is heavily utilized. This load can be managed by
rolling out to a limited number of computers at a time. This also allows you to test the
installation method in a live environment, without impacting a large number of users in
the event of problems.

49

4
CATIA Code Server
Installation
In this architecture, CATIA V5 is installed on servers and is executed from workstations
across the network. Such an arrangement frequently reduces the administrative
overhead required to run the system, particularly during installation and later upgrades. It
is also similar to a UNIX-based CATIA system, which may suit those migrating to
Microsoft Windows. However, you are likely to see a higher level of network traffic
with a code server installation than a comparable locally installed system would generate.
For a full description of the advantages of this approach and a comparison with local
installation, see Chapter 2, "Planning a CATIA UNIX to Windows Migration."
The scalability and efficiency of a code server installation can be improved by using two
features of Windows 2000:

Offline Folders allow clients to create a local cache of a shared folder from a file
server, they can reduce network traffic, and they can create a marked
improvement in speed of execution.

The Distributed File System (Dfs) can be used to share the load between multiple
CATIA code servers.

There are several techniques involved in setting up this architecture. In this chapter the
first section, Preparing for Code Server Installation, describes the architecture in detail
and compares the setup techniques. You will find step-by-step example procedures for
the tools you have selected in the "Methodologies" section.

51

Preparing for Code Server Installation

If you have chosen this model, the main installation of CATIA is done only on the code
server or servers. When clients run the package, code is executed from the server.

General Architecture

Figure 4.1
General Architecture for Code Serving

Figure 4.1 illustrates that only a small amount of configuration is required on the client
computers. The majority of the setup steps are run on the servers and, because there are
fewer servers than desktop computers, the time and effort involved in this setup is often
smaller.
A code server installation of CATIA V5 involves these general steps:

A setup of CATIA V5 on the code servers. This process is very similar to a local
installation.

A runtime environment creation in which environment variables are set. This can
be done on either client or server.

A light setup on the client, including fonts, shortcuts, and the update of
configuration files.

Figure 4.2
Code Server Installation of CATIA

Optionally, Offline Folders and Dfs may be set up after the main installation for greater
performance and efficiency.

52

Server-side Installation
The installation of CATIA on the code server is identical to that on desktop computers
when performing a local installation. For a step-by-step run-through of this procedure,
see the "Methodologies" section of Chapter 3, "CATIA Local Installation."
Having completed the installation, it will be helpful to your users to share the
documentation directory on the server so that they can easily access help. This
documentation can be accessed with a browser.

Runtime Environment Creation

The runtime environment of any application consists of environment variables used to
store properties. CATIA uses around 40 of these and provides a command to
automatically create them: setcatenv.exe. This generates an environment file that is
stored on the code server and is used to create the environment when the application is
run.
Runtime environments could be created either on clients or on servers. Typically, global
environments are stored on servers and user environments are stored locally.
To create the runtime environment, your user account must have read and write
permissions on the share where CATIA is installed. Users, however, should have only
read access to this share so that they can run programs, but not be able to delete files or
change the environment. The environment file can be stored either in the same directory
as the CATIA V5 code itself or in a sub-directory.
The runtime environment creation process involves the following actions:

Access the share where the environment will be stored. This must use the same
path users will access to run CATIA V5. It can be either via a UNC name, such as
\\SERVER1\CATIA, or a mapped drive letter.

Create the directory where the runtime environment file will be stored.

Execute the setcatenv command.

The setcatenv command also creates shortcuts on the servers desktop and Programs
menu. These appear in the All Users profile. For users to be able to access CATIA
easily, these shortcuts must be copied to the same location on client computers.

53

Client-side Installation
In a code server installation, the setup steps required on the client are comparatively few.
However, the following components are required on all client computers:

The C++ Runtime library

Shortcuts to run CATIA V5

In addition, some other components may be needed, depending on the functionality a

user needs:

54

VBA 6. Microsoft Visual Basic for Applications 6.0 is used to replay or record
macros. Macros allow a complex procedure to be recorded so that it can later be
repeated by selecting it from a list.

Fonts. CATIA V5 includes extended fonts.

Tools. Environment Editor, Nodelock Key Management, Settings Management,

and Software Management are CATIA administrative tools. These tools are
required only on computers that will be used to administer the system.

OLE records. Object linking and embedding (OLE) support allows a user to open
documents by a double-clicking on them.

etc\services file. This file includes the configuration necessary to exchange

information between CATIA V5 and other services, such as DMU, a Dassault
Systemes service. If you wish to use process interoperability, you must make
additions to this file.

Client-side MSI Package Creation

Chapter 3 explains that local installation on clients is a long process that could be
automated using package and deployment tools. When you are using code server
architecture, the client-side setup is much quicker. However, if you have hundreds of
clients or more, a similar packaging approach can save you valuable administrative effort.
The same techniques used to package and deploy a complete local installation of CATIA
can also be used to roll out the client-side components of a code server installation. For
example, having set them up on a master client, you could create a Symantec Ghost
image and deploy it with the Ghost Console.
In this chapter, the use of MSI files for packaging and deployment is discussed and the
AdminStudio tool from InstallShield examined. Figure 4.3 provides an overview of this
process. Bear in mind, however, that the other solutions described in Chapter 3 can be
used instead.

Figure 4.3
Client side deployment of CATIA

An MSI package can be created to install both required and optional components. The
Methodologies section later in the chapter provides example procedures for each of
these components.

55

Deployment of MSI Packages

A full discussion of options for deploying MSI packages can be found in Chapter 3,
"CATIA Local Installation." To recap:
Deploying an application from a central point can be done either with Active Directory
Group Policies, Microsoft Systems Management Server (SMS), or Symantec Ghost
Console.
Active Directory Group Policies permit:

Deployment of MSI packages from a central point.

Highly flexible per-user, per-group, or per-computer assignment.

Installation of packages under local system account.

Un-installation from a central point.

SMS adds the following management functions:

Planning. Systems Management Server permits administrators to meter

application usage. The planning tools in SMS also help administrators conduct
audits and compliance checks, monitor and restrict application use, and plan
operations such as deployments and upgrades.

Deployment. Using SMS, an IT administrator can distribute and install software in

the background on a Windows 2000-based network, irrespective of whether the
users are logged on or not.

Diagnosis. Systems Management Server provides a range of advanced remote

diagnostic tools to help administrators manage desktops and servers without
having to conduct on-site visits. These include tools such as remote control and
remote reboot, a network monitor with real time and post-capture experts to
analyze network conditions and performance, and a tool that can track critical
performance information on the Microsoft Windows NT Server operating system
and the Microsoft BackOffice family.

The Symantec Ghost suite of applications is principally designed for the creation and
deployment of Ghost images and AutoInstall (AI) packages. If you have selected these
package types, Ghost Console is the natural choice for deployment. Although Ghost
Console can be used to deploy MSI packages, it is unlikely that you would choose it for
this feature alone because Group Policy, a standard feature of Windows 2000 Server, is
sufficient.
For step-by-step procedures showing the use of these tools for deployment, see Chapter
3, "CATIA Local Installation."

Multiple Releases of CATIA V5 on the Same Workstation

When a service pack or a hotfix for CATIA V5 becomes available, it is advisable to run
tests for a period before rolling the new version out to all users. To achieve this, you may
have dedicated client computers. However, due to constraints such as budget, desktop
space, and time, it is more likely that testing will have to be done on the production client
computers. Thus, during the testing phase the pilot and production versions of CATIA
are run on the same workstation.
Generally, there will be two or three releases of CATIA V5 available for dedicated users
groups who perform testing.

56

Fortunately, in a code server installation only the following components are stored on
workstations:

Shortcuts to CATIA V5 launcher program

C++ Runtime

Etc\Service file configuration (optional)

CATIA V5 specific fonts (optional)

OLE records (optional)

VBA runtime (optional)

Given that all these components are compatible between CATIA V5 releases, multiple
releases of CATIA V5 can be started from the same workstation without upgrading
issues.

Rollback of CATIA V5
To avoid data corruption, ensure that all users use the same CATIA V5 release level of
patch or service pack for production purposes. If an issue occurs on a new release,
access to this release has to be disabled and access to the previous one must be
enabled without delay. This can be done by removing the share on the faulty version of
CATIA, and sharing the previous one with the same share name. When users restart
CATIA, they will thus be automatically directed to the stable version and avoid whatever
issues have been discovered with the new release.
For example, to switch back from V5R9SP1 to V5R9 when workstations are using a
share named Production Version that points to the V5R9SP1 directory, stop the
sharing of the V5R9SP1 directory, and then share the V5R9 directory with the same
name (Production Version). No modification is necessary on workstations and rollback
is done at the same time for all workstations.

Offline Folders
This feature of Windows was originally designed to help laptop users by allowing them to
create a local cache of the files they use on a file server. These cached files could then
be worked on while the laptop is disconnected from the corporate network. Any changes,
either to the cached files or the versions on the server, are automatically synchronized on
reconnection.
The technique can also be used to speed the execution of a code server application such
as CATIA. The executables and other files that make up the package can be cached on
any computer desktop or laptop on first use. When CATIA is run, the cached versions of
these files can be used instead of downloading them again from the code server. This
reduces the amount of network traffic generated and helps CATIA to start quickly and
perform well.
Offline folders require no extra software to be purchased or installed. A small amount of
configuration must be done on the server and on the client, although these procedures
can be performed centrally using Group Policy. For this reason, the use of Offline Folders
with a CATIA code server installation is highly recommended, even in small deployments.

57

Using Multiple Code Servers with Dfs

Multiple Code Serving of CATIA V5 can be achieved through the effective use of
Microsoft Distributed File System (Dfs). The Distributed File System is a network server
component that makes it easier to find and manage data on network infrastructures. Dfs
provides a means for uniting folder trees on different computers into a single hierarchy.
Dfs also makes it easy to build a single tree of folders from file servers and file server
shares on one network.
Many benefits can be gained from Dfs features:

Custom hierarchical view of shared network resources.

Flexible volume administration.

Higher data availability.

Load balancing.

Name transparency.

Integration with Windows NT security model.

Dfs client integrated into Windows NT Workstation 4.0, available for Windows 95
and Windows 98.

Intelligent client caching.

The ability to interoperate with other network file systems.

In a CATIA code server installation, Dfs helps by providing multiple copies of read-only
shares. These copies are accessed via a single path. If one of the copies becomes
unavailable, an alternate is automatically selected, providing a degree of fault tolerance.
In addition, the load placed on code servers is automatically shared. Load balancing in
this way helps CATIA scale to cope with large numbers of users. As users request files
from the Dfs volume, they are transparently referred to one of the network shares
comprising the Dfs volume.

Interoperability with Other Networks

This is an added advantage of Dfs functionality. Any volume that is accessible through a
redirector on Windows NT Workstation can participate in the Dfs name space. This can
be through either client redirectors or server-based gateway technology. If, for example,
your UNIX-based CATIA users store files in a folder on a UNIX server, the folder can be
published to Windows users using a Samba server and integrated into the Dfs tree.
Windows users thus can access the UNIX folder transparently and share information with
UNIX users very easily. For more information on sharing information between UNIX and
Windows, see Chapter 8, "UNIX-Windows Interoperability and Data Sharing."

Performance of Code Serving

The code serving approach outlined in this section has been evaluated by Microsoft,
Infosys Technologies, and Intel in the CATIA V5 Scalability Tests. These tests show that
Code Serving provides good performance in terms of CATIA start time, change
workbench time, memory (RAM) used, and processor usage, even with 24 client
workstations for each server.
The use of Offline Folders and multiple code servers with Distributed File System further
improve performance. For a full description of the scalability and performance tests run
on CATIA, refer to the Appendix, "Scalability, Performance and Capacity Testing."

58

Methodologies
The following subsections explain the methodologies that can be used for code server
installations.

Server-side Installation Process

The server installation process is identical to a local installation on a workstation. For a
step-by-step run-through, see the "Methodologies" section of Chapter 3, "CATIA Local
Installation."

Creating the Runtime Environment

Creation of the runtime environment requires read and write access to the network share
where it is stored, and read access to the share where CATIA V5 programs are located.
The environment file is created using the following command at the server:
Setcatenv e environment_name a global d environment_location
where environment_name is a label for the environment, and environment_location
is the directory where the environment file will be created.
Note: The setcatenv program is located in the Intel_a\code\bin directory of CATIA V5
shared installation.
In the following example, a batch file creates a new directory for the environment file,
then runs the setcatenv command and stores the results in the new directory. In this
example;

CATIA code is located on a share named \\CATIA.net\CATIA\V0.

The environment label is V0.

The environment file is located in the \\CATIA.net\CATIA\V0\env directory.

Rem Directory creation
Md \\CATIA.net\CATIA\V0\env
Rem Runtime environment creation
\\CATIA.net\CATIA\V0\intel_a\code\bin\setcatenv -e V0 -a global -d
\\CATIA.net\CATIA\V0\env
Check to ensure that the example batch file generates a runtime environment file
that resembles the following file. A portion of your path (for example,
\\CATIA.net\CATIA\VO) will differ from this example.
!---------------------------------------------------------!
!

DASSAULT SYSTEMES - V5 ENVIRONMENT FILE

!---------------------------------------------------------!
CATInstallPath=\\CATIA.net\CATIA\V0\intel_a
CATDLLPath=\\CATIA.net\CATIA\V0\intel_a\code\bin
CATICPath=\\CATIA.net\CATIA\V0\intel_a\code\productIC
CATCommandPath=\\CATIA.net\CATIA\V0\intel_a\code\command
CATDictionaryPath=\\CATIA.net\CATIA\V0\intel_a\code\dictionary

59

(continued)
CATDocView=\\CATIA.net\CATIA\V0\intel_a\doc
CATReffilesPath=\\CATIA.net\CATIA\V0\intel_a\reffiles
CATFontPath=\\CATIA.net\CATIA\V0\intel_a\resources\fonts
CATGalaxyPath=\\CATIA.net\CATIA\V0\intel_a\resources\galaxy
CATGraphicPath=\\CATIA.net\CATIA\V0\intel_a\resources\graphic;\\
CATIA.net\CATIA\V0\intel_a\resources\graphic\icons;\\CATIA.net\C
ATIA\V0\intel_a\resources\graphic\figures;\\CATIA.net\CATIA\V0\int
el_a\resources\graphic\splashscreens;\\CATIA.net\CATIA\V0\intel_a
\resources\graphic\symbols;\\CATIA.net\CATIA\V0\intel_a\resources
\graphic\textures
CATMsgCatalogPath=\\CATIA.net\CATIA\V0\intel_a\resources\msgc
atalog
CATFeatureCatalogPath=\\CATIA.net\CATIA\V0\intel_a\resources\fe
aturecatalog
CATStartupPath=\\CATIA.net\CATIA\V0\intel_a\startup
CATW3ResourcesPath=\\CATIA.net\CATIA\V0\intel_a\docs
CATReferenceSettingPath=
CATUserSettingPath=CSIDL_APPDATA\DassaultSystemes\CATSettin
gs
CATReferenceStandardPath=
CATUserStandardPath=CSIDL_APPDATA\DassaultSystemes\CATStan
dards
CATTemp=CSIDL_LOCAL_APPDATA\DassaultSystemes\CATTemp
CATMetasearchPath=DSKEY_TMPDIR
CATW3PublishPath=DSKEY_TMPDIR
CATSharedWorkbookPath=DSKEY_TMPDIR
CATErrorLog=CSIDL_LOCAL_APPDATA\DassaultSystemes\CATTemp\
error.log
CATReport=CSIDL_LOCAL_APPDATA\DassaultSystemes\CATReport
CATDisciplinePath=
USER_HOME=CSIDL_PERSONAL
DB2INSTANCE=%DB2INSTANCE%
TNS_ADMIN=%TNS_ADMIN%
ORACLE_HOME=%ORACLE_HOME%
ORA_NLS33=%ORA_NLS33%
This command also creates shortcuts located on All users\desktop and in the All
users\programs menu.
However, these shortcuts are created on the code server and so will be unavailable to
clients. For an automated setup process, these shortcuts have to be copied to all
workstations so that users can quickly run CATIA.

60

Client-side Installation Process

The setup of client computers is described in the following procedures, beginning with the
components that are always required and then moving on to optional components.

Required Components
C++ Runtime
On a Windows XP Professional workstation, there is no need to add C++ runtime
because it ships with the correct version.
If you have an earlier operating system, the Msvcp60.dll file must be copied to the
%systemroot%\system32 directory on a Windows 2000 workstation.
Note: The CATSoftwareMgtB P command, found in the CATIA directory
Intel_a\code\bin, indicates if the required dynamic-link libraries (DLLs) are up-to-date.

CATIA V5 Shortcuts
The necessary shortcuts were created with the runtime environment by the
setcatenv.exe command. However, these will be on the computer where that command
was issued (probably the code server itself). You must therefore copy the CATIA
shortcuts from the All Users profile on the server to the same location on all client
computers.

Optional Components
The following optional components are required only for specific CATIA features. If these
are unimportant to you, skip these steps.

Visual Basic for Applications

Microsoft Visual Basic for Applications is needed if users wish to record and replay
macros in CATIA. Because CATIA is shipped with an MSI file (Vba6.msi), its installation
is straightforward. However, if you are setting up a Windows NT 4.0 Workstation,
Windows Installer 2.0 must be installed to be able to install the package.
Windows Installer 2.0 can be downloaded from the Microsoft Website:
http://download.microsoft.com/download/WindowsInstaller/Install/2.0/NT45/ENUS/InstMsiW.exe. Unattended installation of Windows Installer can be done by running
this file with a /q switch. Following this installation, reboot the workstation.
The Vba6.msi package, located on CATIA V5 CD-ROM in the VBA directory, could be
deployed with a group policy or with the following command:
msiexec /q /i VBA6.msi

When the installation has been completed, reboot the computer.

61

Extended Fonts
To install CATIA V5 extended fonts, run the following command on the client:
VE0ifont env environment_name direnv environment_location
where environment_name is the environment label and environment_location is the
directory where the environment file is stored.
In the following script sample,

CATIA V5 code is located on a share named \\CATIA.net\CATIA\V0.

The environment label is V0.

The environment file is located in the \\CATIA.net\CATIA\V0\env directory.

\\CATIA.net\CATIA\V0\intel_a\code\bin\vE0ifont -env V0 -direnv
\\CATIA.net\CATIA\V0\env

Tools
The CATIA V5 administration tools (Environment Editor, Nodelock Key Management,
Settings Management, and Software Management) should be installed only on clients
from which administration of CATIA will be performed. To install them, the following
command must be run:
Setcatenv tools cs CATIA
If CATIA V5 code is located on a share named \\CATIA.net\CATIA\V0, the command will
be the following:
\\CATIA.net\CATIA\V0\intel_a\code\bin\setcatenv -tools -cs CATIA

OLE Records
OLE records assist the user by allowing CATIA documents to be opened simply with a
double-click. To register OLE records, the following command must be executed:
CNEXT /regserver -env environment_name -direnv
environment_location
where environment_name is the environment label and environment_location is the
directory where the environment file is stored. In the following example,

CATIA V5 code is located on a share named \\CATIA.net\CATIA\V0.

The environment label is V0.

The environment file is located in the \\CATIA.net\CATIA\V0\env directory:

\\CATIA.net\CATIA\V0\Intel_a\code\bin\CNEXT /regserver -env V0 direnv \\CATIA.net\CATIA\V0\env

etc\services File
To use process interoperability (for example, between the Dassault applications CATIA
V5 and DMU), the Background process needs to be configured on each computer
running applications that need to communicate.
To use this service, add the following lines in the services file located in the
%windir%\system32\drivers\etc\ directory:
CATIAv5bb 6666/tcp
CATIAv5run 6667/tcp

62

Client-side MSI Package Creation Process

See the Preparing for Code Server Installation section at the beginning of this chapter
for help on deciding whether packaging and deployment techniques will be useful. These
procedures are based on the AdminStudio tool from InstallShield. Similar techniques may
be used with your preferred MSI packaging tool. Examples of using AdminStudio with
each of the required and optional client side components are given.

Extended Fonts Component

! To install CATIA V5 extended fonts, add each font as a component in the MSI
package. Using Administrator Studio 3.0, this can be done with the
Component Wizard. This process is described here:
1. Start the wizard. Select Let me select a type and define components myself
and click Next.
2. Select Fonts and click Next.
3. Select one font and click Next.
4. Click Finish.
5. Repeat these operations for each font and associate font components to the Fonts
feature. The list of fonts is displayed in the Setup Design dialog box.

Shortcuts Component
A new component can be created to contain all the shortcuts necessary for users to
quickly access CATIA from their desktop.
! To perform shortcut packaging, follow this procedure:
1. Right-click the folder where the shortcut is to be created.
2. Provide values for the Display name, Argument, Target, and Component text fields
as indicated below:

Argument: env environment_name direnv environment_directory

where environment_name is the name of the environment label and
environment_directory is the name of the directory where the environment
file is stored.

Target: CNext.exe

Note: Shortcuts for CATIA administration tools (Nodelock Key Management,

Environment Editor, and so on) can be created by using the same components).

Backbone Service
To modify the file services, three custom actions have to be created:

One for installation

One for un-installation

One for rollback

For installation, a Microsoft Visual Basic Scripting Edition (VBScript) file is used that adds
the required lines to the services file. Two other VBScripts remove these lines for uninstallation and rollback.

63

The following example script adds lines in services files. To use this code, copy it into a
text file and rename it with a .vbs file extension:
'****************************************************************
' Add CATIA V5 ports in services file
'****************************************************************
Option Explicit
Dim WshShell,SystemFolder,Fso,File,Line,CATIA1,CATIA2
Const ForReading = 1, ForWriting = 2, ForAppending = 8
CATIA1 = 0
CATIA2 = 0
On error resume next
'Environment variable reading
set WshShell = CreateObject("WScript.Shell")
SystemFolder = WshShell.ExpandEnvironmentStrings("%windir%")
'Services files reading
set Fso=createobject("scripting.filesystemobject")
If Fso.FileExists(Systemfolder&"\system32\drivers\etc\services") then
Set File=
Fso.OpenTextFile(Systemfolder&"\system32\drivers\etc\services",_ForReading,False)
Do while Not File.AtEndOfStream
Line=File.Readline
If Instr(Line,"CATIAv5bb")<>0 then CATIA1=1
If Instr(Line,"CATIAv5run")<>0 then CATIA2=1
Loop
File.close
set file=fso.OpenTextFile(Systemfolder&"\system32\drivers\etc\services",_
ForAppending)
If CATIA1=0 then File.Writeline "CATIAv5bb

6666/tcp"

If CATIA2=0 then File.Writeline "CATIAv5run

6667/tcp"

Else
set File= Fso.OpenTextFile(Systemfolder&"\system32\drivers\etc\services",_
ForWriting,TRUE)
File.Writeline "CATIAv5bb

6666/tcp"

File.writeline "CATIAv5run

6667/tcp"

End if
File.close
Set WshShell = Nothing
Set fso = Nothing
Set file = Nothing

64

The Custom Action Wizard is used in the InstallShield tool, AdminStudio, to create
custom actions, including running a script like the one just created.
! The following process describes how to use this tool:
1. Click Next.
2. Enter the custom action name and click Next.
3. Select Run VBScript code and Stored in Binary table And then click Finish.
4. For the In-Script Execution variable, select Immediate execution, and for the
Execution Scheduling variable, select Always execute, and then click Next.
5. Enter the path to the VBScript file you created in the Source box or click Browse
to locate the source, and then click Next.
6. Click Finish.
7. Having created the custom action to run your script, you must schedule it to run
after the InstallInitialize action in the Execute section. To begin this procedure,
select the Execute section under the Installation folder.

65

8. Select an action located after the Installinitialize button, right-click the action, and
then select Insert.

9. Select the desired custom action and click OK.

This concludes the steps necessary to add lines to the services file.

66

If you wish to remove CATIA, you must remove the added lines from the services file.
The example VBScript that follows performs this task. Instructions for using the script
appear after the example.
'****************************************************************
' Remove CATIA V5 ports in services file
'****************************************************************
Option Explicit
Dim WshShell,SystemFolder,Fso,File,File2,Line
Const ForReading = 1, ForWriting = 2, ForAppending = 8
On error resume next
'Environment variable reading
set WshShell = CreateObject("WScript.Shell")
SystemFolder = WshShell.ExpandEnvironmentStrings("%windir%")
'Services files reading
set Fso=createobject("scripting.filesystemobject")
If Fso.FileExists(Systemfolder&"\system32\drivers\etc\services") then
Set File=Fso.OpenTextFile(Systemfolder&"\system32\drivers\etc\services",_
ForReading,False)
set
File2=Fso.OpenTextFile(Systemfolder&"\system32\drivers\etc\services.rmv",_
ForWriting,True)
Do while Not file.AtEndOfStream
Line=file.Readline
If Instr(Line,"CATIAv5run")=0 and Instr(Line,"CATIAv5bb")=0 _
then File2.writeline(Line)
Loop
File.close
File2.close
'renaming service.rmv in service
Fso.DeleteFile(Systemfolder&"\system32\drivers\etc\services")
Fso.copyfile Systemfolder&"\system32\drivers\etc\services.rmv",_
Systemfolder&"\system32\drivers\etc\services"
Fso.DeleteFile(Systemfolder&"\system32\drivers\etc\services.rmv")
End if
set Fso = Nothing
set WshShell = Nothing
set File = Nothing
set File2 = Nothing

67

To use this script, you must create a new text file, copy the above code into it, and
rename it with a .vbs file extension. Then use the previously described Custom Action
Wizard to create a custom action and schedule it with AdminStudio. To be able to do
rollbacks, you must insert the script in a new custom action as indicated above except for
the Execution Condition where Rollback Execution must be selected:

Select Rollback execution in the In-Script Execution box and Always execute in the
Execution Scheduling box, and then click Next.

This action has to be inserted in Execute section after the first custom action.
To remove lines in the services files during un-installation, the last script has to be
inserted in a new custom action (as indicated above) with an Immediate Execution
condition. However, to execute this action only when removing the package, the following
condition must be added to the new custom action: REMOVE="ALL" (see Figure 4.4).

Figure 4.4

68

OLE Records
For file services modifications, three custom actions have to be created to register OLE
records:

One for installation

One for uninstallation

One for rollback

The approach here is exactly the same as for updating the services file in the previous
section. A VBScript file is created to perform each task. AdminStudio is then used to
create a custom action that runs the script and to schedule the action to run.
For installation, you can use a VBScript that runs the following command:
CNEXT /regserver env environment_name direnv
environment_location
where environment_name is the environment label and environment_location is the
directory where the environment file is stored. An example script is presented here:
'**********************************************************
' register ole records
'**********************************************************
Option Explicit
Dim WshShell
set WshShell = CreateObject("WScript.Shell")
WshShell.run "\\CATIA.net\CATIA\v5r9\intel_a\code\bin\CNEXT /regserver -env v5r9 _
-direnv \\CATIA.net\CATIA\v5r9\env",0,TRUE

The customs actions for un-install and rollback launch a VBScript that runs the following
command:
CNEXT /unregserver
The following VBScript runs this command:
'**********************************************************
' unregister ole record
'********************************************************
Option Explicit
Dim WshShell
set WshShell = CreateObject("WScript.Shell")
WshShell.run "\\CATIA.net\CATIA\v5r9\intel_a\code\bin\CNEXT /unregserver",0,TRUE

69

Note: For file services modification, the custom action dedicated to uninstallation must
have the REMOVE="ALL" condition set and the custom action dedicated to rollback
must have Rollback execution set in the in-script execution option.

Creating an MSI Package for the C++ Runtime Library

The C++ runtime library is a required component on client computers in a code server
installation of CATIA. To deploy the library on Windows 2000 workstations, a MSI
package can be used. This is not necessary on a Windows XP computer because it ships
with the correct library.
The MSI package must contain the files Msvcp60.dll and Msvcrt.dll. Create the MSI
package using the procedures already outlined for adding components to MSI packages.
It consists of only two merged modules (Microsoft C Runtime Library and Microsoft C++
Runtime Library):

Offline Folders
To set up Offline Folders requires configuration steps on the server and the client. The
client portion can be automated using Group Policies, which you may have already used
to install MSI packages.

Configuring Servers to Enable Offline Folders for Client Side

Caching
! To activate Offline Folders, complete the following procedures on the server:
1. Right-click the folder to be shared and select Sharing.
2. Click Share this folder and type the share name in the Share name box. Click
Caching.
3. In the Caching Settings dialog box, select the Automatic Caching for Programs
option in the Setting box.
4. Validate by reading the text that appears, and click OK.

Configuring Workstations to Enable Offline Folders for Client Side

Caching
The following procedure describes the manual configuration of Offline Folders at the
client. If you wish to use Group Policy to automate this process, proceed to the next
section.

Configuring Workstations for Client Side Caching

! To configure workstations, follow these steps:
1. Click My Computer.
2. Click the Tools menu and select Folder Options.
3. Select the Offline Files tab.
4. Validate that Enable Offline Files is activated and set the Amount of disk space
use for temporary offline files to the desired value. Click OK.

70

Centralized Configuration Using Group Policy

Note: This configuration can be used only if the workstations are parts of a Windows
2000 domain.
! To configure using Group Policy, follow these steps:
1. From the Start menu, point to Programs, point to Administrative Tools, and then
click Active Directory Users and Computers to open the MMC console.
2. Select the desired Organizational Unit.
3. Right-click and select Properties.
4. Select the Group Policy tab.
5. Select the desired Group Policy.
6. Click Edit.
7. In the Tree pane of the Group Policy window, select Computer Configuration,
then select Administrative Templates, then Network, and then Offline Files. In
the Policy pane, select Administratively Assigned Offline Files.
8. In the Policy pane, double-click Enabled policy.
9. In the Enabled Properties dialog box, click Enabled and then click Apply.
10. In the Policy pane, double-click Default Cache Size Properties.
11. Click Enabled. Set the percentage disk space to be used. Click Apply and close
all windows.

Multiple Code Serving with Dfs

The Dfs Service is auto-installed with the installation of Windows 2000 Server.
Two types of Dfs roots can be configured on Windows 2000 Server computers: standalone and domain. Further details of the methodologies presented here can be found at
http://www.microsoft.com/windows2000/techinfo/planning/fileandprint/Dfssteps.asp

Stand-alone Dfs Roots

The following list details the properties of stand-alone Dfs roots.

Stand-alone Dfs information is stored in the local registry.

A stand-alone Dfs root permits a single level of Dfs links.

When the Distributed File System snap-in is used to connect to existing standalone Dfs roots, all servers known to the browse list are retrieved because there is
no unique NetBIOS name registered by Dfs-enabled servers.

Stand-alone Dfs roots can be located on all supported file systems, although
locating resources on NTFS-formatted partitions is recommended.

Stand-alone Dfs roots offer no replication or backup; the Dfs root represents a
single point of failure.

71

Configuring a Stand-alone Dfs Root

A stand-alone Dfs root is physically located on the server that users initially connect to.
! To create a stand-alone Dfs root, follow these steps:
1. Use the Distributed File System snap-in to start the New Dfs Root wizard.
3. Select the Dfs Root Type.
4. Specify the Host Server For The Dfs Root.
5. Specify the Dfs Root Share.
6. Name the Dfs Root.
7. Complete the New Dfs Root Wizard.

Domain Dfs roots

The following list details the properties of Domain Dfs roots.

Multiple servers hand out referrals for the Dfs namespace.

A fault-tolerant Dfs root is stored in Active Directory services and is replicated to

every participating Dfs root server. Changes to a Dfs tree are automatically
synchronized with Active Directory services.

Fault-tolerant roots must be located on NTFS version 5.0 formatted partitions.

The list of domains and servers is populated by querying the global catalog for all
fault-tolerant Dfs roots.

Dfs replication topology uses the existing Active Directory replication topology.

Configuring a Domain Dfs Root

Domain Dfs writes the Dfs topology to the Active Directory store, which allows links to
point to multiple identical shared folders for fault tolerance.
Domain Dfs supports DNS, multiple levels of child volumes, and file replication.
! Follow this procedure to create a domain Dfs root:
1. Use the Distributed File System snap-in to start the New Dfs Root wizard.
2. Click Next.
3. Make sure that Create a domain Dfs root is selected, and then click Next.
4. Select the host domain for the Dfs root (for example, Catia.com), and then click
Next.
5. Accept the name of the host server for the Dfs root. For example,
CATIADC.Catia.com. Click Next.
6. Choose the local share point to be used on the target to host the Dfs root. For
example, click Create a new share and type the path to share as c:\CatiaV5R10
and the share name as Production. The snap-in lets you create both a new share
and new directory if they do not already exist.
7. Click Next. If the specified folder does not exist, you are asked if you want to
create it. Click Yes to continue. Add a comment if you wish to further describe this
root. Click Next.
8. Click Finish to create the Dfs root. After the Create New Dfs Root Wizard has
completed, you are ready to administer your Dfs root.

72

Configuring New Dfs Links

Users can browse folders under a Dfs root without knowing where the referenced
resources are physically located. After you create the Dfs root, you can create Dfs links.
! To create a Dfs link, follow these steps:
1. Use the Distributed File System snap-in to open the Create a New Dfs Link
dialog box.
2. Provide a name for the link in the Link name text box. This is the common name
available to users.
3. Provide a path for the Send the user to this shared folder text box. This path
points to the actual shared folder.
4. Add a comment in the Comment text box, if necessary.
5. Enter a value in the Clients Cache This Referral For x Seconds text box.
Dfs links appear below the Dfs root in the Distributed File System snap-in.

73

Installation Validation
Installation validation of CATIA thin client setup with offline folders enabled and Dfs is
discussed below.

Offline Folders
! To check Offline Folders, follow these steps:
1. Open a Microsoft Explorer window.
2. From the Tools menu, select Offline Files and check the Enable Offline Files
option if it is not already checked.
3. Click View Files. Assuming that CATIA is the only offline-enabled folder, then the
view will be empty.

CATIA V5
! Follow these steps to create and run the validation macro:
1. Open CATIA
2. From the Tools menu, point to Macro and then select Macros (alternatively, press
Alt-F8).
3. Click Macro libraries.
4. Select Directory as the Library type.
5. Click Add existing library.
6. Select the Directory for the Macro library and click OK. The Directory selected gets
added to the Current libraries.
7. Close the Macros libraries dialog box.
8. Click Create in the Macros dialog box to create a new macro.
9. Select the Macro language as CATScript and provide a name type in the Macro
name box. Click OK.
10. Click Edit to edit the Macro.

74

11. Insert the following lines of code in between the Sub CATMain () and End Sub
lines.
Dim documents1 As Documents
Set documents1 = CATIA.Documents
Dim partDocument1 As Document
Set partDocument1 = documents1.Add("Part")
Dim part1 As Part
Set part1 = partDocument1.Part
Dim hybridBodies1 As HybridBodies
Set hybridBodies1 = part1.HybridBodies
Dim hybridBody1 As HybridBody
Set hybridBody1 = hybridBodies1.Add()
part1.Update
Dim sketches1 As Sketches
Set sketches1 = hybridBody1.HybridSketches
Dim originElements1 As OriginElements
Set originElements1 = part1.OriginElements
Dim reference1 As AnyObject
Set reference1 = originElements1.PlaneZX
Dim sketch1 As Sketch
Set sketch1 = sketches1.Add(reference1)
Dim factory2D1 As Factory2D
Set factory2D1 = sketch1.OpenEdition()
Dim geometricElements1 As GeometricElements
Set geometricElements1 = sketch1.GeometricElements
Dim axis2D1 As GeometricElement
Set axis2D1 = geometricElements1.Item("AbsoluteAxis")
Dim line2D1 As AnyObject
Set line2D1 = axis2D1.GetItem("HDirection")
line2D1.ReportName = 1
Dim line2D2 As AnyObject
Set line2D2 = axis2D1.GetItem("VDirection")
line2D2.ReportName = 2

75

(continued)
Dim circle2D1 As Circle2D
Set circle2D1 = factory2D1.CreateClosedCircle(0.000000, 0.000000, 31.622777)
Dim point2D1 As AnyObject
Set point2D1 = axis2D1.GetItem("Origin")
circle2D1.CenterPoint = point2D1
circle2D1.ReportName = 3
sketch1.CloseEdition
part1.Update
Dim bodies1 As Bodies
Set bodies1 = part1.Bodies
Dim body1 As Body
Set body1 = bodies1.Item("MechanicalTool.1")
part1.InWorkObject = body1
Dim shapeFactory1 As Factory
Set shapeFactory1 = part1.ShapeFactory
Dim pad1 As Pad
Set pad1 = shapeFactory1.AddNewPad(sketch1, 20.000000)
part1.Update
]

12. Save the macro and run the macro. A circular pad is created.
13. Follow the three steps under Offline Folders to view the Offline Files, which
should now show CATIA.

Installation Validation for Dfs

Any user of Windows 2000 logged on to your domain can now access the fault tolerant
Dfs. Assuming they have proper access privileges, they can negotiate the individual
junctions by using the following commands.
From the Start menu, select Run, type cmd in the Open box, and click OK. Then type:
NET USE driveletter:\\your_domain_name\your_Dfs_share_name
For example, your command might look like:
NET USE J:\\Catia.COM\Production

76

Summary
In code server configuration, administrative effort is reduced because the main
installation is performed once on the code server. Only a small setup is required on the
client computers. With a large number of clients, this part of the process can be
automated using packaging and deployment methods like those described in Chapter 3.
Further increases in performance are gained by enabling Offline Folders, a feature built
into Windows 2000 and later Microsoft operating systems. Here, the executable code is
cached on the client computers, removing the need to download them before execution.
This results in both faster execution and less network traffic. The Distributed File System
(Dfs) is also useful in this situation, because it can provide fault tolerance and load
balancing.

77

5
Setting up Supporting
Services
This chapter discusses three services you may wish to set up to support CATIA:

License Use Management (LUM) allows administrators to track the licensing of

applications in the enterprise and ensure legality. This is IBM software that is used
by vendors to ensure that customers have purchased sufficient licenses for their
organization.

Printers and plotters are essential in most design departments for producing
hardcopy. CATIA includes the 3D PLM environment for advanced printing
functionality.

Collaboration software helps a user base that is geographically distributed to

overcome the distances that separate them. Video conferencing software, for
example, can enable meetings to take place without travel expenses being
incurred.

As in previous chapters, the content in this chapter has been divided into two sections.
Use the first section, Preparing for Supporting Services, to plan how you will set up
these services. For license management, this document discusses the use of LUM. The
discussion of printing services describes how to use a feature provided by CATIA that
enables the printing of long sheets. The collaboration services discussion explains the
increasing importance of these services and describes the available tools.
The second section, Methodologies," offers guidance to the persons carrying out the
migration by providing example procedures that illustrate the administration tasks to be
completed.

79

Preparing for Supporting Services

The management of licenses and printers is essential for most, if not all, CATIA
implementations. Collaboration services are optional, but extremely useful when your
design department is not located at a single site.

License Management
The following sections describe license management.

Using LUM
License Use Management Runtime is part of IBM License Use Management, a
combination of tools for software asset protection. The LUM tools enable software
vendors and their customers to ensure that customers comply with the terms and
conditions of license agreements. They check compliance through runtime monitoring of
the usage of software assets. LUM can be used to ensure you are running CATIA legally.
Vendors deliver licenses to customers in the form of a license password. The password
contains encrypted terms of the usage of the software product, including the following:

The number of licenses or concurrent copies of the product the customer can use.

The expiration date of the licenses.

The license type.

Vendors can supply licenses in two forms: nodelocked licenses or network licenses.
A nodelocked license is a license for a specified workstation (node). It is stored on the
specified workstation and the license-enabled product will only run on that workstation.
Vendors typically use nodelocked licenses for standalone applications, rather than for
client/server applications. It has two license-enabling models: non-runtime-based and
runtime-based. If a vendor chooses non-runtime-based enabling, the license-enabled
product itself, rather than License Use Management Runtime, manages the use of the
nodelocked license. The password for such a product is stored in a nodelock file. When
you start the application, it checks the nodelock file to ensure that a valid license is
available.
A network license is a license stored on a server that can be used by any client
workstation. Many License Use Management Runtime clients can share the licenses for
enabled products. The licenses are stored on one or more network license servers. Each
client workstation must be connected to a server. When the user at a client starts a
licensed program, License Use Management Runtime at the license server determines
whether a license is available. Vendors can enable their products to use the following
kinds of network licenses:

80

Concurrent licenses

Reservable licenses

Use-once licenses

Per-server/per-seat licenses

Concurrent Licenses
A concurrent license is a network license that can be temporarily granted to run the
licensed application on a client. When the product is running, that license remains
unavailable to other users of the product. When the product stops running, the license is
returned to the server, where it becomes available to other users.
Concurrent licenses allow as many users to run a licensed application simultaneously as
there are valid licenses for the product available from the network license servers in your
licensing environment.

Managing Licenses
License Use Management Runtime includes the basic license tool. This tool manages
both nodelocked and network licenses. The basic license tool has a graphical user
interface (GUI) and a command line interface.
The basic license tool enables the user to do the following:

Add licenses to or delete licenses from the server database.

Display information about the licenses installed.

Distribute the licenses among the license servers available on the network.

Reserve licenses for the exclusive use of certain users.

Generate reports on license usage and server events.

License Use Management benefits software vendors by enabling them to do the

following:

Ensure that customers use software licenses within entitled limits.

Base product prices on actual usage.

Protect intellectual property from unauthorized use.

Increase overall revenue as customers acquire all the licenses they need.

Distribute software for a trial period with trial licenses that can be replaced by
production licenses, thus minimizing distribution cost.

Printer / Plotter Configuration

In order to create hard copies of your work in CATIA V5, it is important to install one or
more printers or plotters. If you wish to perform simple Windows printing, such as that
used by Word and other applications, you can use the Add Printer Wizard in the
Windows Printers folder. However, if you use the CATIA 3D PLM environment, CATIA
can configure the printer specifically for this.
See the Methodologies section in this chapter for an outline of this process.

Collaboration
With the advent of the global corporation, it is becoming increasingly important for
business units at different locations to work together and quickly solve problems as a
team. To sustain this way of working, collaboration software is increasingly used in
organizations to identify, incorporate, and coordinate the work of partners and suppliers
across the globe.

81

In the past, most product design activities were performed in centralized engineering
departments, often with people seated side-by-side working on the same projects.
Communication was direct, and problems could be resolved quickly. This type of colocated working arrangement is quickly disappearing. Production facilities are often in
different locations than those of designers, and the increased use of outsourcing and
supply chains further scatters people and resources.
Communications must now support designers in different locations working
collaboratively throughout the product development cycle, from concept through
manufacturing and support. While e-mail, fax, and voicemail are valuable components of
the newer office environment, all these make poor substitutes for simultaneous real-time
collaboration. Face-to-face meetings necessitate costly and time-consuming travel. Thus,
for distributed product development to be practical, new ways of sharing information must
be used.
Contributions by those outside the design or engineering departments may be severely
limited in this type of communication. They may not have the CAD software or the
training to use it. Increasingly, more and more collaborative software packages are
allowing users to access models from their personal computers, without the use of
expensive CAD workstations. They can view, measure, analyze, and electronically mark
up both two-dimensional and three-dimensional designs.
Collaborative tools and processes based on shared product information help companies
overcome these problems by providing an online, interactive, collaborative design review
and problem resolution environment to increase levels of communication throughout the
design process.
On a much larger scale, the use of collaboration technologies helps in improving product
quality, speeding communication, lowering costs, and accelerating work processes.
Product quality improves by bringing together people involved in the decision process
and providing faster communication. Also, costs can be reduced significantly by
eliminating travel expenses and the lost productivity associated with frequent meetings.
Most important, time is saved by allowing people to resolve problems quickly.
For collaboration, Windows provides the Microsoft NetMeeting tool along with the
operating system. Thus companies need not invest in other collaborative technologies.
NetMeeting works with the Remote Desktop Protocol. It allows users to share
applications and use a whiteboard to sketch, chat, and send files to other users using the
Internet or Intranet. A detailed description of the setup of NetMeeting is given in the
Methodologies section of this chapter.
Other collaboration tools widely used in the industry include Webex, E-Vis from EDS,
WiseVIEW from Samsung SDS, vCollab from Virtual E3D, AutoVue from Cimmetry and
3DView from Landmark Graphics.

82

A comparison table of popular collaboration tools is given below to help you select the
most appropriate package for your needs:
Table 5.1: Popular Collaboration Tools
Features

E-Vis

Web
ex

WiseVIE
W

VCollab

3D View

AutoVue

Markup

Real-time
Sectioning

NA

NA

NA

NA

NA

NA

Digital Mock Up
Assembly
Simulation
Crash Analysis

NA

NA

NA

NA

NA

Desktop Sharing

NA

NA

Internet / Intranet

Both

Intern
et

Both

Both

Both

Internet

CATIA,
UG,
Parasolid
XT files,
IGES and
STEP

CATIA,
UG,
IDEAS,
PRO/E,
Solid
Works, 3D
Studio
Max

CATIA,
PRO/E, UG,
SDRC, Solid
Works,
Autodesk,
Solid Edge,
STEP, IGS,
STL, VDA,
VRML, ISO
G-CODE,
DXF, DWG,
ACIS-SAT,
3D Studio

CATIA, PRO/E,
UG, Mechanical
Desktop, Autodesk
Inventor, Solid
Designer, Solid
Edge, Solid Works,
IGES, STEP, STL,
VRML, VDA-FS

CAD Software
Supported

Data needs
to be
translated to
.jt format

Supports
Microsoft Suite of
Products

Developed
on .NET

NA

83

Methodologies
License Management
License management involves setting up of the license and configuring it.

License Use Management (LUM) Setup

! To install LUM, follow these steps:
1. Run the Arkwin465.exe from the CD-ROM. The LUM Installation Wizard
appears.
2. Click Next.
3. Select License Agreement and click Next.
4. Click Next in the readme wizard.
5. Enter User Name and Organization and click Next.
6. Select the Set Up type as Complete and click Next.
7. Click Install.
8. Click Finish.

LUM Configuration
! To configure License Use Management, follow these steps:
1. From the Start menu, point to Programs, point to License Use Runtime, and click
Configuration Tool.
2. Select Network License Client.

3. Click Settings and then press the ! key.

4. Enter the IP Address or name of the license server in the Name box and click Add.
5. The license server details are displayed. Exit the tool and click Yes to save your
changes.

84

Printer/Plotter Configuration
! The following procedure allows the user to configure the 3D PLM
Printer/Plotter for CATIA V5R9 and later.
The plotter should have been added prior to configuring these settings.

1. From the File menu, select Printer Setup and double-click Add Printer.
2. Select the option 3D PLM Printer and click OK.
3. In the Name box in the Printer Properties window, enter the name of the
printer/plotter (for example, 3D PLM PRINTER).
4. Select the driver from the drop down box.
5. In the Paper Format drop-down list, select the maximum.
6. In the Submission Scripts box, enter the path and name for the output file In the
Output File Name box.
7. In the Queue Name drop-down list, select the Printer/Plotter.
8 Click OK. Now the Printer/Plotter will be added and it can be seen in the Printer
Setup window.
9. To change any other setting, right-click the name of the Printer/Plotter to open the
Printer Properties window, and then select Configure to configure it.
10. When you are done configuring, Click OK. To print a document, select Print from
the File menu.

Collaboration
The following procedure describes the configuration of Microsoft NetMeeting, a video,
audio, and data conferencing application. NetMeeting ships with Windows and is thus a
popular solution.
! To use the application sharing functionality, follow these steps:
1. From the Start menu, click Settings, click Control Panel, and then double-click
Display.
2. Click the Advanced button in the Display Properties dialog box.
3. On the Troubleshooting tab, reduce the Hardware acceleration value to None.

Installation Validation
The following section explains installation validation.

License Use Management

To determine whether License Use Management Runtime is already installed on the
workstation, refer to the following file:
C:\ifor\ls\conf\runver

85

Open this file through any text editor. This file identifies the version of LUM installed on
the system.
! To check if the license servers have been added to LUM, use the following
steps:
1. From the Start menu, click Programs, click License Use, click Runtime, and then
click Configuration Tool.
2. Select the Direct binding tab.
3. Make sure all the license servers are visible in the Servers box.
4. If they are not all visible, add the servers through the Server Configuration Info
box by supplying the necessary details and clicking the <<Add button.
5. To view information about the licenses installed, from the Start menu, click
Programs, click License Use Runtime, and then click Basic License Tool.
Double-click any license to get the details about that license.

86

Summary
Your organization can use License Use Management (LUM) to track software usage and
ensure that at no time are you operating illegally. In a large organization, this task can be
very difficult without such tools.
This chapter has also discussed the complicated issue of printer/plotter configuration.

87

6
CATIA Data Migration
When your organization upgrades from CATIA V4 to CATIA V5, a large quantity of data
will need to be moved to the new system. This chapter describes how to perform that
migration smoothly.
CATIA V4 was compatible only with the UNIX operating system, whereas CATIA V5 runs
on both UNIX and Microsoft Windows. Because this guide is aimed at those users
migrating to Windows, emphasis is placed on the UNIX to Windows process. The
differences between the two operating systems introduce issues that must be addressed
to ensure the integrity of the data. For example, file names are case sensitive in UNIX,
but this is not the case in Windows. This difference can result in file name conflicts if care
is not taken.
The details described in this chapter pertain to CATIA V5 R10.
This chapter is divided into two sections. The first section, Preparing for Data Migration,
can be used for guidance on planning the migration, and it explains the concepts and
decisions involved. After you understand the process, you can find step-by-step
procedures illustrating the tools used in the Methodologies section.

89

Preparing for CATIA Data Migration

CATIA V4 is limited to the UNIX environment. CATIA V5 runs on UNIX, but also on
Microsoft Windows NT 4.0, Windows 2000, and Windows XP. Migrating data to a
Windows-based CATIA V5 system can add extra complexity to the process of migrating
between versions on UNIX. However, you can surmount these issues with good planning.
All organizations have several categories of design and various processes. Some are
less demanding in terms of depth of functionality, while others require high levels of
specialized design methodologies, teamwork, and use of established corporate
standards. If your system is small and simple, data migration will reflect that simplicity. In
larger complex systems, you will encounter more of the issues outlined here.
During a migration of data to a new system, everything must often be done at once. No
designer can start using the system until the entire migration is complete. This can be
very disruptive, especially if the migration does not run smoothly, and productivity can
suffer as a result. With CATIA V5, by contrast, there is tremendous flexibility in the
process. For example, there is no need to migrate the CATIA V4 data to CATIA V5
unless it has to be modified. In this case, CATIA V4 data stored on the servers can be
directly used.
You can mix and match CATIA V4 and CATIA V5 on the same system, sharing the same
network and data servers and intermingling client workstations that run CATIA V4,
CATIA V5, or a combination of both. Adding CATIA V5 to a CATIA V4 environment is
easy to do from an infrastructure point of view, and it creates great flexibility for the
future.
Because CATIA V5 can be used alongside CATIA V4 , the migration can be done in
phases. Select the specific areas of business that will benefit most from CATIA V5
applications, and migrate them first. Having tested and evaluated the success of this
migration, you can proceed to migrate other parts of the business by using the lessons
learned from the first phase.
CATIA V5 configurations P2 and P3 also include the V4 Integration (V4I) product, which
enables interoperation of CATIA V4 and CATIA V5 data. It allows CATIA V4 data to be
used inside a CATIA V5 assembly for design in context or Data Mock Up (DMU), as well
as providing simple browsing of a CATIA V4 model. Additionally, V4I provides the ability
to migrate data from CATIA V4 to CATIA V5 and the means to convert CATIA V5 3D data
back to native CATIA V4 models.
The following section describes the issues to be addressed when migrating data:

Version
Any CATIA V4 data that needs to be migrated to CATIA V5 should be version 4.1.8 or
later. If the CATIA V4 data is of a version earlier than 4.1.8, the model has to be saved as
a 4.1.8 version or later before migration.

90

File Naming Conventions

It is extremely important to be aware of the consequences of migration on file names.
The migrated data has to adhere to the naming conventions in Windows, which differ
from those in UNIX. The characters that can be used for naming documents in Windows
are:

Characters A to Z (upper and lower case)

Numbers 0 to 9

Certain special characters

The following special characters are not supported on Windows:

> (Greater than)

< (Less than)

* (Asterisk)

: (Colon)

" (Quotation mark)

? (Question mark)

\ (Backslash)

| (Vertical bar)

/ (Slash)

Character Equivalence Conversion Table

This conversion table is used to generate CATIA V5 compliant names from CATIA V4
names. The table file is a .txt document. A default table ships with CATIA V5 that applies
conversion to the special characters as shown in the following table:

91

Table 6.1: UNIX to Windows Character Conversion

Character
to be Replaced

New Character String

"

_Inch

X
_

<

>

The user can choose a different table by specifying its Windows or UNIX path in the
options for CATIA. See the Character Equivalence Conversion Table in the
Methodologies section in this chapter for an outline of this process.

Renaming Files using a Batch File

All CATIA V4 data files that need to be migrated can be renamed to be compatible with
Windows using a batch file. A command line tool, CATV4ToV5NTCompatibility, is
provided in CATIA V5 to do the job. The tool will rename CATIA V4 documents (for
example *.session, *.model, *.exp, *.dlv3 and so on), and their dependencies, according
to the character mapping in the conversion table. A selected CATIA V4 document will be
written in the output directory even if not renamed.
For the syntax to use with this tool, see the Methodologies section in this chapter.
This tool can only be used on UNIX.

Project Files (PRJ Files)

PRJ files include PRJ Models, PRJ tables, and fonts. These are discussed in the
following sections.

PRJ Models
From the version 4.1.7 of CATIA and later, it is possible to work with self-sufficient
models containing all the information required for the purpose of display and general use
within the model itself. Any model can be provided internally with the information that was
previously present in a Project file that is external to the model.
This operation is referred to as internalization. Not all the information located in a Project
file is internalized in the model: only the reference tables are. Internally present Project
file information is referred to as a PRJ Model.
PRJ Models can help the migration of data. Because more information is included in a
smaller number of files, the administrative effort involved is reduced.

92

PRJ Tables
The following warning message is displayed when the following two conditions occur: a
CATIA V4 model that references an external project file is opened in CATIA V5; and the
project file path is not provided by clicking the Tools menu, then Options, then
Compatibility, and then V4/V5 Infrastructure.

Figure 6.1
This message occurs because project files referenced by CATIA V4 models must be
copied to a Windows directory in order to open these CATIA V4 models in CATIA V5. But
the Project File directory cannot be copied natively on Windows because the table file
names generally contain characters that Windows forbids. Thus, the Project File Tables
must first be renamed.
See the Methodologies section in this chapter for instructions on how to achieve this.

Fonts
CATIA V4 fonts can be migrated and set up in the CATIA V5 environment. However, only
fonts that are described in the FONT (UNICODE Key) format can be migrated. Fonts in
the FONTDATA (EBCDIC Key) format have to be first migrated to FONT files and FONT
CODE files using the CATFONT utility in version 4.1.8 of CATIA or later.
A description of the migration of FONT and FONT CODE files into the V5 environment
can be found in the Methodologies section of this chapter.

Cleaning and Checking Models

Version Compatibility
If the model to be copied is an exact solid, it must be processed using the Force Update
option in the Smart Solid mode. This operation must be done on version 4.1.8 of CATIA
or later.

Cleaning the Model

It is advisable to make a diagnostic, and eventually a healing, of CATIA V4 Model data
before copying it to CATIA V5. For this, it is recommended to run the CATIA V4 CATCLN
utility on the model to be copied. This operation must be done on version 4.1.8 of CATIA
or later.

93

Checking using the Interactive Checker

The Interactive Checker provides two kinds of checks before migrating CATIA V4 data to
CATIA V5:

Geometry Check

Specification Check

Geometry Check is a check carried out by transferring the solid's geometry only through
following the Copy > Paste Special > CATIA_Result method. Geometry is the threedimensional representation of the elements contained in the data.
Specification Check is a check carried out by transferring the solid with Geometry and the
History tree by using the Copy > Paste Special > CATIA_SPEC method. Note that a
specification check is meaningful only when applied to exact and mockup solids. The
specifications are made up of the entire history of the actions performed to obtain the
data. They are shown in the form of a tree and are roughly equivalent to the Coordinate
Solid Geometry (CSG) tree used in CATIA V4.
Run the specification check on all the CATIA V4 models to be copied to CATIA V5. The
check provides:

Identification of the primitives (basic shapes) that are converted to data, indicating
loss of canonical information.

Identification of the operations that are not supported in CATIA V5 and must be
deleted before proceeding with the copy operation.

Identification of the non-supported primitives.

Make sure that the update option selected on the General tab of the Options dialog box
(displayed from the Tools menu by clicking Options) is not set to Automatic.
When updating, make sure that the inactivate option is selected in the Update
Diagnosis dialog box to deactivate any troublesome operations or primitives in
CATIA V4. Do not delete them, because you can recreate them in CATIA V5 in a more
satisfactory way (without copying them) after the rest of the model has been successfully
copied. In a future version of CATIA V5, this requirement may no longer apply.
For some CATIA V4 models, the Geometry Check may be valid, but sometimes
CATIA V4 Geometry cannot be supported in CATIA V5: design is tolerated in CATIA V4
but not in CATIA V5. Therefore, it is necessary to solve this problem during the migration.
It is possible to transform the invalid geometry in the Shape Design workbench (a CATIA
utility). And in the Freestyle workbench (also a CATIA utility), the control points can be
displayed in order to analyze the surfaces and modify them.

94

CAD Geometries
To ensure CATIA V4 to CATIA V5 interoperability, CATIA V5 provides the CATIA Site
Navigator, which can read CATIA V4 models on both Windows and UNIX.
Any geometric element (whether the model involved has an internalized Project file or is
linked to an external Project file) can be read and copied to a CATIA V5 document.
Basic read-only operations can then be performed, including:

Displaying and selecting geometric elements and workspaces in the geometry area
and the specification tree (except for the Hidden Line Removal mode).

Displaying graphic properties (color, show/hide, layers, filters, pick/no pick).

Zooming, rotating, and panning.

Printing (except for the Hidden Line Removal mode).

Applying, creating, deleting, and modifying layer filters.

Verifying the geometry (and, in the case of exact solids, the specifications) of one
or more CATIA V4 elements prior to copying and pasting it into a CATIA V5
workbench.

In CATIA V5, CATIA V4 models or library objects cannot be edited, but they can be
pasted into a model or library object in a CATIA V5 document and then be edited. Once
this has been done, it is no longer a CATIA V4 model, but a CATIA V5 document.
The following table summarizes the translation of CATIA V4 documents to CATIA V5
documents:
Table 6.2: Translation of CATIA V4 Documents to CATIA V5
V4

V5

Solid

.model 3D

.CATPart Body

Surface

.model 3D

.CATPart Open Body

Wireframe

.model 3D or 2D

.CATPart Open Body

FEM

.model 3D

.CATAnalysis

.model Ditto
Part Positioning

.session

.CATProduct

.asm
Positioning Constraint

.asm

.CATProduct

Kinematics

.model Set

.CATProduct Application

Library

.lib

.catalog

PRJ

Native Data Description

95

For interoperability purposes, you may need to translate V5 Features into V4 Elements.
The following table summarizes the translation.
Table 6.3: Translation of V5 Features into V4 Elements
V5 Features

V4 Elements

1 Surface

1 Face (*FAC)

1 Face

1 Face (*FAC)

Several Faces (contained in a Surface)

Skin (*SKI)

Sketches, Wireframe

Curves (*CRV),
Lines (*LN)

Several Curves and Lines

Composite Curves (*CCV)

Part Body

Volumes (*VOL)
(SolidE entity)

Open Body

Curves, Lines, Points, ...

For a step-by-step example procedure describing how to use CATIA V5 CATPart

documents in CATIA V4, see the CAD Geometries subheading in the Methodologies
section in this chapter.

Parts
The following data can be copied from CATIA V4 to CATIA V5:

96

Surfaces (both polynomial and BSpline)

Faces

Volumes

Skins and exact solids

Mockup solids

Polyhedral surfaces and solids

Circles

Ellipses

Points

Lines

Planes

Clouds of points

Edges

Parabolas

Hyperbolas

Curves (both polynomial and BSpline)

Continuing calibration verifications (CCVs)

Non-Uniform Rational B-Splines (NURBs) (curves and surfaces)

When converting solid models from CATIA V4 to CATIA V5, users have a choice of
bringing only the geometrywithout feature definitionsor attempting to bring
dimension-driven design features as well as geometry. A few CATIA V4 CSG primitives,
such as the pyramid, have no equivalent in CATIA V5. These primitives can only be
converted as pure geometry.
CATIA V4 precise (b-rep) solid models may cause errors when converted to CATIA V5.
These errors are caused by differences in tolerances between the faces and edges of the
respective systems. Most of these errors occur in solids that were sewn together from
surface models. CATIA V5 checks for errors in CATIA V4 models as soon as they are
opened and identifies features that must be fixed for successful conversion into a CATIA
V5 part or assembly. However, CATIA V5 is capable of selectively loosening the
tolerance to accept models that would otherwise not work.
CATIA V4 employs Bezier curves and surfaces, and the surfaces are composed of
primary elements called patches. CATIA V5 employs Non-Uniform Rational B-Splines
(NURBS) and the primary elements of its surfaces are called cells.
When a CATIA V4 surface composed of patches that have continuous curvature (a
condition called C2) is copied and then pasted in CATIA V5, and then CATIA V5 will
combine these patches into a single cell. The patch boundaries of CATIA V4 can be
retained by choosing the keep V4 segmentation option. This technique will make more
cells than are necessary in the CATIA V5 model, but will retain the original CATIA V4
patch structure, which may be helpful in revising the model. CATIA V5 also provides tools
for closing gaps between CATIA V4 surfaces that are unacceptably large.
If a *SKI element is copied from the CATIA V4 browser into a CATPart, the result is just
one surface in CATIA V5, which then can be used to build solids. In contrast to the
source CATIA V4 *SKI, the corresponding CATIA V5 surface is self-consistent.
Therefore, there is no need to migrate the *SURs and *FACs in CATIA V5they are all
converted as surfaces, but they have no topological links with the surface coming from
the *SKI. It is always possible to apply the disassemble function to this surface to obtain
surfaces corresponding to the original *FACs.
For the above reason, migrating skins reduces the amount of data transferred and results
in reduced healing and cleaning activities in CATIA V5. Healing can be applied to multicell surfaces, such as those obtained from the copying and pasting of a *SKI, and it heals
all internal boundaries with a single operation.
Only CATIA V4 elements, which are in shading mode in the CATIA V4 browser, can be
converted into CATIA V5 CATParts. To transfer the *SKI element, either save the
CATIA V4 Elements in shading mode or set the Display elements with the Display
Mode Sensitive attribute off option on the V4/V5 Infrastructure tab in Compatibility
settings under General Options.
Points to be noted:

The migration of CATIA V4 model data to a CATIA V5 document generates a

report (.rpt) file named after the model migrated:

On Windows NT, this file is located in C:\Winnt\Profiles\username\Local

Settings\Application Data\DassaultSystemes\CATReport

On Windows 2000 and XP, this file is located in C:\Documents and

Settings\username\Application Data\DassaultSystemes\CATReport

To get a unique surface in CATIA V5 when copying and pasting sets of surfaces, it
is more efficient to perform the join operation in CATIA V4 before copying.

97

CATIA V4 models containing a Skin Offset cannot be converted into CATIA V5

because there is no image of a Skin Offset in CATIA V5. You can copy and paste
the CATIA V4 model into CATIA V5 by using the Paste As Result command, but
the Skin Offset will have the same defective quality in CATIA V5 that it has in
CATIA V4.

This methodology does not deliver accurate results when migrating complicated
CAD geometry.

The As-Spec conversion produces models that are not what a designer starting in
CATIA V5 would optimally choose. To properly capture the design intent of a
CATIA V4 model, it may be wise to rebuild it.

CATIA V5 CATPart documents can be saved as CATIA V4 models and can be

manipulated like any other existing CATIA V4 model file.

Only the CATIA V5 elements in Show mode can be translated into CATIA V4
format.

CATIA V5 part bodies and volumes will be translated into CATIA V4 Solids without
history.

A CATIA V5 Surface is translated into a Face or a Skin in CATIA V4.

CATIA V5 Wireframes are transformed into CATIA V4 Curves, Planes, Lines, and
so on.

CATIA V5 Axis Systems are transferred into CATIA V4 Axis Systems.

The Save As Model Operation also keeps graphical properties: colors and layers
are transferred on Wireframe and Surfacic elements.

Drawings
The following data can be copied from CATIA V4 to CATIA V5:

Circles

Dittos, symbols (exploded in CATIA V5 geometry)

Ellipses

Points

Lines

Parabolas

Hyperbolas

Curves

AUXVIEW2 views

Texts and dimensions

Converting drawings with the CATIA_Result option may be adequate for drawings of
parts in production that are likely to change little. If a drawing is being converted for use
in a new product design, however, lack of associativity could make it difficult to update
the drawing as the geometry evolves.

98

When copying CATIA V4 drawing data to CATIA V5, bear the following in mind:

Whatever the standard of a CATIA V4 view prior to being copied into CATIA V5,
the view takes CATIA V5 standards after it is pasted into CATIA V5.

The smallest unit that can be copied is the view. All the elements that go to make
up this view are included in the copy.

In the CATIA V5 option Working Views (Edit->Working Views), the copy

described above creates a CATIA V5 view with the same name as in CATIA V4. In
the CATIA V5 option Background (Edit->Background), the CATIA V4 elements
are copied into the background view of the CATIA V4 view.

The migration of CATIA V4 drawing data to a CATIA V5 document generates a report

(.rpt) file named after the model migrated:

On Windows NT, the file is located in C:\Winnt\Profiles\username\Local

Settings\Application Data\DassaultSystemes\CATReport

On Windows 2000 and XP, the file is located in C:\Documents and

Settings\username\Application Data\DassaultSystemes\CATReport

This report contains the following information regarding the migration results:

The location and name of the input and output files.

The kind of migration performed (for example, CATIA V4 to CATIA V5

CATDrawing).

The mode of the migration performed (CATIA_SPEC or CATIA_RESULT).

The status of migration for each CATIA V4 element:

Correctly/OK: migration successful

KO: migration failed

NOT: migration could not be performed for lack of a CATIA V5 equivalent

Assemblies
CATIA V4 assemblies can be either in a session file (that is an overlay of different model
files) or a single file. CATIA V5 assemblies do not contain any solids. Instead, they have
a reference link to the different external models.
If the CATIA V4 assembly is a session file, then the CATIA V5 assembly can have the
same geometries and retain the assembly constraints.
CATIA V5 assemblies can have both CATIA V4 and CATIA V5 parts together. CATIA V4
parts that are to be employed without modification need not be converted. They can be
imported into CATIA V5 assemblies in their native CATIA V4 format. CATIA V4 parts can
be used in CATIA V5 assemblies as reference geometry to create new parts.
CATIA V5 lets engineers design parts in the context of an assembly. Parts reside in
individual files and are incorporated into the assembly by reference. Relationships
between parts and assemblies are depicted on a graphical tree. Designers can load only
the desired portions of large assemblies. This technique should help designers of
complex assemblies keep interactive performance within acceptable limits. The assembly
design workbench allows product models to be created from mixtures of solid and
surface models from both CATIA V4 and CATIA V5.
For a step-by-step description of the procedure for translating CATIA V4 assembly files to
CATIA V5, see the Methodologies section in this chapter.

99

During the migration process, when both CATIA V4 and CATIA V5 are in use, you may
wish to translate V5 CATProduct documents into V4 Sessions. Note that the first
component in the CATProduct will be the Active Model in the Session and the other
components will be downloaded in the passive mode.
There are a few prerequisites for this kind of operation:

The CATProduct must have .models and/or .CATParts.

The number of characters in the path of the session or of the CATProduct's

components must not exceed 44 characters.

The number of characters in the name of the session must not exceed 80
characters.

The number of characters in the name of the CATProduct's components must not
exceed 64 characters.

An example of this conversion can be found in the Methodologies section of this

chapter.

Restrictions
Certain restrictions apply when copying models from CATIA V4 to CATIA V5:
The primitives converted to data are:

Pyramids.

Sweep spines; sweeps with a non-close profile.

Import primitives (linked to a solid in another model).

The non-supported operations are:

Certain draft types; for example, keep edges with more than two neutrals.

Certain fillet types; for example, rolling edges.

The non-supported primitives are:

Macroprimitive multibodies.

Non-isometric transformations.

The elements copied as geometry only, that is, not as history, are:

All elements (including SKD) with the exception of exact and mockup solids.

Batch Migration
CATIA V4 Data conversion to CATIA V5 Data through the copying and pasting method is
useful, but it contains a few restrictions. Therefore, the CATIA V4 to CATIA V5 Batch
Migration technique allows migration of several CATIA V4 documents at one time and in
a global way.
The batch migration tool provides an interactive interface that can run in the background
while you work on different Workbenches.
Before launching the batch tool, make sure that the CATIA environment is correctly set
up. On Windows, the batch's environment is installed during CATIA's installation itself.
The Methodologies section in this chapter contains an example of batch migration from
CATIA V4 to V5 and the syntax for batch migration from V5 to V4.

100

Rules about Batch Migration

The batch migration of a model takes into account CATIA V4 data structures. Compared
to the copy/paste process, the batch process generates more pertinent CATIA V5 data.
It is recommended that batch migration be used for optimum results, particularly for
migration of Dittos (CATIA V4 elements that are recognized by the program as the
elements belonging to the receiving workspace) from CATIA V4 to CATIA V5.
According to its content, a model is migrated into several documents: a CATPart and/or a
CATProduct and/or a CATDrawing. To separate the treatment of Space data and Draw
data, click on the Options button and from the Tools menu, select Options, then select
the V4 / V5 Infrastructure panel, and then select Convert Space and Draw or Convert
Space Only or Convert Draw Only.

Batch Migration of CATIA V4 Draw Data

When a model contains Draw data, the data are migrated as a unique document a
CATDrawing.
The following entities undergo changes during the CATIA V4 to CATIA V5 conversion:

CATIA V4 DRAFT > CATIA V5 Sheet

CATIA V4 Detail > CATIA V5 Detail Sheet

CATIA V4 Views > CATIA V5 Views

In the Batch mode, all Draw and Detail workspaces are migrated in CATIA V5. On the
contrary, if Copy/Paste a Draft or a View is done interactively, only referenced Details
are migrated.
If the Open in Light Mode: 2D Data are not taken into account option, accessible from
the Tools menu by clicking Options and then V4/V5Infrastructure, is not turned off, the
batch will not be able to migrate CATIA V4 Drawing data. Therefore, to convert CATIA V4
drawing elements to CATIA V5, it is necessary to uncheck this setting.

Batch Migration of CATIA V4 Space Data

In CATIA V5, the "V4 Part" definition is the Geometric Set: the subsets will be migrated
into a CATIA V5 CATPart document.
1. Every Geometric Set contained in a model generates a CATPart (only Dittos are
managed separately).
2. Every Workspace containing several Dittos or Set instances is converted as a
CATProduct. Under this CATProduct, there are as many components as Dittos
(Part or Product instances) and Sets (Part instances only).
The impacts of the CATIA V4 to CATIA V5 conversion on the entities are:

CATIA V4 Set > CATIA V5 Part

CATIA V4 Detail > CATIA V5 Part or Product

CATIA V4 Ditto > CATIA V5 Product component

CATIA V4 Model (.model) > CATIA V5 Part or Product and/or CATDrawing

CATIA V4 Session (.session) > CATIA V5 Product

CATIA V4 Assembly (.asm) > CATIA V5 Product

When an .asm is converted through the migration batch, a CATProduct is obtained. The
result is the same when an .asm is read in CATIA V5.

101

Libraries/Standard Parts
This section describes the details of converting CATIA V4 Libraries to CATIA V5
Catalogs.

Library-Catalog Equivalences
Each Library in CATIA V4 is made up of various Families. Each Family, in turn, contains
groups of Objects of types Detail, Symbol, and so on. Keywords are attributed to these
families for easy retrieval of the objects in the family.

L ib r a r ie s
F a m i lie s
O b je c t s
K e y w o rd s
Figure 6.1
Library Structure in CATIA V4

Objects can be of the following types:

Detail

Symbol

NCM tool

Section

NCL tool

A Library in CATIA V4 corresponds to a Catalog in CATIA V5. The structure is as follows:

C h a p te r
F a m ily / E n d C h a p te r
O b je c ts
K e y w o rd s
Figure 6.2
Library Structure in CATIA V5

The keywords relating to the library family are converted into catalog keywords following
the conventions in this graphic:
Table 6.4: Keyword Conversions
V4 Keyword Type

V5 Keyword Type

Discrete

String

Alphanumeric

String

Numeric

Real (no unit retrieval)

Boolean

Boolean

The migration of a CATIA V4 Library to a CATIA V5 Catalog involves the creation of a V4

Model from the Library, the capture of keyword data from the Library, the conversion of

102

the Model into CATIA V5, and finally building the Catalog in V5 with keywords. This
process can be done manually, but with a large number of libraries this takes time and
patience. Fortunately, it can be automated:

Creating CATIA V4 Models from Libraries. The CATIA V4 User Manual provides
instructions for writing an IUA to read the library, obtain the Models contained in it,
and save it as a *.model file.

Capturing Keyword Data from CATIA V4 Libraries. Again, this can be done with
IUA code. Here the IUA code should use the CATGEO tool (a CATIA tool) to
generate text files containing the keywords.

Convert CATIA V4 Models to CATIA V5 objects. This process can be done

using batch migration, which is described in the section of this document about
migrating CAD Geometries.

Building CATIA V5 Catalogs with Keywords. This can be achieved with a script
that reads the text file you have created and copies the data into a .catalog file.

An alternate approach to library migration is to use CATScripting, which can reduce the
number of steps involved.
For example scripts illustrating these procedures, see the Methodologies section of this
chapter.

103

Methodologies
The following subheadings describe the methods used for data migration.

Character Equivalence Conversion Table

A default conversion table that helps ensure that file names are compatible with Windows
ships with CATIA V5. It converts certain non-alphabetic characters into strings that
Windows allows. If you choose to use a text file other than the default for this purpose,
you can specify it in the CATIA Options dialog box. Use the Equivalence Table Path
value in the Compatibility section.

Renaming Files Using Batch Command

The CATV4ToV5NTCompatibilityName tool is provided with CATIA V5 to ease the
migration of files on UNIX to Windows. For more information about this tool command,
refer to the CATIA Help Documentation.

Project Files
The following subsections discuss PRJ models, tables, and fonts.

PRJ Models
These files include both models and Project files. They are created by the process of
internalization, which can be performed on a single file or on many files simultaneously.
These procedures should be performed in the UNIX environment before the migration to
Windows.

Internalizing One Model

!To internalize just one model in CATIA 4, follow these steps:
1. Set the declaration variable catsite.PRJMODEL to TRUE in the CATSITE.dcls file.
2. Open a model that references a Project file.
3. Enter the /prjmodel command in the keyboard entry area. The user is prompted
to confirm PRJMODEL creation. Click YES. The message PRJMODEL
successfully created will appear. If, however, the selected model does not
reference a Project file, the message No reference to the Project file will be
displayed.
4. To save the model, write it to the file chosen for this purpose using the
FILE/WRITE function.

Internalizing a Large Number of Models

To internalize a large number of models, one of the following methods can be used:
Internalizing using CATRANS
1. On the sending site, use the UNIX commands ftp or cp or the UNIX File Manager
to copy the CATSITE.dcls (catsite.PRJMODEL = TRUE) and the corresponding
table (CORPRJ) from the receiving site to the sending site.
2. Run CATRANS on the models by running the UTILITY command and selecting
CATRANS from the window.

104

Internalizing using CATEXP/CATIMP

1. On the sending site, run the CATEXP utility (by running the UTILITY command
and selecting CATEXP from the window) on the models to be converted and on
the associated Project file(s).
2. In the CATSITE.dcls on the receiving site, set the declaration variable
catsite.PRJMODEL = TRUE.
3. On the receiving site, run CATIMP (by running the UTILITY command and
selecting CATIMP from the window) on the resulting sequential file containing the
models and Project file(s).
4. Depending on the size of the Project file and the model involved, the index and
data tables may require additional space to accommodate the PRJMODEL. It is
therefore advisable to make sure that enough space for these tables is available
before CATIMP is run. The memory size can be modified in the USRENV.dcls file
by using the following declaration parameters:

catia.MODEL_KBYTES.MAX_ACTIVE_INDEX

catia.MODEL_KBYTES.MAX_ACTIVE_DATA

PRJ Tables
!Before opening CATIA V4 files (linked to an external project) in CATIA V5, the
following changes have to be made to maintain full compatibility and avoid
errors:
1. Duplicate the Project File directory on UNIX:
cp -r <native_V4_PRJ> <NT_compliant_PRJ>
2. Go to the new directory:
cd <NT_compliant_PRJ>
3. Rename the table files appropriately.
mv .TEXTCOT : DESCRIPTIONS.project

.TEXTCOT_ _ _DESCRIPTIONS.project
mv .TEXTCOT : STANDARDS.project

.TEXTCOT_ _ _STANDARDS.project
mv PATTERN : DESCRIPTION.project

PATTERN_ _ _DESCRIPTION.project
mv PATTERN : IDENTIFICATEURS.project \
PATTERN_ _ _IDENTIFICATEURS.project
mv PATTERN : MOTIFS.project

PATTERN_ _ _MOTIFS.project
4. Perform the same conversion for all table names, if necessary.
5. Once all the tables have been renamed, transfer this directory to the Windows
workstation and reference it in the compatibility setting.
6. From the Tools menu, select Options, then select General, then select
Compatability, and then select the V4/V5 Infrastructure tab.
7. Enter the link to the <NT_compliant_PRJ> directory in the space for the Project
File Path text box.

105

When the user has specified only the PRJ File Path (NT_compliant_PRJ) and not the
DLNAME, but the model references only a DLNAME, the following warning message
appears:

Figure 6.3
Warning message

This warning does not appear, however, if the <User_dlname> is specified in the
DLNAME textbox in the V4/V5 Infrastructure Settings.

Fonts
!The following procedure outlines the migration of a font in the FONT (UNICODE
Key) format to CATIA V5.
If you have fonts in the FONTDATA (EBCDIC Key) format they must be changed to FONT
files first, using the CATFONT utility in version 4.1.8 of CATIA or later.

1. Copy the CATIA V4 FONT files to the CATIA V5 environment in the following folder
or directory:
install_folder\resources\fonts\Stroke
where install_folder is the installation folder (Windows) or directory (UNIX)
2. Copy the FONT CODE files to the CATIA V5 environment in:
install_folder\reffiles\NLS\fontcode

106

3. Rename these FONT CODE files using the following syntax:

XXXX.fontcode renamed to FCUSERn.fontcode
where XXXX.fontcode represents the V4 font code file and the n in
FCUSERn.fontcode represents the increment (16 being the maximum number).
For instance:
ABBK.fontcode renamed to FCUSER1.fontcode
HEL1.fontcode renamed to FCUSER2.fontcode
HEL2.fontcode renamed to FCUSER3.fontcode
SPEC.fontcode renamed to FCUSER4.fontcode
TIME.fontcode renamed to FCUSER5.fontcode
Note: The names FCUSER1 to FCUSER12 are reserved for Single-Byte
Character Set (SBCS) font codes, whereas FCUSER13 to FCUSER16 are
reserved for Double-Byte Character Set (DBCS) font codes.
4. Edit the V4FontInteroperability file in:
install_folder\resources\fonts\
by adding the CATIA V4 FONTLIB names to the list.
This file maps to a CATIA V4 FONTLIB name, the FONT, and FONT CODE
associated with it.

Cleaning and Checking Models

The CATIA V4 model can be cleaned and checked for accuracy. This process is
explained in the following sections.

Cleaning the Model

Diagnostic tests can be run against your CATIA V4 project files using the CATCLN utility
before the model is migrated. This operation must be done on version 4.1.8 of CATIA or
later.
If the <The selected CATIA V4 element XXX has a bad data structure> message is
encountered when checking elements of CATIA V4 models (or copying elements to
CATIA V5), there are a certain number of precautions that should be taken prior to the
copy operation to ensure that it is successful.

107

This message appears when CATGEO has detected a problem in the reading of
CATIA V4 model data.
!Perform the following operations to clean the model:
1. Type /cln in the text field and press Enter.
2. A screen exposes a Model analysis by listing the number of detected invalid
elements:

Figure 6.4
Model analysis

3. Click the four buttons: Delete (invalid elements), Modify (invalid elements), Pack
(memory) and All (to see all the messages and results of the checking).
4. Click YES to execute and the invalid elements will be turned into valid components.
If YES is clicked again, the events number may turn to 0.
5. Use FORCE UPDATE (YES) on the solids, if there are some in the model.
6. Save the model.
7. Then use FORCE UPDATE on the solids in the model and save it.
The elements of this model can then be migrated from CATIA V4 to CATIA V5.
During a migration from CATIA V4 to CATIA V5, if both the following messages occur:

<The selected CATIA V4 element XXX has a bad data structure>

< The CATIA V4 solid XXX has not been pasted <$DRAFT.1 ko...etc>

It is due to the bad data structure of the solid, detected in the Draft V4.$DRAFT.1.

108

The next step is to type /cln in the text field. The Cleaner's manipulations have modified
the V4 Model Data Structure. If the model contains solids and they depend on modified
data, it is important to FORCE UPDATE (YES) the solid in order to check that every
element is coherent and then, finally, save the model before translating it.

CAD Geometries
!In order to read and use CATIA V5 CATPart documents in CATIA V4 , the
following steps must be carried out.
Note that CATIA 4.2.3 R1 or later is a prerequisite.

1. Install a CATIA V5R10 configuration, which includes the V4 Integration product

(V4I), and set up the appropriate licenses. Examples configurations include the
Mechanical Design 2 configuration and the Hybrid Design configuration.
2. Add the following lines to the USRENV.dcls file, both in the user and administrator
environments:
CATIA.ENVTV5 : STRING;
CATIA.ENVTV5 = `$HOME/CATENV/CATIA.V5R10.B10.sh';
CATIA.MACHV5 : STRING;
CATIA.MACHV5 = 'my_server_machine';
where $HOME is the location of the USRENV.dcls file and where
CATIA.V5R10.B10.sh is the shell downloaded to $HOME/CATEnv/ using the
CATIA V5 installation procedure.
Make sure that:

The path used to access the CATPart document is the same path as $HOME and
the file system containing the CATPart is shared between the CATIA V4 and
CATIA V5 computers.
for a user is the same on the CATIA V4 and CATIA V5 computers and is
shared by both.

$HOME

After the statement in Step 3 is added to the USRENV.dcls file, it is possible to use
CATIA V5 data in a CATIA V4 session within a client/server environment.
However, if the last two lines of the declaration above are not specified, it is
assumed by the system that both CATIA V4 and CATIA V5 are installed on a local
computer. Following these steps (1-4) enables you to avoid the error message
"Dynamic storage cannot be allocated," which would otherwise be displayed while
attempting to read CATIA V5 data.

109

Parts
!The following procedure describes how an entire model is pasted from
CATIA V4 to CATIA V5.
1. Open the CATIA V4 document to be converted in a CATIA V5 session.
2. Click the New icon or select New from the File menu to open a new CATIA V5
document.
3. In the specification tree or geometry area where the CATIA V4 model is displayed,
select the geometrical element or elements to be converted.
4. To convert the data without the specifications (history), either:
a. Drag and drop the element(s) onto the appropriate location in the CATIA V5
document.
or
b. Copy the element(s) by selecting Copy from the Edit menu and paste in the
CATIA V5 document by selecting Paste from the Edit menu.
or
c. Copy the element(s) by selecting Copy from the Edit menu and paste in the
CATIA V5 document by selecting Paste Special from the Edit menu, and then
selecting CATIA_Result in the dialog box and clicking OK.
5. To copy the specifications of the selected CATIA V4 elements, copy the element(s)
by selecting Copy from the Edit menu. Paste them in the CATIA V5 document by
selecting the Paste Special from the Edit menu, selecting CATIA_Spec in the
dialog box, and then clicking OK.
6. Click Update icon to update and view the copied data.
!The following task describes how an entire model is pasted from CATIA V5 to
CATIA V4:
1. Select Options from the Tools menu. The Options dialog box appears with the
General category selected in the left-hand column
2. Click the Compatibility tab. The following dialog box appears:
3. Open the WRITING_CODE_PAGE list in the V4 Declarations part of the dialog
box. The default WRITING_CODE_PAGE value is ISO-8859-1.
Select the appropriate code page from the drop down menu and click OK.
4. The V4 Model Dimension can be modified in order to be consistent with the
CATIA V4 destination site value.
5. Select Save As from the File menu.
6. In the Save As dialog box, select the location of the .model document to be saved
and rename it (or not) as required.

110

7. Click the Save as type: list and select model.

8. Click Save. The model file just created can now be opened in CATIA V4.
9. If some elements cannot be correctly transferred, the migration of CATIA V5 data
into native CATIA V4 format generates a report file (.rpt). Therefore, CATIA V5
CATPart documents are translated into CATIA V4 models with an enhanced report
of errors and problems. This report has the same name as the CATPart document.
The following list provides the files location.

On Windows NT, the file is located in C:\Winnt/Profiles\username\Local

Settings\Application Data\DassaultSystemes\CATReport

On Windows 2000 and XP, the file is located in C:\Documents and

Settings\username\Application Data\DassaultSystemes\CATReport

In this way, the message lets the user know which element could not be translated in
CATIA V4 .
Additional information about the error cause is provided as well. The cause of the error
may include:

Detection of a gap greater than the maximum allowed value.

Detection of an element with a dimension smaller than the minimum allowed value.

Detection of a shell that cannot be closed into a volume or detection of faces that
cannot be joined into a shell.

A surface that is too small.

Drawings
!The following procedure allows translation of CATIA V4 2D into the
corresponding CATIA V5 format.
1. Open the CATDrawing document.
2. Click the New icon or select New from the File menu to open a new CATIA
Drawing.
3. In the specification tree or geometry area where the CATIA V4 drawing is
displayed, select the view (or views) to be copied into CATIA V5.
4. Select Copy from the Edit menu and copy the selected view(s).
5. In the specification tree of the CATIA V5 CATDrawing document, select the
appropriate sheet.
6. Select Paste from the Edit menu and paste the selected view(s).
7. The migration of CATIA V4 drawing data to a CATIA V5 document generates a
report (.rpt) file named after the model migrated.

Assemblies
The following procedure allows translation of CATIA V4 assembly files (document
structure) into the corresponding CATIA V5 format. Opening a CATIA V4 session
generates a CATIA V5 CATProduct. This CATProduct contains the .model documents
linked to the .session document. The models contained in the Session are automatically
transferred into the CATProduct. Only CATIA V4 Sessions saved in "References only"
can be read in CATIA V5.

111

In addition, CATIA V4 Session documents containing models that are stored in

databases can also be opened in CATIA V5.
!To open documents, follow these steps:
1. Click the Open icon or select Open from the File menu.
2. In the File Selection box, select the file location.
3. In the Files of type list, select session as document type.
4. Select the .session document of choice and click OK.
The result in CATIA V5 is the same: the CATProduct contains the .models documents. It
keeps its links with the models referenced in the session and stored in the databases.
!The following is the procedure to translate CATIA V5 CATProduct documents
into CATIA V4 Sessions:
1. Select the Save As from the File menu. The Save As dialog box appears. In the
Format list, select session and select the location/path of the .session document
to be saved, and enter a name for it. Click Save As.
If no name is entered for the document that is saved, it is automatically saved
under the original CATProduct name and the extension is .session: for example,
plane SESSION.session
2. When the CATProduct contains one or several CATParts, they are saved as
.model into the same directory as the session file. Only the CATIA V5 elements in
Show mode can be translated into CATIA V4 format.
3. The .session file just created can now be opened in CATIA V4.

Batch Migration
!The following procedure describes the use of batch migration to convert many
CATIA V4 documents to V5 simultaneously:
1. On Windows, the Batch can be launched by entering the command:
CNEXT -batch -e CATV4ToV5Migration
2. Select CATIA V4 Documents in the File Selection dialog box.
3. Confirm that the Specification Check has been performed on the CATIA V4
documents.
4. Press the Migrate button in order to convert CATIA V4 documents into CATIA V5
documents. The migration is progressive when one or several models are selected,
and a progress bar appears, giving the user an insight into the migration time. The
screen is not frozen during the migration process.
5. The migration report is displayed in another dialog box at the end of the operation.
Double-click the line of choice to get more information. In the Migration Report
box, if the message is OK, then the selected files and their components can be
converted into CATIA V5.
6. The results obtained by performing a Copy/Paste operation may be different from
batch migration. Batch migration reduces the number of interactions and simplifies
the migration of complex CATIA V4 data structures.
7. The migration report can be saved as a text file. In the Migration Report window,
the elements list can be expanded for a particular model by double-clicking the
model. If the Save As Text button is clicked, these data will be saved in the file
and directory of choice.

112

For command line CATIA V5 to CATIA V4 Batch Migration on Windows and UNIX, the
migration can be launched by entering the CATV5ToV4 command. For more information
about this command, refer to the CATIA Help Documentation.

Libraries / Standard Parts

The major steps involved in converting any CATIA V4 Library to CATIA V5 Catalog are:
In CATIA V4 ,

Create CATIA V4 Models from Libraries.

Capture Keyword Data for each object from CATIA V4 Libraries.

In CATIA V5

Convert CATIA V4 Models to CATIA V5 CATParts, CATDrawing, etc.

Build CATIA V5 Catalogs with Keywords.

Executing these steps for migration of large libraries is tedious. These four steps can be
automated as described below :
Create CATIA V4 Models from Libraries
This process can be automated by writing an IUA to read the Library, extract the Models
from the Library, explode it, and save it as a *.model File in V4.
!The following are the steps to read the library file, explode the DITTOs, and
create .Model Files:
1. Get Input Library Name.
2. Test the validity of the input.
3. Read, Allocate and Open Library.
4. Scan the family in library.
5. Create a model.
6. Scan the objects in family.
7. Read object.
8. Paste in model file.
9. Create a standard symbol occurrence.
Capture Keyword Data for each object from CATIA V4 Libraries
The keyword data related to each object in all the families can be captured using the
CATGEO tool and IUA code. A text file is generated by running the IUA code. The
created text file can be modified to a CSV file of the required format, which would be the
input for creating catalogs.

113

!The code takes the following steps:

1. Get Input Library Name.
2. Test the validity of the input.
3. Read, allocate and open Library.
4. Create and pop the stack and read family data.
5. Capture Discrete keyword data.
6. Capture Numeric keyword data.
7. Capture Alphanumeric keyword data.
8. Capture Binary keyword data.
9. Capture Discrete keyword data of object.
10. Capture Numeric keyword data of object.
11. Capture Alphanumeric keyword data of object.
12. Capture Binary keyword data of object.
Convert CATIA V4 Models to CATIA V5 CATParts, CATDrawing, Etc.
CATIA V4 data can be converted to CATIA V5 using the already mentioned Batch
command in the Batch Migration section.

114

Build CATIA V5 Catalogs with Keywords

The following VBScript reads the keywords text file captured from the CATIA V4 library,
and places the keywords into a V5 .catalog file. To use this code, copy it into a text file
and rename it with a .vbs extension.
Sub CATMain()

Dim FileSys As FileSystem

Set FileSys = CATIA.FileSystem

Dim File_OP As String

Text file containing the name of the Families with File Path
File_OP="/FileName.txt"

Dim NamesFile As File

Set NamesFile = FileSys.GetFile(File_OP)

Dim Txt_Stream As TextStream

Set Txt_Stream = NamesFile.OpenAsTextStream("ForReading")

Dim File_Name As String

File_Name = Txt_Stream.ReadLine
Do Until Txt_Stream.AtEndOfStream
Input CSV file containing the Keyword of Objects with File Path
InputFile="../" & File_Name & ".csv"
Path for creation of output catalog file
OutputFile="./" & File_Name & ".catalog"
Dim Catalog As Document
Set Catalog=CATIA.Documents.Add("CatalogDocument")
Catalog.CreateCatalogFromcsv InputFile, OutputFile
Catalog.Close
File_Name = Txt_Stream.ReadLine
Loop
Txt_Stream.Close
End Sub

115

Migration using CATScripting

The CATIA V4 Libraries can also be migrated to CATIA V5 as catalogs using
CATScripting. The script given below can be used when migrating only DETAIL objects
of the Library. No link is kept between the CATIA V4 library and the new CATIA V5
catalog.
Language="VBSCRIPT"
Sub CATMain()
AS_SPEC = 0
AS_RESULT = 1
CONVERSION_FORMAT = AS_SPEC
MIGRATION = 0
SIMULATION = 1
RATTRAP = 2
BATCH_MODE = MIGRATION
libraryDirectory = "http://../../FASTENERS"

catalogName = "LIB.catalog"
catalogDirectory = "E:\..\..\Catalog"
projectDirectory = "http://../../Interop"
tablePath = "E:\..\..\table.txt"
Dim Catalog As Document
if ( BATCH_MODE = RATTRAP ) then
Set Catalog = CATIA.Documents.Open(catalogDirectory & "/" & catalogName)
else
Set Catalog = CATIA.Documents.Add("CatalogDocument")
end if
Catalog.CreateCatalogFromLibrary libraryDirectory, projectDirectory,
catalogDirectory, tablePath, CONVERSION_FORMAT, BATCH_MODE
Catalog.Close
End Sub

116

Summary
The migration of data from CATIA V4 to CATIA V5 can be involved if you intend to run V5
on Windows because the V4 data must be hosted on UNIX. The migration process must
be planned carefully if the productivity of your design department is to be maintained
throughout the process.
The V4 to V5 migration process does not have to be an all-at-once event, in which all
processes must be complete before users can access the new system. Instead, you can
phase your migration, with parts of your user base moving to the new system while
others continue with V4. This prevents a major interruption to the departments work,
allows you to test and gain confidence in your procedures with a small number of users,
and lessens the impact of failures. However, it also means that you must plan for the
movement of data both from V4 to V5 and from V5 to V4 while the migration is in
process.
If you have large amounts of data to migrate, it is likely that manual techniques will be
repetitive and time consuming. Bear in mind that the automated migration techniques
described in this chapter will reduce administrative effort in this situation.

117

7
Migrating Custom Applications
and Scripts
Your organization may need to develop and maintain custom code and scripts for use
with your CATIA system. If you have invested time in code development, you will want
to leverage this investment with the new system. Therefore, techniques for the migration
of custom solutions are of great importance.
Migrating CATIA V4 to CATIA V5 running on UNIX involves no changes in the operating
system and requires few changes in the code in order for it to continue working. Most of
the code issues surrounding upgrades arise because of the change to the Microsoft
Windows architecture that can be made with V5 and which this guide is designed to
address.
Custom applications are typically implemented either with compiled languages, such as
C++, or with scripting languages, such as Perl or UNIX shell scripts. In this chapter,
approaches to the migration of custom code will be discussed, first for compiled code,
and then for scripts.
A more detailed approach can be found in UNIX Application Migration Guide Patterns &
Practices at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnucmg/html/ucmglp.asp

119

Compiled Code Application Migration

Organizations with a large code base of installed UNIX applications will be interested in
the ability to continue using the entire suite of packages they have developed or
acquired. If these applications were written to interact with CATIA, and they are being
moved to Windows, the application will usually need to be migrated as well. Fortunately,
there are ways to preserve your investment in this code while developing under, or
moving to, Windows over a longer period.
Most applications are written in a compiled language. After you have written your code, it
must be converted into a binary executable file, a process called compilation. No coding
can be done if you have only this binary, which may be the case if you purchased the
application off the shelf from a third party. If you have the source code, however, you can
take the following approaches to move it over to Windows.

Options
Porting a UNIX application to Windows may be as simple as recompiling, or it may
require significant redesign and recoding. It does require access to the applications
source code.
There are four possible options for migration or co-existence between UNIX and
Windows:
Quick port
Full port
Application rewrite
Co-existence
Detailed descriptions of these options appear in the sections that follow.

Quick Port
One of the simplest migration paths possible is to port the code directly to
Microsoft Services for UNIX 3.0. Services for UNIX 3.0 includes Microsoft Interix, which
provides a UNIX environment that runs on top of the Windows kernel, allowing native
UNIX applications and scripts to work alongside Windows applications. This is achieved
by obtaining the source code, installing it in the Interix development environment,
modifying the configuration scripts and Makefiles, and recompiling the application.
The ported application may be successful immediately, or it may require modifications to
the configuration scripts or Makefiles to account for the new hardware platform, the target
operating systems, and local configuration information. It may not be possible to
determine whether a quick port is possible without actually conducting the port. Extensive
testing of the application is essential after the port to ensure that all features have been
migrated successfully.
Advantages:

120

A quick port is the fastest way of migrating an application.

When the Interix environment is used, the native UNIX applications and scripts can
be run alongside Windows applications on that platform.

Disadvantages:
A quick port may fail in the following scenarios:

The application proves too complex to be ported quickly.

Some parts of the application have to be rewritten for the port to be successful.

The code depends on some part of the UNIX environment.

The quick port uncovers some new issues in the code or shows that assumptions
were incorrect.

Often, a quick port can be attempted as the first stage of the migration process. If it does
not work, the results can be used as a basis for a full port or a rewrite.

Full Port
During a full port, the application is migrated with the minimum necessary changes to the
source code using UNIX-compatible libraries and utilities available on the Windows
platform, which can include Interix. Unlike the quick port, however, significant changes
may be required to enable the code to run on the new platform. This can happen when
the original code is not fully compliant with programming standards, or when code
elements such as device drivers are specific to the original system.
Advantages

A large quantity of code can be migrated quickly.

The application can easily be run on both operating systems for a sustained period
because there is a single code base where changes can be made.

The current look and feel of the UNIX application can be retained.

The business logic of the application is retained.

There is no need for new documentation or user training.

Disadvantages

If the original code is not fully compliant with standards, or when code elements
such as device drivers are specific to the original system, a full port may require
significant changes to enable the code to run on the new platform.

Extensive testing is essential.

Application Rewrite
Here, the application is recreated from scratch for the new Windows platform. Rewriting
the application is the ideal approach to make full use of the Windows platform. Though
this course requires the greatest amount of work, it also promises great rewards. This
strategy has the highest potential risk, but it frequently produces the best results.
Advantages

A rewrite results in the maximum use of the advanced features of the native
Windows environment, including the Win32 Application Programming Interface
(API).

A rewrite offers the best performance in a native Windows environment.

You can standardize all of your organizations Windows coding in the Microsoft
Visual Studio environment.

Rewriting offers the best possible integration with other Windows applications.

121

Disadvantages

A rewrite is potentially the most costly and time-consuming option.

A solution based on this strategy requires a thorough analysis of the UNIX

application before a Win32-based redesign of the application architecture is
undertaken.

A rewrite strategy is most appropriate when the costs of porting the application may
outweigh the benefits, or when specific application qualities, such as performance or
scalability, require that code be written specifically for the Windows platform.

Co-existence
To reduce the impact of code migration on users, you can plan a phase in which both the
old version of an application and the new one exist simultaneously. With co-existence,
the original application is retained alongside the new version while the application is
being ported or rewritten. This approach significantly reduces risk because it allows the
use of the original system should unexpected issues appear with the new application.
However, a cross-platform source code control system is needed to organize and
synchronize concurrent development on UNIX and Windows.
In this approach, choose a quick port, full port, or rewrite of the application, but retain the
original after deploying the new version. There are a number of reasons to choose coexistence:

The two applications, original and migrated, can be run in parallel to minimize risk.

A new set of users or customers will use the ported application, leaving the original
users unaffected.

A staged migration is planned between the original and the migrated application,
enabling you to minimize disruptions to the working environment.

When planning to maintain co-existent applications, you should maintain parallel

development and build environments in order to support both platforms on which the
application will run. A major challenge is the synchronization of changes in code between
the two versions. This may require a cross-platform source control system such as the
non-Microsoft products Revision Control System (RCS), Source Code Control System
(SCCS), Concurrent Version System (CVS), or Program Version Control System (PVCS).
The native Windows source control system is Microsoft Visual SourceSafe, which
supports the cross-platform Source Code Control Interface (SCCI) API. Interix supports
the RCS.

A Mix of All Strategies

It might also be appropriate to mix strategies. This often happens with large applications
where certain portions can be rewritten and others ported. Porting and then rewriting the
application can be done to reduce the overall time requirements on the project, or to
accommodate short-term time or budget constraints. For example, the migration could
begin as a port and continue as an incremental rewrite based on the integration or
evolution of portions of the application.
As in a port strategy, a common source code base across UNIX and Windows can be
retained. This strategy is similar to the way in which UNIX software is ported between
UNIX platforms because it allows developers to take advantage of platform-specific
functionality.
To ensure the selection of the most appropriate strategy, perform a cost-benefit analysis
that weighs the benefits of the strategy against its costs.

122

UNIX Script Migration

UNIX application and development environments commonly use scripts. These are text
files with code that must be interpreted as it is executed. This includes shell scripts, such
as those written for the bash shell, and Perl scripts, as well as other languages. These
scripts may be used to automate parts of CATIA. If the scripting language used in UNIX
is supported in Windows, it becomes a straightforward exercise to migrate the scripts.
Otherwise, the scripts can be rewritten in a language that Windows supports, such as
VBScript or JavaScript.
The following sections describe the available scripting options.

Interix
This environment, part of Services for UNIX 3.0, is able to migrate compiled applications.
It also allows UNIX scripts to be moved to Windows with little or no revision.
Advantages

No migration effort. All the UNIX scripts will work on the Interix subsystem without
change, including those written with sed, awk, Perl, and other languages.

This is an excellent option for programs using complex system calls such as fork,
exec, or signal handling, which require a lot of effort to convert to Win32.

No retraining is required for using the current scripts and developing new ones.
Users can continue to script in their familiar scripting language.

The UNIX to Windows migration effort can focus on the core migration of the
desktops, servers, and CATIA itself, rather than the peripheral supporting scripts.

Disadvantages

The migration is not really complete because it still uses a UNIX style of scripting.

There may be a tendency for users to expect other familiar UNIX resources and
functionality, such as file systems, path syntax, and user interfaces, after the
migration.

There may be no clear perception of the benefits of migration from a user

perspective.

The script may include no graphical user interface. Scripts developed natively for
Windows can create an interface more easily.

Performance may be slower than a native Windows script. This arises from the
extra load of running the Interix environment, as well as the script itself.

ActivePerl
ActiveState has developed the ActivePerl implementation of the popular Perl scripting
language. ActivePerl can be used for migrating Perl-based scripts as a long-term or
short-term option because it can run on both UNIX and Windows. Perl scripts migrated
this way should require little or no rewriting to run on Windows

123

Windows Scripting Host (WSH)

WSH is an interpreter, built into Windows 2000 and later, for scripting languages
including VBScript and JavaScript. It includes a set of objects for manipulating system
configuration settings and files system resources, and it can be used with other object
models provided with Windows and third party applications. WSH is frequently used to
automate administrative tasks and create logon scripts.
Objects and services supplied allow the script to perform tasks such as displaying
messages on screen, accessing network resources, and modifying environment variables
and registry keys. Other languages, including Perl, Rexx, and Python can also be run
under the WSH environment.
Scripts for batch jobs in UNIX are best migrated to WSH. However, as a short-term
option, Interix can be used. UNIX style emulation tools such as Cygwin and MKS32 can
also be helpful as a short-term solution for migration.

124

Summary
Customization of your UNIX implementation of CATIA can adapt the system to any
specific requirements you may have. If you have already customized your system,
however, the application may present challenges for the migration of CATIA to Windows.
Your custom application may consist of compiled code, such as that written in C++. In
this case, a port of the code in which it is simply recompiled for Windows may work well.
However, any code that references specific UNIX features or hardware will need to be
rewritten. The Interix environment from Microsoft Services for UNIX 3.0 can help with
this, but rewriting the application from scratch makes best use of the Windows
architecture and can increase performance.
You may also have script code to migrate. The language this is written in will determine
how difficult the migration of such code is. Various tools are available to help, including
Interix, ActivePerl, and the Windows Scripting Host.

125

8
Windows-UNIX Interoperability
and Data Sharing
If you are moving from CATIA V4 running on UNIX to CATIA V5 running on Microsoft
Windows, you must ensure that the two environments can communicate smoothly.
However there are significant differences in the way these systems approach common
tasks, such as file serving, security, and the user interface.
During a migration project UNIX and Windows-based systems must communicate or
interoperate. Even if the migration is to be done very quickly, data must be transferred
and custom scripts and applications migrated. If you have planned your migration to run
in phases, it might last several weeks or even months, and there will be a sustained
period when the two operating systems must share information in a variety of ways.
This chapter presents the issues that arise in Windows and UNIX interoperability and the
tools available to address the issues.
A more detailed approach can be found in UNIX Application Migration Guide Patterns &
Practices at http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnucmg/html/ucmglp.asp

127

Four categories of interoperability issues and the tools to address them are presented in
the following sections:

Windows to UNIX Connectivity. This section discusses how a user on one

operating system can connect to and use the other operating system over a
network.

User Authentication and Authorization. This section discusses the UNIX and
Windows security models and how to integrate them so that users on one
operating system can securely use resources on the other.

Resource and Data Sharing. This section discusses how to provide access to
UNIX and Windows-based resources (specifically, networked file systems) across
the two operating systems.

Choosing Interoperability Solutions. This section presents strategic

considerations posed by Win32 and Interix environments and by cross-platform
support for interoperability.

More information about Interix is available at http://www.interix.com/

A CATIA migration is likely to use many of the solutions presented here. For example, if
you have planned to migrate the desktop computers before the file servers,
Windows 2000 or XP computers will need to access CATIA files hosted on UNIX file
servers. If there is a need for those computers to run a custom CATIA script, they may
need to issue a command to run on the UNIX computer. For more information on
interoperability in general, see the "References" chapter at the end of this document.

128

Windows to UNIX Connectivity

A CATIA administrator or user on Windows may wish to access a UNIX server to run a
command or custom script that manipulates a CATIA file. This can be done with a
command line shell accessed by using a terminal or terminal emulator. Similar situations
may arise for UNIX users who wish to access Windows computers. To do more complex
tasks such as run a full implementation of CATIA installed on a Windows code server
from UNIX, a GUI may be required.
Command line access tools include telnet, Berkeley r access commands such as rsh,
rexec, rcp, and secure shell (ssh). The telnet client allows the user to operate in the
multi-user, command-driven environment provided by a host with a telnet server. Telnet
servers and clients exist for both Windows and UNIX. The rsh command allows the user
to run commands remotely from the local computer.
In UNIX, the GUI is provided by the X Windows system. This has always been designed
as a multi-user system, and so it extends to remote clients quite simply. With an X
Windows server on the desktop, developers can also use a GUI to connect to UNIXbased applications. Windows operating systems do not provide X Windows. For X
Windows connectivity, developers need a third-party X Windows server.
Windows, by contrast, is traditionally thought of as a single user operating system.
However, the recent addition of Terminal Services to Windows 2000, as well as third
party systems like Citrix Metaframe, has allowed multiple users to gain GUI access from
remote computers.
These access methods are of particular importance when migrating custom applications
and scripts (see Chapter 7, "Migrating Custom Applications and Scripts"). While
migrating, developers need access to the UNIX development servers from their Windows
desktops. Even during a rewrite to Win32which replaces the UNIX environment
permanentlydevelopers must have access to the UNIX environment.
Developers need access for operations such as:

Running the UNIX application to check the original functionality.

Referring to UNIX code, the build configuration, or management scripts.

Migrating any missing portions of code or scripts.

The following sections describe the main connectivity solutions available.

Note: In X Windows terminology, server refers to the software running on the users
desktop that provides the user interface; and client is the application running on the
UNIX server.

Terminal Emulation and Command Line Connectivity

UNIX developers and administrators use the tools described in this section to access
UNIX servers from the command line. If a UNIX application has a command line
interface, these tools are also helpful to users. Various aspects of CATIA can be
accessed from a command line, and custom scripts can be run.

129

Windows Telnet Clients

The Windows telnet client provides basic command line access to UNIX systems. Its
command syntax is identical to the telnet clients found on UNIX operating systems. The
Windows telnet client can be initiated by typing the command telnet at the command
prompt or Run box. Users can cut and paste text between the UNIX command line and
Windows-based applications.
The Microsoft HyperTerminal application also includes a telnet client. HyperTerminal
offers more configuration options than the command line telnet client. Terminal types for
the client range from American National Standards Institute (ANSI) to VT52 to VT100,
which allows you to select an environment you are already used to. It is straightforward to
cut and paste text between HyperTerminal and Windows-based applications.
A third-party telnet client may be required for command line tools that use terminal
characteristics beyond those provided by HyperTerminal, such as function keys or fullscreen operation.

Windows Telnet Server

Developers who need to connect from UNIX to Windows-based servers can set up the
telnet server included in the Windows operating systems.
! To connect from UNIX to a Windows-based server, follow these steps:
1. Use the tlntadmn command to modify the NTLM authentication option. NTLM
authentication is only supported by other Windows computers. If you want to
connect to the Windows telnet server from a UNIX computer, the default value
needs to be changed from 2 to 1 as follows:
a. Run the tlntadmn command utility.
b. Choose option 3 to configure registry settings.
c. Then choose option 7 for NTLM settings.
d. Change the value to 2.
e. Exit the utility.
2. Start the server by typing net start tlntsvr.
Note: Standard telnet is inherently insecure in that passwords are transmitted over the
network in clear text. Some UNIX telnet servers and clients make use of Kerberos
authentication, and the Windows client and servers can use NT authentication for
added security. If the application to be migrated makes use of standard telnet, consider
migrating it to a more secure version of telnet.

130

Remote Shell (rsh), Remote Copy (rcp), and Remote Execute (rexec)
Using the Berkeley r commands for remote access into UNIX servers can simplify
access. Authentication occurs only once on first connection to the UNIX system a user
does not need to log on again to connect to other systems.
The remote shell client (rsh) is available on all Windows computers and provides a shell
for running commands on UNIX servers elsewhere. The syntax is as follows:
rsh [Host] [-l UserName] [-n] [Command]
The remote execute tool (rexec) has similar syntax and performs similar remote
commands. The tool you use will depend on whether the UNIX server is running the rsh
or rexec daemon:
rexec [Host] [-l UserName] [-n] [Command]
For copying files between remote computers, the rcp tool is provided. The syntax is as
follows:
rcp [{-a | -b}] [-h] [-r] [Host][.User:] [Source] [Host][.User:]
[Path\Destination]
On Windows-based clients, the UserName parameter is required if user names on UNIX
and Windows are different.
The Windows 2000 Resource Kit includes an rsh server; Rshsvc.exe.
Note: Authentication for Berkeley r commands is based on the existence of a valid
client host and username combination as command parameters because if this
information is revealed, these commands can present a security risk. For this reason,
the commands are often disabled and replaced by the ssh command, as described
later in this chapter.

Secure Shell (ssh)

The secure shell provides extra authentication and encryption features. It is often used to
replace telnet and the Berkeley r commands where security is an issue. The ssh
command functionality is similar to the rsh command, except that ssh can be made
secure (client and user information is not revealed to third parties).
Windows operating systems do not include a secure shell client or server. However, thirdparty products do provide ssh functionality.

Remote Graphical User Interfaces

Users who require GUI access to a UNIX server from the Windows-based desktop
normally use an X Windows server. In the opposite direction, remote desktop services
are provided by Windows Terminal Services and its clients, which can be run on UNIX,
Linux, and other operating systems.
GUI access to a CATIA code server allows users to enjoy all the features and
convenience they would if they were running CATIA on their local desktop.

131

X Windows
Windows operating systems do not include an X Windows server. However, the Interix
environment, included in Microsoft Services for UNIX 3.0, does include X Windows
clients, which can be used to develop applications that use an X Windows user interface.
Xterm can be run from Interix with an X Server.
Third-party products that provide Windows-based X Windows servers are well integrated
with the Windows desktop. Users of the third-party products can cut and paste text and
graphics between X Windows and Windows. The following are popular X Windows
servers for Windows clients:

Hummingbird Exceed. For more information, refer to the Hummingbird Web site at
http://www.hummingbird.com

MKS Toolkit. For more information, refer to the MKS Web site at
http://www.mks.com

WRQ Reflection(r) X. For more information, refer to the WRQ Web site at
http://www.wrq.com

These products provide support for most X Windows standards. Each product also
includes extras. For example, MKS Toolkit also includes more than 300 UNIX commands
that can be used within Windows.

Remote Desktops
A Windows operating system and UNIX each handle multiple users in a different way.
Traditionally, only a single user at a time could log onto a Windows computer. However,
by using Windows 2000 Terminal Services, multiple users, seated at remote computers,
can log on to a single server. A Windows-based server can thus provide a desktop to
remote users on clients spread over the network, including those on other operating
systems. The software that runs on the remote desktops is often called a thin client,
because the client only has to handle input and output while the application runs on the
server. With Windows XP Pro, even local sessions use Remote Display Protocol (RDP),
which means that you can log off your machine, someone else can log on to your
machine, and then log off, and you can log on again with all your programs still running.
For UNIX to Windows connectivity, UNIX and Linux can implement the RDP) used by
Terminal Services by installing the Terminal Services client software on them. At the time
of writing, these products are new. It has not been determined whether they are
appropriate for a commercial environment.
Such a system can be made more manageable and scalable using Citrix MetaFrame.
This product is an add-on to Terminal Services and eases administration while improving
the end users experience. MetaFrame also has clients for a wide range of operating
systems, including UNIX and Linux.
(For more information about Citrix MetaFrame, refer to the Citrix Web site at:
http://www.citrix.com/products/. An X Windows interface to UNIX is required to use the
product.

132

User Authentication and Authorization

This section discusses security issues during UNIX to Windows migration and potential
solutions.
In any heterogeneous network such as a network migrating to Windows users need
to work across systems and the systems themselves need to interoperate. This situation
is very likely to arise when migrating to CATIA V5 running on Windows from a previous
version running on UNIX. In order to maintain security, each user must be identifiable on
both systems. This can be done by providing each user with two accounts: one in UNIX,
the other in Windows.
Migration planners need to consider the following security questions:

Do users require two sets of user names and passwords: one for UNIX and one for
Windows?

If so, how will users keep their passwords synchronized?

Do administrators need to manage two user databases?

How do administrators manage user security on shared resources, such as

network file systems?

The greater the need for interoperability during the migration, the more important these
questions become. The rest of this section presents information about Windows and
UNIX security and how to integrate them. This should enable you to answer the above
questions.
Security models for both operating systems typically have two components:

Authentication to verify the users identity.

Authorization to control access to resources and to limit what a user can do.

Authentication and Authorization in UNIX

UNIX security relies on user credentials and file permissions. In UNIX, user credentials
consist of two unique identifiers for each user: a user identifier (UID) and a group
identifier (GID). Every UNIX process runs in the context of such identifiers and this
determines what that process is able to do. UIDs and GIDs are integers assigned by the
administrator. They are not guaranteed to be unique across a network.
Users are listed in the /etc/passwd file. This file contains a single line of text for each
user. The line has fields for the user name, user ID, password, home directory, default
shell, and others. The password is encrypted so neither the administrator nor anyone
else can read it.
Groups are listed in the /etc/group file, which lists the names of the users in each group.
UNIX assigns permissions to every file, directory, and device. The permissions are for the
user (that is, the owner of the file), for the group, and for everyone else.
When a process seeks access to a file, UNIX uses the UID and GID of the process to
determine which permissions apply to that process.
To authenticate a user at logon, UNIX uses protocols such as clear text authentication,
Kerberos, and other proprietary schemes. After logon, every process a user creates has
the same UID and GID, and thus the access rights of the user referenced by the UID.

133

To secure stations, some UNIX installations may also use a Host.equiv or .Rhosts file
containing host information based on the host name and IP address. These files define
the set of trusted hosts, users, and host-user pairs that certain UNIX processes use to
verify access. For example, rlogin (remote logon) and rsh (remote shell) bypass the
normal logon and password security mechanisms of /etc/passwd or Network Information
Service (NIS) and use these files instead. The /etc/hosts.equiv file contains trusted hosts
and/or trusted host-user pairs.
The UNIX user database can be centralized for a network of UNIX computers using NIS.
NIS maps the /etc/passwd and /etc/group files to a central database held on the NIS
servers. All other aspects of UNIX security continue to work in the same manner, but use
UIDs and GIDs from the NIS server rather than local files.

Authentication and Authorization in Windows

Windows security relies on user credentials and object permissions. When a user logs on
to a Windows-based computer or domain, Windows authenticates them using either
Kerberos or NT LAN Manager (NTLM) authentication. These are protocols that provide a
secure way to check the user name and password typed by the user against a
centralized user list. Kerberos is used if the computers involved all have Windows 2000
or later; for earlier versions, NTLM is used. The user list is stored locally if this is a standalone computer, or on domain controller servers if this computer is a member of a
domain.
Each user account, once authenticated, is identified by means of a security identifier
(SID). This is a long number unique to that account. Each group that the account is a
member of also has a SID. A list of the SIDs of the user account and its groups is created
at logon and used when resources are accessed around the network. This list is called
the Access Token.
Windows objects (including files and directories) have a security descriptor (SD)
associated with them. The information in the security descriptor includes the owner of the
object and a discretionary access control list (DACL). This DACL is a list of SIDs together
with the level of access granted to that account and it allows a much greater range of
permissions than UNIX does. Further, those permissions can be assigned more
selectively than those provided by UNIX. When a user tries to access a resource, the
Access Token is compared with the DACL to determine the appropriate level of access.

134

Integrating UNIX and Windows Security

Figure 8.1 illustrates the differences between the UNIX and Windows security models.
Although the differences in this example focus on NIS and Active Directory domains, the
differences are identical for UNIX and Windows-based computers that are not part of a
security domain.

Figure 8.1
UNIX and Windows security model differences

The following figure summarizes the differences illustrated in Figure 8.1.

Figure 8.2
UNIX and Windows Security Model Differences

135

These differences raise a number of interoperability issues:

How to map UNIX-style user names to Windows-style user names.

How to map UIDs to SIDs and SIDs to UIDs to control access to resources, such
as files, when accessed across the two systems.

How to convert incompatible file and resource permissions.

How to centralize the management of UNIX and Windows users.

The following sections describe some tools for integrating UNIX and Windows security.

User Account Management and Synchronization

There are three possible approaches to managing user accounts across UNIX and
Windows:
1. Create separate and unrelated accounts for UNIX and Windows.
This solution is simple, but requires the most effort for users of both platforms. It
complicates cross-system authentication and security permissions. This solution is
appropriate when the need for interoperability between UNIX and Windows is
limited and brief.
2. Create duplicate, identical accounts on UNIX and Windows.
Duplication of accounts simplifies interoperability because UNIX and Windows
accounts can relate to each other. It also simplifies the conversion of permissions.
However, it does double administration and results in each user having two
passwords.
3. Integrate UNIX and Windows account management.
This long-term solution accommodates a long-term migration project or a target
environment that includes both UNIX and Windows-based servers. In this case,
administrators should centralize user management into one place, such as the
Windows Active Directory. Management from Windows Active Directory is
consistent with a migration to the Windows platform.
Many third-party and Microsoft interoperability products provide UNIX-to-Windows user
mapping. For example, Samba provides its own methods of mapping user names. (For
more information about Samba, see references to Samba in the "Resource and Data
Sharing" section later in this chapter.) Although sometimes helpful, these methods can
create a need for additional administration and could complicate the system.

Microsoft Services for UNIX Server for NIS

Microsoft Services for UNIX 3.0 includes a Network Information System (NIS) server
called Server for NIS. This service uses Windows 2000 Active Directory to implement
NIS.
Administrators can use Server for NIS to:

136

Store NIS maps in the Active Directory.

Integrate NIS objects (such as users) with corresponding Active Directory objects.

Use Windows 2000-based servers as NIS servers.

Migrate NIS domains to Active Directory.

Merge multiple NIS domains.

Synchronize passwords (see the "Microsoft Services for UNIX Password

Synchronization" section later in this chapter).

Figure 8.3 shows the architecture of Server for NIS. Notice that although UNIX slave NIS
servers are still usable, the master NIS server now resides on Windows.

Figure 8.3
Architecture of Server for NIS

Server for NIS is especially useful for large networks that already have NIS and Active
Directory. However, administrators need to be aware of how Server for NIS interoperation
works.
Server for NIS must be installed on a Windows 2000 domain controller. The Windowsbased server uses Active Directory to store the NIS information. Normal Active Directory
replication is used to propagate the NIS data to other Windows domain controllers.

The computer running Server for NIS must be the master NIS server. This means
that all the other Windows-based and UNIX NIS servers are subordinates.

The Active Directory tools on the master computer administer both the NIS and the
Active Directory domains.

An NIS to Active Directory Migration Wizard assists in moving the existing NIS
domain into Active Directory.

For more information on Server for NIS, refer to the Microsoft white paper, Server for
NIS Overview, at:
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/
windows2000serv/deploy/sfu/servnis.asp

137

Microsoft Services for UNIX Password Synchronization

Microsoft Services for UNIX includes two-way password synchronization between UNIX
and Windows. This is not necessary if you are using Server for NIS because Active
Directory and NIS are already closely integrated. Use this system if you wish to maintain
separate UNIX and Windows user lists, but ensure their passwords match.
To synchronize from UNIX to Windows, a single sign-on daemon (SSOD) must be
running on the UNIX NIS server. Microsoft Services for UNIX supplies precompiled
SSODs for popular UNIX versions. For UNIX versions without a precompiled SSOD,
Microsoft Services for UNIX supplies the source code to create one. You must compile
this code on your UNIX platform.
Password synchronization occurs only between systems that are configured to
synchronize by an administrator. A file on the UNIX side contains a list of computers to
notify of password changes. Tools on the Windows side maintain the list in the registry. In
addition, administrators can specify which users have passwords that must be
synchronized.
To synchronize passwords for Windows 2000 domain accounts, all domain controllers on
the network must be running the synchronization service, and all participating UNIX
computers must be running the SSOD. When synchronizing passwords for local user
accounts, the service must be installed on all Windows 2000-based computers.
Because password synchronization does not use user name mapping, the user names
must be exactly the same for both UNIX and Windows. Therefore, user names must
conform to the most restrictive definition of length and structure. For example, because
Windows user names are not case sensitive, but UNIX user names are, all Windows user
names must be in lowercase.

138

Resource and Data Sharing

Any migration from UNIX to Windows requires the two very different environments to
share data and resources. In the simplest case, UNIX servers quickly migrate files to
Windows-based servers. At the other end of the spectrum, UNIX servers and Windowsbased servers share data and resources, such as printers and folders, during and after
migration. Your situation will depend on the complexity of both your original and your new
CATIA implementations.
This section presents the options for sharing resources between the two environments,
concentrating on networked file systems. By using networked file systems, users of
Windows or UNIX can manipulate files as though they were stored on a local file system.
Less integrated methods exist to transport files between systems, such as the File
Transfer Protocol (FTP) and removable media such as tapes or compact disks. These
methods are not considered here because they do not provide close interoperability.
However, removable media and FTP can be useful during the migration. Tapes are
particularly effective for transferring volumes of data too large to feasibly move across the
network.
Developers or application users should ideally be able to use the files they need in their
local environment transparently, that is, they should not need to know whether the files
are on a UNIX server or a Windows-based server. However, UNIX systems and
Windows-based systems use different network protocols, functionality, and naming
conventions for file sharing, and so this can be challenging.
In Windows-based networks, the most common file-sharing protocol is Server Message
Block (SMB), also known as the Common Internet File System (CIFS). In this document
SMB and CIFS are used interchangeably. The most common network file system on
UNIX systems is called, simply, the Network File System (NFS). NFS and CIFS protocols
are not compatible.
The following sections review the file-sharing environments in UNIX and Windows and
the options for providing interoperability.

UNIX Data Sharing Environment

The network file system (NFS) protocol is a UNIX-style file system that can be shared
over the network. NFS uses UNIX user identification, group identification, and
permissions.
NFS uses the export naming convention, in which an exported file system is referred to
by the host name and the export name. For example,
server:/usr/local/pub
where server is the host name and /usr/local/pub is the export name.

139

An NFS client mounts the NFS export into its file system tree just as it mounts any other
file system, such as one on a local disk drive. To the user, the network file system looks
like another directory under the root of the file system (/).
The mount command can be used to connect to an NFS file system. Such a command
might look like this:
mount t nfs server:/usr/local/pub /pub
NFS is used in many ways in UNIX environments. Servers can share common data by
using NFS. Desktops or workstations can streamline administration by centralizing user
data on an NFS server.

Windows Data Sharing Environment

CIFS was designed to integrate transparently into Windows operating systems. It uses
Windows security to control access to resources, including the SIDs, Access Tokens, and
DACLs already described. Available networked file systems are called shares.
A Universal Naming Convention (UNC) name identifies the networked file. The UNC
name consists of a server name and a share name, for example; \\SERVER\SHARE.
On a client, a share can be accessed directly with these UNC names. Alternatively, it can
be mapped to a drive letter in the same way as a disk partition or floppy disk. For
example, the path X:, could be mapped to the UNC name above. Drive letters can be
mapped in a number of ways. The most basic way is to use the command line utility net
use. For example:
net use X: \\SERVER\SHARE
Windows also provides Browser Services, which compiles a list of all the servers in the
Windows environment with the shares on them. Users can navigate this hierarchy with
the Explorer program, just as they would navigate their local disk drives.
File-naming conventions and other features of the networked file system are the same as
for other Windows file systems.
As in UNIX with NIS, desktop clients can thus store all their data on a centralized server,
which simplifies administration.

Network File System Interoperability

The Windows and UNIX networked file systems are incompatible, but there are three
ways in which they can interoperate:

140

Using a service installed on the file server. For example, Samba can be
installed on a UNIX server to make it appear to be a Windows server, or an NFS
server can be installed on a Windows server.

Using a client on the workstation computers. For example, an NFS client can
be installed on a Windows 2000 Professional computer to allow it to access the
NFS UNIX servers.

Using a gateway. This could be a Windows server with a service installed on it

that allows Windows clients to access the UNIX NFS shared file system through it.
No extra software must be installed on the Windows clients or the UNIX server.
Gateway schemes place significant load on the gateway server, which must
translate between the protocols. Although they are relatively easy to configure,
they are usually less scalable than the previous approaches for this reason.

The scheme you choose may be influenced by the order of your CATIA migration. For
example, if you plan to migrate the data to Windows file server before migrating the
application itself, UNIX users will need regular access to those servers during the
migration. You might consider installing an NFS server on the Windows computers to
facilitate this, or a CIFS client on the UNIX desktops.
For interoperability, network file system software must provide some basic functionality:

It must provide connectivity between the network client and the file server.

It must translate between opposing environments.

It must provide for security mapping between the two systems (for more
information, see the "User Authentication and Authorization" section earlier in this
chapter).

It must convert file system features between UNIX and Windows; for example,
links and file locking.

File sharing between UNIX and Windows-based systems can be implemented in many
ways. Figure 8.4 provides an overview of the options. Each of the interoperability
solutions can be implemented either on a UNIX platform or on a Windows platform.
The following combinations are commonly used:

A UNIX server provides CIFS file shares to Windows clients via Samba and NFS
file shares to UNIX clients.

A UNIX server provides NFS file shares to both Windows and UNIX clients. The
Windows clients must have a NFS client, such as that provided with Microsoft
Services for UNIX 3.0, installed locally.

A Windows-based server provides CIFS file shares to Windows clients and NFS
file shares to UNIX clients via a NFS server for Windows. Such a NFS server is
provided with Microsoft Services for UNIX 3.0.

A Windows-based server provides CIFS file shares to Windows and UNIX clients.
The UNIX clients must have a CIFS client installed locally.

141

Figure 8.4
File-sharing options for UNIX and Windows

NFS for Data Sharing

If you have elected to use the NFS protocol to share files between UNIX and Windows,
NFS software must be running on the Windows-based server or client or an NFS
gateway must exist to convert an NFS export into a Windows share.
One system must be the NFS file server and the other must be the client. Often, because
it probably already runs NFS, the UNIX side becomes the server. In this case, the
Windows-based client computer must run an NFS client program.
If files must be shared from a Windows-based server to UNIX clients, then it is easiest to
set up the Windows-based system as the NFS file server. The Windows-based server
needs to run NFS server software.

142

NFS software products for Windows, including clients and servers, are available from
Microsoft and others. The next sections discuss these products.

Microsoft Services for UNIX

Microsoft Services for UNIX provide the tools needed to set up sharing between UNIX
and Windows-based systems. In addition to shells and command line tools, Microsoft
Services for UNIX delivers a server and a client for NFS and an NFS gateway. In
addition, Microsoft Services for UNIX delivers User Name Mapping, which allows NFS
access via the users Windows credentials.
The most straightforward way to set up NFS sharing is to install an NFS client on each
Windows client computer that needs access to NFS shares. By using the NFS client,
users have access to files saved on NFS shares just as they have access to files on
Windows-based servers. The same mechanisms used to map drive letters to Windows
shares can be used with NFS shares. The share can be assigned a drive letter or the
client can access the share by using an UNC name. After the share is accessed, users
have normal access to the files.

Authentication and Permissions

The Microsoft Services for UNIX NFS system uses User Name Mapping to authenticate
the user to the server, whether or not the names match on both systems. Actual name
mapping makes it possible to set up different schemes for allowing access to the NFS
shares.
Note that UNIX user names are case sensitive and Windows user names are not. Name
mapping can handle this discrepancy by mapping names with uppercase letters to the
UNIX convention of all lowercase letters. However, if your UNIX user names do not
conform to this convention, this issue may cause trouble.
When Microsoft Services for UNIX NFS client software is being used to provide filesharing integration, each workstation client uses its native authentication protocol:
Windows NTLM and Kerberos for the Windows-based workstation user and NIS for the
UNIX workstation user. However the Microsoft Services for UNIX NFS Client uses the
Microsoft Services for UNIX User Name Mapping Server to map the authenticated
Windows user to a corresponding UNIX user name using the user SID. It obtains the UID
and GID to use for authorization (for example, file access permissions) in an NFS request
to the NFS server.

Microsoft Services for UNIX Gateway for NFS

Gateway for NFS is another Microsoft Services for UNIX feature. In this case, the
gateway computer, which runs Windows, communicates with the client computers by
using the usual Windows file-sharing protocol: CIFS. This eliminates the need to install
the NFS client software on each client.
However, the best environment in which to use the gateway has a limited number of NFS
shares that need to be available to the Windows clients. The server makes shares
available as though they were shares on the gateway computer. Each share must be
mapped to an available drive letter on the gateway computer. It is possible to use more
than one gateway computer, but any single gateway computer is limited by the number of
available drive letters.

143

Hummingbird NFS
The Hummingbird NFS Maestro suite offers NFS solutions similar to those in Microsoft
Services for UNIX. NFS Maestro includes an NFS client package, an NFS server, and an
NFS gateway product. The NFS Maestro gateway also eliminates the need to install NFS
client software on each client computer.
For more information, see Host Access and Network Connectivity on the Hummingbird
Web site at http://www.hummingbird.com

WRQ Reflection
WRQ Reflection products also deliver NFS functionality for Windows computers. The
WRQ Reflection NFS Client offers client functionality, and WRQ Reflection Suite for X
contains the NFS client, X Windows capabilities, and connectivity to UNIX and mainframe
systems.
For more information, see the WRQ Web site at http://www.wrq.com

Microsoft Windows Powered NAS Solution

Windows Powered Network Attached Storage (NAS) is a product designed specifically for
file serving. It is intended to be simple to configure, stable, scalable, easy to administer,
and flexible in different file serving situations.
Preconfigured Windows Powered NAS solutions are available from third parties. These
include all the hardware and software required to roll out an efficient file server or system
of servers in a very short time. By running such a locked-down version of Windows 2000,
the more complex setup required for general purpose servers is eliminated. This allows
Windows Powered NAS appliances to be quickly configured and integrated into an
existing Windows 2000 infrastructure.
Windows Powered NAS supports standard TCP/IP connections and provides access to a
full range of file sharing protocols including the CIFS, NFS, Netware Core Protocol
(NCP), Apple Talk, File Transfer Protocol (FTP), and Web-based Distributed Authoring
and Versioning (WebDAV).
The support for CIFS and NFS is of prime importance for a CATIA migration from UNIX
to Windows. This allows a single server, or set of servers, to be used for data storage
throughout the migration, regardless of the clients operating systems. If you have
decided to perform a local installation of CATIA on many client computers, perhaps using
Group Policy as described in Chapter 3, you will need high performance file servers from
which to download the setup files to CATIA workstations. Windows Powered NAS servers
are ideal for this. See Chapter 3, "CATIA Local Installation" for a full discussion.
Windows Powered NAS, however, should not be thought of as a tool useful exclusively
during the migration. Once this is over, the high availability, optimized performance,
advanced backup and restore, replication, and ease of use become highly advantageous,
particularly for large systems with large amounts of CATIA data and large numbers of
users distributed over several sites. The low cost per megabyte of storage space is also
attractive.

144

Why Windows Powered NAS?

The following table summarizes the business needs solved by a Windows Powered NAS
solution:
Table 6.1: Windows Powered NAS and Business Needs
Technical scenario

Business Need

Why Windows Powered

NAS

File Serving

Low TCO
High availability
High reliability
Ease of management
Integration into existing
infrastructure

Optimized for File Serving

No overhead of running
applications
Replace multiple GP servers
used for file serving with single
solution

Backup/Restore and
Replication

Business continuity
- Disaster recovery
- Availability of data

Backup without taking servers

offline
Geographic replication

Server Consolidation

Optimize IT resources
- Lower touch points
- High availability
- Reduce admin costs

Low $/MB
Consolidate multiple file servers
More data per server per admin

Active Directory-Based Deployment Scenarios

Here are three real-world scenarios that illustrate how Windows Powered NAS
appliances can be deployed within an Active Directory infrastructure and use specific
Windows 2000 services to create robust enterprise storage solutions. Each scenario has
different priorities; in the first scalability and availability, in the second security, and in the
third disaster recovery.
In your CATIA implementation your priorities may be similar to one of these, a
combination of them, or entirely different. The scenarios are intended as illustrations of
common implementations:
1. Deploying Windows Powered NAS Appliances for High Availability and High
Performance File Services
Company ABC has deployed an Active Directory infrastructure and wants to reduce
software installation and configuration management costs through an automated process.
In order to configure 20,000 Windows 2000 clients distributed across five locations,
applications will be deployed using Group Policy software installation and the Windows
Installer technology. All of the software distribution points will be hosted on Windows
Powered NAS appliances. The set of applications distributed includes CATIA installed
locally.
In order to minimize wide area network (WAN) traffic, Company ABC wants client
computers to find the closest NAS appliance to use as the software distribution share. In
addition, Company ABC would like to reduce software deployment complexity by
deploying software anywhere in their infrastructure using a single UNC mapping. With
Windows Powered NAS appliances, Active Directory, DFS, and File Replication Services
(FRS), Company ABC can create a highly available software distribution system that will
meet these criteria.

145

Implementing Domain-based DFS

Company ABC begins by deploying a new Windows Powered NAS appliance in the
company headquarters.
The DFS namespace will be configured as follows:
\\CompanyABC\Files\Software !
\\NASServerHQ1\Software
A newly installed Windows Powered NAS appliance will provide the company
headquarters location with Group Policy based software installation. The use of DFS will
enable installation of software anywhere in the world using the common \\CompanyABC
\Files\Software UNC mapping.
While this configuration will provide local software installation for the company
headquarters clients, it still does not meet the requirement for local software installation
at the four remote locations. At this stage, if users in the remote locations attempt to
install software, the installation process would occur over the WAN and the bandwidth
utilization could affect critical business processes.
In order to allow clients to install software locally using the common UNC, \\Company
ABC \Files\Software, a Windows powered NAS appliance will be deployed at each of the
remote locations and host a DFS link replica of the \Software share that is synchronized
using File Replication Service (FRS) replication.
The DFS namespace hierarchy would then look like:
\\CompanyABC\Files\Software !
\\NASServerHQ1\Software
!

\\NASServerRL1\Software

\\NASServerRL2\Software

\\NASServerRL3\Software

\\NASServerRL4\Software

NASServerRL1 through NASServerRL4 will hold an exact copy of the \Software share
on NASServerHQ1. When a client in a remote site requests installation of software using
the \\CompanyABC\Files\Software UNC mapping, they will be referred to the DFS
server located at their remote location and the software will be installed using the LAN. If
a remote location DFS server happens to be unavailable due to system maintenance or
component failure, a client initiating a software installation would be automatically and
transparently referred to another DFS server. The client would not be aware of or be
affected by this type of event.
FRS will take care of reliably and efficiently replicating the package to the Windows
Powered NAS appliances in the other sites.
After six months, Company ABC grows by 75 percent at one of the four remote locations.
Because of the growth, clients at this location have started to experience slower software
installation performance. The IT organization wants to improve the client software
installation experience without incurring additional management costs.
Company ABC decides to use the automatic load balancing features of DFS by deploying
two more replicas of the \Software share at the remote location that experiences the
problem.

146

Adding two new NAS appliances to distribute the load, the DFS namespace will reflect
the following:
\\CompanyABC\Files\Software !
\\NASServerHQ1\Software
!

\\NASServerRL1\Software

\\NASServerRL2\Software

\\NASServerRL3\Software

\\NASServerRL3A\Software

\\NASServerRL3B\Software

\\NASServerRL4\Software

With the deployment of the two new Windows Powered NAS appliances, clients at the
remote location still use the common UNC, \\CompanyABC\Files\Software, to access
any available software installation point. The two new replicas added to the existing
replica set will synchronize their content through FRS. DFS will transparently allocate
client requests in this site to the underlying shared folders on \\NASServerRL3 through
\\NASServerRL3B, providing a degree of load balancing across the NAS appliances.
2. Deploying Windows Powered NAS Appliances for Highly Secure File Services
Company XYZ relies heavily on proprietary financial data to provide services to its
customers. Loss or theft of this financial data could translate into the loss of millions of
dollars of revenue.
Although this scenario concentrates on financial data, your engineering and design data,
including CATIA files, may have similar sensitivity. You may wish to protect your
investment against industrial espionage, for example.
Company XYZ has deployed a Windows 2000 Active Directory infrastructure that allows
their mobile work force to upload the financial data from their notebooks to Windows
Powered NAS appliances on the corporate network on a daily basis. In order to maximize
the protection of the financial data, Company XYZ has decided to implement a secure
enterprise file storage infrastructure based on the following criteria:

Encryption of the data on the notebooks to prevent data being compromised if the
notebooks are lost or stolen.

Encryption of the data on the Windows Powered NAS appliances to prevent data
being compromised if an intruder gains access into the enterprise network.

Encryption of data flowing across the network between client notebooks and
Windows Powered NAS appliances to prevent data being compromised during
transfer.

A centralized management solution.

Smart cards for all authentication requirements.

Using a combination of Windows 2000 Active Directory, Group Policy, Encrypted File
System (EFS), IP Security Protocol (IPSec), and Windows Powered NAS devices,
Company XYZ can achieve an integrated solution based on the standard Kerberos v5
authentication protocol or certificates.

147

Implementing EFS to Encrypt Client and Server Data

The Encrypted File System (EFS) is built on top of NTFS to store encrypted files on file
system volumes. Encryption is transparent to the user that encrypted the file and a file
does not have to be manually decrypted before it can be used. Files can be opened and
modified without any special action being taken by the file owner. Using EFS services,
Windows Powered NAS appliances can provide encrypted data storage on a user-byuser basis.
An unauthorized user who gains physical access to encrypted files or folders will be
prevented from reading them. If the intruder tries to open or copy an encrypted file or
folder, an access denied message will be displayed.
Encryption and decryption of files and folders is configured by setting an encryption
property similar to other file and folder attributes such as read-only, compressed, or
hidden. If a folder is encrypted, all files and subfolders created in the encrypted folder are
automatically encrypted.
Files and folders may be encrypted on standalone or domain member computers.
Recovery agent user accounts are required to recover encrypted files and folders that
can no longer be accessed by the file owner. For a standalone computer, the local
administrator is the default recovery agent, but you can designate other local accounts as
recovery agents. For computers that are a member of a domain, members of the Domain
Admins group can designate recovery agents.
If EFS will be used on an enterprise-wide scale, then all participating systems, including
Windows Powered NAS appliances, should be members of an Active Directory domain.
You can assign one or more recovery agent accounts to a set of computers within a
domain by using Group Policy. Any of the designated recovery accounts can be used to
recover users' files. EFS stores the recovery agent information for EFS recovery policy in
Active Directory. This centralizes and simplifies the management of recovery agents for
large numbers of enterprise systems, a task which would quickly become unmanageable
for hundreds or thousands of standalone systems, each requiring management of
individual recovery agents stored in Local Group Policy.
By implementing EFS in an Active Directory environment, Company XYZ can ensure that
data remains encrypted on both the company notebooks and Windows Powered NAS
appliances that will provide file services. Without Active Directory integration, enterprisewide recovery agents cannot be defined. Local computer accounts would have to be
maintained and saved in an external store. If the external store was corrupted, the
encrypted data stored on the standalone notebooks may not be recovered if the original
file owner leaves the company or forgets their authentication credentials.
By implementing EFS in an Active Directory environment, Windows 2000 domain
accounts can be designated using Group Policy as recovery agents for all notebooks and
Windows Powered NAS appliances in the domain. This allows recovery regardless of the
state of any local computer account database and provides a centrally managed and fault
tolerant solution as both the domain accounts and recovery agent Group Policy
configuration information is stored in the Active Directory.
For EFS to function correctly, the file owner must have a valid EFS user certificate, and
the current EFS recovery policy must specify at least one valid recovery agent certificate.
If available, EFS requests certificates from a Windows 2000 enterprise Certificate
Authority (CA), but EFS does not require a CA to issue certificates. If an enterprise CA is
not available, EFS automatically generates its own certificates to users and to default
recovery agent accounts.

148

EFS certificates that are self-signed are identified by Windows 2000 as "not trusted"
because the certifying authority does not have a certificate in the Trusted Root
Certification Authorities store. Nevertheless, self-signed EFS certificates are valid for use
by EFS.
Implementing IPSec for Data Transfers between Clients and Servers
Windows Powered NAS appliances can also use the IPSec integrated in Windows 2000
to provide enhanced protection of network data flowing across enterprise networks.
IPSec is a network protocol that was designed by the Internet Engineering Task Force
(IETF) to provide IP packets with data authentication, integrity, confidentiality, and replay
protection. IPSec is implemented at the IP Transport Layer, which enables a high level of
protection for applications, services, and upper layer protocols such as TCP and UDP.
IPSec negotiations between the source and destination systems require mutual
authentication before the exchange of secured data. Windows 2000 IPSec provides
multiple methods of authentication to ensure compatibility with legacy systems, nonWindows-based systems, and remote computers.
In order to ensure that Company XYZ data remains encrypted during data transfers
between client notebooks and Windows Powered NAS appliances, IPSec can be
implemented in the Active Directory environment. The flexibility of IPSec can be utilized
to assign different polices and levels of security for different computers and users. In
addition, computers can be configured to accept or transmit data only if an IPSec secure
channel can be established.
The amount of configuration required to enable IPSec will be minimized by using the
default Windows 2000 IPSec authentication method: Kerberos v5. This is also the
standard authentication protocol used between Windows 2000 systems that are
members of an Active Directory domain. Company XYZ selected Kerberos authentication
and domain trusts to simplify the management of IPSec configuration. If required in the
future, certificates or pre-shared keys can be used for non-trusted domains or third-party
interoperability.
To enforce the use of IPSec for all network communications between the companyowned notebooks and the Windows Powered NAS appliance without applying it to all
other computers in the Active Directory domain, Company XYZ creates an organizational
unit (OU) named Financial Systems that contains two child OUs: NAS and Notebooks.
The NAS OU contains all appropriate Windows Powered NAS appliance computer
objects. The Notebooks OU contains all appropriate notebook computer objects.
A Group Policy is created and linked to the NAS OU that sets configuration parameters
for IPSec policy to require security. This will require that all IP traffic between the
Windows Powered NAS appliances and clients use IPSec to encrypt network data
transfers and will not allow any unsecured communication with non-trusted clients.
A second Group Policy is created and linked to the Notebooks OU that sets configuration
parameters for IPSec policy to request security. This will allow computers in the
Notebook OU to communicate normally with all other servers, but to use IPSec for
network data transfers to the Windows Powered NAS appliances.

149

3. Deploying Windows Powered NAS Appliances for Business Continuance

This scenario illustrates how NAS and DFS can be used to build a disaster recovery
solution. Using commodity hardware and off-the-shelf software, a business continuance
solution can be built at a fraction of the cost of other proprietary solutions. Apply these
configurations to your CATIA system if you need to ensure that a major failure, resulting
in data loss, disrupts the productivity of your design team as little as possible.
Company RST has deployed Active Directory at three locationsone main datacenter
and two regional datacenters. The company deploys large Windows Powered NAS
systems in each datacenter to host data for users at that site. Each regional site has a
domain controller replica. DFS is configured in such a way that each share on the NAS
appliance in the regional datacenters has a replica in the main datacenter. DFS replicas
in the main datacenter are set to the offline state to avoid users being directed to these
data shares.
In case of data loss at either of the regional datacenters, an administrator in the main
datacenter can set the appropriate DFS target online in order to redirect clients to access
the regional data stored at the main site.
FRS takes care of replicating all files from the regional datacenters to the main
datacenter. In case of a server going down, all users would be redirected to access data
stored on the Windows Powered NAS appliance at the main datacenter. The main site
would contain all files replicated up to the last replication cycle. The replication cycle can
be adjusted to minimize data discrepancies. In any case, the customer can be back in
business in the time required by an administrator at the main site to change the status of
the DFS target to be online.
The DFS namespace will be configured as follows:
\\CompanyRST\Files\Data
!

\\main\userdata1 (offline)

\\main\userdata2 (offline)

\\reg1\userdata1 (online)

\\reg2\userdata2 (online)

In day-to-day operations, users in the first regional datacenter are always directed to
\\reg1\userdata1 to access their data. If the Windows Powered NAS server in this
regional datacenter becomes unavailable, an administrator at the main site can bring
online the data replica stored on \\main\userdata1. Clients from the regional site are
automatically redirected to the data stored at the main datacenter.

150

Summary
In any migration from UNIX to Windows, including migrations to CATIA V5, the two
operating systems must cooperate, even if it is only for a small period of time. In realworld situations, with complex systems and hundreds or thousands of users, the
migration may take months to complete. You may also need to continue using UNIX longterm, as in situations where part of your user base continues to use CATIA V4 or you
have other applications specific to UNIX. Thus the communication between UNIX and
Windows is of great importance to those moving CATIA to Windows.
There are three main areas of interoperability:

Connectivity. communications between UNIX and Windows for running

commands or applications on the opposing operating system.

Authentication and authorization. the identification of users for the purpose of

controlling their level of access.

Resource Sharing. the serving of files from Windows to UNIX, or from UNIX to
Windows.

When selecting your interoperability solutions, you should pay close attention to the final
system you are moving toward. For example, there seems little point in using a solution
running on UNIX, if UNIX is to be phased out.

151

9
Conclusion
CATIA V5 is turning out to be the design tool preferred by most organizations in the
automobile, aerospace, and manufacturing industries. Windows is becoming more
popular in the engineering environment as the platform for all engineering tools, including
CATIA. If you have decided to run CATIA V5 on Windows, it is important to evaluate all
the deployment options. By selecting the most appropriate option for your needs, you can
implement a scalable, stable, and highly available design system with the minimum
administrative overhead.
Where CATIA should be installed is one of the first questions to be considered.
Traditionally, local installation on all workstations has been considered to provide the best
performance and least network traffic. However, the Appendix to this document shows
that, with Offline Folders and DFS, a code server can perform as well as a local
installation in these respects.
Code serving of the CATIA application not only reduces the overhead for packaging,
deployment, and distribution, but also almost eliminates administration of CATIA V5 on
workstations. With this type of installation, only OLE records, shortcuts, fonts, and two
lines in the etc\services files are deployed locally on workstations. This solution, which is
similar to many UNIX CATIA systems, avoids heavy local installations.
If you have a large number of workstations in your system, you will appreciate automated
installation of CATIA on workstations, especially with local installation. There are many
packaging and deployment tools available to help with this. The one you choose will
depend on budget, workstation numbers, whether you have already rolled out Windows,
and other factors.
When migrating to Windows from an existing UNIX-based CATIA V4 setup, you must
ensure that existing data is migrated smoothly and that none is lost or made unusable.
Furthermore, if you have added to CATIA with your own custom code, you will be keen to
retain this, without major rewriting, because of the investment it represents.
Finally, any UNIX to Windows migration will require these two operating systems to
interoperate, whether it is for the purposes of issuing commands, ensuring security, or
sharing files.
These are the principal areas your migration project will concentrate on. If you ensure
that each of them is fully planned for and thoroughly thought out, your project should run
smoothly with few headaches.

153

You will find details of tests carried out on CATIA to determine its performance and
scalability on Windows in the Appendix. Also included are recommendations for and the
limitations of each setup.
For more information and further reading, see the "References" chapter.

154

Appendix
Scalability, Performance, and
Capacity Testing
Introduction
Microsoft and Infosys, in partnership with a leading automotive manufacturer in Europe
and Intel Solution Services, have developed a set of comprehensive tests aimed at
validating the scalability of the Microsoft operating platform on Intel architecture to
support the CATIA V5 application.
Extensive tests with various combinations of components and scenarios were executed
at the Intel Solution Center in Munich, Germany with the objectives of validating the
feasibility of Code Serving the CATIA V5 application and identifying an optimal
architecture for deploying CATIA V5 using the Windows operating platform on Intel
architecture. A dedicated lab environment with isolated infrastructure ensured that the
tests were not influenced by external parameters. A worst-case scenario methodology
was adopted for the tests to simulate the maximum simultaneous load, utilizing multiple
workstations accessing the server at the same time, supplemented with automated
macros ensuring concurrency. The test results were analyzed and are documented in
detail in the subsequent sections of this chapter.
The results of these exhaustive tests bring to light some key findings:

CATIA V5 in Windows on the latest 32-bit Intel architecture is an extremely viable,

scalable, and cost-effective alternative to the existing UNIX environment.

Code serving of CATIA V5 utilizing Windows 2000 Advanced Server is comparable

in performance to locally installed CATIA V5 code on the workstations, and it
reduces management and maintenance headaches significantly.

The use of Offline Folders provides efficient caching of the code on individual
workstations, thus reducing the CPU, disk, memory, and network load on the
servers distributing the binaries.

The tests also proved that the use of Distributed File Systems (DFS) further
enhances the scalability of the servers while providing mission-critical high
availability of these servers to ensure continued and uninterrupted access to the
data.

In addition, the use of Code Serving allows simple switching between versions of
CATIA with minimal user disruption.

155

In summary, network connectivity between the Code Servers and the workstations is the
limiting factor for Code Serving of CATIA V5 on a Windows operating environment and
supporting infrastructure. However, the network limitation can be alleviated through the
use of the features mentioned above to arrive at an architecture capable of providing
comparable performance to local installation of CATIA while providing higher levels of
availability.
The results from the proof of concept tests at the Intel Solution Center have gone a long
way in confirming the industry-wide belief that CATIA deployment on a Windows
operating environment based on an Intel architecture is highly reliable and scalable,
reduces the total cost of ownership (TCO), and is the optimal architecture for the future,
thereby paving the way for its adoption and implementation in industry.

156

Testing Methodology
The subheadings below list the methods used in the test.

Objective
The tests provided the first-ever extensive scalability and sizing information for the codeserving functionality of Dassault Systems CATIA V5 software on the Microsoft operating
platform based on Intel architecture.
The objectives of the tests were to evaluate the following:

The scalability of a CATIA V5 Code Server. Dassault Systems has provided a

Code Serving capability to CATIA V5 since Release 9. The tests were designed to
establish the feasibility of the Code Serving function and to define the number of
workstations a Code Server could support in a real life scenario. Moreover,
recommendations for infrastructure sizing needed definition.

Impact of Offline Folders. Windows 2000 Server and Windows XP provide the
Offline Folders feature. Here, a client caches any files it uses from the server, on
the local hard disk. This allows the file to be opened more quickly and with little
network traffic on subsequent occasions. The feasibility and impact of effectively
utilizing this feature in a CATIA code-serving environment were to be validated.

DFS. Windows 2000 Server provides the DFS feature to access multiple Code
Servers. CATIA code was installed on multiple servers and a common share was
published using DFS. The DFS feature, designed to automatically guide
workstations to pick CATIA code from the next available server at any given time,
was to be verified.

The server and client performance needed to be compared to a locally installed CATIA
system accessing local CATIA data on a standalone workstation. These scenarios were
tested at network speeds of 10 Mbps and 100 Mbps.

Configuration of Macros and Scripts

Macros and CATIA scripts were used to simulate the real-world user behavior of CATIA
V5 R9 in several different scenarios. The macros were developed using CATIAs
CATScripting tools, Windows Shell scripts, and batch command files. Windows tools
were used to automate the tests and log the data for analysis.
Cases were planned to test performance in scenarios like Code Serving, Offline Folders
and DFS compatibility with CATIA, as well as the performance of the workstations, Code
Servers, and data servers. Macros and scripts executed the tests and recorded the
events, times, and other key parameters during the test.

Configuring CATIA for Tests

License User Management (LUM) Configuration
Before CATIA can be accessed for the first time, a license server configuration is needed
on the server and the workstation. For more information about CATIA license
management, see Chapter 6, "CATIA Data Migration." The concurrent CATIA licenses
were installed on a LUM server. Workstations were configured with the license server
information on the LUM client software to allow them to pick the license when CATIA
starts up.

157

CATIA Code Server Tests

CATIA V5 R9 SP1 Product AL2 was installed on the Code Servers. For a detailed
discussion of this style of setup see Chapter 4, "CATIA Code Server Installation." The
code files were located in the B09_SP1 folder and the environment file under
CATENV\B09_SP1. The code folder B09_SP1 and the environment folder
CATENV\B09_SP1 were shared to enable all client machines to access CATIA from the
server. In the case of tests with client side caching, Offline Folders were enabled with an
Active Directory group policy, and the caching option was turned on for the folder
B09_SP1 with automatic caching for the programs option. The CAD data (CATPart and
CATDrawing) was located under a specific share on the data server.
CATIA Local Tests
To compare the above setup with a local installation, CATIA V5 R9 SP1 Product AL2 was
installed on the local drive of a workstation. The code files were located under the
B09_SP1 folder and the environment file in the location CATENV\B09_SP1. The CAD
data (CATPart and CATDrawing) were located on the local drive of the workstation.
CATIA with DFS Tests
A DFS setup is similar to a Code Server setup. CATIA code folders were located on
multiple machines and a common DFS link was available for the workstations to access
CATIA.

158

Test Environment
The test setup was hosted in the Intel Solution Center in Munich, Germany. The tests
used 24 client workstations and 6 servers. The servers were Windows 2000 Advanced
Servers SP3 and the clients were running Windows 2000 Professional Edition SP3.
A Windows 2000 domain, with DNS name ProtoV5.fr, was set up for all the components
in the infrastructure. Server IP addresses were static, whereas IP addresses for the
workstations were configured to be automatically allocated using a DHCP server.
Additionally, two servers were used for CATIA Code Serving and one more was used for
housing the CAD data. A (LUM) and two Active Directory servers were also part of the
setup. The servers were connected through an Intel Netstructure 480T Routing Switch
and the workstations through an Intel Express 510T Switch. Both switches were
interlinked using a Gigabit Fiber connection.
Further details about the hardware, software, and the testing tools used in the project are
documented in subsequent sections.

159

Network Schematic Diagram

Figure A.1 shows the network infrastructure of the testing environment in the lab:

Figure A.1
Network Schematic

Note Thick lines in the figure indicate 1Gbps links, while thin lines indicate 100 Mbps
links.

Hardware and Software Components

The hardware and software components used in the scalability test are listed below.

Hardware Components
Servers

Supermicro Intel Xeon DP

Data Server: Stores CATIA Models and associated data accessed by all clients.

License Server: Issues CATIA licenses to the clients to run CATIA.

Active Directory/DNS: Acts as Domain Controller and resolves host names to IP

addresses.

DHCP Server: Issues IP addresses to the clients.

Code Server

Intel Xeon MP

Central installation of CATIA; shares the CATIA-code with clients.

160

Workstations HP Workstation x2100

24 workstations used as clients for accessing CATIA.

Network Components
The network connectivity between the Servers and the workstations was established
through Intel switches. The Data Server and Code Servers were connected with 1 Gbps
links and the other connections were 100 Mbps. A list of the network switches used in the
testing environment follows:
Switches

Intel Express 510T Switch

Intel Netstructure 480T Routing Switch

Software Components

Windows 2000 Advanced Server SP3

Windows 2000 Professional Edition SP3

CATIA V5 R9 SP1

LUM 4.6.4

Testing Tools
Testing the scalability feature of CATIA for Code Serving, Offline Folders, and DFS was
carried out entirely using macros and batch commands based on the Windows platform.
No specific commercially available tools were used for the testing exercise. Real world
scenarios were simulated through the use of user-defined scripts and CATIA macros in
addition to certain Windows Resource Kit utilities.
CATIA macros were used to automate the work of the CATIA application. Windows
scripts were created to modify the registry settings as required. Test metrics were defined
and selected performance counters were captured automatically during the test runs.
Multiple iterations and other sequential operations for the tests were included in batch
files and script files to avoid manual intervention, thus ensuring the accuracy of the
results.
Tests were scheduled with the Windows Scheduler, and performance counters were
captured using the Windows command line utility TypePerf.exe. Registry values were
modified in the scripts to run automatically for a pre-defined number of iterations (10).

161

Test Configuration Summary

CATIA performance was analyzed under many different scenarios. Test combinations
included location of the code, network speed, use of Offline Folders, number of Code
Servers (DFS), number of CPUs on the Code Servers, amount of memory on the
workstations, and number of clients simultaneously accessing CATIA.
The table below presents detailed information for each test. The number of iterations was
10 for all tests. Key statistics, such as CATIA start time, Change Work Bench, and
Drawing time, were used for the analysis of the results.
Table A.1: Test Scenarios

162

Test No

Test Scenario

Test 01

Local Data; Local Code SP1 (2 Workstations 512 MB RAM, 1 Workstation 1

GB RAM)

Test 02

Local Data; Local Code SP4; 1 Workstation

Test 03

Data Server; Code Server SP1; 100 Mbps; 1 Workstation

Test 04

Data Server; Code Server SP1; 100 Mbps; 1 Workstation; Offline Folders

Test 05

Data Server; Code Server SP1; 100 Mbps; 10 Workstations

Test 06

Data Server; Code Server SP1; 100 Mbps; 10 Workstations; Offline Folders

Test 07

Data Server; Code Server SP1; 100 Mbps; 24 Workstations

Test 08

Data Server; Code Server SP1; 100 Mbps; 24 Workstations; Offline Folders

Test 09

Data Server; 2 Code Servers SP1; 100 Mbps; 10 Workstations; DFS

Test 10

Data Server; 2 Code Servers SP1; 100 Mbps; 24 Workstations; DFS

Test 11

Data Server; Code Server SP1; 10 Mbps; 10 Workstations

Test 12

Data Server; Code Server SP1; 10 Mbps; 10 Workstations; Offline Folders

Test 13

Data Server; Code Server SP1; 10 Mbps; 24 Workstations

Test 14

Data Server; Code Server SP1; 10 Mbps; 24 Workstations; Offline Folders

Test 15

Data Server, Code Server SP1; 100 Mbps; 1 Workstation; 256 MB RAM on the
workstation

Test 16

Data Server; Code Server SP1; 100 Mbps; 24 Workstations; 2 CPUs on the Code
Server

Test 17

Data Server; Code Server SP1; 100 Mbps; 24 Workstations; 4 CPUs on the Code
Server

Test 18

Data Server; Code Server SP1; 100 Mbps; 24 Workstations.

5 minutes wait after the first iteration

Test 19

Data Server; Code Server SP1; 10 Mbps; 24 Workstations.

15 minutes wait after first Iteration; Offline Folders

Test Plan
The following table summarizes the characteristics that were tested in each of the 19
tests.

Test
Number

Table A.2: Test Plan Summary

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Network
Number of
# of Code
Configuration
Clients
Servers
Location
Location
Level
100
10
1 10 24
Local Server Local Server SP1 SP4 Mbps Mbps
1
2
CATIA Data

CATIA Code

Offline
Limited
Folders
RAM
Enabled

2CPU
4CPU
Wait 5
min
Wait 15
min

163

Hardware and Software Details for Tests

This section contains a detailed description of hardware and software used in the
scalability tests.
Table A.3: Hardware
Active Directory, DNS, and DHCP Servers - Lorient, Quiberon, StMalo
Vendor: Supermicro
2 x Intel Xeon DP Processors, 2.2 GHz
4 GB RAM
100 Mbit/s Network Adapter
2x Seagate ST318406LC SCSI HD, 18GB, 10krpm

Data Server - Bourges:

Vendor: Supermicro
2 x Intel Xeon DP Processors, 2.2 GHz
4 GB RAM
1 Gbit/s Network Adapter
Adaptec 2000S SCSI RAID Controller
6x Seagate ST318406LC SCSI HD, 18GB, 10krpm (2x RAID0, 4x RAID5)

Code Server - Vichy & Strabourg

Vendor: Intel
4 x Intel Xeon MP Processors, 2.0 GHz
2 GB RAM
1 Gbit/s Network Adapter
ICP Vortex GDT8523RZ RAID Controller
5x Seagate ST318404LC SCSI HD, 18GB, 10krpm (1x single, 4x RAID5)

Workstations WS01 to WS24

Vendor: HP, Workstation x2100
Intel Pentium 4 processor, 2.6 Ghz
512 MB RAM
100 Mbit/s Network Adapter
1x Maxtor 6L020J1 IDE HD, 20GB, 7.2krpm
ATI Fire GL 8800 Graphic Adapter

Switch - Intel Express 510T

24 ports 100 BASE-T
1 port Fiber GBIC

164

Switch - Intel Netstructure 480T Routing Switch

12 ports 100 / 1000 BASE-T
4 ports Fiber (SX, LX, LH, GBIC)

Software
Windows 2000 Advanced Server SP3
Windows 2000 Professional Edition SP3 for Workstations
CATIA V5R9 SP1
LUM 4.6.4
Symantec Ghost 7.5

165

Test Results and Analysis

The following subheading discuss the test results and perform analysis on the results.

Key Statistics for Analysis

Key counters were captured during test execution. These parameters were used for
analyzing the results and arriving at conclusions. Some of them and their objectives are
listed below:

CATIA Start Time. Start time of CATIA is the most important statistic for analysis.
CATIA start time is measured as the time required for starting CATIA on a
workstation, either with local code or Code Serving. By comparing the CATIA start
times, one can determine how scalability varies with different Code Serving
scenarios and when the code is installed locally. Comparison of Code Serving with
and without Offline Folders shows how this feature benefits performance. CATIA
start times on 10 Mbps and 100 Mbps networks were also compared because
some corporations are currently utilizing 10 Mbps network configurations. Statistics
were captured for multiple iterations without a restart of the workstation to measure
the effect of disk, memory, and any other caching on the start times. The minimum
and maximum CATIA start times and average times with client side caching were
computed to indicate the best and worst performance.

CATIA Total Time for Changing Workbench and Drawing. The CATIA total time
value captures the total time for a user to change from one workbench to another
and create a new drawing. This statistic indicates the performance of CATIA in a
scenario where a user changes to a drawing workbench of CATIA and creates a
drawing, resulting in an effect on both network and CPU of the local workstation.

Memory Utilization. The performance of CAD workstations depends heavily on

the amount of memory available on the workstation and the servers. Parameters
required to decide on an optimal memory configuration were captured, including
Memory Used and Memory Available.

The values of the parameters mentioned above are represented graphically for all the
tests in the following section.
Some of the other performance parameters measured in the tests for example, CATIA
Open Time, Percentage Processor Use, and Bytes Sent and Received by Code Servers
are not represented graphically in the following section, but have been used in the
analysis.

166

Scalability Test Results

Table A.4: Effect of Local Code Vs Code Server Vs Offline Folders (for 1 Client)
Test No.

Configuration

Test 01

Local Code Local Data

Test 03

Code Server, Data Server without Offline Folder

Test 04

Code Server, Data Server with Offline Folder

Start Time (Sec)

Start Time
45
40
35
30
25
20
15
10
5
0

Test 01
Test 03
Test 04

Test Average

Test Max

Test Min

Figure A.2
Start Time

Change Workbench Time

10

Time (Sec)

8
Test 01

Test 03
4

Test 04

2
0
Test Average

Test Max

Test Min

Figure A.3
Change Workbench Time

167

Memory used (MB)

Memory Usage
400
350
300
250

Test 03

200
150
100
50
0

Test 04

Test Average

Test Max

Test Min

Figure A.4
Memory Usage

Test 03 shows that with a single client, the Code Serving works well. It gives the
average CATIA Start Time of below 10 seconds and Change Workbench Time of
about 3 seconds, which are not too high compared with the results obtained in
local code test (Test 01).

In Test 03, at the Code Server, the Percentage Processor Use value is always
below 29%, with an average of below 2%.

In Test 04, the Code Serving for a single client is supplemented by the use of
Offline Folders. The average CATIA Start Time is almost the same as that
obtained in the previous test without Offline Folders.

The Change Workbench Time reduced from 3.3 sec in Test 03 to 2.9 sec in Test
04. Also, there is a small drop in CATIA Open Time from 16 sec in Test 03 to 14
sec in Test 04.

When we compare the performance at the Code Server in Test 04 with the same in
Test 03, the Memory Used decreased by 10% and the Percentage Processor Use
decreased by 2%. This shows that the performance is significantly improved by
using Offline Folders with Code Serving.

Bytes Sent decreased by 60% from Test 03 to Test 04. Bytes received decreased
by 30% from Test 03 to Test 04.

Table A.5: Effect of Code Server Vs Offline Folders (for 10 and 24 Clients)

168

Test 05

Code Server, Data Server without Offline Folder, 10 workstations

Test 06

Code Server, Data Server with Offline Folder, 10 workstations

Test 07

Code Server, Data Server without Offline Folder, 24 workstations

Test 08

Code Server, Data Server with Offline Folder, 24 workstations

Start Time (Sec)

Start Time
45
40
35
30
25
20
15
10
5
0

Test 05
Test 06
Test 07
Test 08

Test Average

Test Max

Test Min

Figure A.5
Start Time

Change Workbench Time

36

Time (Sec)

30
Test 05

24

Test 06

18

Test 07
Test 08

12
6
0
Test Average

Test Max

Test Min

Figure A.6
Change Workbench Time

169

Memory used (MB)

Memory Usage
450
400
350
300
250
200
150
100
50
0

Test 05
Test 06
Test 07
Test 08

Test Average

Test Max

Test Min

Figure A.7
Memory Usage

In Test 06, Code Serving was supplemented with Offline Folders and the test was
carried out for the same number of clients as in Test 05, that is, 10 clients. The
average CATIA Start Time and average Change Workbench Time show slight
reductions.

CATIA Open Time, not shown here, reduced significantly from 19.90 seconds in
Test 05 to 15.75 seconds in Test 06.

The performance parameters (Memory Used at the Server and the Percent Usage
of Processor) show substantial reduction from Test 05, in which Offline Folders
were not used. Bytes Sent decreased by 60% and Bytes Received decreased
approximately 30%. Thus Code Serving with Offline Folders has improved the
server performance.

The aim of Test was to see the effect of enabling Offline Folders for Code Serving
with a large number of clients (24). The average CATIA Start Time shows some
reduction (approximately 10%) and average Change Workbench Time shows
some increase (approximately 10%), but CATIA Open Time reduced from 20.17
seconds in Test 07 to 18.68 seconds in Test 08.

In Test 08, Memory Used at the Server went down by about 10%. The Percent
Usage of Processor shows about a 25% reduction from Test 07, in which Offline
Folders were not used. Bytes Sent decreased by more than 60% and Bytes
Received decreased by approximately 23%. Thus, the Code Serving with Offline
Folders has improved the server performance, even with more workstations.

Table A.6: Effect of Number of Clients on Code Server with and without Offline
Folders Enabled

170

Test 03

Code Server, Data Server without Offline Folder, 1 workstation

Test 05

Code Server, Data Server without Offline Folder, 10 workstations

Test 07

Code Server, Data Server without Offline Folder, 24 workstations

Test 04

Code Server, Data Server with Offline Folder, 1 workstation

Test 06

Code Server, Data Server with Offline Folder, 10 workstations

Test 08

Code Server, Data Server with Offline Folder, 24 workstations

Start Time (Sec)

Start Time
45
40
35
30
25
20
15
10
5
0

Test 03
Test 05
Test 07
Test 04
Test 06
Test 08

Test Average

Test Max

Test Min

Figure A.8
Start Time

Change Workbench Time

36
Test 03

Time (Sec)

30

Test 05

24

Test 07

18

Test 04

12

Test 06
Test 08

6
0
Test Average

Test Max

Test Min

Figure A.9
Change Workbench Time

171

Memory used (MB)

Memory Usage
450
400
350
300
250
200
150
100
50
0

Test 03
Test 05
Test 07
Test 04
Test 06
Test 08
Test Average

Test Max

Test Min

Figure A.10
Memory Usage

The comparative graphs show the effect of an increasing number of client

workstations with and without enabling Offline Folders for Code Serving. When the
results of Test 03, 05, and 07 are compared, the average CATIA Start Times show
significant increases approximately 9 seconds, 11 seconds, and 20 seconds.
The average Change Workbench and Drawing Times show steady increases
approximately 19 seconds, 24 seconds, and 27 seconds. However, the Memory
Used remains almost constant between 310 and 340 MB.

In Test 04, 06, and 08, the CATIA Timings do not show significant changes, but the
performance parameters certainly improve due to the use of the Offline Folders. In
Test 08, in which Offline Folders are enabled, the Memory Used at the Server goes
down by about 10%. The Percent Usage of Processor (not illustrated in the graph)
shows about a 25% reduction from Test 07, while Bytes Sent goes down by more
than 60%, and Bytes Received decreases by approximately 23%. As you can see,
when number of workstations increases, Code Serving with Offline Folders
provides good performance.

Table A.7: Effect of Number of Code Servers with and without DFS

172

Test 05

Code Server, Data Server without DFS, 10 workstations

Test 09

Code Server, Data Server with DFS, 10 workstations

Test 07

Code Server, Data Server without DFS, 24 workstations

Test 10

Code Server, Data Server with DFS, 24 workstations

Start Time (Sec)

Start Time
45
40
35
30
25
20
15
10
5
0

Test 05
Test 09
Test 07
Test 10

Test Average

Test Max

Test Min

Figure A.11
Start Time

Change Workbench Time

24

Time (Sec)

20
Test 05

16

Test 09

12

Test 07
Test 10

8
4
0
Test Average

Test Max

Test Min

Figure A.12
Change Workbench Time

173

Memory used (MB)

Memory Usage
400
350
300
250

Test 05
Test 09

200
150
100
50
0

Test 07
Test 10

Test Average

Test Max

Test Min

Figure A.13
Memory Usage

174

In Test 09, there are 2 Code Servers with DFS to serve 10 clients. The average
CATIA Start Time decreased by about 15% when compared with Test 05, which
used the same number of clients with a single Code Server. The average Change
Workbench Time also showed a slight reduction. CATIA Open Time (not shown
here) reduced from 19.90 seconds in Test 05 to 17.99 seconds in Test 09.

Observing the performance parameters of both the Code Servers, it is clear that
both are sharing the load of Code Serving, but not always equally. The Percent
Usage of Processor (not shown here), and consequently Bytes Sent and Received,
are different in both the Code Servers and the processor of the Vichy server seems
to be taking more load. However, Memory Used at the Server does not seem to be
significantly different in both the servers.

Test 10 was done with two Code Servers (Vichy and Strabourgh) with DFS to see
the effect of a larger number of clients (24). The average CATIA Start Time
decreased by about 25% when compared with Test 07, in which the same number
of clients used a single Code Server. The Change Workbench Time decreased
more than 10%. Also, CATIA Open Time (not shown here) decreased marginally
from 22 seconds in Test 07 to 21 seconds in Test 10.

The performance parameters of both the Code Servers show that both are sharing
the load of Code Serving, but not equally. The Percent Usage of Processor (and,
consequently, Bytes Sent and Received) differ between Code Servers and the
processor of the Vichy server is again taking more load. Memory Used at the
Server does not seem to be significantly different in both the servers, as earlier.

These tests show that Code Serving is possible with multiple Code Servers
through DFS and provides satisfactory performance, even with a large number of
clients.

Table A.8: Effect of Limited RAM in Client Workstations (256 MB Vs 512 MB with 1
Client)
Test 03

Code Server, Data Server with 512 MB RAM, 1 workstation

Test 15

Code Server, Data Server with 256 MB RAM, 1 workstation

Start Time

Start Time (Sec)

16
14
12
10

Test 03

8
6

Test 15

4
2
0
Test Average

Test Max

Test Min

Figure A.14
Start Time

Change Workbench Time

8

Time (Sec)

7
6
5

Test 03

Test 15

3
2
1
0
Test Average

Test Max

Test Min

Figure A.15
Change Workbench Time

175

Memory used (MB)

Memory Usage
400
350
300
250
200
150
100
50
0

Test 03
Test 15

Test Average

Test Max

Test Min

Figure A.16
Memory Usage

Test 15 was done with reduced memory in the workstation (256MB), a single client, a
single Code Server, and a single data server on a 100 Mbps network. CATIA Start
Timings are up to approximately 30% higher with 256 MB RAM than those in a similar
test configuration with 512 MB RAM (that is, Test 03). Server Utilization is similar to Test
03. This implies that for a CATIA model workstation size of approximately 18 MB, 256 MB
of RAM provides a reasonable performance.
Table A.9: Effect of Number of CPUs Effect of Number of CPUs in Code Servers (1,
2 and 4 CPUs with 24 Clients)
Test 07

Code Server, Data Server, 24 workstations, 1 CPU

Test 16

Code Server, Data Server, 24 workstations, 2 CPUs

Test 17

Code Server, Data Server, 24 workstations, 4 CPUs

Start Time
70
Start Time (Sec)

60
50
Test 07
Test 16
Test 17

40
30
20
10
0
Test Average

Figure A.17
Start Time

176

Test Max

Test Min

Change Workbench Time

30

Time (Sec)

25
20

Test 07

15

Test 16
Test 17

10
5
0
Test Average

Test Max

Test Min

Figure A.18
Change Workbench Time

Memory used (MB)

Memory Usage
400
350
300
250
200

Test 07
Test 16

150
100
50
0

Test 17

Test Average

Test Max

Test Min

Figure A.19
Memory Usage

Test 16 used a data server, a single Code Server with 2 CPUs, 24 clients, and
Offline Folders disabled. Test 17 was the same, but it had 4 CPUs in the Code
Server. These tests can be compared with Test 07, in which only one CPU was
installed in the Code Server.

In these tests, the CATIA performance parameters showed negligible differences.

This implies that the number of CPUs in the Code Server does not affect the
performance of CATIA, because the network is the major limiting factor. Server
performance was also similar.

Table A.10: Effect of Network Speed (with 10 and 24 Clients)

Test 05

Code Server, Data Server 10 workstations, 100 Mbps

Test 11

Code Server, Data Server 10 workstations, 10 Mbps

Test 07

Code Server, Data Serve, 24 workstations, 100 Mbps

Test 13

Code Server, Data Server, 24 workstations, 10 Mbps

177

Start Time

Start Time (Sec)

60
50
Test 05
Test 11
Test 07
Test 13

40
30
20
10
0
Test Average

Test Max

Test Min

Figure A.20
Start Time

Change Workbench Time

30

Time (Sec)

25
20

Test 05

15

Test 07

Test 11
Test 13

10
5
0
Test Average

Figure A.21
Change Workbench Time

178

Test Max

Test Min

Memory Usage

Memory used (MB)

400
350
300

Test 05
Test 11
Test 07
Test 13

250
200
150
100
50
0
Test Average

Test Max

Test Min

Figure A.22
Memory Usage

In Test 11, there was a data server, a single CATIA Code Server, a 10 Mbps
network, 10 client machines, and Offline Folders disabled. The maximum CATIA
Start Time is 43 seconds, which is close to the typical CATIA Start Time with local
installation (40 seconds), but much higher than that with a 100 Mbps network (11
seconds in Test 05).

In Test 13, the number of clients was increased to 24. When compared with the
results of Test 11, in which there were 10 client machines, CATIA performance
variation is negligible.

179

Analysis of Network Utilization in Tests

One key observation during the tests is that the Backbone Network Bandwidth, that is,
the network connectivity between the clients and the switch, saturated when more clients
were accessing the Code Server. The performance data for the following tests are
considered to analyze the effect of more clients on the network utilization:

Tests 03, 05 and 07

Configuration: Code server, data server, 100 Mbps network: For 1, 10, and 24
clients.

Bytes Sent / Sec from Code Server

Bytes Sent / Sec (Mbps)

12 0

97.76

10 0

81.20

80
60
40

10.79

20
0

9.71

6.50

0.72
1C lie nt (Te s t 03)

10 C lie nts (Te s t 05)

24 C lie nts (Te s t 07)

Numbe r of Clie nts

Average Bytes Sent

Maximum Bytes Sent

Figure A.23
Bytes Sent per Second

Observations. The graph clearly shows that when the number of machines is increased
from 1 to 10, there is an approximately 8-fold increase in the Maximum Bytes Sent from
the server. However when the number of machines is further increased from 10 to 24F,
there is only a further 20% increase in the same counter. This confirms the saturation in
the backbone network.

180

Tests 04, 06 and 08

Configuration: Code server, data server, Offline Folders enabled, 100 Mbps
network: For 1, 10, and 24 clients.

Bytes Sent / Sec from Code Server

Bytes Sent / Sec (Mbps)

12 0
10 0

89.20
70.47

80
60
40

10.45

20
0

3.56

2.46

0.28
1C lie nt (Te s t 04)

10 C lie nts (Te s t 06)

24 C lie nts (Te s t 08)

Numbe r of Clie nts

Average Bytes Sent

Maximum Bytes Sent

Figure A.24
Bytes Sent per Second

Observations. Similar to Figure 3.23, this graph also indicates that increasing the
number of clients from 10 to 24 is not accompanied by a corresponding increase in the
Maximum Bytes Sent from the server as a result of network saturation.

181

Key Findings
These scalability tests simulated a variety of real life scenarios to obtain conclusive
results on scalability and performance. The network bandwidth between the Code
Servers and the workstations was found to be the limiting factor for Code Serving of
CATIA V5 on the Windows operating environment and supporting infrastructure. Hence,
binary Code Serving is an architecture capable of providing comparable performance to a
local installation of CATIA, and it can also provide higher levels of availability.

182

Recommendations for Capacity Planning

The scalability of the CATIA Code Server and the client workstations was proved in the
test environment for a 24 client configuration. All the counters which affect the
performance of CATIA were captured on both server and client. Analysis of the counters
on the server indicated that the peak load on the server CPU was just 20 percent.
However, the network bandwidth was 100% utilized (refer to Figure 3.25). By
extrapolating the optimum CPU load data, it can be concluded that the Windows server
can scale up to 50 workstations in a Code Serving environment.

Bytes Send from Code Server

Bytes Send (MB/Sec)

100
80
60
40
20
0
1

10

24

Number of Clients
Figure A.25
Bytes Sent from Code Server

Table A.11: Server Configuration Recommendations:

Intel Xeon processors, 2.0 GHz
2 GB RAM
1 Gbit/s network adapter
ICP Vortex GDT8523RZ RAID Controller
SCSI HD, 73GB, 10krpm (1x single, 4x RAID5)

Table A.12: Workstation Configuration Recommendations:

1x Intel Pentium 4 processor, 2.6 GHz (Single Processor)
512 MB RAM
100 Mbit/s network adapter
1x Maxtor 6L020J1 IDE HD, 20GB, 7.2krpm
ATI Fire GL 8800 graphic adapter

183

Conclusion
The CATIA binary Code Serving solution has been performance tested and proved in the
Windows architecture. This solution is recommended for CATIA deployments in large
Windows technical environments. The Code Serving solution provides a better
deployment paradigm resulting in reduced administration overheads in large engineering
installations.

184

References
For further information on any specific topic, please refer to the following links:

UNIX and Windows Interoperability

Migrating to Windows from UNIX and Linux:

http://www.microsoft.com/windows2000/migrate/unix

Windows Interoperability:
http://www.microsoft.com/windows2000/interop

Microsoft Windows Services for UNIX (product home page):

http://www.microsoft.com/windows2000/sfu/

Microsoft Interix:
http://www.microsoft.com/windows2000/interix/

Windows Services for UNIX version 2 (white paper):

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/w
indows2000serv/deploy/sfu/sfu.asp

Customizing Windows Services for UNIX Installation:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/wi
ndows2000serv/deploy/sfu/sfucustm.asp?frame=true

Windows 2000 Professional in a UNIX Environment (white paper):

http://www.microsoft.com/windows2000/library/planning/default.asp

Excerpts from the Windows 2000 Resource Kits:

http://www.microsoft.com/windows2000/library/resources/reskit/default.asp

Application/Script Migration from UNIX to Windows

How to Successfully Migrate UNIX Applications to Windows 2000 Professional

(white paper):
http://www.microsoft.com/windows2000/techinfo/interop/UNIXapps.asp

UNIX Code Migration Guide (Prescriptive Architecture Guide PAG):

http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnucmg/html/ucmglp.asp

Windows Scripting (TechNet Script Center):

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/scriptcenter/de
fault.asp

Remote Management/Resource Management

Microsoft Remote Installation Services:

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/w
indows2000serv/deploy/depopt/remote.asp

Microsoft Software Update Services:

185

Server Requirements and Recommendations for Installing Microsoft Software

Update Services (Q322365):
http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/ittasks/suppor
t/corpwu.asp

Manage Change with Windows 2000 Platform

http://www.microsoft.com/windows2000/server/evaluation/business/managechang
e.asp

Implementing Common Desktop Management Scenarios (white paper):

http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppo
licy.asp

Microsoft Systems Management Server:

http://www.microsoft.com/smserver/default.asp

Microsoft Windows Installer

Overview of Windows Installer:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/over_1gdu.asp

Windows Installer: Benefits and Implementation for System Administrators:

http://www.microsoft.com/windows2000/techinfo/administration/management/winin
staller.asp

Microsoft Windows 2000 Server

http://www.microsoft.com/windows2000/server/default.asp

Microsoft Distributed File System

White paper Microsoft Distributed File System:

http://www.microsoft.com/windows2000/techinfo/howitworks/fileandprint/dfsnew.as
p

Step-by-Step Guide to Distributed File System (Dfs):

http://www.microsoft.com/windows2000/techinfo/planning/fileandprint/dfssteps.asp

Distributed File System (Dfs): Best Practices and Troubleshooting Guide:

http://www.microsoft.com/windows2000/techinfo/administration/fileandprint/dfsbp.a
sp

Microsoft Offline Folders

Use Automatic Caching To Make Files Available Offline:

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/w
indows2000serv/tips/autoca.asp

High Performance Computing (HPC)

186

Microsofts Solutions for High Performance Computing with Windows:

http://www.microsoft.com/windows2000/hpc/

CATIA Application (Dassault Systemes 3D PLM

solution)

CATIA:
http://www.3ds.com/en/brands/CATIA_ipf.asp

CATIA V5 Introduction:
http://www3.ibm.com/servlet/solutions/plm/plmgk?did=052569650058d112&pid=v5_intro

187