Rehost Utility Guide

12.1.2.0
Copyright © 2022 PTC Inc. and/or Its Subsidiary Companies. All Rights
Reserved.
User and training guides and related documentation from PTC Inc. and its
subsidiary companies (collectively "PTC") are subject to the copyright laws of the
United States and other countries and are provided under a license agreement that
restricts copying, disclosure, and use of such documentation. PTC hereby grants to
the licensed software user the right to make copies in printed form of this
documentation if provided on software media, but only for internal/personal use
and in accordance with the license agreement under which the applicable software
is licensed. Any copy made shall include the PTC copyright notice and any other
proprietary notice provided by PTC. Training materials may not be copied without
the express written consent of PTC. This documentation may not be disclosed,
transferred, modified, or reduced to any form, including electronic media, or
transmitted or made publicly available by any means without the prior written
consent of PTC and no authorization is granted to make copies for such purposes.
Information described herein is furnished for general information only, is subject
to change without notice, and should not be construed as a warranty or
commitment by PTC. PTC assumes no responsibility or liability for any errors or
inaccuracies that may appear in this document.
The software described in this document is provided under written license
agreement, contains valuable trade secrets and proprietary information, and is
protected by the copyright laws of the United States and other countries. It may
not be copied or distributed in any form or medium, disclosed to third parties, or
used in any manner not provided for in the software licenses agreement except
with written prior approval from PTC.
UNAUTHORIZED USE OF SOFTWARE OR ITS DOCUMENTATION CAN
RESULT IN CIVIL DAMAGES AND CRIMINAL PROSECUTION.
PTC regards software piracy as the crime it is, and we view offenders accordingly.
We do not tolerate the piracy of PTC software products, and we pursue (both
civilly and criminally) those who do so using all legal means available, including
public and private surveillance resources. As part of these efforts, PTC uses data
monitoring and scouring technologies to obtain and transmit data on users of
illegal copies of our software. This data collection is not performed on users of
legally licensed software from PTC and its authorized distributors. If you are
using an illegal copy of our software and do not consent to the collection and
transmission of such data (including to the United States), cease using the illegal
version, and contact PTC to obtain a legally licensed copy.
Important Copyright, Trademark, Patent, and Licensing Information: See
the About Box, or copyright notice, of your PTC software.
UNITED STATES GOVERNMENT RIGHTS
PTC software products and software documentation are “commercial items” as
that term is defined at 48 C.F.R. 2.101. Pursuant to Federal Acquisition Regulation
(FAR) 12.212 (a)-(b) (Computer Software) (MAY 2014) for civilian agencies or

2
the Defense Federal Acquisition Regulation Supplement (DFARS) at 227.7202-1
(a) (Policy) and 227.7202-3 (a) (Rights in commercial computer software or
commercial computer software documentation) (FEB 2014) for the Department of
Defense, PTC software products and software documentation are provided to the
U.S. Government under the PTC commercial license agreement. Use, duplication
or disclosure by the U.S. Government is subject solely to the terms and conditions
set forth in the applicable PTC software license agreement.
PTC Inc., 121 Seaport Blvd, Boston, MA 02210 USA

3
 Contents

About This Guide ........................................................................................................6

Rehost Process Overview..........................................................................................15
General Rehost Process .....................................................................................16
Various Rehost Scenarios ...................................................................................18
Rename Scenario Process ..................................................................................21
Rehost Scenario Process ....................................................................................22
Clone Scenario Process......................................................................................26
Move Scenario Process ......................................................................................29
License Considerations for Rehost Scenarios .......................................................33
Planning Rehost Project Activities ..............................................................................34
Selecting the Right Scenario................................................................................35
Setting Up The Rehost Environment ....................................................................36
Identifying Activities for Rename ..........................................................................39
Identifying Activities for Rehost ............................................................................41
Identifying Activities for Clone ..............................................................................43
Identifying Activities for Move...............................................................................45
Identifying Optional Activities to Include When Rehosting ......................................49
Out-of-Scope Configurations ...............................................................................50
Installing and Uninstalling the Windchill Rehost Utility ..................................................51
Installing the Windchill Rehost Utility ....................................................................52
Uninstalling the Windchill Rehost Utility ................................................................54
Using the Windchill Rehost Utility ...............................................................................55
Windchill Rehost Utility Overview .........................................................................56
Using Modules ...................................................................................................61
Editing Contents of projects.properties.......................................................63
Creating rehost.properties Files ..................................................................66
Running the Windchill Rehost Utility .....................................................................66
Backing Up Artifacts from a Custom Windchill Environment ...................................72
Recovery Using Windchill Rehost Utility Backups..................................................73
Rehost Utility Configuration Details.............................................................................75
Rehost Module Descriptions ................................................................................76
Rehost Property Descriptions ............................................................................ 102
Rehost Scenario Examples ...................................................................................... 140
Rename Scenario Example ............................................................................... 141
Rehost Scenario Example ................................................................................. 145
Rehost Cluster Scenario Example...................................................................... 150
Clone Scenario Example ................................................................................... 163

4 Rehost Utility Guide

 Move Scenario Examples.................................................................................. 168
Manual Rehost Activities.......................................................................................... 175
Planning Rehost Project Activities ...................................................................... 176
Update Host Name in Windchill Enterprise Systems Integration (ESI) Failure
Task URL...................................................................................................... 176
Exporting Database from Source System and Importing It into Target System:
Oracle .......................................................................................................... 177
Exporting Database from Source System and Importing It into Target System:
Microsoft SQL Server .................................................................................... 178
Automated Rehost Activities .................................................................................... 179
Automated Solr Rehost ..................................................................................... 180
Rehost Utility Script Examples.................................................................................. 190
Windows Script Examples ................................................................................. 191
UNIX and Linux Script Examples ....................................................................... 197
Using the xconfmanager Utility in a Script ........................................................... 203
Appendix A.Pro/Intralink Rehost Support .................................................................. 204
Appendix B.Rehosting Windchill with Configured PTC System Monitor........................ 205

Contents 5
 About This Guide

This guide documents the installation and use of the PTC Windchill Rehost
Utility. It contains the following chapters:
• Rehosting Process Overview on page 15
• Planning Rehost Activities on page 34
• Installing the Windchill Rehosting Utility on page 52
• Using the Windchill Rehosting Utility on page 55
• Rehosting Utility Configuration Details on page 75
• Rehosting Scenarios Examples on page 140
• Rehosting Utility Script Examples on page 190
• Manual Rehosting Activities on page 175
This guide is intended for system administrators who are installing the PTC
Windchill Rehost Utility and then using the utility to rename, rehost, move, or
clone an existing Windchill system.
To take advantage of the functionality in the PTC Windchill Rehost Utility, you
must have:
• General system administration and networking knowledge
• General Windchill knowledge
• Knowledge of or access to someone who has knowledge of the database used
by Windchill
• Knowledge of or access to someone who has knowledge of the LDAP servers
that are used by Windchill

6 Rehost Utility Guide

Revision History
Date Modified Description of Change
December 2022 No content change for 12.1.2.0 release.
for 12.1.2.0
June 2022 for • Added new Rehost properties for ldap in Rehost Property
12.1.1.0 Descriptions chapter.
• Support for Windchill Bulk Migrator (WBM) module.
○ Required and optional properties are added.
December 2021 • Added optional properties for multiple source and target
for 12.1.0.0 entries in the rehost.properties file.
• The terminology has been updated in few property names,
file names and labels in images in this release of
Windchill Rehost Utility. Though this is a terminology
change, there is no impact or change in the existing
behavior of the product or the features associated with the
properties or file whose names have been modified.
○ List of modified property names:
Old Name Modified Name
cluster.master.ga cluster.main.gate
teway way
cluster.slave. cluster.secondar
hostname y.hostname
cluster.slave.re cluster.secondar
host y.rehost
wt.cache.master. wt.cache.main.
hostname hostname
rehost.clustermas rehost.cluster
ter_example main_example
rehost.cluster rehost.clusterse
slave_example condary_example
rehost.clustermas rehost.cluster
ter_vault_example main_vault_
example

7
Date Modified Description of Change
○ List of modified file names:
Old Name Modified Name
rehost_ rehost_
clustermaster.pro clustermain.pro
perties perties
rehost_ rehost_
clustermaster_ clustermain_
vault.properties vault.properties
rehost_ rehost_
clusterslave_ clustersecondary_
first.properties first.properties
rehost_ rehost_
clusterslave_ clustersecondary_
second.properties second.properties

○ List of modified terms:

Old Name Modified Name
master node main node
master host main host
master server main server
master site main site
slave node secondary node
slave host secondary host
June 2021 for • Support for the Restore Module in Windchill Rehost
12.0.2.0 Utility.
• Support for automated recovery task.
December 2020 • New installation does not support installation of Windchill
for 12.0.1.0 Directory Server. You have the option to install and
configure any V3 compliant LDAP or active directory
instead.
• Changes in rehost.properties file.
June 2020 for Added optional properties for JMS in InfoEngine Module.
12.0.0.0
December 2019 • Added Windchill Performance Advisor Utility as a default
for 11.2 M010 task for Clone and Rehost scenarios
• Removed support for auto-execution of Backup task

8
Date Modified Description of Change
June 2019 for • Added automated Rehost activities:
11.2 F000
○ Support for Solr rehost script for rehosting Standalone
Solr server and rehosting Standalone Solr server on
Cloud platform.
○ Debugging the Solr Rehost Utility Script.
• PDMEssentials is not supported from 11.2 F000 release
onwards.
December 2018 • Support for Rehost for Pro-Intralink.
for 11.1 M020
June 2018 for • Support for Rehost of PTC System Monitor.
11.1.M010 • Support for Rehost of PDMEssentials.
• Section Various Rehost Scenarios added to the guide.
• Section Rehosting Standalone Solr Server updated to add
information about Rehost and Clone scenarios.
December 2017 • Cognos is not supported.
for 11.1 F000 • Added manual steps for configuring standalone Solr.
• Added updates for additional settings for PSI about WVS
workers.
June 2017 for • File Server is no longer supported:
11.0 M030 ○ Removed a small piece of code related to file server
settings from the rehost_clustermain_vault.properties
section of the Configuration Properties File for Rehost
Cluster Example section.
○ Removed “and file servers” from several locations
throughout the guide.
• Added a note at the end of the Configuration Properties
File for Rename Example section.
• Removed ContainerTemplate module sections until it has
been more thoroughly tested.
• Removed the codebase bullet in the Media Content
section.

9
Date Modified Description of Change
July 2016 for • The following new sections were added:
11.0 M010 ○ What’s New
◆ Discusses changes from 3.0 to 3.0 M010
○ Properties Used By All Modules
◆ Contains both new properties not previously
described in this guide, as well as properties that
were moved into this new section from other areas
• The following sections were removed:

10
Date Modified Description of Change
○ File Server Settings
○ ValidateMount
◆ For Windchill 11.0 M010 and higher, no separate
task is executed for ValidateMount, as it is an in-
built task in the Vault task.
• The following existing sections were updated (some
extensively):
○ Rehost Scenario Process
○ Selecting the Right Scenario
○ Setting Up the Rehost Environment
○ Identifying Activities for Rename
○ Activities when Moving Windchill to a Different
Directory on the Same System
○ Activities when Moving Windchill to a Different
Directory on a Different System
○ Installing the Windchill Rehost Utility
○ Bundled Modules
○ Scenario rehost.useCase Property
○ Where to Run the Utility
○ Log Files for Scenarios
○ Backing Up Artifacts from a Custom Windchill
Environment
○ Apache
○ Copy
○ Cluster
○ InfoEngine
○ Solr
○ Vault
○ LDAP Settings
○ Rehost Additional Adapters
○ Changing Additional Adapters
○ Windchill Path Settings
○ Host Settings

11
Date Modified Description of Change
○ Cluster Settings
○ Installation Registry Settings
○ File Vault Settings
○ Copy Settings
○ Selective Content Settings
○ Solr Settings
○ rename.example Property for Rename Example
○ Configuration Properties File for Rename Example
○ Configuration Properties File for Rehost Example
○ Configuration Properties File for Rehost Cluster
Example
○ Clone Scenario Example
○ Configuration Properties File for Clone Example
○ Configuration Properties File for Move Home
Directory Example
○ Configuration Properties File for Move to New
Platform Example
○ oraexp.bat
○ oraimp.bat
○ windchillStart.bat
• Added new properties and updated many property names
and descriptions all throughout the guide
• Removed support for the DOORS adapter, which was
retired at 11.0 F000
• Updated links to referenced documentation
• Fixed various minor typos
September 25, Updates for Windchill Rehost Utility 3.0 release
2015
June 19, 2014 Initial Windchill Rehost Utility 2.0 release
July 10, 2014 Added references to the 1.0 utility and guide. See Installing
the Windchill Rehost Utility and Using the Windchill Rehost
Utility.
Made minor corrections throughout the guide.

12
Related Documentation
The following documentation may be helpful:
• Windchill Installation and Configuration Guide
• Windchill Upgrade Guide
• Windchill Customization Guide
• Enterprise Deployment Resources Support Policy

Technical Support
The PTC eSupport portal provides the resources and tools to support your
Windchill implementation:
https://support.ptc.com/appserver/cs/portal/
If you encounter problems using this product, contact PTC Technical Support. For
complete details, see “Opening a Case” on the Processes tab of the PTC
Customer Support Guide:
http://support.ptc.com/appserver/support/csguide/csguide.jsp
You must have a Service Contract Number (SCN) before you can receive
technical support. If you do not know your SCN, see “Preparing to contact TS” on
the Processes tab of the PTC Customer Support Guide for information about how
to locate it.

Documentation for PTC Products

You can access PTC documentation using the following resources:
• Windchill Help Center—The Windchill Help Center includes all Windchill
documentation. You can browse the entire documentation set, or use the search
capability to perform a keyword search. To access the Windchill Help Center,
you can:
○ Click any help icon in Windchill
○ Select Help ▶ Windchill Help Center from the Quick Links menu at the top
right of any Windchill page
○ Use the following link to access all PTC help centers:
https://support.ptc.com/appserver/cs/help/help.jsp
• Reference Documents website—Information assistance in Portable Document
Format (PDF):
http://support.ptc.com/appserver/cs/doc/refdoc.jsp
A Service Contract Number (SCN) is required to access the PTC
documentation from the Reference Documents website. If you do not know
your SCN, see “Preparing to contact TS” on the Processes tab of the PTC
Customer Support Guide for information about how to locate it:

13
 http://support.ptc.com/appserver/support/csguide/csguide.jsp
When you enter a keyword in the Search Our Knowledge field on the PTC
eSupport portal, your search results will include information from knowledge base
articles, product documentation, and the PTC community.

Comments
PTC welcomes your suggestions and comments on its documentation:
• To send feedback about a topic you are viewing in the Windchill Help Center,
click the send feedback icon in the top right corner of the topic. The title of
the help topic you were viewing when you clicked the icon is automatically
included with your feedback.
• You can also send an email to [email protected]. To help us more
quickly address your concern, include the name of the PTC product and its
release number with your comments. If your comments are about a specific
help topic or book, include the title.

14
 1
Rehost Process Overview
General Rehost Process ............................................................................................16
Various Rehost Scenarios ..........................................................................................18
Rename Scenario Process.........................................................................................21
Rehost Scenario Process...........................................................................................22
Clone Scenario Process ............................................................................................26
Move Scenario Process .............................................................................................29
License Considerations for Rehost Scenarios..............................................................33

Rehosting is a useful part of the Windchill System Configuration Management

process. This process consists of a set of activities that can be performed to
manage changes to a deployed Windchill solution, as described in the System
Configuration Management document.
The System Configuration Management process is an important part of the
administrative process framework that has been documented by PTC. To gain an
understanding of the administrative processes that the PTC community
recommends as a framework, see the Windchill Administrative Processes that are
presented on the Windchill Installation and Configuration Resource Page.
The following sections provide general information about the rehost process and
specific rehost scenarios.

15
General Rehost Process
Rehosting consists of the the update of a test or development environment to
account for a change in the system host name. This rehost use case includes the
duplication of the production dataset to test and development landscapes. This
duplication is done to eliminate risk when validating new changes, as well as to
minimize rework in test and development landscapes. By using the Windchill
Rehost Utility, configuration details and data is updated to reflect a change in the
Windchill environment, such as the system host name or platform after copying a
duplicated dataset to test or development landscapes.
The following diagram highlights rehost activities across all landscapes:

The general rehost process uses the following types of systems:

• A target system is required. This is the system that is updated as a result of
rehost activities and is normally a test or development system. Changes are
made to this system. The utility updates the information stored on this system
as part of the rehost process.
• A source system is required. Depending on the scenario, the source and target

16 Rehost Utility Guide

 systems can be the same system. This is the starting system for rehost
activities. When separate from the target system, no changes are made to the
source system.
• A staging area is required when there are unique source and target systems and
when the utility cannot access the source system from the target system. When
this is the case, content will need to be copied from the source system to the
staging area. Depending on the rehost scenario, some or all or the following
content in the staging area will be needed.

The diagram shows that the following content could be

included in the staging area:
• A copy of the source software code (represented by file
folders)
○ IEConf folder of source (represented by configuration
icon)
○ Source database exports (represented by a cylinder)
○ A copy source vault files (if present) [represented by
documents]

The following are additional potential uses for rehost:

• The rapid deployment of development environments
• Retiring obsolete environments
• Promoting individual business unit environments up to the enterprise level
• Changing the virtual machine host name on a test or demo system
• Moving a production system to a test environment for validation
• Rapid deployment of the development environment, or a migration rehearsal
• Moving a test or development environment from a source platform to a target
platform that is different from the source, such as moving from a source Linux
platform to a target Windows platform

Rehost Process Overview 17

When rehosting, there are many references to host names, installation paths, and
third-party modules that require updates. The common trait of most rehost
scenarios is to modify the configuration and dataset copied from the source system
so that it functions properly in the target system. The typical rehost process
includes the following general steps:
1. Export the database and vault contents from the source system (commonly the
production environment).
2. Import the exported content into the target system such as a test environment.
3. Modify the configuration and dataset to reflect the new environment identity.
Depending on the requirements for a particular rehost, the starting conditions and
necessary steps can vary.
The following sections describe the out-of-the-box rehost scenarios supported for
use with the Windchill Rehost Utility: Rename, Rehost, Clone, and Move.

Various Rehost Scenarios

Criteria Rehosting Clone Move Rename
Source and target
machines are same
Source and target
machines are different
Windchill <home>
location is same
Windchill <home>
location is different
Platform is same

Platform is different

Hostname is the same

[but different domain
name]
Hostname is different
[only hostname not the
domain name]
Domain name is same

Domain name is different

Same database Instance

can be used
Require new database
Instance

18 Rehost Utility Guide

 Criteria Rehosting Clone Move Rename
Same LDAP instance can
be used
Require new LDAP
Instance

Rehost Process Overview 19

 Criteria Rehosting Clone Move Rename
Can Source server NO, If NO, If NO, If NO
remains UP along with target server target server target server
the Target Server uses the uses the uses the
same same same
Database, Database, Database,
and/or ldap and/or ldap and/or ldap
as source as source as source
Yes, If Yes, If Yes, If
target server target server target server
uses uses uses
different different different
Database, Database, Database,
and/or ldap and/or ldap and/or ldap
than Source than Source than Source
Purpose The Rehost Cloning is The Move This
scenario is commonly scenario is scenario can
often used used to commonly be used
to populate rapidly used to each time a
test and deploy non- relocate an virtualized
develop- virtualized existing test or
ment environ- Windchill develop-
environ- ments such environment ment
ments with as on new environment
a production environ- hardware so is copied
dataset. ments for that the old
Migration hardware
Rehearsal, can be
Production retired
Mirror, and
Disaster
Recovery

Note
Can be categorized as <Type> Scenario

Cannot be categorized as <Type> Scenario

Where <Type> is the type of scenario indicated by the heading of the column
e.g. Rehost, Clone, Rename or Move

20 Rehost Utility Guide

Rename Scenario Process
It is common to change the host name of a test or development environment in
place, particularly if the environment is virtual. The host name consists of two
parts: a host and a domain. Changing the host, the domain, or both are considered
a host name change.
The Rename performs a host name change. In the Rename scenario, the single
environment is both the source system and target system, and the environment is
expected to be fully functional as the source before the host name change and then
also fully functional as the target after the host name change.
Since one environment is both the source and target, there is no need to export and
import the configuration and dataset. The Rename scenario simply updates the
existing configuration and dataset after the physical host name of the system has
been changed. This scenario can be used each time a virtualized test or
development environment is copied.
The following diagram shows how the Rename scenario changes the host name in
an existing monolithic system.

The diagram shows that running the Rename

scenario makes changes to the following:
• The software configuration (represented as
file folders)
• IEConf folder of source (represented by
configuration icon)
• The database tables (represented as a
cylinder)
The * in the diagram indicates that changes are
only made in place.
There are no changes made in any vault files
(if present). In the diagram, the vault files are
represented as documents.

Rehost Process Overview 21

The following diagram shows the effect of running the Rename scenario on an
existing clustered system, both the main and secondary nodes in the cluster are
renamed.
The diagram indicates that the utility must
be run on all nodes. The end result is that
the renamed cluster has changes made to
the main node and all secondary nodes in
the cluster.

To use the Rename scenario, the next step is to plan the activities for the scenario.
See Planning Rehosting Activities on page 34.

Rehost Scenario Process

The Rehost scenario provides the ability to copy Windchill data from one system
(called the source system) to another system (called the target system) and then to
configure the target system so that it operates in a similar manner to the source
system. In this scenario, the following assumptions are made:
• The host names of the source and target systems are different.
• The target system must be on the same hardware platform as the source
system. For example, both the source and target systems must be on the
Windows platform or both must be on the same UNIX platform such as Sun
Solaris.
• The source and target systems have the same Windchill installation directory.
For example, the installation directory for both the source and target systems
can be D:\ptc\Windchill10\Windchill or they can be /ptc/
Windchill10/Windchill. The target installation directory cannot be
D:\ptc\Windchill10\Windchill when the source installation

22 Rehost Utility Guide

 directory is D:\ptc\Windchill10.2\Windchill. Nor could that target
installation directory be /ptc/Windchill10/Windchill when the
source installation directory is D:\ptc\Windchill10\Windchill.
The data that can be copied from the source system to the target system is data
stored in the database, IEConf folder, and any file vaults that are set up.
In a typical Windchill deployment, Windchill stores the content files of some
objects as files directly accessible at the operating system level. This functionality
uses Windchill objects called Vaults and Folders, and provides mounting
information that connects these objects to the real file system folders. When
copying a dataset from one host to another host, the relationship between the
metadata in the database and file systems must be maintained. The modules used
within the Rehost scenario make the necessary configuration changes.
The following diagram shows a typical Rehost scenario used on two monolithic
systems that have the same version of Windchill installed. The diagram depicts the
flow of copying the IEConf folder (represented by configuration icon), data
content stored in database tables (represented as a cylinder), and vault files
(represented as documents) from the source system to the target:

The previous diagram includes a staging area that is used when there is no direct
communication between the source and target systems.
This scenario does not copy Windchill installation files (designated by the file
folders in the diagram); it only updates Windchill configuration files (such as
db.properties) on the target system. To copy a Windchill installation, see the
Clone scenario that is describe in the next section.

Rehost Process Overview 23

The Rehost scenario is often used to populate test and development environments
with a production dataset.

Note
In this scenario, the source and target systems are intended to function
simultaneously and independently.

24 Rehost Utility Guide

The following diagram shows the Rehost scenario used on two clustered
environments that have the same version of Windchill installed, where the host
names used on the target nodes are different from the host names on the source
nodes. The diagram depicts the flow of copying the IEConf folder (represented by
configuration icon), data content stored in database tables (represented as a
cylinder), and vault files (represented as documents) from the source environment
to the target:

Since both the target main and secondary host names are different from the names
used on the source cluster, the utility must be executed on all nodes in the cluster.
To use the Rehost scenario, the next step is to plan the activities for the scenario.
See Planning Rehosting Activities on page 34.

Rehost Process Overview 25

Clone Scenario Process
The Clone scenario provides the ability to duplicate the Windchill software
(codebase) that is on a source system as well as perform the activities available
from the Rehost scenario. The target system must be on the same platform as the
source system and have the same file structure. For example, both the source and
target systems must be Windows systems or both must be on the same UNIX
platform such as Sun Solaris.
Being able to clone a system is valuable when the target Windchill environment
does not exist, is in an unknown state of configuration, or is not fully functional.

Note
Before running the Clone scenario, you must set up a database instance to use
with the cloned Windchill system.

The result of cloning is that there can be two Windchill systems (source and
target) that have identical behaviors, each running on a different host. Cloning is
commonly used to rapidly deploy non-virtualized environments such as
environments for Migration Rehearsal, Production Mirror, and Disaster Recovery.

Note
In this scenario, the source and target systems are intended to provide the same
functionality.

26 Rehost Utility Guide

The following diagram shows a typical Clone scenario used on two monolithic
systems where the target system does not have a functioning Windchill
environment installed. The diagram depicts the flow of copying the source
codebase (represented as folders), source IEConf folder (represented by
configuration icon), source data content stored in database tables (represented as a
cylinder), and source vault files (represented as documents) from the source
system to the target where the host names for the source and target systems are
different:

The previous diagram includes a staging area that is used when there is no direct
communication between the source and target systems.

Rehost Process Overview 27

The following diagram shows the Clone scenario used on a source environment
that is a cluster. The target environment has the same number of servers available
as the source environment. The diagram depicts the flow of copying the codebase
(represented as file folders), IEConf folder (represented by configuration icon),
data content stored in database tables (represented as a cylinder), and vault files
(represented as documents) from the source environment to the target:

Since the source files from all nodes are copied to target nodes and both the target
main and secondary host names are different from the names used on the source
cluster, the utility must be executed on all nodes in the cluster.
To use the Clone scenario, the next step is to plan the activities for the scenario.
See Planning Rehosting Activities on page 34.

28 Rehost Utility Guide

Move Scenario Process
The Move scenario provides the ability to do the following activities:
• Change the installation path of a Windchill environment (both WT_HOME
and third party applications) after moving the Windchill installation directory
to a new location on the same system. For example, change the installation
directory from D:\ptc\Windchill to D:\ptc\Windchill_10.
In this scenario, you move the files independently to the new directory on the
same system and then run the utility to make the required changes to the data.
The following diagram shows an existing monolithic system where the source
has been moved to become the target.

The diagram shows that running the Move scenario makes

Windchill installation directory changes in place in the
following:
• The Windchill configuration files that are in the Windchill
installation directory (represented as file folders)
○ IEConf folder (represented by configuration icon)
○ The database tables (represented as a cylinder)
The * in the diagram indicates that changes are only made in
place.
If there are any file vaults on the system (represented as
documents), they are unchanged by the move of the
installation directory.

When doing this type of move in a clustered environment, the target

environment must have the same number of nodes available as the source
environment and it is assumed that the host names remain the same. When this
is the case, you only need to run the utility on the main node (when defined) or
on one of the nodes (when no main node is defined). There are no changes
needed on the other nodes in the cluster.

Rehost Process Overview 29

• Change the installation path of a Windchill environment after moving the
Windchill environment from one machine to another machine, where the
target machine is on the same platform as the source machine. In this scenario:
○ The host name of the source machine and the target machine are the same
and the source system is not expected to function after completing the
Move scenario.
○ The target location of the Windchill environment (both WT_HOME and
third-party applications) is different from the source location.
Because the source and target machines are on the same platform, you can
either use the utility to copy the software installation directories from a staging
area or you can move the directories independently before running the utility.
In either case, it is necessary to update the installation path in the Windchill
environment on the target system. The following example shows that the files
staged from a retired monolithic source system are copied to a new location on
the target system.

In this diagram, the X drawn through the source system indicates that it is no
longer running.
When doing this type of move in a clustered environment, the target
environment must have the same number of nodes available as the source
environment and it is assumed that the host names remain the same. If you are
using the utility to copy software installation directories to new directories on

30 Rehost Utility Guide

 the target nodes, you must run the utility on each node. If you have moved
installation directories to new directories on target nodes before running the
utility, then you can run the utility on the main node (when defined) or on one
of the nodes (when no main nodes is defined). There are no changes needed on
the other nodes in the cluster.
• Change the installation path of a Windchill environment while moving a
Windchill environment from one platform to another platform. In this
scenario,
○ The host name of the source machine and the target machine are the same
and the source system is not expected to function after completing the
Move scenario.
○ The target location of the Windchill environment (both WT_HOME and
third party applications) is different from the source location.
Because the source and target machines are on different platforms, you must
install the same version of Windchill and third-party products on the new
platform using the PTC Solution Installer (PSI) pointing to either a new or
existing instance of the database. Then you can use the utility to make the
required changes to the data on the target system to update the data
configuration to match the source system and also change the Windchill
installation directory information that was imported from the source system to
the new path on the target system. You can also use the utility to copy files
from source file vaults to a new location on the target system.

Rehost Process Overview 31

 As shown in the following diagram, the Move scenario is commonly used to
relocate an existing Windchill environment on new hardware so that the old
hardware can be retired.

In this diagram, the X drawn through the source system indicates that it is no
longer running. The target system is updated in place using the IEConf,
database, and configuration information extracted from the source system and
any source files vaults can be copied to the target system.
When doing this type of move in a clustered environment, the target
environment must have the same number of nodes available as the source
environment and it is assumed that the host names used for the source nodes
become the host names for the target nodes. When this is the case, you only
need to run the utility on the main node (when defined) or on one of the nodes
(when no main nodes is defined). There are no changes needed on the other
nodes in the cluster.
If you want to use the Move scenario, the next step is to plan the activities for the
scenario. See Planning Rehosting Activities on page 34.

32 Rehost Utility Guide

License Considerations for Rehost
Scenarios
For Rehost, Clone, or Move scenario, you are required to acquire a new license
key. Rename scenario does not require a new license key.
During rehosting if you want to change the location of a license file in the target
system, update the target.directory.licenseusage property with the
new license path when running the Windchill Rehost Utility . The
target.directory.licenseusage property is located in
rehost.properties file. This is applicable to all the rehost scenarios.

Rehost Process Overview 33

 2
Planning Rehost Project Activities
Selecting the Right Scenario ......................................................................................35
Setting Up The Rehost Environment ...........................................................................36
Identifying Activities for Rename.................................................................................39
Identifying Activities for Rehost...................................................................................41
Identifying Activities for Clone.....................................................................................43
Identifying Activities for Move .....................................................................................45
Identifying Optional Activities to Include When Rehosting .............................................49
Out-of-Scope Configurations ......................................................................................50

The following sections shows which scenario and modules to run in the utility to
accomplish rehost projects.

34 Rehost Utility Guide

Selecting the Right Scenario
Before using Windchill Rehost Utility, you must decide on a starting point for the
rehost process. Initially, you must decide which of the following scenarios to use:
• Use the Rename scenario to change the host name in an existing Windchill
environment. The host name changes made are made in the existing Windchill
environment.
• Use the Rehost scenario to duplicate a Windchill environment on an existing
Windchill server so that both Windchill systems function independently of
each other, but provide the same functionality. This scenario is often used to
update a separate test environment so it functions similar to a production
environment.
• Use the Clone scenario to copy the Windchill software code from an existing
system to a new system that is on a platform that is of the same type as the
existing Windchill system. After the code copy is complete, other rehost
activities are performed so that the copied code is updated to work on the new
system.
• Use the Move scenario to update a target Windchill environment in which
there has been a change to the Windchill installation directory.
You can use the utility when moving existing Windchill software code in one
of the following ways:
○ Move to a new directory on the same system.
The actual movement of code in this scenario can be done through the
utility or independently before running the utility.
○ Move to another system on a platform that is the same as the original
platform.
Here also, the actual movement of code can be done through the utility or
independently before running the utility.
Use the utility to move a Windchill environment to a new platform. In this
case, the source code cannot be copied to the new platform; a new Windchill
instance is installed on the target platform, the utility then rehosts the database
and IEConf to match the new installation.
In addition to configuring the target environment so that the Windchill
installation directory is updated, other rehost activities can be performed at the
same time.
All scenarios can be done using either a standalone or clustered Windchill
environment.
Read the process overview for each scenario in the previous chapter, Rehosting
Process Overview on page 15, and then decide which scenario best fits the desired
rehost activity.

Planning Rehost Project Activities 35

 Note
PTC understands that rehosting in a given environment often does not follow
the strict interpretation of any one of the documented scenarios. Therefore, the
utility allows the addition and modification of rehost activities. This in
customization also requires that you spend time determining the necessary
configuration settings.

After you have selected the scenario, read the appropriate sections that follow to
determine which modules are needed. Then, create a check list of activities and
property configuration settings.

Setting Up The Rehost Environment

When planning rehost activities, be aware of the following source, staging, and
target system setup requirements:
• The source Windchill system version must be 10.0 or later to use the
documented procedures for rehosting as described in this guide. For details on
rehosting a Windchill 9.1 system, see the 9.1 Windchill Rehost Guide.
• The user performing the database-related procedures must have database
administrator privileges for both the source database and target database
instance. Additionally, the source and target database platforms must be the
same.
• Unless using a Move scenario between systems on different platforms, you
must use the same source and target operating system for the Windchill server.
For example, you cannot rehost a source Windchill deployment on a Windows
platform to a target deployment on an HP-UX platform. Additionally, a
compatible version of Java must be installed on the target system.
• Unless you are using the Move scenario, you must use the same Windchill
installation directory full path for both the source and target systems.
• If you are using vaults, consider the following:
○ The rehost process assumes that the entire structure under each vault folder
mount location (actual storage location) is the same on the source and
target systems.
○ With the Windchill Rehost Utility, you can change the target folder
mounts. The utility makes all required changes for the new mount
locations.
• Rehosting Windchill Business Reporting (WBR) is not currently supported. If
your environment includes WBR, you must reinstall on the target system after
rehost activities are completed.

36 Rehost Utility Guide

• No other Windchill installations can exist on the target system.
• Consideration must be given to ensure appropriate synchronization between
data sources during rehosting:
○ For standalone scenarios where the source and target are the same
machine, the Windchill system must be shut down before performing the
rehosting.
○ For scenarios involving multiple systems, there is a trade off between
fidelity and convenience. If the source system is shut down before the
content (database, IEConf, vaults indexes, and so on) is copied to the
target, then the target will have the highest level of data fidelity. If the
source system is running when the content is copied to the target, then
there is risk that the various data elements may not be 100% aligned. The
longer the span of time between the copying of all the elements of the
content, the greater the risk of data integrity issues in the target; for
example, if the database is copied three hours before the IEConf and vault
indexes, then the source system may have added or updated content in that
data which is not reflected in the database. How the target system behaves
if the data is not 100% aligned varies, depending on the specifics of the
misalignment.
• Ensure that the target database has the same database schema that is being
used on the source database. Export the schema from the source instance and
then import the exported file on the target database instance before running the
utility. For details about database exporting and importing, see Manual
Rehosting Activities on page 175.
• When using a staging area, the designated area (as defined in rehost
properties) must be accessible to the Windchill Rehost Utility and contain the
files requested by the utility.
• When starting with a functional target Windchill system, the target system
must have the following configurations:
○ The same maintenance releases and patches that are on the source system
Use the windchill version command on each system to verify that
the installations are the same.
○ The same customizations that are on the source system

Planning Rehost Project Activities 37

 ○ Users from the source system.
Use the Windchill Directory Server to export users from the source
system. Then the exported file can be imported before running the utility
or imported using a user-defined module through the utility.
○ Additional adapters that were installed on the source system, such as a
custom JNDI adapter for connecting to an enterprise LDAP directory.
It is not necessary to configure adapters on the target system as that can be
done through the Windchill Rehost Utility.

38 Rehost Utility Guide

Identifying Activities for Rename
Running a Rename scenario requires one Windchill environment that is both the
source and target system.
The goal in using the Rename scenario is to modify the host name in place so that
system functions under the new host name.

Note
This scenario assumes that you have a running Windchill environment on a
virtual machine for which you want to change the host name.

To complete a Rename scenario, accomplish the following activities:

1. Outside of the utility, stop Windchill and change the host name of the system
(or move Windchill to a new host).
2. Install the Windchill Rehost Utility in the environment where Windchill
resides. The utility must have access to the target database instance.
In a clustered environment, the utility must run on each node in the cluster and
be sure to include the Cluster module as one of the modules that the utility
executes to update host names in cluster-related properties. Always run the
utility on the main node first (when one is defined) or on one node (when all
nodes can be the main). Then run the utility on all other nodes. After the initial
run on the cluster, set the cluster.secondary.rehost property to
true for all other runs so that the utility doesn’t modify IEConf and database
data when executing the InfoEngine and Database modules on those nodes.
For installation information, see Installing and Uninstalling the Windchill
Rehosting Utility on page 51.
3. Determine if there are additional areas in your system that need host name
changes. For the Rename scenario, there is a basic set of modules that are
required (InfoEngine, Apache, and Database). Depending on your
environment, there can be additional host name changes needed (such as in
WVS workers) that require additional modules.
For general information about additional modules that you can include in
rehost scenarios, see Identifying Optional Activities to Include When
Rehosting on page 49.

Planning Rehost Project Activities 39

4. Set up the input files required to run the utility and then run the utility.
As part of this setup, identify properties that must be set and decide if
passwords should be encrypted.
For details, see Using the Windchill Rehosting Utility on page 55.
For a detailed example of executing Rename scenario using the basic set of
modules, see Rename Scenario Example on page 141.

40 Rehost Utility Guide

Identifying Activities for Rehost
Running a Rehost scenario requires both a fully functional source environment
(typically, production) and a fully functional target system, such as a test or
development environment.
The Rehost scenario builds on the Rename scenario; it requires a host name
change as well as the exporting and importing of a dataset.
To complete a Rehost scenario, accomplish the following activities:
1. Set up a functional target environment (including Windchill and a database
instance) as described in Setting Up Your Rehosting Environment on page 36.
2. Set up a staging area (if needed).
The items that need to be accessible to the target system can include:
• Exported database content from the source database instance
For details on exporting and importing database content, see the applicable
appendix for your database software:
○ Exporting Database from Source System and Importing It into Target
System: Oracle on page 177
○ Exporting Database from Source System and Importing It into Target
System: Microsoft SQL Server on page 178
• The set of vault files that should be available on the target system. This set
could include all of the vault files from the source system or a subset of
files.
If the items are not available to the target system from the source system, then
a staging area is required. The staging area must be accessible to the target
system and it must contain those items from the source system that are needed
for the Rehost scenario.
3. Install the Windchill Rehost Utility in the target environment. The utility must
have access to the target database instance.
In a clustered environment, the utility must have access to all nodes in the
cluster and the Cluster module should be the last module executed. The
Cluster module makes host name changes to cluster properties. Always run the
utility on the main node first (when one is defined) or on one node (when all
nodes can be the main), where all other nodes are shut down. Then run the
utility on all other nodes. The host names are updated in cluster-related
properties when the Cluster module executes. After the initial run on the
cluster, set the cluster.secondary.rehost property to true for all
other runs so that the utility doesn’t modify IEConf and database data when
executing the InfoEngine and Database modules on those nodes.

Planning Rehost Project Activities 41

 For installation information, see Installing and Uninstalling the Windchill
Rehosting Utility on page 51.
4. Determine which additional areas in your source system need to be included
on the target system. For the Rehost scenario, there is a basic set of modules
required (InfoEngine, Apache, Database, and Vault) and additional optional
modules you can include. The list of optional modules to include depends on
your environment.
For general information on the additional modules that can be included in
rehost scenarios, see Identifying Optional Activities to Include When
Rehosting on page 49.
5. Set up the input files required to run the utility and then run the utility.
As part of this setup, identify the properties that must be set and decide about
encrypting passwords.
For details, see Using the Windchill Rehosting Utility on page 55.
For detailed examples of executing the Rehost scenario using the basic set of
modules, see Rehost Scenario Example on page 145 and Rehost Cluster Scenario
Example on page 150.

42 Rehost Utility Guide

Identifying Activities for Clone
Running a Clone scenario requires a fully functional source environment and a
target environment that is on the same platform as the source. The source and
targets environments have the same file structure. Usually there is also a staging
area where content from the source is staged so that it is accessible to the utility.
Additionally, a database instance must be available for use with the cloned
Windchill system.

Note
When running a Clone scenario, ensure that the OS user name that you use to
run the utility has sufficient permissions to read all files from the staging area
and write to the target system.

The first time you run the Clone scenario in a given situation, the target
environment does not have the Windchill codebase and bundled components
installed. Therefore, you must copy the files from the source or staging
environment to the target environment. This results in the target system having the
same Windchill installation directory as the source. After this initial copy is
complete and the target system is running, it may not be necessary to copy the
codebase again to update the target system. When there are additional changes
made on the source system that do not include the codebase changes, they can be
pushed to the target using a Rehost scenario.
To complete a Clone scenario, accomplish the following activities:
1. Set up a staging area (if needed).
The items that need to be accessible to the target system can include:
• Software directories to copy to the target system. These directories
include:
○ IEConf directory
○ Java installation directory
○ Apache or PTC HTTP Server (for Windchill 10.2) installation
directory
○ Windchill Directory Server installation directory
○ PTC Solution Installer (PSI) installation directory
○ Other directories specific to your environment
• Exported database content from the source database instance.

Planning Rehost Project Activities 43

 For details on exporting and importing database content, see the applicable
appendix for your database software:
○ Exporting Database from Source System and Importing It into Target
System: Oracle on page 177
○ Exporting Database from Source System and Importing It into Target
System: Microsoft SQL Server on page 178
• The set of vault files that should be available on the target system. This set
could include all of the vault files from the source system or a subset of
files.
2. Install the Windchill Rehost Utility in the target environment.
Ensure that the utility has access to the target database instance.
In a clustered environment, the utility must have access to all nodes in the
target cluster and the Cluster module should be the last (or only) module
executed. The Cluster module makes host name changes to cluster properties.
There are multiple ways to clone the nodes in a cluster. Run the utility on the
main node first (when one is defined), or on one node (when all nodes can be
the main), with all other nodes shut down. Then, run the utility on all other
nodes:
• If all nodes are identical, then you can clone the same source node onto
multiple target nodes.
• If there is a main node that is unique and all secondary nodes are identical,
then clone source main to target main and one source secondary node to all
target secondary nodes. Another variant to this would be to clone one
source secondary node to a target secondary node and then copy the target
secondary node to other target secondary nodes.
The host names are updated in cluster-related properties when the Cluster
module executes. After the initial run on the cluster, set the
cluster.secondary.rehost property to true for all other runs so that
the utility doesn’t modify IEConf and database data when executing the
InfoEngine and Database modules on those nodes.
For installation information, see Installing and Uninstalling the Windchill
Rehosting Utility on page 51.
3. Determine which additional areas in your source system need to be included
on the target system. For the Clone scenario, there is a basic set of modules
required (Copy, InfoEngine, Apache, Database, and Vault) and additional
optional modules. The list optional modules to include depends on your
environment.

44 Rehost Utility Guide

 For general information on the additional modules, see Identifying Optional
Activities to Include When Rehosting on page 49.
4. Set up the input files required to run the utility and then run the utility.
As part of this setup, identify the properties that must be set and decide about
encrypting passwords.
For details, see Using the Windchill Rehosting Utility on page 55.
For a detailed example of the Clone scenario using the basic set of modules and
the optional IEAdapter module, see Clone Scenario Example on page 163.

Identifying Activities for Move

Some of the activities that are needed to complete the move of a Windchill
installation depend on the type of move required. The following subsections
provide details for supported types of moves, all of which involve changing the
installation path of a Windchill environment (both WT_HOME and third-party
applications). In these cases, the source system is shut down before the move and
does not function after the move is complete.
The following sections describe the activities for Move scenarios. For detailed
examples of Move scenarios, refer to Move Scenario Examples on page 168.

Activities when Moving Windchill to a Different Directory on the Same

System
Install the Windchill Rehost Utility on the system that is both the source and
target. This gives the utility the access it needs. For installation information, see
Installing and Uninstalling the Windchill Rehosting Utility on page 51.
When changing the location of Windchill from one directory to another on the
same system, the actual file copy can be performed by the Copy module from
within the Windchill Rehost Utility, or by manually copying files before running
the utility. The source files can be manually deleted after the rehost is complete.
At a minimum, the files in the following installation directories need to be in the
target location:
• Windchill
• Web Server (Apache or PTC HTTP Server [powered by Apache] in Windchill)
• IEConf
• PTC System Installer (PSI)
When doing this type of move, it is assumed that the moved Windchill system
uses the database instance that was used by the source system. If that is not the
case, create a new database instance to use, and import the exported content from
the source database.

Planning Rehost Project Activities 45

After the target system is in place, run the utility to change the configuration files
and database tables to reflect the new installation directory by executing the
ChangeHome module.

Activities when Moving Windchill to a Different Directory on a

Different System
For this type of move, the resulting target system must be on a machine that is on
the same hardware platform as the source machine and must have the same host
name as the source machine. The source system is shut down.
Install the Windchill Rehost Utility on the target system. If needed, set up a
staging area that is accessible to the utility. For installation information, see
Installing and Uninstalling the Windchill Rehosting Utility on page 51.
When changing the location of Windchill from one directory to another on
different systems that are on the same hardware platform, you can do one of the
following:
• Make the software move by running the Copy module from within the
Windchill Rehost Utility (and later delete the directories where the source files
reside).
• Move the software files before running the utility.
At a minimum, the files in the following installation directories need to be in the
target location:
• Windchill
• Web Server (Apache or PTC HTTP Server [powered by Apache] in Windchill)
• IEConf
• PTC System Installer (PSI)
When doing this type of move, it is assumed that the moved Windchill system
uses the database instance that was used by the source system. If that is not the
case, create a new database instance to use and import the exported content from
the source database. The import can be done from a user-defined module within
the utility or manually before running the utility. Using a different database
instance requires that the Database module be run to update the database
connection configuration.
After the target system is in place, change the configuration files and database
tables to reflect the new installation directory by running the ChangeHome
module.

46 Rehost Utility Guide

Activities when Moving Windchill to a Different Hardware Platform
When changing the location of Windchill from a directory on one platform to a
directory on a different platform, you must install the same version of Windchill
and third-party products on the new platform using the PTC Solution Installer
(PSI) before running the utility; you cannot copy software files from one platform
to another.
The Windchill environment on the target system must include the same
components and customizations that are on the source system. The target system
used in the Move scenario is similar to the target system used in the Rehost
scenario. For target setup details, see Setting Up Your Rehosting Environment on
page 36.
Install the Windchill Rehost Utility on the target system. If the utility cannot
access content on the source system, a staging area is required. For installation
information, see Installing and Uninstalling the Windchill Rehosting Utility on
page 51.
The items that need to be accessible to the utility on the target system can include:
• IEConf folder.
• If the target system has its own database instance, exported database content
from the source database instance is required.
For details on exporting and importing database content, see the applicable
appendix for your database software:
○ Exporting Database from Source System and Importing It into Target
System: Oracle on page 177
○ Exporting Database from Source System and Importing It into Target
System: Microsoft SQL Server on page 178
• The set of vault files that should be available on the target system. This set
could include all of the vault files from the source system or a subset of files.
Import the exported database configuration files on the target system and, if the
host name of the target system is different from the host name of the source
system, then execute the InfoEngine, Apache, and Database modules. The imports
can either be done before running the utility or executed as user-defined module in
the utility. After the imports and host name changes are made, then execute the
ChangeHome module to change the configuration files and database tables to
reflect the new installation directory.

Planning Rehost Project Activities 47

Additional Activities When Moving a Cluster

Note
When the host names of nodes in a cluster are not changing as a result of the
move, the Cluster module is not required.
If any host name is changing, the Cluster module is required.

Execute the ChangeHome module on each server where the Windchill installation
directory has changed, after moving the files. If the directory has changed on only
one of the servers, then execute the ChangeHome module only on that server.
Import database data to a location accessible from all nodes. The imports can
either be done before running the utility or executed as user-defined modules in
the utility.

48 Rehost Utility Guide

Identifying Optional Activities to Include
When Rehosting
Your Windchill environment can include some aspects that are not covered in the
basic sets of modules, but can easily be included in a rehost scenario.
The following list describes some additional environmental options that may exist
on your source system that you can take into account when running the utility:
• Clustered servers
In a clustered environment, the Cluster module is required to update the host
names in the target cluster. When host names have changed, the host names in
cluster-related properties need to be updated on each node in the target cluster.
For this reason, it is often necessary to run the utility multiple times when
rehosting clustered servers.
• File vault content
To manipulate file vault content on the target system, use the Vault and
SelectiveContent modules. The Vault module reconfigures vault mounts and
either copies content or creates empty stub files. After creating stub files, the
SelectiveContent module can replace specific stub files with content.
• WVS workers
There are two modules that can be used to work with CAD files. Use the
WVSAgent module for host name updates to agent configuration files. Use the
WVSWorker module to make worker start file updates for the workers which
resides on the same machine where Windchill is installed.
The following list describes additional changes the utility can perform:
• Change the Windchill web application name on the target system
Set the source.wc.webapp and target.wc.webapp properties, then
run the Apache, InfoEngine, and Database modules. This can be combined
with any scenario.
• Change initial queue processing options on the target system
The QueueMgmt module can control some of the processing of queues on the
target system and can clear queue entries.
To include any of the modules described in this topic in any of the rehost
scenarios, add the module to the scenario property, and set the required properties.
For additional details on these and other modules, see Using Task Modules on
page 61.

Planning Rehost Project Activities 49

Out-of-Scope Configurations
The following sections contain information about configurations that cannot be
rehosted using the Windchill Rehost Utility.

File Servers with main Vault

This version of the guide does not cover rehosting a source system if the system
has one or more remote Windchill File Servers where there is content stored on a
main Vault. For this configuration, a case-by-case analysis is requirde before
rehosting the system.
Before rehosting a system that has main vaults on remote Windchill File Servers,
contact Windchill Technical Support for help in analyzing your system and
coming up with alternate techniques or workarounds. The support provided for
this type of rehosting may fall under the Enterprise Deployment Resource Support
Policy, which can be accessed from the following URL:
http://www.ptc.com/view?im_dbkey=123331.

Windchill Business Reporting using Cognos

Using the Windchill Rehost Utility to perform rehost activities related to Cognos
files is not supported with this release of the utility. There is no utility module that
addresses the complex issues of rehosting Cognos files.
The target system resulting from the rehost scenarios that are supported will not
have the same Windchill Business Reporting functionality that is available on the
source system.

50 Rehost Utility Guide

 3
Installing and Uninstalling the
Windchill Rehost Utility
Installing the Windchill Rehost Utility ...........................................................................52
Uninstalling the Windchill Rehost Utility.......................................................................54

The Windchill Rehost Utility media is available from the PTC Software Download
page.
The following sections provide information about installing and uninstalling the
Windchill Rehost Utility media.

51
Installing the Windchill Rehost Utility
For Windchill Release 11.1 Onwards
The Windchill Rehost Utility is part of Windchill Installation, separate installation
of the utility is not required. The wcRehost folder can be located under <WT_
HOME>/utilities folder.

Media Content
The Windchill Rehost Utility is deployed as a set of Java classes and configuration
files that are invoked from a batch file (Windows) or shell script (UNIX and
Linux). Additionally, the utility includes a password encryption program that can
be run to set and encrypt passwords that are needed for rehost activities.
Download the media as the wcRehost.zip file. When unzipped, the ZIP file
creates a set of directories that consists of the following set of directories and files:
• conf
The conf directory contains property files and a modules directory as
follows:
○ modules
Contains XML files that are the bundled modules used in rehost activities.
See Using Task Modules on page 61.
○ log4j.properties
Contains the log4j property settings that are used when producing the
debug.log file. For additional details, see Log Files for Scenarios on
page 71.
○ projects.properties
Identifies the modules that are executed for each rehost scenario. Update
this file to define the scenarios you plan to use. For details, see Editing
Contents of projects.properties on page 63.
○ recovery.properties
Identifies the artifacts that are backed up when the utility runs. For details
on the automated backup, see Automatic Backup Activities Performed
when Windchill Rehosting Utility Runs on page 70.
○ rehost.properties
Contains a sample of the configuration properties required in a rehosting
scenario. Use this file to create multiple site-specific files that can provide
reproducible configurations for the scenarios you plan to execute. For
details, see Creating rehost.properties Files on page 66.

52 Rehost Utility Guide

 ○ rehost.xml
The PTC script engine for Windchill Rehost Utility. This script engine
enables the separate utility modules as Apache Ant tasks.

Note
Modification of the PTC script engine is not supported.

• lib
The lib directory contains the wcRehost.jar.
• scripts
The scripts directory contains sample Windchill start scripts for Windows,
UNIX, and Linux.
○ windchillStart.bat
○ windchillStart.sh
These scripts can be used as a starting point for a module that starts the
Windchill components. For details on using these scripts, see Script on page
92.
Use the scripts directory to store site-specific scripts you create.
• readme.txt
The readme.txt file describes the contents of the ZIP file and location of
the documentation.
• rehost.bat
The batch file used to run the Windchill Rehost Utility on Windows.
• rehost.sh
The shell file used to run the Windchill Rehost Utility on UNIX and Linux
systems.

Installing and Uninstalling the Windchill Rehost Utility 53

Uninstalling the Windchill Rehost Utility
The Windchill Rehost Utility does not register itself or make any other changes to
the server on which it is installed.
To uninstall the Windchill Rehost Utility, delete the top-level utility installation
directory and its contents, along with any custom directories that have been
created for rehost activities.

Note
Deleting the utility installation directory and other directories does not undo
any changes made to the environment, or remove any passwords that have
been stored in the Windchill keystore.

54 Rehost Utility Guide

 4
Using the Windchill Rehost Utility
Windchill Rehost Utility Overview................................................................................56
Using Modules ..........................................................................................................61
Editing Contents of projects.properties .............................................................63
Creating rehost.properties Files.........................................................................66
Running the Windchill Rehost Utility............................................................................66
Backing Up Artifacts from a Custom Windchill Environment ..........................................72
Recovery Using Windchill Rehost Utility Backups ........................................................73

The rehost process has traditionally consisted of many manual activities that
included command-line execution, direct modification of database tables using
SQL, and the text editing of LDIF files. These activities can still be done
manually. However, understanding which properties, database tables, LDAP
entries, and third-party configurations require changes has become increasingly
complex. This complexity is due to the additional Windchill modules and
capabilities that have been implemented.
The following sections provide details on how to use the Windchill Rehost Utility
3.0 instead of doing the rehost manually.

55
Windchill Rehost Utility Overview
Using the Windchill Rehost Utility simplifies the knowledge and effort needed to
complete a rehost. The utility makes rehost activities more efficient and easy. The
utility automates configuration and database updates, as well as providing a
flexible execution model that allows for varied customer environments and
requirements.

Input Files
Simplification of the knowledge and effort to complete a rehosting process is
accomplished by providing the utility with two types of inputs:
• Senarios
The scenarios are listed in the projects.properties file. Each scenario
property lists the default modules it includes. The utility requires only one
projects.properties file that is reused in all landscapes in a Windchill
deployment and therefore the file name is enforced. The file allows for the
tailoring of execution order, required modules, and custom scripts inclusions
for each scenario. The file also supports any number of defined scenarios.
• Environment-specific configuration information
The environment-specific configuration information needs to be provided in a
configuration file modeled on the default rehost.properties file. This
configuration file contains all environment-specific information for the utility
and must be provided as an argument on the command entered to run the
utility. It is expected that most deployments will require multiple rehosting
configurations and, as a result, the utility is designed to support many different
configuration files for a single Windchill deployment. The file name for
rehost.properties is not hard coded.
The rehost.properties file contains many properties that use the
following standard formats:
○ Properties that start with source.*, target.*, and staging.* are
used for referencing specific host names or paths on source, target, and
staging systems (respectively).
○ Properties that start with rehost.* are used to control the behavior of
the utility.
When an environment-specific need or configuration is not provided by the out-
of-the-box functionality of the utility, custom batch files or shell scripts that can
be included in a scenario can be created. With the inclusion of user-defined
scripts, utility execution in complex or non-standard Windchill architectures can
be automated. See Scripting (later in this topic).

56 Rehost Utility Guide

After environment-specific information, scenario activities, and custom scripts
have been configured properly, the utility can be executed unattended by simply
providing the appropriate rehost.properties file as an execution argument.

Staging Area
The utility is designed to only affect the target environment, leaving the source
environment unchanged. Many production landscapes are segregated from the test
and development landscapes. This eliminates the ability of the utility to access the
source datasets and configurations. For this reason, the staging area can be used to
provide the utility with access to required content when the source environment is
not directly accessible from the target environment. The staging area can be a
system level directory that the source environment is able to write to and the target
environment is able to read from. PTC recommends using a staging area to store
the data needed during utility execution. For example, include the following in the
staging area.

As depicted in the diagram, staging area data can include:

• A copy of the source codebase (represented by file folders)
• IEConf folder (represented by configuration icon)
• Source database exports (represented by a cylinder)
• A copy of vaulted source content (represented by documents)

In situations where the source environment is accessible from the target, the
source can be configured to function as the staging area.
An exception for needing a staging area is when the source and target
environments are the same environments. This is true when renaming or moving
an environment in place.

Using the Windchill Rehost Utility 57

Password Encryption
The configuration files (such as rehost.properties) used by the utility can
contain passwords. Although these passwords can be provided as clear text, they
can also be encrypted.
To encrypt a field value, specify $encrypt as the property value in
rehost.properties. The first time the property is needed the utility prompts
for the actual value. Type it in and press enter, the value is added directly to the
Windchill keystore. Set the property rehost.keystore.clear=true in the
rehost property file to remove encrypted properties from the Windchill keystore
after a successful scenario is complete.

Scripting
Custom scripts can be written to execute any system-level commands desired. The
script definitions can be direct shell commands, other executables, or references to
shell scripts or batch files. Scripting makes it easy to extend or replace utility
functionality with deployment or environment specific details by requiring only
system administrative knowledge rather than Java development or Windchill-
specific skills.
The following sections provide examples of scripting uses. For details on setting
up and using scripts in the rehost process, see Script on page 92.

Export and Import of Source Datasets

The utility does not provide direct export and import capabilities due to the
variance in requirements from one environment to the next. Automating the
import of datasets can be done through the utility scripting capabilities and
common script examples are provided in Rehosting Utility Script Examples on
page 190.
In addition to automating the import of datasets into the target environment,
example scripts are also provided for automating the export of datasets from the
source environment. Although the utility can be configured to execute the export
scripts on the source environment, exporting from within the utility is not
necessary. PTC recommends using standard administrative procedures for
executing export scripts on the source environment.

Environment Manipulation
Some activities in the rehost process require the Apache, Windchill to be running,
and others require that these components are shut down. Other actions, such as
importing datasets, deleting logs or caches, or disabling notification systems, may
also be required. The utility scripting capabilities allow you to insert user-defined
scripts in the chain of activities so that you can start and stop processes as needed,
or perform other actions. In the utility scripts directory, there are sample start

58 Rehost Utility Guide

scripts that you can modify. Additionally, this guide documents example scripts
for both Windows and UNIX (and Linux) in Rehosting Utility Script Examples on
page 190.

General Steps for Using the Windchill

The Windchill is executed directly on the target environment. Once the utility is
invoked, it runs without user interaction until it completes successfully or an error
is encountered. Therefore before running the Windchill Rehost Utility program,
set up the target system and all required input files.
Complete the following steps for first time utility configuration and execution:
1. Complete the planning activities for the rehost scenario you have chosen to
implement. The activities include:
a. Download and install utility on target environment.
See Installing the Windchill Rehosting Utility on page 52.
b. Set up the staging area (if needed). This can include exporting database
dataset and the IEConf from source and putting the generated files on the
staging area. In some scenarios, source directories should also be copied to
the staging area.
This step can be required when the source and target systems are not the
same system. For staging area details, see Staging Area on page 57.
c. Backup target environment (if pre-existing).
The utility backs up the database tables and configuration files it will
modify before making any changes. It may be necessary to perform
additional backups or back up custom directories outside of the utility. See
Backing Up Artifacts from a Custom Windchill Environment on page 72.
d. Import dataset and copy IEConf files from staging area into target.
The imports can be done outside of the utility using standard procedures or
with custom scripts to do the imports using the utility.
For additional details about planning activities, see Planning Rehosting
Activities on page 34.
2. Configure utility artifacts that include projects.properties scenario
definition, rehost.properties property settings, and any custom scripts:
a. Determine which out-of-the-box modules to use and which user-defined
modules need to be created.
See Using Task Modules on page 61.
b. Create scripts for user-defined modules identified in step a.

Using the Windchill Rehost Utility 59

 For details on setting up user-defined modules and for links to examples of
user-defined modules, see the module description for Script on page 92.
c. Edit the project.properties file so that it contains the definitions
of the modules to execute for the chosen rehost scenario.
See Editing Contents of projects.properties on page 63.
d. Create a unique rehost.properties file for the rehost scenario. The
sample rehost.properties file in the Windchill Rehost Utility
install conf directory is available to be used as a template.
For details, see Creating rehost.properties Files on page 66.
3. Run the Windchill Rehost Utility.
For details, see Running the Windchill Rehost Utility on page 66.
If errors are found, restore target from backed-up files, adjust properties in the
utility configuration file, and rerun the utility.
4. Complete any manual steps that have been identified as being required after
running the Windchill Rehost Utility. There are no manual steps for the
documented scenarios. However, as part of your personalized scenario, you
may have identified one or more manual steps.
If no manual steps are needed before or after you run the utility, you can schedule
it to run automatically. For example, using a UNIX cron job.
If there are manual steps, the requirements needed for subsequent executions of
the utility are as follows:
1. Update files in the staging area. This can include exporting database dataset
and copying IEConf files from source and putting the generated files on the
staging area.

60 Rehost Utility Guide

2. Backup target environment.
The utility backs up the database tables and configuration files it will modify
before making any changes. Outside of the utility, you can perform additional
backups.
3. Import dataset and IEConf files from staging area into target.
The imports can be done outside of the utility using standard procedures or
you can create custom scripts to do the imports using the utility.
4. Run the Windchill Rehost Utility using the same configuration file used in the
first run.
5. Complete all manual steps (if any) that are required after running the
Windchill Rehost Utility.

Using Modules
The Windchill Rehost Utility provides a set of out-of-the-box modules that you
can use to accomplish many rehost activities.
Additionally, you need to identify any tasks that are unique to your site and need
to be run as part of the rehost activity. User-defined modules can be created to
execute scripts and accomplish the tasks.
For a brief explanation of the out-of-the-box modules, see the following section
Bundled Task Modules on page 61.
Each supported scenario uses a core set of modules that can be modified for your
individual use case. The projects.properties file contains the core set of
modules for each supported scenario. For additional details, see Editing Contents
of projects.properties on page 63.

Bundled Modules
The following table describes the modules that are bundled with the Windchill
Rehost Utility. The modules reside in the conf/modules directory where the
Windchill Rehost Utility is installed.
Module Description
Apache Updates the target Apache configuration file to reflect new
host names and host aliases.
For additional details, see Apache on page 77.
Backup Used by the utility to identify the modules in a rehosting
scenario so that existing files on a target system can be
backed up. Include this module, where backup is required.

Using the Windchill Rehost Utility 61

Module Description
For additional details, see Automatic Backup Activities
Performed when Windchill Rehosting Utility Runs on page
70.
ChangeHome Updates configuration settings to reflect a change in the
Windchill installation directory (WT_HOME) on the target
system.
For additional details, see ChangeHome on page 79.
Cluster Updates properties to reflect changes in cluster-related
properties on the nodes in a cluster.
For additional details, see Cluster on page 85.
Copy Copies directories and files from a staging area to the target
system.
When included in any rehost scenario, the Copy module
runs first no matter where it appears in the list of modules
identified for the scenario.
For additional details, see Copy on page 81.
Database Propagates database changes.
For additional details, see Database on page 87.
InfoEngine Propagates a change in the host name on the target
Windchill system that is stored in the Info*Engine
configuration. The host name is stored in IEConf and in
properties files.
For additional details, see InfoEngine on page 89.
QueueMgmt Controls the processing of queues on the target system and
optionally clears queue entries.
For additional details, see QueueMgmt on page 91.
Restore Restores changes made by the Windchill Rehost Utility.
To perform restore operation, you can add a set of DB_BAK
tables as per your requirement to the
recovery.properties file. For more details on
running a recovery, refer to Recovery Using Windchill
Rehost Utility Backups on page 73.
Script Executes user-defined shell scripts and batch files during
the rehost process.
For additional details, see Script on page 92.
SelectiveContent Locates a set of files in vault folders in a staging area and
copies those files to the target system. Use with Vault
module.

62 Rehost Utility Guide

Module Description
For additional details, see SelectiveContent on page 95.
Solr Changes Solr-related configurations.
For additional details, see Solr on page 94.
Vault Updates file vault hosts and mounts on the target system.
Either copies vaulted content or generates empty stub files.
For additional details, see Vault on page 96.
WVSAgent Configures the Windchill Visualization Services agent
configuration file agent.ini on the target system.
For additional details, see WVSAgent on page 98.
WVSWorker Configures the worker start file so that it points to the
updated target Windchill system host name. Runs on the
worker system.
For additional details, see WVSWorker on page 100.
Windchill Executes RehostWAUtility to check if a repository
Performance with the name PTC_WNC_Internal exists, If it exists,
Advisor Windchill Performance Advisor updates the record in the
database table. If not, it generates a new record in the table.
This record helps to identify the Windchill server that is
running.
For additional details, see Windchill Performance Advisor
(WPA) on page 101.
Windchill Bulk Propagates the Windchill Bulk Migrator (WBM) properties
Migrator on target Windchill. Execute the WBM task as required in
the Rehost scenarios.

Module Examples
For examples of how to use the modules, see Rehosting Scenarios on page 140.

Editing Contents of
projects.properties
The out-of-the-box projects.properties file contains sample scenario
properties that identify the default modules used to execute supported rehost
scenarios. The projects.properties file is located in the conf directory
where the Windchill Rehost Utility is installed.

Using the Windchill Rehost Utility 63

After determining the desired rehost activities, ensure that the modules required
are identified in the scenario property in projects.properties. The
Windchill Rehost Utility executes the modules in the order they are listed in the
scenario property.
The following sections provide information about the scenario property syntax
and use.

Scenario Property Syntax

The general syntax of scenario properties in projects.properties is:
<scenario>.<variant>=<module_list>

where:
• Specify a scenario name (<scenario>) using one of the supported scenario
names. Supported names are rename, rehost, move, and clone. For
information on the different types of rehost processes, see the sections under
Rehosting Process Overview on page 15.
• Including .<variant> is optional. If included, <variant> creates a
custom sub-case for the scenario. The addition of a scenario variant allows
you to maintain a single projects.properties file for all of your
landscapes. This allows multiple scenarios of each type (rename, rehost, clone,
move) to be configured in a single projects.properties file for
simplified utility deployment and configuration management.
The variant string can be any number of alphanumeric characters; spaces are
not allowed. For example, if you are renaming a Windchill 10 development
system, the property listing the modules for renaming the development system
could be rename.WC10dev.
• <module_list> is a comma-separated list of modules. The order of the
modules in the list determines the execution order with the following
exception, the Copy module always executes first (regardless of where it is
listed).
The following modules can be included:
○ Bundled modules
These modules provide specific actions that PTC has grouped together to
automate changes in the target Windchill environment.
○ User-defined modules
These modules are identified in the list using the bundled Script module.
Each Script module names a user-defined script that allows you to
automate a site-specific rehost activity.
For details on the modules, see Using Task Modules on page 61.

64 Rehost Utility Guide

Scenario rehost.useCase Property
The value of the rehost.useCase property in rehost.properties must
match a <scenario>.<variant> name set in projects.properties.
This determines which rehost scenario is performed. For example, assume
projects.properties has the following rename scenario property set:
rename.prod=InfoEngine,Apache,Database,Vault,WBM

Note
Windchill Bulk Migrator (WBM) is an optional module.

To use the set of modules established in rename.prod, the

rehost.useCase property in the rehost.properties file being used
must be set as follows:
rehost.useCase=rename.prod

Using the Windchill Rehost Utility 65

Creating rehost.properties Files
Multiple rehost configuration files can be created. In each file, set values for
specific source, staging, and target systems, and include settings for specific
rehost activities. PTC provides the rehost.properties template file that is
located in the conf directory where the Windchill Rehost Utility is installed.
As part of planning activities, determine how many property files are needed for
the rehost activities. Each property file contains all configuration properties
needed for one rehost scenario and can be named according to any convention.
For example:
• rename_dev_vm.properties—properties for changing the name of a
development system that is both the source and target system.
• rehost_test_as_prod.properties—properties for rehosting a
development source system as a test target system.
Property files can be saved and reused. The files can be stored in any directory
that is accessible to the utility. Specify the path to the file in the command to run
the utility.
For details on the properties that can be set, see Rehosting Property Descriptions
on page 102.

Running the Windchill Rehost Utility

The Windchill Rehost Utility is only executed on the target system. When the
target and source systems are separate, this ensures that the source system remains
unaffected by any rehost operations. When there is only one system that is both
the source and target, changes are made to that system. For example, just one
system is used when doing in-place renaming or when moving of an environment.
Many production environments are segregated from the test and development
networks. This eliminates the ability of the utility to access production
configurations and datasets from the target system. For this reason, the utility
supports the concept of a staging location. The staging location is designed to be a
location accessible by both the source and target systems. When the source system
is not accessible to the target system, PTC recommends exporting the source
database, IEConf folder, codebase, and vaults to a staging area. Then, complete
rehost activities using the staging area, which is accessible to the target.

Where to Run the Utility

In monolithic target environments, only one set of configuration files and one
execution of the utility is needed to fully rehost the environment. The rest of the
content in this section can be skipped.

66 Rehost Utility Guide

In clustered, distributed, or non-standard target environments, multiple
configuration files and multiple utility executions are required to fully rehost the
environment.
In environments containing more than one machine, the utility must be executed
on all target systems. For example, run the utility multiple times when there are:
• Multiple servers configured in a cluster
When there is more than one system involved, execute the utility in the following
order:
1. Cluster main node (when one is defined)
2. Cluster secondary nodes (if needed)
For clustered target environments, the utility manages dataset changes differently:
• It only modifies datasets when executing on the main node (if one is defined)
and never on secondary nodes.
• When executing on secondary nodes, it only makes configuration changes
directly affecting the secondary node.
Use the following information to determine when to run the utility on the nodes in
the cluster:

Note
When rehosting a cluster that is running Windchill 10.2 or later, there may not
be a dedicated main node in the cluster. If that is the case, run the utility first
on the node that is currently acting as the main node. Then complete all other
runs as if the nodes were secondary nodes, where database and IEConf
changes are not needed.

• When renaming, first run the utility on the main node (if defined) and then run
it on all secondary nodes as well. This is because host name changes are
required on all nodes in the cluster. Therefore, at least two
rehost.properties files are needed: one for the main (or for first node
on which the utility is run), and one for all secondary nodes. For additional
details, see Identifying Activities for Rename on page 39.
• When rehosting into an existing clustered target, typically execute the utility at
least one time on each node. Only the database and IEConf are modified from
the main (or first) node, but cluster-related properties need to be updated on
each node. For additional details, see Identifying Activities for Rehost on page
41.

Using the Windchill Rehost Utility 67

• When cloning, all nodes require execution because all nodes require updated
codebase files and configurations. For additional details, see Identifying
Activities for Clone on page 43.
• When moving (involving the changing of installation directories but not host
names), nodes may require different modules based on the type of move. For
additional details, see Identifying Activities for Move on page 45.
The utility must be run on each target system used for WVS workers. Each of
these systems requires changes for all scenarios, except when rehosting only the
database and IEConf for WVS worker systems.

Running the rehost Program

The Windchill Rehost Utility is a command-line utility that is not interactive,
except to prompt for values to be encrypted. Therefore before running the
Windchill Rehost Utility program, set up the required input files, and then enter
the command that runs the program.
The main program in the utility is called by executing rehost.bat (on
Windows) or rehost.sh (on UNIX and Linux). This program performs specific
rehost activities based on the modules run and the settings n the
rehost.properties file. The rehost.properties file is named on the
command entered to run the utility.

Note
The target system database must be running when you run the Windchill
Rehost Utility.

When running the Windchill Rehost Utility from a target environment where
Windchill is installed, the utility can be executed from within a Windchill shell.
Open the shell, navigate to the directory where the Windchill Rehost Utility is
installed. Then enter the command to run the Windchill Rehost Utility.
When running the Windchill Rehost Utility where the target system does not have
Windchill installed, start the utility from a command prompt where you have the
access you need. For example:
• When copying Windchill software to a target system, the utility with a user
that has write access to the directory where the files will be copied.
• When updating a WVS worker start file from a server where Windchill is not
installed, please manually update the start files of workers with updated
Windchill server hostname.
Navigate to the directory where the Windchill Rehost Utility is installed and enter
the command to run the Windchill Rehost Utility using the following syntax.

68 Rehost Utility Guide

On Windows, enter:
rehost.bat <rehost.properties_file>

On UNIX and Linux, enter:

./rehost.sh <rehost.properties_file>

where:
<rehost.properties_file> is the file path to the configuration property
file that contains the setting for this rehost scenario. Although you can use any
name for the file, the documentation usually uses rehost.properties as the
configuration property file name. When a partial path is specified, the utility
assumes that the path specified is under the top-level directory where the
Windchill Rehost Utility is installed.
Instead of using plain text passwords in a rehost.properties file, the value
can be specified as $encrypt and then entered at the command line when the
rehost utility is executed.

Example rehost Commands

To run the utility to rehost Windchill data to a target Windows system where
Windchill is installed, select Windchill Shell from the Windows Start menu on the
target system. From the window that opens, navigate to the directory that contains
rehost.bat, and enter the following command to run the utility. The example
uses the dev-to-test-rehost.properties file that is stored in the
utility’s conf directory:
rehost.bat conf\dev-to-test-rehost.properties

After successfully running the Windchill Rehost Utility, save the startup command
and all artifacts used in the run. This allows the utility to be rerun or automated for
future use.
You can also run the Windchill Rehost Utility as a UNIX cron job. For example,
include the following .crontab entry to run the utility every Sunday at
midnight:
0 0 * * 0 /ptc/Windchill/rehost/rehost.sh conf/rehost.properties

For examples of setting up the required files and running the Windchill Rehost
Utility, see the examples in Rehosting Scenarios on page 140.

Using the Windchill Rehost Utility 69

Automatic Backup Activities Performed when
Windchill Rehost Utility Runs
Before making any changes, the Windchill Rehost Utility creates backups of
affected configuration files, database tables, and IEConf entries on the target
system. To create backups, the utility uses the recovery.properties file
that is located in the utility conf directory and uses the Backup module.
What is backed up is based on which modules will be run. The utility checks the
recovery.properties file to determine what to back up for each module.
For example, when the InfoEngine module is in the list of modules to run, the
following entries in recovery.properties determine what is backed up:
InfoEngine_LDAP_BAK=true
InfoEngine_FILE_BAK=@WT_HOME/codebase/wt.properties,@WT_HOME/codebase/WEB-INF/,@WT_HOME/IEConf
ieStructProperties.txt,@WT_HOME/codebase/WEB-INF/web.xml,@WT_HOME/codebase/
WEB-INF/mapCredentials.txt
InfoEngine_DB_BAK=

The InfoEngine entries indicate that the utility will back up IEConf entries and
selected files. There are no database tables to back up.
Out-of-the-box, there is no automatic backup done on artifacts that will be
changed when the Windchill Rehost Utility runs user-defined modules. For
example, database tables that will change as a result of importing database data in
a user-defined module are not backed up before the utility executes modules. A
full backup should be created before running the utility or as a user-defined
module as the first action in the scenario.
Automatic backup activities occur at the beginning of the run. Notification that the
activities are occurring display in the command window with the [backup]
prefix and are captured in the utility log file. Each affected configuration file,
database table, and IEConf entry is backed up before any supported modules run.
The utility determines what to back up by inspecting the list of modules that will
run. The affected files, database tables, and IEConf entries are documented with
each module description in Rehosting Module Descriptions on page 76.
The backed-up tables are named using the following format:
<name>_rhbak

Backup files are stored in the backups directory under the Windchill Rehost
Utility installation directory. The name of the directory for a particular run has the
following format:
<scenario>.<variant>-<date>_<time>

70 Rehost Utility Guide

where:
• <scenario>.<variant> is the name of the property that identifies the
scenario that was executed. The property is stored in the
project.properties that was used.
• <date> is the date of the program run and has a format of yyyymmdd.
• <time> is the time of the run and has a format of hhmm.

Log Files for Scenarios

The log file contains the output from running the utility. If it was run from a
windchill shell, the log is created in <WINDCHILL_HOME>/buildlogs and
called rehost-<NNNN>.log.
When the utility is run, RehostUtility.log is created in the rehost utility
installation directory. Logs for previous runs of the rehost utility are renamed with
a timestamp of RehostUtility_<yyyymmdd>.log.
When the Copy module runs, it generates a separate log file that captures the
details of the copy activities. Logs for the Copy module runs are stored in the
copylogs directory under the rehost utility installation directory. This is because
the execution of the module could produce errors and stop before the target
<Windchill>/buildlogs directory is available. Also, the details for each
Copy module run are captured in the log file for the scenario when possible.

Execution Results
Each rehost scenario has unique results. General results for each scenario are as
follows:
• Results from running the Rename scenario are that the host name change has
been completed in the Windchill application and the application is functional.
In this case, there is only one system that is both the source and target.
• Results from running the Rehost scenario are that:
○ The Windchill application configuration changes that were required to
make the data usable on the target system have been made.
○ A dataset has been copied from the Windchill application on the source
system to the target system.
The dataset could include actual files with content or just stub files.
• Results from running the Clone scenario are that the Windchill software and a
dataset have been copied from the source system (using the staging area) to
the target system. On the target system, the copy replaces any Windchill

Using the Windchill Rehost Utility 71

 software on the target system. The dataset can include actual files with content
or just stub files. Additionally, all Windchill application configuration changes
that were required on the target system have been made.
• Results from running the Move scenario could be either of the following:
○ An existing Windchill application that was moved to a new directory on
the same computer is functional.
○ An existing Windchill application that was moved to a new computer on
the same hardware platform is functional.
○ An existing Windchill application that was moved to a new hardware
platform is functional.
For examples that include specific results, see the examples in Rehosting
Scenarios on page 140.

Backing Up Artifacts from a Custom

Windchill Environment
The Windchill Rehost Utility automatically creates backups of affected
configuration files, database tables, and IEConf entries on the target system using
the recovery.properties file. The recovery.properties file is
located in the utility conf directory. For details on this backup process, see
Automatic Backup Activities Performed when Windchill Rehosting Utility Runs
on page 70.

Note
Customers may customize the recovery.properties file, but do so at
their own risk.

For a customized Windchill environment in which additional files, IEConf entries,

or database tables need to be backed up before rehosting, perform the following
steps:
First, identify which of the following are affected:
• IEConf entries
• Files
• Database tables

72 Rehost Utility Guide

Next, add the information in the recovery.properties file by editing the
file. This file contains lines for each module that modifies artifacts. The module
name at the beginning of each line groups the lines:
• For IEConf entries, the <module_name>_LDAP_BAK=true line indicates
that IEConf entries are modified. The <module_name>_LDAP_BAK=
false indicates that no entries are modified.
• For backing up additional files, add the files to the file list in <module_
name>_FILE_BAK=<comma-separated_file_list>.
• For backing up database tables, add the table names to the list in <module_
name>_DB_BAK=<comma-separated_table_list>.
Save any changes made to the recovery.properties file before running the
utility.

Recovery Using Windchill Rehost Utility

Backups
The process to perform a recovery is automated and you can restore the Windchill
application on a target system to the state it was in before the Windchill Rehost
Utility was run.

Prerequisites
When running the Windchill Rehost Utility, you must execute the Backup task.

Codebase Recovery
You can directly run recovery.bat for Windows and recovery.sh for
Linux environment from the scripts folder. Alternatively, you can use the
rehost utility Script module to run the recovery script. For more information on
the Script module, refer to Script on page 92.

Note
Recovery script uses the latest backup folder from the backup directory for
restoration.

Database Recovery
For database recovery, follow these steps:
1. In the projects.propeties file,
a. Add Restore task as a first module.
b. Remove the Backup module.

Using the Windchill Rehost Utility 73

 c. Keep all other modules as it is, as they required to identify DB_BAK tables
per module from the recovery.properties file.
2. Run the Windchill Rehost Utility.

Note
Windchill Rehost Utility executes only the Restore task and then exits
automatically. It does not execute the subsequent modules from the
projects.properties file.

74 Rehost Utility Guide

 5
Rehost Utility Configuration
Details
Rehost Module Descriptions.......................................................................................76
Rehost Property Descriptions ................................................................................... 102

When setting up for a rehost scenario, decide which modules to use and set the
appropriate rehost properties before running the utility.
The following sections provide information about the rehost modules and
configuration properties used by the Windchill Rehost Utility.

75
Rehost Module Descriptions
The following sections provide details about using the modules bundled with the
Windchill Rehost Utility. The modules reside in the conf/modules directory
where the Windchill Rehost Utility is installed.

76 Rehost Utility Guide

Apache

Note
Before proceeding with rehosting tasks, if a server is configured with SSL,
then you need to generate new certificates and configure it on the new
machines for the rehost scenarios namely, Rename, Rehost, Clone and Move
to a different machine.

Use the Apache module to update the target Apache configuration file to reflect
new host names and host aliases.

Note
In Windchill 10.2 and later releases, the web server bundled with Windchill is
named the PTC HTTP Server (powered by Apache). Use the Apache module
to update the PTC HTTP Server configuration file. Throughout the guide,
references to Apache also apply to the HTTP Server.

Required Properties
A value for the target.wc.hostname and
target.directory.httpserver properties must be set in the
rehost.properties file that is specified when running the Windchill Rehost
Utility.

Optional Properties
If values for the following properties have changed the Apache module should be
run:
cluster.main.gateway
source.directory.httpserver
source.directory.windchill
source.local.domain
source.wc.webapp
target.directory.windchill
target.httpserver.port
target.httpserver.ssl.port
target.ldap.serviceName
target.ldap.hostname.*

Rehost Utility Configuration Details 77

target.ldap.password.*
target.ldap.port.*
target.ldap.scheme.*
target.ldap.username.*
target.wc.hostname
target.wc.webapp
For property details, see Windchill Path Settings on page 114 and Host Settings on
page 115.

78 Rehost Utility Guide

ChangeHome
Use ChangeHome to update a set of configuration files and database tables on the
target system so that the configuration settings on the target system are updated to
point to a new Windchill installation directory (WT_HOME).
Updating an installation home directory using the ChangeHome module is useful
when running a Clone or Move scenario where the installation directory has
changed. After moving Windchill to a different installation directory on the same
or a different machine, either with the Copy module or by another method, run
ChangeHome to update the Windchill installation directory on target system.
For details on executing a Clone scenario, see Identifying Activities for Clone on
page 43.
For details on executing a Move scenario, see Identifying Activities for Move on
page 45.

Optional Properties
If values for the following properties have changed, the ChangeHome module
should be run:
source.directory.httpserver
source.directory.java
source.directory.psiBase
source.directory.windchill
target.directory.httpserver
target.directory.java
target.directory.psiBase
target.directory.windchill

Rehost Utility Configuration Details 79

80 Rehost Utility Guide
Copy
Use the Copy module to copy directories and files (including nested directories
and files) from a staging area to the target system. The module uses standard
copying mechanisms for each platform to do the actual copying.

Note
To run this module, correct permissions are required to create the target
directory for Windchill and to read the directories and files that are in the
staging area.

The Copy module is designed to run in an empty computer environment that does
not have Java, Windchill, or Ant installed. Use this module, to specify directories
and files to be copied.

Note
When included in a rehost scenario, the Copy module always runs first
regardless of where it appears in the list of modules identified for the scenario.
This means that the Copy module runs before any user-defined modules.
To set up your environment before copying files, perform one of the
following:
• Do the set up outside of the utility before running the rehost utility.
• Run the rehost utility two times:
1. Do the setup that is required using the utility. This can usually be done
through one or more user-defined scripts.
2. Copy directories and files using the Copy module, and then execute
any other modules for the scenario.

Rehost Utility Configuration Details 81

The directories where the files reside are named in the properties that are set. The
files that can be copied include files in the following directories:
• Windchill installation directory
• Java installation directory
• Web Server (Apache or PTC HTTP Server) installation directory
• IEConf directory
• PTC Solution Installer (PSI) installation directory

Note
No changes are made to the files that are copied as a result of executing this
module.

Properties Used by Copy

Before executing Copy, set values for sets of properties in the
rehost.properties file that is specified when running the Windchill Rehost
Utility; for example, set both the staging.directory.windchill and the
target.directory.windchill properties to copy the content of the
Windchill installation directory from the staging directory named to the target
directory named. If copying directly from your source system, specify source path
values as values for corresponding staging.directory properties.

Note
Windows UNC paths require adding an additional backslash (\) as an escape
character at the beginning of the path. For example:
staging.directory.windchill=\\\mcsrc.src.domain\ptc\Windchill_10.2\Windchill

82 Rehost Utility Guide

Copying is done only when there are directories named in both the corresponding
staging and target properties:
staging.directory.windchill
target.directory.windchill
staging.directory.java
target.directory.java
staging.directory.httpserver
target.directory.httpserver
staging.directory.psiBase
target.directory.psiBase
staging.directory.<char>
target.directory.<char>
The staging.directory.<char> and target.directory.<char>
properties allow for the flexibility to copy additional directories that are unique to
your environment.
If the target.directory.* properties set for the Copy module are different
from the corresponding directories on the source system, then the installation
directory will be changed while doing the copy. If the installation directory is
changed, the ChangeHome module is requried. For additional details, see
ChangeHome on page 79.
For property details, see Copy Settings on page 127.

Rehost Utility Configuration Details 83

Log File for Copy Module Execution
Each time the Copy module runs, it creates a unique log file containing the copy
output from the module run. The log file is stored in the copylogs directory.
The copylogs directory is created under the rehost utility installation directory
the first time the Copy module runs. The name of the file has the following
format:
yyyymmdd-hhmmss-Copy.log
where yyyymmdd-hhmmss is the date (year, month, and day) and time (hour,
minutes, and seconds) when the module was run. For example, if the Copy
module was run on January 22, 2014 at 8:57:26 PM, the log file created has the
following name:
20140122-205726-Copy.log
The log file for the Copy module output is not stored with the other rehost utility
log files in the target <Windchill>/buildlogs directory since the execution
of the module could produce errors and stop before the target <Windchill>/
buildlogs directory is available.

84 Rehost Utility Guide

Cluster
Use the Cluster module to update properties to reflect changes in cluster-related
properties on each node in a target system cluster.

Note
This module is required when changing the host names of nodes in a
Windchill cluster and must be run on the main node (if defined) before
running it on secondary nodes. On the secondary utility runs, set
cluster.secondary.rehost=true.
If all nodes can be the main node (as can be the case in clusters using
Windchill 10.2 or later), then run the utility (including Cluster) on one of the
nodes to update IEConf and database data as well as the cluster properties.
Then execute the Cluster module on all other nodes to update host names in
cluster properties on those nodes.

When the Apache module is included in the scenario, place the Cluster module
after the Apache module.

Required Properties
Before executing Cluster, set values for the following properties in the
rehost.properties file that is specified when running the Windchill Rehost
Utility:
cluster.main.gateway
cluster.secondary.hostnames
target.wc.hostname
For property details, see Cluster Settings on page 116.

Rehost Utility Configuration Details 85

ContainerTemplate
Run the ContainerTemplate module after the Vault module to copy
ContainerTemplates from the database into the stubbed vault created by the Vault
module. This may be useful when using the rehosted environment for upgrade
testing.

Required Properties
For property details, see Vault on page 96.

86 Rehost Utility Guide

Database
Use the Database module to propagate a change in the host name of the system on
which Windchill is installed. The changes are made in the target database and in
its associated properties file.

Required Properties

Note
Running this module requires that the database is running and that a valid
database user name and its password are stored in the
rehost.properties file. Use the target.db.username and
target.db.password properties to store those values.

Before executing Database, values for the target.db.* and

cluster.secondary.rehost properties must be set in the
rehost.properties file that is specified when running the Windchill Rehost
Utility.

Optional Properties
cluster.main.gateway
source.wc.webapp
source.local.domain
target.ldap.renameAdapter
target.ldap.serviceName
target.directory.windchill
target.wc.hostname
target.wc.organization
target.wt.home
cluster.secondary.rehost
For property details, seeDatabase Settings on page 112, Windchill Path Settings
on page 114, Host Settings on page 115, and Cluster Settings on page 116.

Rehost Utility Configuration Details 87

88 Rehost Utility Guide
InfoEngine
Use the InfoEngine module to update IEConf with any changes made in the
environment. The module makes the necessary changes to the target Info*Engine
configuration that is stored in IEConf and in properties files.

Required Properties
Before executing InfoEngine, values for the following properties must be set in
the rehost.properties file that is specified when running the Windchill
Rehost Utility:
cluster.secondary.rehost
target.directory.windchill
target.ldap.hostname.*
target.ldap.password.*
target.ldap.port.*
target.ldap.username.*

Optional Properties
cluster.main.gateway
source.directory.windchill
target.ldap.IEConfDir
source.local.domain
source.wc.webapp
target.ldap.deleteAdapter
target.ldap.scheme.*
target.ldap.serviceName
target.ldap.renameAdapter
target.ldap.setAdapterAttributes.*
target.directory.windchill
target.wc.hostname
target.wc.webapp

Optional Properties for JMS

target.jms.hostname
target.jms.port
target.jms.username
target.jms.recoveryRetryInterval
target.jms.CtxFactory

Rehost Utility Configuration Details 89

For property details, see Windchill Path Settings on page 114, Host Settings on
page 115, Database Settings on page 112, Cluster Settings on page 116, and LDAP
Settings on page 106.

90 Rehost Utility Guide

QueueMgmt
Use the QueueMgmt module to control the processing of queues on the target
system and optionally clear queue entries.
The QueueMgmt module is useful when rehosting for a variety of purposes. Some
examples of actions that can be taken using the QueueMgmt module are:
• Stopping the Workflow queue on a target system to aid in troubleshooting a
workflow issue that was present on the source system.
• Clearing and stopping the email notification queue to ensure that users do not
receive multiple copies of an email notification from both source and target
environments.
• Clearing the WVS publishing queues to prevent the target environment from
attempting to publish content when file vaults have not been rehosted.
The queues are displayed on the Queue Management page from Site ▶ Utilities
on your system.

Required Properties
Before executing QueueMgmt, set values for the following properties in the
specific rehost.properties file:
rehost.queue.name.<n>
rehost.queue.enabled.<n>
rehost.queue.clear.<n>
For property details, see Queue Settings on page 130.

Restore
Use the Restore module to roll back the changes made by the Windchill Rehost
Utility. The Restore module offers an automated mechanism to restore the
changes in Windchill application on a target system.
To perform the Restore operation, you can add a set of DB_BAK tables as per your
requirement to the recovery.properties file. For more details on how to
run a recovery, refer to Recovery Using Windchill Rehost Utility Backups on page
73.

Note
There are no additional properties required for the Restore operation.

Rehost Utility Configuration Details 91

Script
Use the Script module to execute user-defined shell scripts and batch files during
the rehost process.

Syntax
Use the following syntax for the Script module entry on the scenario modules
property in projects.properties:
Script:<module_name>

where:
<module_name> is a unique module name. The specified name must match a
corresponding script.<module_name> property in
rehost.properties. In that property, specify the name of a script file in the
scripts directory where the Windchill Rehost Utility is installed.

Required Property
The property and its value identify the module name and script file name as shown
in the following format:
script.<module_name>=<script_file_name>

For property details, see User-defined Script Settings on page 126.

Example
If the scenario requires that Windchill is started a user-defined module to start
Windchill must be created. PTC provides a sample windchillStart.sh file
and windchillStart.bat file in the utility scripts. The documented
examples include start files to use as a model for the required module. See User-
defined Scripts for Rename Example on page 142 and User-defined Scripts for
Rehost on page 147.
Execute the script by naming it in a Script module and setting the script file name
in the rehost.properties file used when the Windchill Rehost Utility is run.
For example, put the mywcstart.sh file in the scripts directory where the
Windchill Rehost Utility is installed. Then include the following entry in the
rehost.dev property in projects.properties:
Script:WindchillStart

Also, include the following property in the rehost.properties file:

script.WindchillStart=mywcstart.sh

92 Rehost Utility Guide

When the utility encounters the WindchillStart user-defined module
(identified by Script), it takes the following actions:
1. Obtains the projects.properties script value (WindchillStart, in
this case)
2. Looks up the property name in rehost.properties
(WindchillStart)
3. Acquires the value that represents the path to the mywcstart.sh script and
executes the script before moving on to the next module.

Rehost Utility Configuration Details 93

Solr
Use the Solr module to change Solr-related configurations so that the Solr
installation works on the target system.
For details on Rehosting the Solr Server, see Automated Configurations for
Rehosting Standalone Solr Server on page 182.

Properties that Are Used

While executing a Rename scenario, if only Windchill server is renamed ,no need
to execute this module as no change in Solr Server (if Solr Server is on different
machine) related properties in windchill configurations.
If Solr Server (same or different machine from Windchill installation) is renamed,
Solr module can be run independently to update Solr Server properties in
Windchill configuration. Below properties can be used to run Solr module
target.solr.host
target.solr.port
target.authTrustedHosts
In rehost Scenario there is no need to run Solr module.
In clone scenario, the solr module can be run to update below properties:
target.solr.host
target.solr.port
target.authTrustedHosts
target.solr.solrEffectiveUid
In Move Scenario run Solr module only if Solr Server and Windchill are installed
on same machine and are being moved to different machine.
target.solr.host
target.solr.port
target.authTrustedHosts
target.solr.solrEffectiveUid
For property details, see Solr Settings on page 136.

94 Rehost Utility Guide

SelectiveContent
Use the SelectiveContent module to locate a set of files in vault folders on a
staging area and copy those files to your target system. Use this module along
with the Vault module when only a selected set of content files is needed on the
target system. Although this module was designed and tested against assemblies
(such as *.asm and *.CATProduct), any file of type EPMDocument (such as
*.prt, *.lay, *.frm, *.CATPart, *.dwg, and so on) can be used in the
target.content.assembly.filename.* property.
Execute this module after executing the Vault module in the same Windchill
Rehost Utility session as follows:
1. First execute the Vault module with target.fv.required=false.
The Vault module then generates stub files with no content (0 size) in
directories identified by target.fv.path.*.
2. Then execute the SelectiveContent module with
target.content.assembly.* properties set to identify the file to copy
from the staging directories (identified by staging.fv.path.*
properties) to the target directories (identified by target.fv.path.*
properties).
The file content identified is then copied, replacing the existing stub files that
have no content.
The SelectiveContent module execution includes the following steps:
1. Copy wcRehost.jar on the target Windchill system at <WT_HOME>/lib
directory to facilitate the copying process.
2. Start Windchill using a standard Java call.
3. Run Rehost utility with SelectiveContent module.
4. When the copying is complete, stop Windchill using a standard Java call.
5. Remove wcRehost.jar that was copied on the target Windchill system.

Rehost Utility Configuration Details 95

Required Properties
Before executing SelectiveContent, values for the following properties must be set
in the rehost.properties file that is specified when running the Windchill
Rehost Utility:
target.wc.password
target.wc.username
target.fv.required=false
staging.fv.path.<n>
target.fv.path.<n>
target.content.assembly.filename.<n>
target.content.assembly.version.<n>
target.content.assembly.configspec.<n>
target.content.assembly.includeAllDependencies<n>
target.content.assembly.viewables.<n>
target.content.assembly.drawings.<n>
target.content.assembly.includeAllFamilyTables.<n>
target.content.assembly.includeimage.<n>
target.content.assembly.includesource.<n>
target.content.metadata.unselectedAssemblies.<n>
For property details, see File Vault Settings on page 120 and Selective Content
Settings on page 131.

Vault
Use the Vault module to update file vault mounts on the target system and, either
copy file vault content to the target system or create stub files. Whether vault
content is copied depends on the setting of the target.fv.required
property and the settings of *.fv.path properties.
Running the Vault module completes the following steps on the target system:
1. Reconfigure vault mounts.
2. Validate the mounts.
3. The next step depends on whether the mounts are valid:
• When a mount is valid, the module completes one of the following:
○ Copy content from the directories that have been specified for that
mount when target.fv.required=true.
○ Generate empty stubs for the files in those same directories when
target.fv.required=false.

96 Rehost Utility Guide

 Note
The user who runs the utility must have permission to create the target
directories. If the user does not have the required permissions, the
Vault module fails.

• When a mount is not valid, the module generates an error that is displayed
at the console and is entered into the log file. No file content or stub files
can be created for the mount when it is not valid.
Check your target system setup and the rehost property values to determine
the issue. After fixing the issue, rerun the Vault module so that it can
complete successfully.
For additional information about copying vaulted content to the target system see
Copying Content from Source to Target Using Vault on page 122.
For additional information about generating empty stubs on the target system, see
Creating Stub Files on Target Using Vault on page 124.
To include only selected file content on a target system, execute both the Vault and
SelectiveContent modules as describe in SelectiveContent on page 95.

Required Properties
Before executing Vault, values for the following properties must be set in the
rehost.properties file that is specified when running the Windchill Rehost
Utility:
source.fv.path.<n>
staging.fv.path.<n>
target.fv.path.<n>
target.fv.required
source.fv.hostname.<n>
target.fv.hostname.<n>
target.db.*
For property details, see File Vault Settings on page 120.

Rehost Utility Configuration Details 97

WVSAgent
When there has been a change to the host name of the system where WVS
workers are located, use the WVSAgent module to configure the Windchill
Visualization Services agent configuration file agent.ini that is on your target
system.

Note
Running the WVSAgent module only updates the host name. It assumes that
the source and target environments have the same path to the worker start file
(such as proeworker.bat) and that the workers in both environments are
set up to use the same worker ports, user names, and passwords (needed for
ftpuser).

When WVS workers are located on Windchill cluster nodes or file servers and
there is a change in Windchill host names, you must run WVSAgent on all target
Windchill hosts in the environment.

Note
Do not run the WVSAgent module on the system where workers are installed.
When there is a change in the host name of the Windchill system, please
manually update the start files of workers with updated Windchill server
hostname.

Required Properties
Before executing WVSAgent, values for the following properties must be set in
the rehost.properties file that is specified when running the Windchill
Rehost Utility:
target.wt.home
source.worker.host.<n>
target.worker.host.<n>
For property details, see Windchill Path Settings on page 114 and WVS Agent
Settings on page 139.

98 Rehost Utility Guide

Rehost Utility Configuration Details 99
WVSWorker
When there has been a change to the host name of the system where Windchill is
installed, use the WVSWorker module to configure the worker start file so that it
points to the updated target Windchill system host name. The host name can only
be changed in one CMD file at a time. To change host names in multiple CMD
files, run the WVSWorker module multiple times with the correct properties set
for each run.
• When the host name has been changed and there are connected WVS workers
(on the same system as Windchill ), use a separate rehost utility Rename
scenario to run the WVSWorker module. For example, set the following in
project.properties:
rename.worker=WVSWorker

Then in a unique rehost.properties file created for each run, include

the rehost.useCase property set to rename.worker.
• When the Windchill host name has changed and there are connected WVS
workers (either on the same system as Windchill or on other systems), use a
separate utility Rehost scenario to run the WVSWorker module on each
system. For example, set the following in project.properties:
rehost.worker=WVSWorker

Then in a unique rehosting.properties file created for run, include

the rehost.useCase property set to rehost.worker.

100 Rehost Utility Guide

Required Properties
Before executing WVSWorker, values for the following properties must be set in
the rehost.properties file that is specified when running the Windchill
Rehost Utility:
wvs.worker.command.file
wvs.source.worker.host
wvs.target.worker.host
wvs.source.worker.port
wvs.target.worker.port
For property details, see WVS Worker Settings on page 138.

Windchill Performance Advisor (WPA)

The Windchill Performance Advisor (WPA) module is designed to automatically
collect and send diagnostic data to PTC after rehosting a Windchill environment.
If the WPA module is listed in the project.properties file as a default task
for a scenario, the RehostWAUtility is executed for that scenario. By default,
WPA is specified in the project.properties file for Clone and Rehost
scenarios.
If you are using the Rename scenario or Move scenario to set the target
environment while the source server is running, add ‘WPA’ in the
project.properties file for the respective scenarios manually.

RehostWAUtility
The Windchill Performance Advisor Utility, also known as RehostWAUtility,
checks if a repository with the name PTC_WNC_Internal exists. If it exists,
Windchill Performance Advisor (WPA) updates the record in the database table. If
not, it generates a new record in table automatically. The record helps to identify
the Windchill server that is running.

Optional Properties
Before executing Windchill Performance Advisor, set value for the following
property in the rehost.properties file that is used when running the
Windchill Rehost Utility:
target.wpa.guid=WPA.myCompany.com
If the Windchill Performance Advisor Utility is executed without setting the above
property, a default value is assigned as the GUID for the repository.

Rehost Utility Configuration Details 101

Windchill Bulk Migrator (WBM)
The Windchill Bulk Migrator (WBM) module automatically propagates the
designated properties after rehosting a Windchill environment. If this module is
listed in the project.properties file as a default task for a Rehost scenario,
the Windchill Bulk Migrator configuration is executed for that scenario.
Windchill Bulk Migrator is an optional module.

Required Properties
target.wbm.stg.db.url
target.wbm.stg.db.type
target.wbm.stg.db.user
target.wbm.stg.db.password
target.wbm.stg.db.protocol
target.wbm.stg.db.sourceOption

Optional Conditional Properties

target.wbm.stg.db.nameList
target.wbm.stg.db.valueList
target.wbm.stg.db.optionalModules

Note
• You need to configure the optional properties
target.wbm.stg.db.nameList and
target.wbm.stg.db.valueList only when the value of the
required property target.wbm.stg.db.protocol is set to tcps.
• You need to configure the optional property
target.wbm.stg.db.optionalModules only when the value of
the required property target.wbm.stg.db.sourceOption is set to
Optional, else you can leave it blank.

Rehost Property Descriptions

Each time you run the Windchill Rehost Utility, a property file is required which
specifies properties used in the rehost activities performed by the utility.
PTC provides the rehost.properties sample file to use as a template for
site-specific configuration property files. The rehost.properties sample
file is located in the conf directory where the Windchill Rehost Utility is
installed.

102 Rehost Utility Guide

The lines in the property file that start with # are considered comments and are not
processed by the utility. All other lines in the file are considered lines that define
rehost properties and must use the following format:
<property_name>=<property_value>

Note
• When entering property values in the configuration property files, it is not
necessary to escape colon and backslash characters with \.
If an equal sign is used in a property value, the equal sign in the property value
can but does not need be escaped using the backslash character. For example,
either of the following is processed correctly:
target.ldap.username=cn\=Manager
target.ldap.username=cn=Manager

• If the ldap username contains a space in it (especially in case of OpenLDAP),

provide the property value in the following format:
For example, username is 'Directory Manager',
Windows platform:
target.ldap.username=cn="Directory Manager"

Linux platform:
target.ldap.username=cn=Directory Manager

The configuration properties needed for a rehost scenario are determined by the
modules included in a specific scenario (as defined in the
projects.properties file). For a list of required properties by module, see
Rehosting Module Descriptions on page 76.
For examples that show the use of a specific set of properties, see Rehosting
Scenarios on page 140.
The following sections describe the properties that can be set, grouping the
properties according to the organization in the rehost.properties sample
file.

Rehost Utility Configuration Details 103

 Note
In the guide, rehost.properties is used as the name of the property file
where rehost scenario configuration properties are set. Determine the name of
the actual file when you create it and specify the file path to the file when you
run the utility.

104 Rehost Utility Guide

Properties Used By All Modules
There are several properties that are used by all modules.
rehost.useCase
Identifies the rehost scenario being executed. The value of the
rehost.useCase property must match the name of a scenario property that
is set in projects.properties. For details on the scenario property
format, see Editing Contents of projects.properties on page 63.
For example, if you set rehost.useCase=rename.test, then the
modules executed are identified in the rename.test property in
projects.properties.

Note
Specify one, and only one, rehost.useCase property in each
rehost.properties file.

rehost.keystore.clear
Removes any rehost related values from the Windchill keystore when a
scenario is successfully completed.
rehost.log.passwords
Logs raw command calls. This leaks plaintext passwords to the log, but is
useful for troubleshooting.
test.prop.values.only
Validates the properties file to see if all required values have been set for the
selected modules, without making any changes.

Rehost Utility Configuration Details 105

LDAP Settings
Properties that start with target.ldapare used to set the target IEConf
information that is needed when running the Windchill Rehost Utility.
Before running utility modules that update IEConf, the IEConf entries on the
target system must be the same as those on the source system. If needed, copy the
IEConf folder to the target system.
Additionally, the source.ldap.serviceName property identifies the source
system alias if an alias is being used.
The following settings must be valid when running the utility to complete many
rehost scenarios. Use these properties without any suffix to refer to the default
LDAP repository.
Additional Adapters
By default, the target.ldap.* properties will be applied to all adapters in the
system, including those for external LDAP servers that may not need to change.
All target.ldap.* properties can also be given a .<suffix> to apply them
to specific JNDI adapters in the system:
• .<adaptername>—property change is applied to the specific JNDI
adapter; for example,
target.ldap.hostname.com.mydomain.corpldap=
mycorpldap.mydomain.com sets the hostname in the LDAP URL for the
JNDI adapter com.mydomain.corpldap to
mycorpldap.mydomain.com.
If the source system has JNDI adapters for external LDAP servers then any values
that do not match the target Windchill DS must be explicitly set using
target.ldap.*.<adaptername> properties; for example:
• target.ldap.hostname.<adaptername>
• target.ldap.port.<adaptername>
• target.ldap.scheme.<adaptername>
• target.ldap.username.<adaptername>
• target.ldap.password.<adaptername>
source.local.domain
Set source.local.domain during a rehost if the target environment is
configured for an Info*Engine serviceName that is different from the source
serviceName. This is common when Windchill has been configured to use an
alias hostname for the URL. On the source server and target systems, check
<Windchill>\WEB-INF\ie.properties If the host/domain name in
the .namingService.directoryProvider property does not match
the same host/domain name in ie.properties on the target system then
set source.local.domain to the source value. For example:

106 Rehost Utility Guide

 Source: com.domain.serveralias1.namingService.directoryProvider
Target: com.domain.serveralias2.namingService.directoryProvider
source.local.domain=serveralias1.domain.com
target.ldap.hostname
The fully qualified host name of the target LDAP directory server. The fully
qualified name is required so that the JNDI adapters can be properly
reconfigured. When reconfiguring JNDI adapters, this host name is assigned to
this host name is assigned to all JNDI adapters, including those for external
LDAP servers (for more information, see “Additional Adapters” in the “LDAP
Settings” section of this guide).
target.ldap.username
The distinguished name of a user who has write privileges on the target LDAP
directory server.
target.ldap.password
The password of the user identified in the target.ldap.username
property.
target.ldap.port
The port number on which the external LDAP listens for requests. By default,
the port number is 389.
target.ldap.IEConfDir
Provides IEConf parent folder location of the target system. This is an optional
property. By default, it locates the IEConf folder in the <WT_Home>. You can
use this property when there is change in the path on the target system after
Rehost.

Rehost Utility Configuration Details 107

target.ldap.serviceName
This property controls the value of wt.rmi.server.hostname and the
Info*Engine service name / LDAP structure. This property should be set as
follows:
• Monolithic server accessed using its fully qualified hostname in the
Windchill URL
○ Set target.ldap.serviceName to the fully qualified hostname
• Monolithic server accessed using an alias hostname in the Windchill URL
○ Set target.ldap.serviceName to the alias hostname
• Windchill Cluster accessed using an alias hostname in the Windchill URL
○ Set target.ldap.serviceName to the alias hostname

Note
If the ie.ldap.serviceName property is explicitly set in
<Windchill>\codebase\WEB-INF\
ieStructProperties.txt on the target, then it must either be unset,
or set to the same value used in target.ldap.serviceName. If
ie.ldap.serviceName is set to a different hostname. then, it may
cause problems starting or running Windchill. For more information, see
target.ldap.*.

target.ldap.scheme
Set or change the protocol (LDAP or LDAPS) for the target LDAP server; for
example, target.ldap.scheme.<adaptername>=ldap.

Properties for multiple source and target values:

The following set of properties are useful in a rehosting process where the source
system has multiple entries in the IE configuration of Windchill. In such cases,
you can use this set of properties to define entries of source and target values in
rehost.properties file.
source.host.domain.<n>
Configure this property in the rehost.properties file to define the
source host values that will be replaced with target host values during the
rehosting process. For each source.host.domain.<n> entry, there must
be a corresponding target.host.domain.<n> entry in the
rehost.properties file, where <n> is the host number. Use 0 for the
first host, 1 for the second host, and so on.

108 Rehost Utility Guide

target.host.domain.<n>
Configure this property with source.host.domain.<n> property in the
rehost.properties file to update the target host values that will be
replaced on a target environment.

Note
The above set of properties are optional. However, configuring the
source.local.domain property in the rehost.properties file is
mandatory.

Rehost Utility Configuration Details 109

Rehost Additional Adapters
PTC supports rehost for any adapter that is built using the ptcInfoEngineAdapter
class. The following adapters are supported for rehost:
• JNDI Adapter
• JDBC Adapter
• SAP Adapter
• Gateway
• Windchill Adapter
• RMAdapter
• Generic Adapter

110 Rehost Utility Guide

Changing Additional Adapters
In addition to the target.ldap.<parameter>.<adapterName>
properties in the previous section, these properties can be specified to modify
additional adapters:
target.ldap.renameAdapter.<adapterName>=
<new.adapterName>
Changes the name of the specified adapter. For more information, see
“Additional Adapters” in the “LDAP Settings” section of this guide.
target.ldap.setAdapterAttributes.<adapterName>
Changes the attributes for the specified adapter. Use the equal sign (=) to
equate each property and value. To specify multiple adapter properties and
values, separate each property and value pair using (NEW_PARAM).
For example:
target.ldap.setAdapterAttributes.com.domain.myAD
=com.domain.myAD.windchill.mapping.user.filter=
someGroupDN(NEW_PARAM)com.domain.myAD.dsaCredentials
=myPassword
Values of existing properties can be changed, or new properties added. The
property is used to configure ADS adapter configuration.
target.ldap.deleteAdapter.<adapterName>=<true\false>
If set to true, the specified adapter is removed.

Rehost Utility Configuration Details 111

Database Settings
Properties that start with target.db are used to set the target database
information needed when running the Windchill Rehost Utility. These settings
must be valid when running the utility as part of any rehost scenario.
The following properties can be set:
target.db.hostname
The fully qualified host name of the target database server.
target.db.port
The port number on which the database listens for requests.
target.db.serviceName
For Oracle, use the Oracle System Identifier (SID) given to the database when
it was created. The Oracle default name used is "wind".
For SQL Server, use the Named Instance that was defined when you created
the database.
target.db.url
This property can be used to connect to the database, specifically added to
connect to PDB database. This property is only used for connection.
However , target.db.port, target.db.serviceName,
target.db.HostName properties will still remain mandatory for database
module in order to change their values or persist the existing values in wt.
properties and db.properties files.
target.db.username
The user name created for Windchill when the database was created.
target.db.password
The password of the user identified in the target.db.username property.
target.db.vendor
The database vendor for the target database. Specify:
• oracle for an Oracle database
• microsoft for a Microsoft SQL Server database

Note
Both source and target database platforms must be the same.

When the database specified is a Microsoft SQL Server database, a valid value
for the target.db.jdbc.database property is required.

112 Rehost Utility Guide

target.db.jdbc.database
When the target database is a Microsoft SQL Server database
(target.db.vendor=microsoft), set the
target.db.jdbc.database property to the database name that is used
when Windchill creates JDBC connections. The utility then uses this value to
update the wt.pom.jdbc.database property on the target system.

Rehost Utility Configuration Details 113

Windchill Path Settings
Windchill path settings identify where Windchill and Apache are installed on the
target system and identify the path to the java.exe file used by Apache.
These settings must be valid when running the utility as part of most rehost
scenarios.
Include values for the following properties:
target.wt.home
The fully qualified file path to the Windchill installation directory.
target.directory.httpserver
The fully qualified file path to the Apache installation directory. In Windchill
10.2, the Apache web server is named PTC HTTP Server (powered by
Apache) and the default installation directory is HTTPServer.
target.httpserver.port
The port number on which Apache or PTC HTTP Server listens for requests.
By default, the port number is 80.
target.httpserver.ssl.port
The port number on which Apache or PTC HTTP Server listens for SSL
requests. By default, the port number is 443.
This property is only required if you have set up SSL.
target.directory.java
The fully qualified file path to the Java directory containing the java.exe
file that is used by the Windchill JAVA_HOME directory.

114 Rehost Utility Guide

Host Settings
The host settings identify the rehost scenario being executed and specific source
and target information that is needed when executing some rehost modules. Read
the description for each property to identify when the property is required.
Include values for the following properties:
target.wc.hostname
The fully qualified host name of the target Windchill server.
This property is always required.
When rehosting a cluster, enter the cluster name that will be used on the target
cluster.
source.wc.webapp, target.wc.webapp
The old and new web application name. Both are required to update the name.
target.wc.username, target.wc.password
The windchill administrative username and password—this is only needed for
modules that access a running Method Server:
SelectiveContent

Rehost Utility Configuration Details 115

Cluster Settings
These settings specify target system information for rehosting a cluster source
system.
cluster.main.gateway
The fully qualified host name of the actual target main host. This property sets
the Windchill property wt.cache.main.hostname on the target system.
Windchill 10.0, Windchill 10.1
Set this property to the fully qualified hostname of the main node in the
cluster.
Windchill 10.2, Windchill 11.0
Set this property depending on the required configuration of the target cluster:
• All nodes will be main nodes:
○ If the source server has an empty wt.cache.main.hostname:
Do not set or specify cluster.main.gateway in
rehost.properties.
wt.cache.main.hostname will be left as-is on the target.
○ If the source server has one or more hosts defined in
wt.cache.main.hostname:
Set cluster.main.gateway to one or more hosts appropriate for
the target environment.
Update wt.cache.main.hostname to a null value manually after
the rehost.
• Specific nodes will be main nodes:
cluster.main.gateway=<Hostname1>, <Hostname2>
• Single node will be main node:
cluster.main.gateway=<Hostname1>
cluster.secondary.hostnames
The fully qualified host names of the actual target secondary nodes in a
cluster. Separate multiple secondary host names using a comma (,).
cluster.secondary.rehost
Determines whether rehost activities ignore IEConf and database data on
target cluster nodes.
Set this property to true to avoid changes to IEConf and database data.
If the property is not set or set to false, IEConf data can be rehosted using
the InfoEngine module and database data can be rehosted using the Database
module.

116 Rehost Utility Guide

 When rehosting a node that is set up as cluster secondary node, set this
property to true.
When rehosting clusters where the Windchill release is 10.2 or later and the
environment is set up so that more than one node can become the main node,
set the cluster.secondary.rehost property to false when rehosting
the first node in the cluster and then set cluster.secondary.rehost to
true when rehosting all other nodes.

Rehost Utility Configuration Details 117

Installation Registry Settings
The installation registry settings set the target and source PTC Solution Installer
(PSI) directory.
target.directory.base
The full directory path to the PSI directory on the target Windchill system.
The PSI base path for Windchill 10.0 and later systems usually ends with
"PSI".
Windows example:
target.directory.base=d:\ptc\Windchill_10\PSI

UNIX and Linux example:

target.directory.base=/.ptc/Windchill_10/PSI

source.directory.base
The full directory path to the PSI directory on the source Windchill system.
The PSI base path for Windchill 10.0 and later systems usually ends with
"PSI".
Windows example:
source.directory.base=d:\ptc\Windchill_10\PSI

UNIX and Linux example:

source.directory.base=/.ptc/Windchill_10/PSI

Additional Settings For PSI

Clone Scenario
• If the target system does not have a Windchill product installed or if there
is no Windchill registry folder present on the target machine, then use
existing copy module or manually copy the below directory on target
machine:
For example on Linux,
staging.directory.0=<homedir>/.ptc/windchill
target.directory.0=<homedir>/.ptc/windchill
For example on Windows,
staging.directory.0=<homedir>\AppData\Roaming\PTC\
Windchill

118 Rehost Utility Guide

 target.directory.0=<homedir>\AppData\Roaming\PTC\
Windchill
• If the target system has Windchill installation, then copy Windchill
instance entry which is being rehosted from the file psi_iir_
index.xml of the source machine and add it into the file psi_iir_
index.xml of the target machine.
Example,
<Instance id="ii72e8818e.158f1e73cd6.-8000" location=
"D:\ptc\Dresden\PSI"/>
Move Scenario
• Moving to different machine (No change in platform) - Use settings as
explained for clone scenario.
• Moving to different directory - Run ChangeHome module. See Change
Home on page 79
• Moving to different machine (Platform change) - No additional settings are
required.
Rename and Rehost Scenarios
No additional settings are required.

Rehost Utility Configuration Details 119

File Vault Settings
The file vault settings set the source, staging, and target paths to vault content and
determine whether vault content is copied to the target system. These settings are
required when the Vault module is run.
To rehost vaults, consider the following:
• The rehost process assumes that the entire structure under the each vault folder
mount location (actual storage location) is the same on the source and target
systems.
• With the Windchill Rehost Utility, you can change target folder mounts. The
utility makes all required changes for the new mount locations.
• The following properties must be configured based on the mounts points for
each vault:
○ For vaults with root folders
Create a source/staging.target.fv.path.<n> set of
properties for the mount path for each root folder only
○ For vaults without root folders
Create a source/staging.target.fv.path.<n> set of
properties for the mount path for each folder in the vault
source.fv.path.<n>
The full directory path to the directory where files in a file vault are stored on
the source system.
Specify a source.fv.path.<n> property for each file vault on the source
system, where <n> is the number of the vault. Use 0 for the first vault, 1 for
the second vault, and so on. The Vault module uses the source vault paths that
are set in these properties to locate the source folder mount information that is
stored in Windchill Site ▶ File Server Administration ▶ Vault Configuration.
For each source.fv.path.<n> property, there must be a corresponding
target.fv.path.<n> property and, in some cases, a corresponding
staging.fv.path.<n> property. For additional information, see the description
of target.fv.required later in this list of properties.
The staging and target directory structure can be the same or different from the
source directory structure. For example, the following properties show
different directories:
source.fv.path.0=d:\abc
source.fv.path.1=d:\abc1
staging.fv.path.0=d:\stagabc
staging.fv.path.1=d:\stagabc1
target.fv.path.0=d:\newabc
target.fv.path.1=d:\newabc1

120 Rehost Utility Guide

staging.fv.path.<n>
The full staging area directory path where the content of the source files in a
file vault are stored. These directories must be accessible from the target
system.
To copy content from a staging area to the target system, these properties are
required. Specify a staging.fv.path.<n> property for each file vault on
the staging area, where <n> is the number of the vault. Use 0 for the first
vault, 1 for the second vault, and so on.
Empty stub files can be created without copying content. In this case, it is not
necessary to specify vault properties, the required vaulting information is read
from the database.
For each staging.fv.path.<n> property specified, there must be
corresponding target.fv.path.<n> and source.fv.path.<n>
properties. If a set of staging.fv.path.* properties is not specified, the
default staging paths are taken from set of source.fv.path.* properties.
The source and target directory structure can be the same or different from the
staging directory structure. For example, the following properties show
different directories:
source.fv.path.0=d:\abc
source.fv.path.1=d:\abc1
staging.fv.path.0=d:\stagabc
staging.fv.path.1=d:\stagabc1
target.fv.path.0=d:\newabc
target.fv.path.1=d:\newabc1

target.fv.path.<n>
The full directory path to the directory where files in a file vault will be stored
on the target. The Vault module uses this vault information when creating the
target directories and updating the folder mount information stored in
Windchill Site ▶ File Server Administration ▶ Vault Configuration.

Note
The user who runs the utility must have permission to create the target
directories.

For each target.fv.path.<n> property, there must be a corresponding

source.fv.path.<n> property and, possibly, a corresponding
staging.fv.path.<n> property. For additional information, see the
description of target.fv.required later in this list of properties.

Rehost Utility Configuration Details 121

 The staging and source directory structure can be the same or different from
the target directory structure. For example, the following properties show
different directories:
source.fv.path.0=d:\abc
source.fv.path.1=d:\abc1
staging.fv.path.0=d:\stagabc
staging.fv.path.1=d:\stagabc1
target.fv.path.0=d:\newabc
target.fv.path.1=d:\newabc1

target.fv.required
Controls the module behavior related to copying file vault content. The value
of the property determines whether content is copied from a staging area to the
target system. Specify either true or false:
• True—Allows the module to copy source vault content from a staging
area to the target system.
For additional details, see Copying Content from Source to Target Using
Vault on page 122.
• False—Does not allow the module to copy file vault content. Instead,
the module generates empty stub files. The main use case for generating
stub files is to replicate a system for testing that does not need the actual
file content. This rehosted target system requires less disk space.

Note
For remote file servers, the creation of stub files through the Windchill
Rehost Utility is not supported.

For additional details, see Creating Stub Files on Target Using Vault on
page 124.
To save disk space on the target system and significantly reduce the time it
takes to run the utility, specify false when vault content is not required.

Copying Content from Source to Target Using Vault

Note
The following discussion assumes that the following property is set:
target.fv.required=true

122 Rehost Utility Guide

Use the Windchill Rehost Utility to copy content from a source system to a target
system in a monolithic environment and in an environment set up on main and
remote file servers. To copy content from a source system to a target system, the
utility must have access to a staging area. After the staging area is set up with
content, set the staging.fv.path.* properties to identify path locations
from which content will be copied and target.fv.path.* properties to
identify the final location of the copied data on the target system.
There are many possible property configurations. The following table presents the
intended behavior for certain use cases. The following items explain the
information in the table:
• The Case column shows the relationship between the property values for
source.fv.path.*, staging.fv.path.*, and
target.fv.path.*. For example source ≠ staging indicates that the
source.fv.path.* properties are not the same as the
staging.fv.path.* properties.
• The Staging Content? column indicates whether there is content stored in the
directories that are identified by staging.fv.path.*.
• The Description column describes the availability of the content to be copied.
• The Behavior column provides details on what happens when the utility is
run.
Staging
Case Content? Description Behavior
source ≠ staging No No content is available Error. Rehost Utility
≠ target in any location must have access to
content.
source ≠ staging Yes Source content copied to Content will be copied
≠ target staging location from staging to target.
source ≠ staging No No content is available Error. Rehost Utility
= target in any location must have access to
content.
source ≠ staging Yes Source content copied to Content will not be
= target target location copied as it is already
in target.
source = staging No No content is available Error. Rehost Utility
≠ target in any location must have access to
content.
source = staging Yes Source directory is used Content will be copied
≠ target as staging location from source to target.

Rehost Utility Configuration Details 123

Creating Stub Files on Target Using Vault

Note
The following discussion assumes that the following property is set:
target.fv.required=false

The Windchill Rehost Utility can be used to create stub files a target system in a
monolithic environment or an environment set up for a main server.

Note
PTC does not support the use of the Windchill Rehost Utility to create stub
files on a remote file server site because stub file creation requires database
access, which remote file servers do not have.

To create stub files in a monolithic environment or on a main site, the Vault

module must:
• Obtain the source vault information (supplied in the source.fv.path.*
properties).
• Obtain the target vault information (supplied in the target.fv.path.*
properties).
• Identify which stub files need to be created.

124 Rehost Utility Guide

There are many possible property configurations. The following table presents the
intended behavior when the target.fv.required property is set to false
for the same set of use cases described in Copying Content from Source to Target
Using Vault on page 122.
Staging
Case Content? Description Behavior
source ≠ staging ≠ No No content is Stub files will be
target available in any generated.
location
source ≠ staging ≠ Yes Source content Stub files will be
target copied to staging generated. Staging
location content is ignored.
source ≠ staging = No No content is Stub files will be
target available in any generated.
location
source ≠ staging = Yes Source content Stub files will be
target copied to target generated. Staging
location content is ignored.
source = staging ≠ No No content is Stub files will be
target available in any generated.
location
source = staging ≠ Yes Source directory is Stub files will be
target used as staging generated. Staging
location content is ignored.

Rehost Utility Configuration Details 125

User-defined Script Settings
The user-defined script settings are entered in properties and identify any scripts
that execute user-defined modules for a rehost scenario.
Each property identifies one script to execute. Use the following format for the
property and its value:
script.<module_name>=<script_file_name>

where:
• <module_name> is a unique module name. The name must match the name
entered on the Script entry specified on the corresponding
<scenario>.<variant> property in the projects.properties file.
• <script_file_name> is the file name of the script to use in this module.
The script file must reside in the scripts directory where Windchill Rehost
Utility is installed.
For example, to use a database import script named dbimp.sh in the scripts
directory, as a module named dbimport, in a scenario named rehost.test,
complete the following activities:
• Add the following property to the configuration property file that will be used
to execute the rehost scenario (such as conf\rehost_to_
test.properties):
script.dbimport=dbimp.sh

• Add the user-defined module identified as script.dbimport to the

projects.properties rehost.test property:
rehost.test=…,Script:dbimport,…

Save any changes, then execute the rehost scenario on a Windows system by
opening a command prompt, navigating to the directory where Windchill Rehost
Utility is installed, and entering:
rehost.bat conf\rehost_to_test.properties

The dbimport module is then executed along with all other modules in the order
specified in the rehost.test property.

126 Rehost Utility Guide

Copy Settings
The Copy property settings identify directories on a staging area that then can be
copied to specified directories on the target system. Use these property settings
when executing the Copy module.
When copying files that are in a Windchill environment, the following directories
should be specified:
• Windchill installation directory
• Java installation directory
• Web Server (Apache or PTC HTTP Server [powered by Apache] in Windchill)
• PTC Solution Installer (PSI) installation directory
There is a one-to-one correspondence between each pair of staging and the target
directories. Both the staging and target directories for a given directory type must
be set in properties for the action to happen. For example, if a staging Java
installation directory but not a target Java installation directory, then the copy is
not done.
If the target directories set for the Copy module are different from the
corresponding directories on the source system, then the installation directory is
changed while doing the copy, and the ChangeHome module is required. For
additional details, see ChangeHome on page 79.

Note
To use Windows UNC paths, an additional backslash (\) is needed to escape
the beginning of the path. For example:
staging.directory.windchill=\\\mcrsrc.src.domain\ptc\Windchill_10.2\Windchill

Include values for the following properties:

staging.directory.windchill
target.directory.windchill
The full directory path to the Windchill installation directory on the staging
and target systems.

Rehost Utility Configuration Details 127

staging.directory.httpserver
target.directory.httpserver
The full directory path to the Web Server (Apache or PTC HTTP Server
[powered by Apache] in Windchill) installation directory on the staging and
target systems.
staging.directory.java
target.directory.java
The full directory path to the Java installation directory on the staging and
target systems.
staging.directory.psiBase
target.directory.psiBase
The full directory path to the PSI installation directory on the staging and
target systems.
staging.directory.<char>
The full directory path of a directory on the staging system to be copied.
Multiple staging.directory.<char> properties can be used. For each
property, <char> is a unique set of alphanumeric characters. For example
staging.directory.custom1 could be used to identify a custom
directory, D:\PTC\CustomDirectory on your source and staging
systems. To copy the directory, set the following:
staging.directory.custom1=D:\PTC\CustomDirectory

For each staging.directory.<char> property, specify a

target.directory.<char> property that has the same alphanumeric
characters; for example, with staging.directory.custom1, also set
target.directory.custom1 to identify where the files will be copied.
target.directory.<char>
The full directory path where the directory will be copied. For each
target.directory.<char> property, there must be a corresponding
staging.directory.<char> property that has the same alphanumeric
characters for <char>.

Change Home Settings

The change home property settings identify only the properties unique to changing
configuration files to use the updated Windchill installation directory that is set
with the ChangeHome module. The complete set of properties used by
ChangeHome are listed in ChangeHome on page 79.
Include values for the following properties:
source.directory.windchill
The full directory path to the Windchill installation directory on the source
system.

128 Rehost Utility Guide

source.directory.java
The full directory path to the Java installation directory on the source system.
source.directory.httpserver
The full directory path to the Apache (called PTC HTTP Server in 10.2)
installation directory on the source system.
source.directory.psiBase
The full directory path to the PSI installation directory on the source system.

Rehost Utility Configuration Details 129

Queue Management Settings
The queue management property settings identify queues on the target system to
be controlled or cleared of queue entries. These settings are used with the
QueueMgmt module.
A group of properties performs the following:
• Identifies a queue
• Enables or disables that queue
• Retains or clears queue entries
After executing the QueueMgmt module, disabled queues are not started. When
ready, they can be started on the target system from the Site ▶ Utilities ▶ Queue
Management page.
Include values for the following properties:
rehost.queue.name.<n>
Specify the name of a queue on which the actions in other queue properties are
performed. The name is the queue name as shown on the Queue Management
page: Site ▶ Utilities on the source system.
Identify the queue in the rehost.queue.name.<n> property and then set
the other rehost.queue properties using the same number (<n>). Use
0 for the first queue, 1 for the second queue, and so on.
rehost.queue.enabled.<n>
Specify true to enable to queue or false to disable it.
By default, the queue is disabled.
rehost.queue.clear.<n>
Specify true to clear all queue entries or false to leave any existing queue
entries.
By default, all queue entries are not cleared.

130 Rehost Utility Guide

Selective Content Settings
The selective content property settings identify a set of files in vault folders in a
staging area to be copied to the target system with the SelectiveContent module.
The files that can be copied are files of type EPMDocument (CAD document).
Although the SelectiveContent module was designed and tested against
assemblies (such as *.asm and *.CATProduct), any file of type
EPMDocument (such as *.prt, *.lay, *.frm, *.CATPart, *.dwg, and so
on) can be used in the target.content.assembly.filename.*
property.
For each EPMDocument file, include information about the file content to be
copied to the target system:
• Assembly version
• Assembly configuration specification
• Assembly dependencies
• Assembly viewables
• Assembly drawings
• Assembly family tables
• Images and source that are related to the assembly
This is controlled by the following properties:
target.content.assembly.filename.<n>
The file name of a part or assembly. Default is null. This file must exist in the
staging area in one of the folders identified by the file vault property settings
for the staging area. For details, see File Vault Settings on page 120.
Identify the EPMDocument in the
target.content.assembly.filename.<n> property, where <n> is
a number. Use 0 for the first file name, 1 for the second file name, and so on.
Then set the other target.content.assembly properties using the
same number (<n>) to establish the actual settings to include for the file.

Rehost Utility Configuration Details 131

 The file names to specify are the names listed as the value of the File Name
field. For example:

One option is to use an export action available from the Folders Actions menu
on the source system to create a file with the names (and other details) of the
objects in a given folder. Using the file, populate
target.content.assembly.filename.<n> properties for those files
to be included as content on the target system.
target.content.assembly.version.<n>
Specify the version number associated with the file.
If not specified, the latest version is used. Default is “Latest”.
target.content.assembly.configspec.<n>
Specify one of the following configuration specification settings:
• As Stored (default)

Use the As Stored value to keep the configuration specification as it is on

the source system. To change the configuration specification to be
something other the default, include this property with the value you want
set.
• Latest
• Latest|<state> (for example, Latest|In Work)
• Baseline|<number> (for example, Baseline|0001
• Promotion|<number> (for example, Promotion|0001

132 Rehost Utility Guide

target.content.assembly.includeAllDependencies.<n>
If true, all dependencies will be included, otherwise only required
dependencies.
To include all dependencies instead of just required dependencies, set this
property to true. Default is false.
target.content.assembly.viewables.<n>
Decide whether to include the viewable:
• Enter true to include the viewable.
• Enter false not to include the viewable. (default)
target.content.assembly.drawings.<n>
Decide whether to include drawings:
• Enter true to include drawings.
• Enter false not to include drawings. (default)
target.content.assembly.includeAllFamilytables.<n>
If true, all family tables will be included, otherwise only selected family
tables.
To include all family tables instead of just the selected family tables set on the
source system, set this property to true. Default is false.
target.content.assembly.includeimage.<n>
Decide whether to include image business objects that are related to the
assembly:
• Enter true to include all related image business objects.
• Enter false not to include the related image business objects. (default)

Rehost Utility Configuration Details 133

 The image business objects included are those that can be gathered when
moving objects on a Windchill system. For example, when collecting objects
to move, select Image from the window that opens after selecting the
Advanced collection option.

target.content.assembly.includesource.<n>
Decide whether to include source business objects that are related to the
assembly:
• Enter true to include all related source business objects.
• Enter false not to include the related source business objects. (default)

134 Rehost Utility Guide

 The source business objects included are those that can be gathered when
moving objects on a Windchill system; for example, when collecting objects
to move, select Source from the window that opens after selecting the
Advanced collection option.

target.cleanup.metadata.unselectedAssemblies<n>
Specifies the flag for cleaning up metadata for the unselected assemblies.
Default value is false.
When set to true, cleans up the metadata for unselected assemblies from
Windchill.

Rehost Utility Configuration Details 135

Solr Settings
Include values for the following properties:
target.solr.host
The host name of the system where Solr is installed in the target environment.
The rehost utility uses the value of target.solr.host to set the value of
wt.solr.host in wt.properties.
target.solr.port
The port number used for Solr Server in the target environment. The rehost
utility uses the value of target.solr.port to set the value of
wt.index.solrPort in wt.properties.
target.authTrustedHosts
Set the following property to add the host on which Solr is running as a trusted
host in Windchill. This is required to allow Solr to download content from
Windchill. The rehost utility uses the value of
target.authTrustedHosts to set the value of
wt.authTrustedHosts in wt.properties.
target.solr.solrEffectiveUid
Set following property to specify the user used by Solr for Windchill
authentication when it downloads the content from Windchill. The rehost
utility uses the value of target.solr.solrEffectiveUid to set the
value of wt.index.solrEffectiveUid in wt.properties.
target.solr.zookeeperhost
The rehost utility uses the value of target.solr.zookeeperhost to set
the value of wt.index.zookeeperHosts in wt.properties. This
property is used if Solr server is installed on cloud environment.
target.solr.oncloud
The value of this property can be set to "YES" or "NO" based on Solr server
location. If it is on cloud set the value to "YES" else "NO". The default value
is "NO".
The value given for property target.solr.zookeeperhost is only
updated when the value of target.solr.oncloud is set to “YES".

136 Rehost Utility Guide

Rehost Utility Configuration Details 137
WVS Worker Settings
The module configures the content in the start file named in the
wvs.worker.command.file property. Only one start file can be configured.
wvs.worker.command.file
Full file path to the WVS (Windchill Visualization Services) worker start file
to configure.
Only configure one start file. Each supported CAD worker has a unique file
that is used to start the worker. For example:
• The Creo (Pro/Engineer) worker start file is proeworker.bat.
• Unigraphics worker start file is ugworker.bat.
Locate the start file and specify the full path to the file as the value for this
property.
wvs.source.worker.host
Host name of the source system that has the WVS workers to be identified in
the start file.
wvs.target.worker.host
Host name of the target system that has the WVS workers to be identified in
the start file.
wvs.source.worker.port
Port number used to communicate with the source system that has the WVS
workers to be identified in the start file.
wvs.target.worker.port
Port number used to communicate with the target system that has the WVS
workers to be identified in the start file.

138 Rehost Utility Guide

WVS Agent Settings
Running the WVSAgent module requires setting the following properties in
rehost.properties.
The module configures the content of the agent.ini file on the target system
using the information provided in the properties specified. The file is located in
the <Windchill>/conf/wvs directory, where <Windchill> is the
Windchill installation directory.
source.worker.host.<n>
Host name of the source system that has WVS (Windchill Visualization
Services) workers.
Specify a source.worker.host.<n> property for each source system
where WVS workers reside, where <n> is an integer that identifies the
property as part of a group of properties. For each
source.worker.host.<n> property, there must be a corresponding
target.worker.host.<n> property with the same integer.
target.worker.host.<n>
Host name of the target system that will has the WVS workers that correspond
to the set of workers on the source system that is named in the
source.worker.host.<n> property with the same integer.

Rehost Utility Configuration Details 139

 6
Rehost Scenario Examples
Rename Scenario Example...................................................................................... 141
Rehost Scenario Example........................................................................................ 145
Rehost Cluster Scenario Example ............................................................................ 150
Clone Scenario Example.......................................................................................... 163
Move Scenario Examples ........................................................................................ 168

The following sections provide detailed examples of common rehost scenarios.

The examples describe how the Windchill Rehost Utility can be used to
accomplish the rehost activities.

140 Rehost Utility Guide

Rename Scenario Example
The Rename scenario is commonly used to make host name changes on systems
that are a result of copying development virtual machines into the same network
or relocating an existing Windchill deployment on a new network.
For general information about the Rename scenario, see Rename Scenario Process
on page 21.
For general setup requirements, see Setting Up Your Rehosting Environment on
page 36.
The following sections provide a detailed example that shows how to use the
Windchill Rehost Utility to change the host name of a virtual machine that was
copied to a new host. This example changes the host name source.ptc.com to
target.ptc.com.
The assumptions for the example are listed in the next section, Rename Scenario
Assumptions on page 141, and the activities that make up the use case are
presented in Rename Scenario Activities on page 142.

Rename Example Assumptions

Platform: Windows
Windchill Environment:
• Entire Windchill 10.0 system (including Apache web server) has been
relocated to a new host on the same platform as the original host and
Windchill is not running
• The Windchill system is not a Windchill cluster
• File vault content and locations do not change . If the FileVault Host is same
as the Windchill Host, then Vault task will be required to update the FVHost
information in database.
Target Database: Same as Oracle source database (no changes required)
Target IEConf: Same as source IEConf (no changes required)
This example shows the basic set of modules that are required to change the host
name: InfoEngine, Apache, and Database. It also shows the use of user-defined
scripts that manage the environment during the run of the utility.
To complete additional activities when changing a host name, add modules to the
basic set of modules. For example:
• To move the location of file vaults, include the Vault module.
• To change the host name of a Windchill cluster, set up the utility to run on
each node and include the Cluster module in each run.

Rehost Scenario Examples 141

For additional details on the requirements and resulting changes of including
additional modules in a rename scenario, see the descriptions of the modules. For
information about modules, see Identifying Optional Activities to Include When
Rehosting on page 49.

Rename Example Activities

The following activities describe the actions needed to set up and execute this
scenario.
User-defined scripts: Create the scripts as described in User-defined Scripts for
Rename Example on page 142.
rename.example property: Set rename.example property in
projects.properties as described in rename.example Property for Rename
Example on page 142.
Configuration properties file: Create rename.properties as described in
Configuration Properties File for Rename Example on page 143. Ensure that
rehost.useCase=rename.example is set under Host Settings.
Rehost Command: Execute the rehost command as described in rehost
Command for Rename Example on page 144.

User-defined Scripts for Rename Example

To automate the rename use case, the utility must be able to start and stop Apache
and start Windchill.
Scripts for the following activities have been identified for this example use case:
Activity Script File to Use
Move existing logs and compiled modules in to a wcclear.bat
staging area for archival (optional). See wcclear.bat on page 194.
Set up in user-defined wcclear script.
Start both Apache and Windchill. Wait until windchillStart.bat
Windchill has completed startup before See windchillStart.bat on
proceeding to any additional modules. In this page 195.
example, no additional modules are run.
Set up in user-defined wc-ap-start script.

rename.example Property for Rename Example

To automate the rename example using the basic set of modules for the Rename
scenarios, set the following property in projects.properties which is in
the utility conf directory. The property setting must be on one line in the file:
rename.example=InfoEngine,Apache,Database,Script:wcclear,Script:wc-ap-start

142 Rehost Utility Guide

In this example, user-defined modules are included at the end of the list of
modules. The wcclear module is optional and backs up files before the wc-ap-start
module starts both Apache and Windchill.

Configuration Properties File for Rename Example

To automate the rename example, open the sample rehost.properties file
that is in the conf directory and set the following properties. Save the changes in
conf\rename.properties. Each property setting must be on one line in the
file.
The password properties included in this example are set to $encrypt. PTC
recommends that you encrypt passwords in configuration files for security.
### Use Case Settings ###
rehost.useCase=rename.example
rehost.keystore.clear=false
rehost.log.passwords=true
test.prop.values.only=false

### Windchill Path Settings ###

target.wt.home=D:\PTC\Windchill10\Windchill
target.java.home=D:\PTC\Windchill10\Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=wcadmin
target.db.password=$encrypt
target.db.hostname=targetdbHostname.ptc.com
target.db.port=1521
target.db.serviceName=wind

### LDAP Settings ###

target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.hostname=target.ptc.com
target.ldap.port=389
target.ldap.serviceName=target.ptc.com

### HTTPServer Settings ###

target.httpserver.port=80
target.httpserver.ssl.port=443

###Windchill Home Directories ###

target.directory.windchill=D:\PTC\Windchill10\Windchill

Rehost Scenario Examples 143

### Apache Home Directory ###
target.directory.httpserver=D:\PTC\Windchill10\Apache

### Windchill Server Hostname ###

target.wc.hostname=target.ptc.com

### User-defined Module Settings ###

script.wcclear=..\scripts\wcclear.bat
script.wc-ap-start=..\scripts\windchillStart.bat

Note
For domain name change scenario, set rename adapter properties, as
mentioned in Changing Additional Adapters on page 111.

rehost Command for Rename Example

Open a Windchill shell, navigate to the directory where the Windchill Rehost
Utility is installed, and execute the following command to run the modules that
execute the rename example:
rehost.bat conf\rename.properties

The command assumes that the configuration property file is

rename.properties (as described earlier in this example) which is in the
utility conf directory and the project.properties file (also in the conf
directory) contains the rename.example property (as described earlier in this
example).
As each module listed in the rename.example property executes, output is
displayed on the command line and entered into to a log file. Review the logs to
ensure each module completes as expected. Always check for any errors that may
have occurred.

Rename Example Execution Results

The resulting target system is the same as the source system, but with the host
name changed. This allows an existing Windchill system to run on a new host.

144 Rehost Utility Guide

Rehost Scenario Example
The following Rehost scenario example copies Windchill data from a source
system to a target system, where the system host names are different. The rehost
properties and modules that are run ensure that the new target host name is used
when accessing the data that has been copied to the target system. The resulting
target system can then run independently from the source system, but has the same
configuration as the source system.
For general information about the Rehost scenario, see Rehost Scenario Process
Information on page 22.
For general setup requirements, see Setting Up Your Rehosting Environment on
page 36.
The example requires user-defined modules to do the following:
• Stop Apache
The following sections provide the example details that show how to use the
Windchill Rehost Utility to copy Windchill 10.1 data set from a system with host
name source.ptc.com to host name target.ptc.com.
The assumptions for the example are listed in the next section, Rehost Example
Assumptions on page 145, and the activities that make up the use case are
presented in Rehost Example Activities on page 146.

Rehost Example Assumptions

Platform: Monolithic Linux environment
Windchill Environment:
• Two Windchill 10.1 systems with the same Windchill version, each on a Linux
platform using Apache web server, and a staging area that is accessible to the
rehost utility.
• Each system resides on a separate server, with databases segmented to their
own host. The target database has the data from the source database already
imported.
• Keeps the source organization name on the target system and keeps the web
application name from the source system.
• Requires no adapter configuration, such as what is needed to connect to an
enterprise directory server.
Target Database: A copy of the Oracle source database. To import the data
exported from the source database instance into the target database instance, use a
utility such as the Oracle Data Pump utility. See Exporting Database from Source
System and Importing It into Target System: Oracle on page 177.
Target IEConf: A Copy of source IEConf folder.

Rehost Scenario Examples 145

This example shows the basic set of modules that are required to perform the
rehost: InfoEngine, Apache, Database, and Vault. It also shows the use of user-
defined scripts that manage the environment during the run of the utility.

Rehost Example Activities

The following activities describe the actions needed to set up and execute this
scenario.
User-defined scripts: Create the scripts as described in User-defined Scripts for
Rehost on page 147.
rehost.example property: Set rehost.example property in
projects.properties as described in rehost.example Property for Rehost
Example on page 147.
Configuration properties file: Create rehost.properties as described in
Configuration Properties File for Rehost Example on page 148. Ensure that
rehost.useCase=rehost.example is set under Host Settings.
Rehost Command: Execute the rehost command as described in rehost
Command for Rehost Example on page 149.

146 Rehost Utility Guide

User-defined Scripts for Rehost Example
To automate the rehost use case, the utility must be able to stop and restart both
Apache and Windchill.
Scripts for the following activities have been identified for this example use case:
Activity Script File to Use
Call the Apache shutdown command. apstop.sh
Set up in user-defined apstop script. See apstop.sh on page 197.
Call the Windchill shutdown command. windchillStop.sh
Set up in user-defined wcstop script. See windchillStop.sh on
page 202.

rehost.example Property for Rehost Example

To automate the rehost example, set the following property in
projects.properties which is in the utility conf directory. The property
setting must be on one line in the file, but has been formatted to fit the page:
rehost.example=Script:apstop,Script:wcstop,InfoEngine,Apache,
Database,Vault

In this example, user-defined modules are included in the appropriate positions in

the list of modules. The Apache web server is stopped as the first module (with
apstop) and Windchill is stopped next (with wcstop).

Rehost Scenario Examples 147

Configuration Properties File for Rehost Example
To automate the rehost example, open the sample rehost.properties file
that is in the conf directory and set the following properties. Each property
setting must be on one line in the file; one setting in the example spans multiple
lines to accommodate the width of the page in the guide. Save the changes in
conf\rehost2.properties.
The password properties included in this example are set to $encrypt. PTC
recommends passwords be encrypted in configuration files for security.
### Use Case Settings ###
rehost.useCase=rehost.example
rehost.keystore.clear=false
rehost.log.passwords=true
test.prop.values.only=false

### Windchill Path Settings ###

target.wt.home=/ptc/Windchill_10.1/Windchill
target.java.home=/ptc/Windchill_10.1/Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=wcadmin
target.db.password=$encrypt
target.db.hostname=targetdbHostname.ptc.com
target.db.port=1521
target.db.serviceName=wind

### LDAP Settings ###

target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.hostname=target.ptc.com
target.ldap.port=1389
target.ldap.serviceName=target.ptc.com
source.local.domain= source.ptc.com

### HTTPServer Settings ###

target.httpserver.port=80
target.httpserver.ssl.port=443

###Windchill Home Directories ###

source.directory.windchill=/ptc/Windchill_10.1/Windchill
target.directory.windchill=/ptc/Windchill_10.1/Windchill

### Apache Home Directory ###

target.directory.httpserver=/ptc/Windchill_10.1/Apache

148 Rehost Utility Guide

### Windchill Server Hostname ###
target.wc.hostname=target.ptc.com

### FileVault Settings ###

target.fv.required=true
source.fv.path.0=/ptc/Windchill_10.1/Windchill/vaults/main_vault_folder
staging.fv.path.0=/misc/staging/vaults/main_vault_folder
target.fv.path.0=/ptc/Windchill_10.1/Windchill/vaults/new_main_vault_folder
source.fv.path.1=/ptc/Windchill_10.1/Windchill/vaults/cache_vault_folder
staging.fv.path.1=/misc/staging/vaults/cache_vault_folder
target.fv.path.1= /ptc/Windchill_10.1/Windchill/vaults/new_cache_vault_folder

### Vault Host Settings ###

source.fv.hostname.0=sourceVault.ptc.com
target.fv.hostname.0=targetVault.ptc.com
source.fv.hostname.1=sourceVault1.ptc.com
target.fv.hostname.1=targetVault1.ptc.com

### User-defined Module Settings ###

rehost.script.apstop=../scripts/apstop.sh
rehost.script.wc-ap-start=../scripts/windchillStart.sh

rehost Command for Rehost Example

Open a command prompt, navigate to the directory where the Windchill Rehost
Utility is installed, and execute the following command to run the modules that
execute the rehost example:
./rehost.sh conf/rehost2.properties

The command assumes that the configuration property file is

rehost2.properties (as described earlier in this example) which is in the
utility conf directory and the project.properties file (also in the conf
directory) contains the rehost.example property (as described earlier in this
example).
As each module listed in the rehost.example property executes, output is
displayed on the command line and entered into to a log file. After the utility is
complete, review the logs to ensure that each module completed as expected.
Always check for any errors that may have occurred.

Rehost Example Execution Results

Two Windchill systems that can run independently, but both have the same
Windchill configuration.

Rehost Scenario Examples 149

Rehost Cluster Scenario Example
The following Rehost cluster scenario example copies Windchill data from a
source clustered environment to a target clustered environment, where the system
host names are different. The rehost properties and modules ensure that the new
target host names are used when accessing the data that has been copied to the
target clustered environment. The target clustered environment can now run
independently from the source clustered environment, but has the same
configuration as the source clustered environment.
The example requires user-defined modules to do the following:
• Stop Apache
• Stop Windchill
For general information about the Rehost scenario, see Rehost Scenario Process
Information on page 22.
For general setup requirements, see Setting Up Your Rehosting Environment on
page 36.
The following sections provide the example details that show how to use the
Windchill Rehost Utility to copy Windchill 10.1 data set from the host
sourcecluster1.ptc.com to the cluster main node
targetcluster1.ptc.com and to update cluster-related properties on all
three nodes in the cluster: targetcluster1.ptc.com,
targetcluster2.ptc.com, and targetcluster3.ptc.com.
The assumptions for the example are listed in the next section, Rehost Example
Assumptions on page 151, and the activities that make up the use case are
presented in Rehost Example Activities on page 152.

150 Rehost Utility Guide

Rehost Cluster Example Assumptions
Platform: Linux environment with three cluster nodes
Windchill Environment:
• Two Windchill 10.1 clustered environments with the same Windchill version,
each on Linux servers using Apache web server, and a staging area that is
accessible to the rehosting utility.
• Each clustered environment resides on three separate servers and the source
and target databases segmented to their own host. The target database has the
data from the source database already imported.
• Keeps the source organization name in the target system and keeps the web
application name from the source system.
• Requires no adapter configuration, such as what is needed to connect to an
enterprise directory server.
Target Database: Same as Oracle source database, but its own instance. To
import the data exported from the source database instance into the target database
instance, use a utility such as the Oracle Data Pump utility. See Exporting
Database from Source System and Importing It into Target System: Oracle on
page 177.
Target IEConf: A Copy of source IEConf folder.
This example shows multiple runs of the utility. The following list shows the
utility execution order and the modules that are run during each execution:
1. Stop Apache and Windchill on the target main node, copy IEConf and run the
basic set of modules that are required to perform the rehost on the main node:
InfoEngine, Apache, Database, and Cluster.
2. On each secondary node, stop Apache and Windchill and then run the
InfoEngine, Apache, Database, and Cluster modules with
cluster.secondary.rehost=true (in this case, there are two
secondary nodes).
3. Start Apache and Windchill on the target system and run the Vault module on
the main node.

Rehost Scenario Examples 151

Rehost Cluster Example Activities
The following activities describe the actions needed to set up and execute this
scenario.
User-defined scripts: Create the scripts as described in User-defined Scripts for
Rehost Cluster Example on page 152.
rehost cluster properties: Set the rehost properties in
projects.properties as described in rehost Properties for Rehost Cluster
Example on page 152.
Configuration properties files: Create four rehost.properties files as
described in Configuration Properties File for Rehost Cluster Example on page
153. Ensure that the correct rehost.useCase setting is set under Host
Settings in each of the files.
Rehost Commands: Execute the set of rehost commands as described in rehost
Command for Rehost Cluster Example on page 161.

User-defined Scripts for Rehost Cluster Example

To automate the rehost use case, the utility must be able to stop and restart both
Apache and Windchill.
Scripts for the following activities have been identified for this example use case:
Activity Script File to Use
Call the Apache shutdown command. apstop.sh
Set up in user-defined apstop script. See apstop.sh on page 197.
Call the Windchill shutdown command. windchillStop.sh
Set up in user-defined wcstop script. See windchillStop.sh on
page 202.

rehost Properties for Rehost Cluster Example

To automate the rehost cluster example, set the following properties in
projects.properties which is in the utility conf directory. Each property
setting must be on one line in the file; the first two properties have been formatted
to fit the page:
rehost.clustermain_example=Script:apstop,Script:wcstop,Script:ldapimport,
InfoEngine,Apache,Database,Cluster
rehost.clustersecondary_example=Script:apstop,Script:wcstop,InfoEngine,Apache,
Database,Cluster
rehost.clustermain_vault_example=Vault

152 Rehost Utility Guide

In this example, user-defined modules have been included in the appropriate
positions in the list of modules. The Apache web server is stopped by the first
module (apstop) and Windchill is stopped next (with wcstop) in both the main and
secondary runs.

Configuration Properties File for Rehost Cluster Example

To automate the rehost cluster example, open the sample
rehost.properties file that is in the conf directory and set the following
sets of properties in four different files. For example:
• Set the properties for rehosting the main node of the cluster in conf\
rehost_clustermain.properties
• Set the properties for rehosting the first secondary node of the cluster in
conf\rehost_clustersecondary_first.properties
• Set the properties for rehosting the second secondary node of the cluster in
conf\rehost_clustersecondary_second.properties
• Set the properties for rehosting the main vault of the cluster in conf\
rehost_clustermain_vault.properties
Each property setting must be on one line in the file.
The password properties included in this example are set to $encrypt. PTC
recommends that passwords be encrypted in configuration files for security
purposes.

Rehost Scenario Examples 153

rehost_clustermain.properties
Use the following property settings when running the utility the first time on the
main node in the cluster:
#### Use Case Setting ###
rehost.useCase=rehost.clustermain_example
rehost.keystore.clear=false
rehost.log.passwords=false
test.prop.values.only=true

##### Windchill Path Settings ######

target.wt.home=/ptc/Windchill_10.1/Windchill
target.java.home=/ptc/Windchill_10.1/Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=wcadmin
target.db.password=$encrypt
target.db.hostname=db.local
target.db.port=1521
target.db.serviceName=wind2

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.hostname=targetcluster1.ptc.com
target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.port=1389

##### Apache Settings ####

target.httpserver.port=80
target.httpserver.ssl.port=443

#### Apache Home Directory #####

target.httpserver.home=/ptc/Windchill_10.1/Apache

#### Windchill Server Hostname ###

target.wc.hostname=targetcluster1.ptc.com

### Cluster Settings ###

cluster.main.gateway=targetcluster1.ptc.com
cluster.secondary.hostname=targetcluster2.ptc.com,targetcluster3.ptc.com
cluster.secondary.rehost=false

### User-defined Module Settings ###

rehost.script.apstop=../scripts/apstop.sh

154 Rehost Utility Guide

rehost.script.wcstop=../scripts/windchillStop.sh

Rehost Scenario Examples 155

rehost_clustersecondary_first.properties
Use the following property settings when running the utility on the first secondary
node in the cluster that has a host name of targetcluster2.ptc.com:
#### Use Case Setting ###
rehost.useCase=rehost.clustersecondary_example
rehost.keystore.clear=false
rehost.log.passwords=false
test.prop.values.only=true

##### Windchill Path Settings ######

target.wt.home=/ptc/Windchill_10.1/Windchill
target.java.home=/ptc/Windchill_10.1/Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=wcadmin
target.db.password=$encrypt
target.db.hostname=db.local
target.db.port=1521
target.db.serviceName=wind2

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.hostname=targetcluster1.ptc.com
target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.port=1389

##### Apache Settings ####

target.httpserver.port=80
target.httpserver.ssl.port=443

#### Apache Home Directory #####

target.httpserver.home=/ptc/Windchill_10.1/Apache

#### Windchill Server Hostname ###

target.wc.hostname=targetcluster2.ptc.com

### Cluster Settings ###

cluster.main.gateway=targetcluster1.ptc.com
cluster.secondary.hostname=targetcluster2.ptc.com,targetcluster3.ptc.com
cluster.secondary.rehost=true

### User-defined Module Settings ###

rehost.script.apstop=../scripts/apstop.sh

156 Rehost Utility Guide

rehost.script.wcstop=../scripts/windchillStop.sh

Rehost Scenario Examples 157

rehost_clustersecondary_second.properties
Use the following property settings when running the utility on the second
secondary node in the cluster that has a host name of
targetcluster3.ptc.com:
#### Use Case Setting ###
rehost.useCase=rehost.clustersecondary_example
rehost.keystore.clear=false
rehost.log.passwords=false
test.prop.values.only=true

##### Windchill Path Settings ######

target.wt.home=/ptc/Windchill_10.1/Windchill
target.java.home=/ptc/Windchill_10.1/Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=wcadmin
target.db.password=$encrypt
target.db.hostname=db.local
target.db.port=1521
target.db.serviceName=wind2

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.hostname=targetcluster1.ptc.com
target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.port=1389

##### Apache Settings ####

target.httpserver.port=80
target.httpserver.ssl.port=443

#### Apache Home Directory #####

target.httpserver.home=/ptc/Windchill_10.1/Apache

#### Windchill Server Hostname ###

target.wc.hostname=targetcluster3.ptc.com

### Cluster Settings ###

cluster.main.gateway=targetcluster1.ptc.com
cluster.secondary.hostname=targetcluster2.ptc.com,targetcluster3.ptc.com
cluster.secondary.rehost=true

### User-defined Module Settings ###

158 Rehost Utility Guide

rehost.script.apstop=../scripts/apstop.sh
rehost.script.wcstop=../scripts/windchillStop.sh

Rehost Scenario Examples 159

rehost_clustermain_vault.properties
Use the following property settings when running the utility on the main node in
the cluster to update the vaulting information after the secondary nodes have been
updated:
### LDAP Settings ###
target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.hostname=targetcluster1.ptc.com
target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.port=1389
target.ldap.serviceName=target.ptc.com
source.local.domain=source.ptc.com

### Database Settings ###

target.db.hostname=db.local
target.db.port=1521
target.db.serviceName=wind2
target.db.username=wcadmin
target.db.password=$encrypt
target.db.vendor=oracle
source.fv.hostname.0=sourceVault.ptc.com
target.fv.hostname.0=targetVault.ptc.com
source.fv.hostname.1=sourceVault1.ptc.com
target.fv.hostname.1=targetVault1.ptc.com

### Windchill Path Settings ###

target.wt.home=/ptc/Windchill_10.1/Windchill
target.directory.httpserver=/ptc/Windchill_10.1/Apache
target.httpserver.port=80
target.httpserver.ssl.port=443
target.directory.java=/ptc/Windchill_10.1/Java

### Hosts Settings ###

rehost.useCase=rehost.clustermain_vault_example
target.wc.hostname=targetcluster1.ptc.com

160 Rehost Utility Guide

### File Vault Settings ###
source.fv.path.0=/ptc/Windchill_10.1/Windchill/vaults/main_vault_folder
staging.fv.path.0=/misc/staging/vaults/main_vault_folder
target.fv.path.0=/ptc/Windchill_10.1/Windchill/vaults/new_main_vault_folder
source.fv.path.1=/ptc/Windchill_10.1/Windchill/vaults/cache_vault_folder
staging.fv.path.1=/misc/staging/vaults/cache_vault_folder
target.fv.path.1= /ptc/Windchill_10.1/Windchill/vaults/
new_cache_vault_folder
target.fv.required=true

### User-defined Module Settings ###

rehost.script.wc-ap-start=../scripts/windchillStart.sh

rehost Command for Rehost Cluster Example

To implement the Rehost Cluster example as describe in this topic, there are four
rehost commands that must be entered. For each command, open a command
prompt, navigate to the directory where the Windchill Rehost Utility is installed,
and execute the rehost command to run the identified modules. For this example,
the following commands are executed to complete the rehost cluster example:
1. On the targetcluster1.ptc.com main node, enter:
./rehost.sh conf\rehost_clustermain.properties
2. On the targetcluster2.ptc.com secondary node, enter:
./rehost.sh conf\rehost_clustersecondary_first.properties
3. On the targetcluster3.ptc.com secondary node, enter:
./rehost.sh conf\rehost_clustersecondary_second.properties
4. To complete the rehost cluster example, update the vault information on the
main node, enter:
./rehost.sh conf\rehost_clustermain_vault.properties

Each command specifies a unique configuration property file that is described

earlier in this example. The property files are stored in the utility conf directory
and the project.properties file (also in the conf directory) contains the
rehost properties (as described earlier in this example).

Rehost Scenario Examples 161

As each module listed in the rehost properties executes, output is displayed on the
command line and entered into to a log file. After the utility is complete, review
the output entries to ensure that each module has completed as expected. Always
check for any errors that may have occurred.
The last entries displayed for each run give the date and time, the log file path, the
execution status, and the total execution time.

162 Rehost Utility Guide

Clone Scenario Example
The following Clone scenario example copies files from the Windchill software
(codebase) of an existing Windchill installation. The files have been stored in a
staging area that is accessible from the target system. It also changes host name
values in configuration property files, IEConf, and the database on the target
system so that the copied Windchill software functions on the new hardware. The
platform of system hardware for the source and target systems must be the same.
In this case, the example uses two UNIX systems such as two AIX systems or two
HP-UX systems.
The Clone scenario assumes that a database instance has been set up for the target
system before running the utility and that the credentials needed to make changes
to the database are set in target.db properties.
For general information about the Clone scenario, see Clone Scenario Process on
page 26.
For general setup requirements, see Setting Up Your Rehosting Environment on
page 36.
The example executes the basic set of modules (Copy, InfoEngine, Apache,
Database, and Vault):
• Copy—Copies all files and nested directories from a staging directory named
clone-staging to a target directory named target-home/ptc. This
example calls out the minimum set of directories that should be copied:
Windchill, Java, HTTP Server (Apache), and the PTC Solution Installer (PSI)
installation directories and all nested directories under them.
• InfoEngine—Updates the IEConf host name in IEConf and properties on the
target system. The source IEConf host name source-
host.mycompany.com is changed to the target IEConf host name of
target-host.mycompany.com.
• Apache—Updates the target PTC HTTP Server configuration file to reflect the
new host name target-host.mycompany.com along with other target
settings.
• Database—Updates the host name of the target system where Windchill and
reside in the database and associated properties file. In this example, Windchill
reside on the same target host. The source host name for Windchill source-
host.mycompany.com is changed to the target host name target-host.
mycompany.com.
• Vault—Updates file vault mounts on the target system and copies file vault
content from a staging directory to the target system.

Rehost Scenario Examples 163

Clone Example Assumptions
Platform: Monolithic UNIX environment, where source and target systems are on
the same platform
Windchill Environment:
• The source of one Windchill 10.2 system is staged so that it is accessible to the
utility. The utility copies the source files to the target system.
• The source system has three Info*Engine (IE) adapters that must be
configured on the target system (JDBC and JNDI) and one that can be
removed from the target system (SAP). Configuring adapters as shown by
using the IEAdapter module in this example is optional.
• There is no change in the Windchill and third-party applications installation
directories, organization name, or web application name.
Target Database: Same as Microsoft SQL Server source database, but its own
instance; database contains content from source target database.
Target IEConf: A copy of source IEConf folder.

Clone Example Activities

The following activities describe the actions needed to set up and execute this
scenario.
User-defined script: Create one script.
clone.example property: Set clone.example property in
projects.properties as described in clone.example Property for Clone
Example on page 164.
Configuration properties file: Create clone-test.properties as
described in Configuration Properties File for Clone Example on page 165. Ensure
that rehost.useCase=clone.example is set under Host Settings.
Rehost Command: Execute the rehost command as described in rehost
Command for Clone Example on page 167.

clone.example Property for Clone Example

To automate the clone example, set the following property in
projects.properties which is in the utility conf directory. The property
setting must be on one line in the file:
clone.example=Copy,InfoEngine,Apache,Database,Vault

164 Rehost Utility Guide

Configuration Properties File for Clone Example
To automate the clone example, open the sample rehost.properties file
that is in the conf directory and set the properties that are required for the clone
example. Each property setting must be on one line in the file; however, multiple
settings in the example span multiple lines to accommodate the width of the page
in the guide. Save the changes in conf\clone-test.properties.
Run the utility using a clone scenario that executes the Copy, InfoEngine, Apache,
Database, and Vault modules to create the target Windchill system.
The property settings for the clone example scenario are as follows:
### Use Case Settings ###
rehost.useCase=clone.example
rehost.keystore.clear=false
rehost.log.passwords=false
test.prop.values.only=false

### Windchill Path Settings ###

target.wt.home=/ptc/Windchill_10.1/Windchill
target.java.home=/ptc/Windchill_10.1/Java

### Database Settings ###

target.db.vendor=oracle
target.db.username=DBUSER123
target.db.password=dbpass1234
target.db.hostname=db-host.mycompany.com
target.db.port=1433
target.db.serviceName=cx24_sql
target.db.jdbc.database=DBXUSER123

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.hostname=targetcluster1.ptc.com
target.ldap.username=<ldap_user>
target.ldap.password=pass1234
target.ldap.hostname=target-host.mycompany.com
target.ldap.port=1389
target.ldap.serviceName=target-host.mycompany.com
source.local.domain= source-host.mycompany.com

#### Adapter Changes ####

target.ldap.hostname.custjndiadapter=source-jndi-host.mydomain.com
target.ldap.port.custjndiadapter=1234

##### Copy Settings #####

Rehost Scenario Examples 165

staging.directory.0=/clone-staging/Windchill
target.directory.0=/target-home/ptc/Windchill
staging.directory.1=/clone-staging/Java
target.directory.1=/target-home/ptc/Java
staging.directory.2=/clone-staging/HTTPServer
target.directory.2=/target-home/ptc/HTTPServer
staging.directory.4=/clone-staging/PSI
target.directory.4=/target-home/ptc/PSI

### HTTPServer Settings ####

target.httpserver.port=8888
target.httpserver.ssl.port=443

#### Windchill Home Directories #####

target.directory.windchill=/target-home/ptc/Windchill

#### Apache Home Directory ####

target.directory.httpserver=/target-home/ptc/HTTPServer

#### Windchill Server Hostname ####

target.wc.hostname=target-host.mycompany.com

#### FileVault Settings ####

target.fv.required=true
source.fv.path.0=/ptc/Windchill_10.2/Windchill/vaults/main_vault_folder
staging.fv.path.0=/misc/staging/vaults/main_vault_folder
target.fv.path.0=/ptc/Windchill_10.2/Windchill/vaults/new_main_vault_folder
source.fv.path.1=/ptc/Windchill_10.2/Windchill/vaults/cache_vault_folder
staging.fv.path.1=/misc/staging/vaults/cache_vault_folder
target.fv.path.1= /ptc/Windchill_10.2/Windchill/vaults/new_cache_vault_folder

### Vault Host Settings ####

source.fv.hostname.0=source-host.mycompany.com
target.fv.hostname.0=target-host.mycompany.com

#### Application Rename Settings ####

target.wc.webapp=TrgWindchill
source.wc.webapp=SrcWindchill

### User-defined Module Settings ###

rehost.script.wc-ap-start=../scripts/windchillStart.sh

166 Rehost Utility Guide

rehost Command for Clone Example
Open a command prompt and navigate to the directory where the Windchill
Rehost Utility is installed. The target system and staging area must be accessible
from this directory. Then execute the following command to run the modules that
execute the clone example:
./rehost.sh conf/clone-test.properties

The command assumes that the configuration property file is clone-

test.properties (as described earlier in this example) which is in the utility
conf directory and the project.properties file (also in the conf
directory) contains the clone.example property (as described earlier in this
example).
As the Copy module executes, output is displayed on the command line and
entered into to a Copy log file located in the copylogs directory under the
rehost utility installation directory. As the other modules listed in the
clone.example property execute, output is displayed on the command line
and entered into to a scenario log file located in the buildlogs where Windchill
is installed. After the utility is complete, review the logs to ensure that each
module has completed as expected. Always check for any errors that may have
occurred.

Clone Example Execution Results

The results from executing this clone example scenario are that software has been
copied from a Windchill source system and modules have been executed to
configure the target system so that it is a running development or test environment
with the same Windchill environment as the source system. The target Windchill
system runs independently from the source system.
When the scenario finishes, PTC HTTP Server (Apache) and Windchill will be
running.

Rehost Scenario Examples 167

Move Scenario Examples
The Move scenario is commonly used when there is a change in the Windchill
installation directory.
For general information about the Move scenario, see Move Scenario Process on
page 29.
For general setup requirements, see Setting Up Your Rehosting Environment on
page 36.
There are two Move scenario examples provided:
• Move an existing source system a new location on the same server.
In this scenario, the host name remains the same. The only change needed is
the change in the Windchill installation directory (WT_HOME) and third-
party application installation directories.
• Move the data from an existing source system to a target system on a new
platform.
In this scenario, a new target Windchill system is installed and the Windchill
environment from the source system is duplicated on the new platform. Then
data from the source system is copied to the target system. Then, both the host
name and installation directories (Windchill WT_HOME and third-party
applications) must be updated.

Moving to New Home Directory on Same Host

This Move scenario example describes the activities required to move an existing
source Windchill system a new location on the same server. In this case, the
source system is no longer running; the resulting target system environment
replaces the source system and has all data from the source system.

Move Home Directory Example Assumptions

Platform: Monolithic Windows environment, where source code has been moved
to the target location on the same host
Windchill Environment:
• The source of one Windchill 10.2 system is moved to its new target location
on the same host. As a separate activity, the utility Copy module can move the
files or they can be moved manually.
• There is no change in Windchill environment other than the change in the
installation directories.
Target Database: Same Microsoft SQL Server source database.
Target LDAP: Windchill Directory Server used with source system.

168 Rehost Utility Guide

Move Home Directory Example Activities
The following activities describe the actions needed to set up and execute this
scenario.
move.homedir_example property: Set move.homedir_example
property in projects.properties as described in move.homedir_example
Property for Move Home Directory Example on page 169.
Configuration properties file: Create move_homedir.properties as
described in Configuration Properties File for Move Home Directory Example on
page 169. Ensure that rehost.useCase=move.homedir_example is set
under Host Settings.
Rehost Command: Execute the rehost command as described in rehost
Command for Move Home Directory Example on page 171.

move.homedir_example Property for Move Home Directory Example

To automate the move home directory example, set the following property in
projects.properties which is in the utility conf directory:
move.homedir_example=ChangeHome

Configuration Properties File for Move Home Directory Example

To automate the move home directory example, open the sample
rehost.properties file that is in the conf directory and set the properties
that are required for the clone example. Each property setting must be on one line
in the file. Save the changes in conf\move_homedir.properties.
The property settings for the move home directory example scenario are as
follows:
### Use Case Settings ###
rehost.useCase=move.homedir_example
rehost.keystore.clear=false
rehost.log.passwords=true
test.prop.values.only=false

### Windchill Path Settings ###

target.wt.home=/target-home/ptc/Windchill
target.java.home=/target-home/ptc/Java

### Database Settings ###

target.db.vendor=microsoft
target.db.username=DBUSER123
target.db.password=$encrypt
target.db.hostname=db-host.mycompany.com
target.db.port=1433
target.db.serviceName=cx24_sql

Rehost Scenario Examples 169

target.db.jdbc.database=DBUSER123

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.directory.ldap=/target-home/ptc/WindchillDS
target.ldap.username=<ldap_user>
target.ldap.password=$encrypt
target.ldap.hostname=target-host.mycompany.com
target.ldap.port=3899
target.ldap.serviceName=target.ptc.com

## ChangeHome and Copy Settings ###

staging.directory.1=/staging/Windchill
target.directory.1=/target-home/ptc/Windchill
staging.directory.2=/staging/Java
target.directory.2=/target-home/ptc/Java
staging.directory.3=/staging/HTTPServer
target.directory.3=/target-home/ptc/HTTPServer
staging.directory.4=/staging/PSI
target.directory.4=/target-home/ptc/PSI

### HTTPServer Settings ###

target.httpserver.port=80
target.httpserver.ssl.port=443

###Windchill Home Directories ###

source.directory.windchill=/source-home/ptc/Windchill
target.directory.windchill=/target-home/ptc/Windchill

### Apache Home Directory ###

target.directory.httpserver=/target-home/ptc/HTTPServer

### Windchill Server Hostname ###

target.wc.hostname=target.ptc.com

#### Move Configuration Settings ####

source.directory.windchill=/source-home/Windchill
target.directory.windchill=/target-home/ptc/Windchill
source.directory.java=/source-home/Java
target.directory.java=/target-home/ptc/Java
source.directory.httpserver=/source-home/HTTPServer
target.directory.httpserver=/target-home/ptc/HTTPServer
source.directory.psiBase=/source-home/PSI
target.directory.psiBase=/target-home/ptc/PSI

170 Rehost Utility Guide

rehost Command for Move Home Directory Example
Open a Windchill shell and navigate to the directory where the Windchill Rehost
Utility is installed on the target system. Then execute the following command to
run the modules that execute the move home directory example:
rehost.bat conf/move_homedir.properties

The command assumes that the configuration property file is move_

homedir.properties (as described earlier in this example) which is in the
utility conf directory and the project.properties file (also in the conf
directory) contains the move.homedir_example property (as described
earlier in this example).
As the ChangeHome module executes, output is displayed on the command line
and entered into to a scenario log file located in the buildlogs where Windchill
is installed. When the utility is complete, review the logs to ensure that modules
have completed as expected. Always check for any errors that may have occurred.

Move Home Directory Example Execution Results

The results from executing this move example scenario are that software has been
moved from a Windchill source system to a new directory on the same system and
the ChangeHome module has updated the Windchill and third-party application
installation directories.

Moving to New Home Directory on Different Platform

This Move scenario example describes the activities required to move an existing
source Windchill system a new location on a different server that is on a different
hardware platform. In this case, the source system is no longer running; the
resulting target system environment replaces the source system and has all data
from the source system.

Move to New Platform Example Assumptions

Source Platform: Monolithic Windows environment
Target Platform: Monolithic UNIX environment
Windchill Environment:
• The target location has a newly installed Windchill environment located in a
different directory structure from the source system. The target system has the
same version of Windchill as the source system. For setup details, see Setting
Up Your Rehosting Environment on page 36.
• There is no change in Windchill environment other than the change in the
installation directories. This includes no changes in the host name from the
source to target systems.

Rehost Scenario Examples 171

Target Database: Same Oracle Server source database.
Target IEConf: A copy of source IEConf folder.

Move to New Platform Example Activities

The following activities describe the actions needed to set up and execute this
scenario.
move.newplatform_example property: Set move.newplatform_
example property in projects.properties as described in move.
newplatform_example Property for Move to New Platform Example on page 172.
Configuration properties file: Create move_homedir.properties as
described in Configuration Properties File for Move to New Platform Example on
page 172. Ensure that rehost.useCase=move.newplatform_example
is set under Host Settings.
Rehost Command: Execute the rehost command as described in rehost
Command for Move to New Platform Example on page 174.

move.newplatform_example Property for Move to New Platform

Example
To automate the move to a new platform example, set the following property in
projects.properties which is in the utility conf directory:
move.newplatform_example=InfoEngine,Database,ChangeHome

Configuration Properties File for Move to New Platform Example

To automate the move home directory example, open the sample
rehost.properties file that is in the conf directory and set the properties
that are required for the clone example. Each property setting must be on one line
in the file. Save the changes in conf\move_newplatform.properties.
The property settings for the move to new platform example scenario are as
follows:
### Use Case Settings ###
rehost.useCase=move.newplatform_example
rehost.keystore.clear=false
rehost.log.passwords=true
test.prop.values.only=false

### Windchill Path Settings ###

target.wt.home=/ptc/Windchill
target.java.home=/ptc/Java

### Database Settings ###

target.db.vendor=microsoft

172 Rehost Utility Guide

target.db.username=DBUSER123
target.db.password=$encrypt
target.db.hostname=db-host.mycompany.com
target.db.port=1433
target.db.serviceName=cx24_sql
target.db.jdbc.database=DBUSER123

### LDAP Settings ###

target.directory.IEConfDir=/ptc/Windchill_10.1/WindchillDS
target.ldap.username=cn=Manager
target.ldap.password=$encrypt
target.ldap.hostname=target-host.mycompany.com
target.ldap.port=3899
target.ldap.serviceName=host135.mycompany.com

## ChangeHome and Copy Settings ###

source.directory.1=D:\ptc\Windchill
target.directory.1=/ptc/Windchill
source.directory.2=D:\ptc\Java
target.directory.2=/ptc/Java
source.directory.3=D:\ptc\HTTPServer
target.directory.3=/ptc/HTTPServer
source.directory.5=D:\ptc\PSI
target.directory.5=/ptc/PSI

### HTTPServer Settings ###

target.httpserver.port=80
target.httpserver.ssl.port=443

#### Windchill Home Directories #####

source.directory.windchill=D:\ptc\Windchill
target.directory.windchill=/ptc/Windchill

### Apache Home Directory ###

target.directory.httpserver=/ptc/HTTPServer

### Windchill Server Hostname ###

target.wc.hostname=target.ptc.com

Rehost Scenario Examples 173

rehost Command for Move to New Platform Example
Open a Windchill shell and navigate to the directory where the Windchill Rehost
Utility is installed on the target system. Then execute the following command to
run the modules that execute the move home directory example:
rehost.bat conf/move_newplatform.properties

The command assumes that the configuration property file is move_

newplatform.properties (as described earlier in this example) which is in
the utility conf directory and the project.properties file (also in the
conf directory) contains the move.newplatform_example property (as
described earlier in this example).
As each module executes, output is displayed on the command line and entered
into to a scenario log file located in the buildlogs where Windchill is installed.
After the utility is complete, review the logs to ensure that modules have
completed as expected. Always check for any errors that may have occurred.

Move to New Platform Example Execution Results

The results from executing this move example scenario are that the configuration
has been moved from a Windchill source system to a new directory on a new
Windchill installation that is on a new hardware platform and modules have been
executed to update configuration, Windchill, and third-party application
installation directories.

174 Rehost Utility Guide

 7
Manual Rehost Activities
Planning Rehost Project Activities............................................................................. 176
Update Host Name in Windchill Enterprise Systems Integration (ESI) Failure Task
URL .................................................................................................................... 176
Exporting Database from Source System and Importing It into Target System:
Oracle ................................................................................................................. 177
Exporting Database from Source System and Importing It into Target System:
Microsoft SQL Server ........................................................................................... 178

The following sections provide detailed information about rehost activities that
must be done outside of the Windchill Rehost Utility.

175
Planning Rehost Project Activities
The following sections shows which scenario and modules to run in the utility to
accomplish rehost projects.

Update Host Name in Windchill Enterprise

Systems Integration (ESI) Failure Task
URL
Use the information in this topic when a Windchill system in which the Windchill
Enterprise Systems Integration (ESI) is installed the host name on the target
system is being changed.
As a result of changing the host name on the target system, there is a mismatch in
the host name that is in the ESI Failure task URL on the target system. If the
Windchill system is Windchill 10.0 (all maintenance releases), Windchill 10.1
F000, or Windchill 10.1 M010, the URL cannot be updated; contact PTC
Technical support if this is an issue.
In Windchill 10.1 M020 and beyond, PTC provides a script that you can run to
update the host name in the ESI Failure task URL. Complete the following steps
to manually execute the script:
1. Ensure that the Windchill method server on the target system is running.
2. Open a Windchill shell and enter the following command:
windchill com.ptc.windchill.esi.utl.ESIRepairFailureTaskURL
3. When prompted, enter the user name and password of the Windchill
administrator.
When the script completes, the required updates to the ESI Failure task URL have
occurred.
To automate running ESIRepairFailureTaskURL, include the execution of the
command in a user-defined Script module. For details on creating a script that can
be used, see the module description for Script on page 92.

176 Rehost Utility Guide

Exporting Database from Source System
and Importing It into Target System:
Oracle
The Oracle Data Pump utility can be used to export the Windchill schema of the
source system and import it into the target system.

Note
PTC recommends that the source schema user name be used as the target
schema user name.

Example BAT and SH scripts are provided as a starting point for running the
Oracle Data Pump utility:
• If the database resides on Windows, see oraexp.bat on page 192 and oraimp.
bat on page 192.
• If the database resides on UNIX or Linux, see oraexp.sh on page 197 and
oraimp.sh on page 199.
For more information about the Oracle Data Pump utility or to use a different
target schema user name, see the Oracle example for exporting and importing data
that is documented in the Windchill Upgrade Guide, which can be found at ptc.
com: .https://www.ptc.com/appserver/cs/doc/refdoc.jsp.

Manual Rehost Activities 177

Exporting Database from Source System
and Importing It into Target System:
Microsoft SQL Server
Data can be exported from a Microsoft SQL Server database on the source system
by backing it up. Then, import the backed-up data by restoring it into the database
on the target system.
For more information about the backup and restoration procedures for the SQL
Server, see the Microsoft SQL Server example for backing up and restoring data
that is documented in the Windchill Upgrade Guide, which can be found at ptc.
com: .https://www.ptc.com/appserver/cs/doc/refdoc.jsp.

178 Rehost Utility Guide

 8
Automated Rehost Activities
Automated Solr Rehost............................................................................................ 180

The following sections provide detailed information about automated rehost

activities that must be done outside of the Windchill Rehost Utility.

179
Automated Solr Rehost
About Solr Rehost Utility
The Solr rehost utility is an automated script that you can use to perform Solr
rehosting activities on the same machine or on different machines. Using the
utility, you can perform all four rehost scenarios, namely Move scenario, Clone
scenario, Rename scenario and Rehost scenario, automatically for Solr
applications.
After Solr is installed, the utility is saved at:<Solr_home/solr_
utilities/solr_rehost_utility>.
The solr_rehost_utility folder contains the following files:
• solr_rehost.properties: contains property files that can be
configured as per business requirement. Execute the Solr rehost utility script
after modifying or configuring the property settings in this file.
• solrrehostwin.bat: executable file that is required for the execution of
rehost utility script on Windows platform.
• solrrehostunix.sh: executable file that is required for the execution of
rehost utility script on Unix platform.

About solr_rehost.properties:
The solr_rehost.properties file broadly consists of following sections:
1. Target Solr Properties:
Update the following mandatory properties for target Solr server:
SCENARIO=<Specify the rehost scenario to be used:
Rename, Rehost, Move, Clone>
JAVA_HOME=<Specify java home path in target Solr
machine>
HOST_NAME=<Specify host name of target machine>
SOLR_HOME=<Specify Solr home directory>
SOLR_DATA_DIR=<Specify Solr indexed data directory>
2. Properties to copy Solr from source system to target system:
These are optional properties. Update the following properties to copy Solr
from source system to target system.
SOLR_COPY_REQUIRED=<YES>
COPY_SOLR_SOURCE=<Specify Solr source directory>
COPY_SOLR_DEST=<Specify Solr target directory>
3. Properties to copy Solr indexed data from source system to target system:

180 Rehost Utility Guide

 These are optional properties. Update the following properties to copy Solr
indexed data from source system to target system.
INDEX_DATA_COPY_REQ=<YES>
INDEX_DATA_SOURCE=<Specify source Solr data directory>
INDEX_DATA_TARGET=<Specify target Solr data directory>

Solr Rehost Scenarios

Use the following scenarios as per your business requirement that should satisfy
the following criteria:
Scenario Machine Host- Solr Operat- Domain Solr
Change name Home ing Change Installa-
Change Path System tion
Change Change
RENAME No Yes Not Not Optional Same
applicable applicable Installa-
tion
REHOST Yes Yes Not Not Optional New
applicable applicable Installa-
tion
CLONE Yes Yes Not Not Optional Copied
applicable applicable from
source
MOVE Optional Optional Yes Optional Optional Either
copied
from
source or
new
installa-
tion

Prerequisites and Recommendations:

• Java is installed on the target machine on which Solr is required to be copied
or installed.
• The path to Java environment variable should not contain any spaces as it is
not supported in xconfmanger.
• The path to Solr home and Solr data directory should not contain spaces else
Solr installation will fail.
• You have access to source and target systems.
• Take backup of the Solr installation before executing any steps to avoid loss of
data and configuration settings.

Automated Rehost Activities 181

• Use the following conventions in properties file for different operating
systems:
○ For Windows, use backward slash (\) path separator
For example, path: d:\worklogs\solr1\solrserver
○ For Unix, use forward slash (/) path separator
For example, path: /opt/ptc/solrserver
• Stop the Solr instances before running the script.
• Run cmd as an administrator while executing scripts.
• Use solr_rehost.properties file available with the Solr rehost utility
for copying or indexing the data and rehosting it based on the input scenario
provided in this file.

Automated Configurations for Rehosting

Standalone Solr Server

Note
The instructions in the following sections apply to rehosting a standalone Solr
server on Cloud as well as On-Premise platforms.

Solr Rename Scenario

The rename scenario is commonly used to change Solr host name or relocating an
existing deployment on a new network. There is no need to install a new Solr
server for Rename method.
Use the following procedure to perform Solr Rename scenario on a standalone
Solr server:
1. Update the following details in solr_rehost.properties file:
SCENARIO=RENAME
JAVA_HOME=<java_home_path>
HOST_NAME=<new_host_name>
SOLR_HOME=<Solr_home_name>
SOLR_DATA_DIR=<Solr_data_directory_name>
2. Navigate to {SOLR_HOME}/solr_utilites/Solr_Rehost_
Utilites/ from command prompt and run the following command to
execute the Solr rehost utility script:
• On Windows:

182 Rehost Utility Guide

 solrrehostwin.bat solr_rehost.properties
• On Unix:
./solrrehostunix.sh ./solr_rehost.properties

Solr Rehost Scenario

Rehost scenario provides ability to copy data from source system to target system
and then configuring the target system so that it operates like the source system. In
Rehost scenario, you must install a new Solr server on the target system, provided
the source and target systems have same operating systems. After the new Solr
server is installed on the target system, the Solr indexed data is copied to the target
system using Solr rehost utility.
Use the following procedure to perform Solr Rehost scenario on a Standalone Solr
server:
1. Install a new Solr server on the target system.
2. Copy the Solr indexed data from the source system to the target system, using
following option:
• Manually copy Solr indexed data to the target system.
• Automatically copy Solr indexed data to the target system by updating the
following properties in solr_rehost.properties file:
INDEX_DATA_COPY_REQ=YES
INDEX_DATA_SOURCE=<source_index_data_path>
INDEX_DATA_TARGET=<target_index_data_path>

Note
• You must have four core indexes in the target data folder of the newly
installed Solr server at the target system.
• Specify YES or NO as values for the properties for Solr configurations as
per business requirement. The property values are case sensitive, use
uppercase only.

3. Update following properties in solr_rehost.properties for Solr

Rehost scenario:
SCENARIO=REHOST
JAVA_PATH=<java_home_path>
SOLR_HOME=<solr_home_path>
SOLR_DATA_DIR=<Solr_data_directory_path>

Automated Rehost Activities 183

 SOLR_HOME=<Solr_hostname>
4. Navigate to {SOLR_HOME}/solr_utilites/Solr_Rehost_
Utilites/ from command prompt and run the following command to
execute the Solr rehost utility script:
• On Windows:
solrrehostwin.bat solr_rehost.properties
• On Unix:
./solrrehostunix.sh ./solr_rehost.properties
After execution of this command, the properties in step 3 are updated in the
bin/setenv.bat file in the target Solr system.

Solr Clone Scenario

In Clone scenario, files from an existing Solr installation are copied to a new
system. If the source system and target system have same operating systems, there
is no need to install a new Solr server. Copy the existing Solr installation on the
target system.

Note
You must use Solr Rehost Utility instead of Windchill Rehost Utility to copy
the Solr data completely from source to target system.

Follow this procedure to perform Solr Clone scenario on a Standalone Solr server:
1. Copy the Solr data directory to the target system using the following options:
• Manually copy Solr indexed data to target system.
• Automatically copy the Solr installation and Solr indexed data to the target
system by updating the following properties in solr_
rehost.properties file:
○ Properties to copy Solr installation from source system to target
system.
SOLR_COPY_REQUIRED=YES
COPY_SOLR_SOURCE=<source_solr_path>
COPY_SOLR_DEST=<target_solr_path>
○ Properties to copy Solr data directory from source system to target
system.
INDEX_DATA_COPY_REQ=YES
INDEX_DATA_SOURCE=<source_index_data_path>
INDEX_DATA_TARGET=<targetindex_data_path>

184 Rehost Utility Guide

 Note
◆ Update these properties in the solr_rehost.properties file
only if your Solr data directory is at a location other than the
default location in the source system and you want to copy it to
target location.
◆ Specify YES or NO as values for the properties for Solr
configurations as per business requirement. The property values are
case sensitive, use uppercase only.

2. Update the following properties in solr_rehost.properties file for

Solr Clone scenario:
SCENARIO=CLONE
JAVA_PATH=<java_home_path>
SOLR_HOME=<solr_home_path>
SOLR_DATA_DIR=<solr_data_directory_path>
SOLR_HOSTNAME=<solr_hostname>
3. Navigate to {SOLR_HOME}/solr_utilites/Solr_Rehost_
Utilites/ from command prompt and run the following command to
execute the Solr rehost utility script:
• On Windows:
solrrehostwin.bat solr_rehost.properties
• On Unix:
./solrrehostunix.sh ./solr_rehost.properties
This script copies Solr indexed data from a source system to target system.
After execution of this command, the properties in step 2 are updated in the
bin/setenv.bat in the target Solr system.

Solr Move Scenario

The Move scenario is commonly used if there is a change in the installation
directory.
• If the source system and target system have the same operating systems, there
is no need to install a new Solr server at the target system. You should copy
the existing Solr installation on the target system.
• If the source system and target system have different operating systems, you
must install a new Solr server at the target system and copy the data directory
to the target system.

Automated Rehost Activities 185

To perform Solr Move scenario in case of same operating systems at source and
target machines, follow these steps:
1. Copy the existing Solr installation from source to target system using
following options:
• Manually copy Solr installation and Solr indexed data to the target system.
• Automatically copy the Solr installation and Solr indexed data to the target
system by updating the following properties in solr_
rehost.properties file:
○ Properties to copy Solr installation from source system to target
system.
SOLR_COPY_REQUIRED=YES
COPY_SOLR_SOURCE=<source_solr_path>
COPY_SOLR_DEST=<target_solr_path>
○ Properties to copy Solr data directory from source system to target
system.
INDEX_DATA_COPY_REQ=YES
INDEX_DATA_SOURCE=<source_index_data_path>
INDEX_DATA_TARGET=<target_index_data_path>

Note
◆ Update these properties in the solr_rehost.properties file
only if your Solr data directory is at a location other than default
location in the source system and you want to copy it to target
location.
◆ Specify YES or NO as values for the properties for Solr
configurations as per business requirement. The property values are
case sensitive, use uppercase only.

2. Update following properties in solr_rehost.properties for Solr

Move scenario:
SCENARIO=MOVE
JAVA_PATH=<java_home_path>
SOLR_HOME=<solr_home_path>
SOLR_DATA_DIR=<solr_data_directory_path>

186 Rehost Utility Guide

 SOLR_HOSTNAME=<solr_hostname>
3. Navigate to {SOLR_HOME}/solr_utilites/Solr_Rehost_
Utilites/ from command prompt and run the following command to
execute the Solr rehost utility script:
• On Windows:
solrrehostwin.bat solr_rehost.properties
• On Unix:
./solrrehostunix.sh ./solr_rehost.properties
This script copies Solr indexed data from a source system to target system.
After execution of this command, the properties in step 2 are updated in the
bin/setenv.bat in the target Solr system.
To perform Solr Move scenario in case of different operating systems in source
and target machines, follow these steps:
1. Install a new Solr server on the target system.
2. After the new Solr server is installed, copy the Solr indexed data from source
to the target system using the following options:
• Manually copy the Solr indexed data directory to the target system.
• Automatically copy the Solr indexed data to the target system by updating
the following properties in the solr_rehost.properties file:
INDEX_DATA_COPY_REQ=YES
INDEX_DATA_SOURCE=<source_index_data_path>
INDEX_DATA_TARGET=<target_index_data_path>

Note
• You must have four core indexes in the target data folder of the newly
installed Solr server in the target system.
• Specify YES or NO as values for the properties for Solr configurations as
per business requirement. The property values are case sensitive, use
uppercase only.

3. Update the following properties in the solr_rehost.properties file

for Solr Move scenario:
SCENARIO=MOVE
JAVA_PATH=<java_home_path>
SOLR_HOME=<solr_home_path>
SOLR_DATA_DIR=<solr_data_directory_path>

Automated Rehost Activities 187

 SOLR_HOSTNAME=<solr_hostname>
4. Navigate to {SOLR_HOME}/solr_utilites/Solr_Rehost_
Utilites/ from command prompt and run the following command to
execute the Solr rehost utility script:
• On Windows:
solrrehostwin.bat solr_rehost.properties
• On Unix:
./solrrehostunix.sh ./solr_rehost.properties
This script copies Solr indexed data from a source system to target system.
After execution of this command, the properties in step 3 are updated in the
bin/setenv.bat in the target Solr system.

Finalize Rehosted Standalone Solr Server

Perform the following steps to finalize rehosting a standalone Solr server:
1. After running the Solr rehost utility, start the Solr server.
2. Verify that Solr server is up and running.
• If the installed server is not running, then verify that the properties in
set_env.bat and solrserver.properties files are set correctly.
The properties in both these files must be same.
Path to set_env.bat file: <solr_home\SolrServer\bin\set_
env.bat>
Path to solrserver.properties file: <solr_home\
SolrServer\config\solrserver.properties>
3. Connect the rehosted Solr server with Windchill.
• After performing any specific Solr rehost scenario, update the following
properties in site.xconf properties file in Windchill and propagate the
change using xconf utility.
wt.index.solrHost

188 Rehost Utility Guide

 wt.auth.trustedHosts

Debugging the Solr Rehost Utility Script

Logging
Enable the logging feature to record information about Solr rehost utility script
operation during the execution of the script. Use the data in the log files to verify
and troubleshoot the failures that occur during the execution of Solr rehost utility
script.
The following commands create a rehost.log file in the directory where the
script is running, in Windows as well as in Unix environments.
Run the following command at command prompt to create rehost.log file in
the directory and enable logging.
• On Windows,
solrrehostwin.bat solr_rehost.properties > rehost.log
• On Unix,
./solrrehostunix.bat ./solr_rehost.properties >
rehost.log

Debugging the Solr Rehost Utility Script

Enable the debugging mode of the script in Windows as well as Unix
environments for additional details about Solr rehost utility script. Perform the
below steps to generate detailed command outputs in a log file. Review the data in
the log file to verify different operations and troubleshoot the failures occurred
during rehosting the Solr server.
• Windows:
Edit the solrrehostwin.bat file to modify the first line as follows:
Rem @echo off
• Unix:
Run the rehost utility as follows:
bash -x ./solrrehostunix.sh ./solr_rehost.properties
This generates detailed command outputs in the terminal or in a log file.

Automated Rehost Activities 189

 9
Rehost Utility Script Examples
Windows Script Examples........................................................................................ 191
UNIX and Linux Script Examples .............................................................................. 197
Using the xconfmanager Utility in a Script.................................................................. 203

The following sections provide examples of common rehost utility scripts that can
be modified to fit unique environments. The scripts are grouped by OS: Windows
systems scripts, and UNIX/Linux system scripts.
Using user-defined shell scripts or batch files within a rehosting utility can be
accomplished by using the utility Script task module. For details, see Script on
page 92.
Before using any of the example scripts, inspect them to ensure that the variables
and file paths that are set are applicable to your environment. When creating your
script files, make sure that any lines copied from the guide do not have extraneous
line breaks. Remember that long script lines that are in the guide have been split
into multiple lines so that they fit on the page.

190 Rehost Utility Guide

Windows Script Examples
The following sections provide examples of common rehost utility scripts that can
be used on Windows systems.

apstart.bat
Use a script similar to the following script to start Apache:
:: modify vars as needed
set APACHE_HOME=D:\PTC\Windchill10\Apache

call %APACHE_HOME%\bin\httpd -k start

apstop.bat
Use a script similar to the following script to stop Apache:
:: modify vars as needed
set APACHE_HOME=D:\PTC\Windchill10\Apache

call %APACHE_HOME%\bin\httpd -k stop

Rehost Utility Script Examples 191

oraexp.bat
Use a script that is similar to the following script (which has been formatted to fit
the page) to export a dump file from any Oracle database. Wet the correct schema
SID, user, and two passwords in the script. The script assumes that the dump file
is created in the defined dump directory.
:: modify these as needed
set ORACLE_HOME=D:\PTC\oracle\product\11.2.0\dbhome_1

set SCHEMA_SID=wind10
set SCHEMA_USER=wcadmin
set SCHEMA_PASS=wcadmin
set SYSTEM_PASS=Manager2
set DUMP_DIR=dmpdir

start %ORACLE_HOME%\bin\expdp %SCHEMA_USER%/%SCHEMA_PASS%@%SCHEMA_SID%

directory=%DUMP_DIR% dumpfile=%SCHEMA_USER%.dmp
logfile=%SCHEMA_USER%.log

Make any adjustments to the script to fit your environment; for example, use the
existing DATA_PUMP_DIR instead of dmpdir:
DATA_PUMP_DIR = %ORACLE_INVENTORY%\..\admin\wind10\dpdump/ data_pump.sql

The following SQL statements create a suitable staging area:

CREATE OR REPLACE DIRECTORY dmpdir AS 'D:\misc\staging';
GRANT read, write ON DIRECTORY dmpdir TO wcadmin;

The SQL statement assumes:

• wcadmin is the Windchill schema owner
• D:\misc\staging exists and is writable

oraimp.bat
Use a script that is similar to the following script (which has been formatted to fit
the page) to import a dump file into any Oracle database. Set the correct schema
SID, user, and two passwords in the script. The script assumes that the dump file
is located in the defined dump directory.
:: modify these as needed
set ORACLE_HOME=D:\PTC\oracle\product\11.2.0\dbhome_1

set SCHEMA_SID=wind10
set SCHEMA_USER=wcadmin
set SCHEMA_PASS=wcadmin
set SYSTEM_PASS=Manager2
set DUMP_DIR=dmpdir

192 Rehost Utility Guide

start %ORACLE_HOME%\bin\impdp system/%SYSTEM_PASS%@%SCHEMA_SID%
directory=%DUMP_DIR% dumpfile=%SCHEMA_USER%.dmp
logfile=%SCHEMA_USER%.log

Rehost Utility Script Examples 193

wcclear.bat
Use a script similar to the following script to move existing logs and compiled
tasks into the staging area for archiving.
Example wcclear.bat script (formatted to fit the page):
:: modify vars as needed
set WT_HOME=D:\PTC\Windchill10\Windchill
set STAGING=D:\PTC\Windchill10\staging

IF EXIST %STAGING% (GOTO MOVEFILES)

mkdir %STAGING%

:MOVEFILES
move /Y %WT_HOME%\logs %STAGING%\logs_old
move /Y %WT_HOME%\tasks\codebase\com\infoengine\compiledTasks
%STAGING%\compiledTasks_old
mkdir %WT_HOME%\logs
mkdir %WT_HOME%\tasks\codebase\com\infoengine\compiledTasks

194 Rehost Utility Guide

windchillStart.bat

Note
Windchill only needs to be started using a script for the SelectiveContent
module.

Use a script similar to the following script to start Windchill from a Windows
system.

Note
The windchillStart.bat file as documented here is included in the
scripts directory where the utility is installed.

The script starts Apache using httpd.exe. Then it calls the Windchill start
command and waits until Windchill has completed startup before proceeding to
execute any additional modules. The wait is accomplished by first waiting one
hundred twenty seconds.
The variables used in the script are set in the utility when run on a Windows
system and can be used as shown in the script.
windchillStart.bat (formatted to fit on the page):
rem apache.home, classpath, wt.username, and wt.password env vars are set by
the rehost utility
start %apache.home%\bin\httpd.exe

windchill start
rem ping for 120 seconds for MethodServer to start - increase this if necessary, or decreas
ping 127.0.0.1 -n 120 > nul

Rehost Utility Script Examples 195

windchillStop.bat
Use a script similar to the following script to stop Windchill from a Windows
system.
The variables used in the script are set in the utility when run on a Windows
system and can be used as shown in the script.
windchillStop.bat:
rem classpath, wt.username, and wt.password env vars are set by
the rehost utility

windchill stop

196 Rehost Utility Guide

UNIX and Linux Script Examples
The following sections provide examples of common rehost utility scripts that can
be used on UNIX and Linux systems.

apstart.sh
Use a script similar to the following script to start Apache:
#!/bin/sh

# modify these settings as needed

sudo /ptc/Windchill_10.1/Apache/bin/apachectl -k start

apstop.sh
Use a script similar to the following script to stop Apache:
#!/bin/sh

# modify these settings as needed

sudo /ptc/Windchill_10.1/Apache/bin/apachectl -k stop

oraexp.sh
Use a script that is similar to the example oraexp.sh script to export the
Windchill schema from your source Oracle database to a dump file.
To do the export, the person running the script must be a user with database
administrator (DBA) privileges and the user who installed Oracle must have read
and write access permissions to the dump directory specified in the script DUMP_
DIR variable. Also, the script must set the correct schema SID, schema user, and
two passwords:
• SCHEMA_PASS is the password of the scheme user.
• SYSDBA_PASS is the password of the user running the script (the DBA).
The example script calls the data_pump.sql file. The details on that file are
provided in the data_pump.sql subsection after the example.
The script assumes that the dump file is created in the dump directory defined by
DUMP_DIR. If a staging directory exists with the required permissions, set
DUMP_DIR to that directory (for example, /misc/staging).
Example oraexp.sh script (formatted to fit the page):
#!/bin/sh

# modify these as needed

Rehost Utility Script Examples 197

ORACLE_HOME="/ptc/oracle/product/11.2.0/dbhome_1"

SCHEMA_SID="wind1"
SCHEMA_USER="wcadmin"
SCHEMA_PASS="wcadmin"
SYSDBA_PASS="Manager2"
DUMP_DIR="dmpdir"

$ORACLE_HOME/bin/sqlplus system/$SYSDBA_PASS@$SCHEMA_SID @data_pump.sql

$ORACLE_HOME/bin/expdp $SCHEMA_USER/$SCHEMA_PASS@$SCHEMA_SID
directory=$DUMP_DIR dumpfile=$SCHEMA_USER.dmp

Make any adjustments to the script to fit your environment. For example, use the
existing DATA_PUMP_DIR instead of dmpdir:
DATA_PUMP_DIR = $ORACLE_INVENTORY/../admin/wind10/dpdump/

data_pump.sql
The following SQL statements create a suitable staging area:
CREATE OR REPLACE DIRECTORY dmpdir AS '/misc/staging';
GRANT read, write ON DIRECTORY dmpdir TO wcadmin;

The SQL statement assumes:

• wcadmin is the Windchill schema owner.
• misc/staging must exist and be writable.

198 Rehost Utility Guide

oraimp.sh
Use a script that is similar to the following script (which has been formatted to fit
the page) to import a dump file into an Oracle database. Set the correct schema
SID, user, and two passwords in the script. The script assumes that the dump file
is located in the defined dump directory.
#!/bin/sh
# modify these as needed
ORACLE_HOME="/ptc/oracle/product/11.2.0/dbhome_1"
SCHEMA_SID="wind2"
SCHEMA_USER="wcadmin"
SCHEMA_PASS="wcadmin"
SYSTEM_PASS="Manager2"
DUMP_DIR="dmpdir"
USER_TBLSPACE=USERS
$ORACLE_HOME/bin/sqlplus system/$SYSTEM_PASS@$SCHEMA_SID @data_pump.sql
$ORACLE_HOME/bin/impdp system/$SYSTEM_PASS@$SCHEMA_SID directory=$DUMP_DIR
dumpfile=$SCHEMA_USER.dmp TABLESPACES=$USER_TBLSPACE
RESULT=$?
if [[ $RESULT != 5 && $RESULT != 0 ]]
then
exit $RESULT
fi
$ORACLE_HOME/bin/impdp system/$SYSTEM_PASS@$SCHEMA_SID directory=$DUMP_DIR
dumpfile=$SCHEMA_USER.dmp
RESULT=$?
if [[ $RESULT != 5 && $RESULT != 0 ]]
then
exit $RESULT
fi

Note
The imported schema that is a result of running this script can have invalid
Oracle packages. Verify all Oracle packages after the utility has concluded and
recompile any invalidated packages.

Rehost Utility Script Examples 199

orauser.sh
Use a script that is similar to the example orauser.sh script to drop an existing
user and create a new user for an Oracle database.
To drop and create users, the person running the script must be a user with
database administrator (DBA) privileges. Also, the script must set the correct
schema SID, schema user, and two passwords:
• SCHEMA_PASS is the password of the scheme user.
• SYSDBA_PASS is the password of the user running the script (the DBA).
The script calls the two SQL files provided as subsections after this example:
drop_user.sql and create_user.sql.
Example orauser.sh script:
#!/bin/sh

# modify these as needed

ORACLE_HOME="/ptc/oracle/product/11.2.0/dbhome_1"

SCHEMA_SID="wind1"
SCHEMA_USER="wcadmin"
SCHEMA_PASS="wcadmin"
SYSDBA_PASS="Manager2"

$ORACLE_HOME/bin/sqlplus system/$SYSDBA_PASS@$SCHEMA_SID @drop_user.sql

$ORACLE_HOME/bin/sqlplus system/$SYSDBA_PASS@$SCHEMA_SID @create_user.sql

drop_user.sql
The following SQL statement drops user “wcadmin”:
drop user wcadmin cascade;

create_user.sql
The following SQL statements create user “wcadmin” (formatted to fit the page):
create user wcadmin identified by wcadmin default tablespace USERS
temporary tablespace TEMP quota unlimited on USERS;
grant connect, resource, create sequence, create view, query rewrite wcadmin;

200 Rehost Utility Guide

wcclear.sh
Use a script similar to the following script to move existing logs and compiled
tasks into the staging area for archival.
Example wcclear.sh script (formatted to fit the page):
# modify these as needed
WT_HOME="/ptc/Windchill10/Windchill"
STAGING="/misc/staging"

mv $WT_HOME/logs $STAGING/logs_old
mv $WT_HOME/tasks/codebase/com/infoengine/compiledTasks
$STAGING/compiledTasks_old

tar -czvf $STAGING/backup.tar.gz $STAGING/logs_old

$STAGING/compiledTasks_old

rm -rf $STAGING/logs_old
rm -rf $STAGING/compiledTasks_old

$WT_HOME/ant/bin/ant -f $WT_HOME/codebase/MakeJar.xml

mkdir -p $WT_HOME/logs
mkdir -p $WT_HOME/tasks/codebase/com/infoengine/compiledTasks

Rehost Utility Script Examples 201

windchillStart.sh
Use a script similar to the following script (which has been formatted to fit the
page) to start Windchill from a UNIX or Linux system.

Note
The windchillStart.sh file as documented here is included in the
scripts directory where the utility is installed.

The script starts Apache and then calls the Windchill start command and waits
until Windchill has completed startup before proceeding to execute any additional
modules. The wait is accomplished by executing a sleep command.
The variables used in the script are either obtained from the utility or set in the
script.
windchillStart.sh (formatted to fit on the page):
#!/bin/bash
# apache_home env variable is set by the rehost utility
$apache_home/bin/apachectl start

windchill start

# wait for 120 seconds for MethodServer to start

sleep 120

windchillStop.sh
Use a script similar to the following script to stop Windchill from a UNIX or
Linux system.
The script calls the Windchill stop command. Execute this script before executing
modules that require that Windchill not be running.
The variables used in the script are either obtained from the utility or set in the
script.
windchillStop.sh:
#!/bin/bash
# required variables are set by the rehost utility

windchill stop

202 Rehost Utility Guide

Using the xconfmanager Utility in a Script
A rehost script can execute the xconfmanager utility to set properties in your
Windchill environment using the Script module.
For the script to run with any number of properties, use the following
xconfmanager command syntax:
xconfmanager --setfromfile <property_file> -t <target_prop_file> -p

where:
<property_file> is the full file path of a file that has each property
<name>=<value> pair to be set. Enter each pair on a single line.
<target_prop_file> is the path of the Windchill property file where the
resulting properties are set.
For additional information about the xconfmanager utility, see "About the
xconfmanager Utility” in the Windchill Help Center.
Depending on which rehost scenario is being executed, there may be site-specific
properties that need to be set on the target system. For example, properties specific
to the target system can be automatically set by entering them in the property file
included in the xconfmanager command described previously.
For example, some sites may want to include the wt.auth.trustedHosts
property. This property is used for setting trusted clients that are local to the server
host.

Rehost Utility Script Examples 203

 A
Pro/Intralink Rehost Support

External Database Embedded Database

Scenario
Installation Installation
Move Supported Supported
Clone Supported Supported
Rehost Supported Supported
Rename Supported Not supported

Note
Embedded database installation on a target machine is a prerequisite for Move,
Clone and Rehost scenarios. Migrating an embedded database from a source
system directly to target system is not supported. The migration can be
achieved by importing or exporting the database.

204 Rehost Utility Guide

 B
Rehosting Windchill with
Configured PTC System Monitor
The Windchill Rehost Utility enables you to reconfigure a rehosted Windchill
system with the PTC System Monitor (PSM) agent installed on a new PSM server
and collector. You can reconfigure the rehosted Windchill system by changing the
PSM server and collector name, and ports using a PSM task.
Rehosting of the PSM server and collector is not supported. You need to install a
new PSM server, with its own Performance Warehouse, and collector, on the new
system.
If a Windchill system (source) with a configured PSM agent is rehosted, the PSM
agent does not work with the target Windchill system. To connect a target
Windchill system to the existing PSM server, run the PSM Installer and install a
new agent on the Windchill system. Monitoring rehosted systems using an
existing PSM server is as effective as monitoring multiple Windchill
environments. For more information, refer to the Monitoring Two Different
Versions of Windchill Applications topic in the PTC System Monitor
Administration and Usage Guide – Windchill.

Configuration Properties File for PTC System Monitor

The following properties must be updated in the rehost.properties file in
order to configure PTC System Monitor with Rehosting Windchill.
target.psm.collector.hostname=<psm_collector_hostname>
target.psm.collector.port=<psm_collector_port>
target.psm.server.hostname=<psm_server_hostname>
target.psm.server.port=<psm_server_port>
target.psm.protocol=http

205
Supported Rehosting Scenarios
• Cloning
If a Windchill system with a configured PSM agent is cloned, the PSM agent
continues to work with the cloned system. However, all cloned systems point
to the same system profile and you cannot view reliable data in PSM. If you
make multiple clones, each Windchill clone should point to the unique system
profile for that Windchill clone, in PSM. Monitoring cloned systems is as
effective as monitoring multiple Windchill environments. For more
information, refer to the Monitoring Two Different Versions of Windchill
Applications topic in the PTC System Monitor Administration and Usage
Guide – Windchill.
• Moving
When the Windchill source and target systems are located on different
platforms, uninstall the PSM agent from the source system, and then perform
the move scenario. After completing move, reinstall the PSM agent on the
target system.
To view historical data that is stored after a Windchill system is rehosted, cloned,
or moved, store the entire data as a session and export the session to the desired
location. The stored session can be used to import on the PSM client.
To view historical data which is stored as sessions, perform the following:
• Right-click System Profile and select Session Storage ▶ Export Session.
• Right-click Session Storage and select Import Session.
For more information, refer to Exporting an Entire Session section in the PTC
System Monitor Administration and Usage Guide – Windchill.

206 Rehost Utility Guide