Skip to main content
S
sandy0077-Bedrock
7-Bedrock
August 29, 2025
Solved

did anyone try windchill rehost utility that's coming with Windchill version 12.0 PDMLINK

  • August 29, 2025
  • 1 reply
  • 1184 views

we are doing windchill rehosting of our dev environment (Windows based). we have filled all the required data in the rehost.properties file but we are stuck at vault section.

 

what does those '0' and '1' means in the attached snap vault_properties.png?

we have master vault and a replica as shown in below snap

sandy007_0-1756451950203.png

 

Windchill version 12.0.2.7 

 

Thanks,

Sandeep.

 

Best answer by mmeadows-3

User account must be repaired in Windchill to match against the Dev ldap before they can attempt to login.

Disconnected participants with assigned licenses still consume those licenses.  It only shows four consumed 'access' licenses, 2 base and 2 advanced.

Your first screenshot shows a 500 error/licensing exception/unauthorized message.  So, I'm guessing the account you are logging in with has been repaired, but is not licensed.

Search PTC's knowledge base for the error you are getting on login.

1 reply

M
mmeadows-316-Pearl
16-Pearl
August 29, 2025

Vaults rehosting is per vault mount.  Each number defines a different mount location.

 

Say your production system points to network locations like this:

0) defaultuploadrootfolder: \\\{production vault server}\D$\PTC\Vaults\defaultuploadrootfolder

1) defaultsystemrootfolder: \\\{production vault server}\D$\PTC\Vaults\defaultsystemrootfolder

2) defaultsystemrootfolder2: \\\{production vault server}\E$\PTC\Vaults\defaultsystemrootfolder2

 

And development looks the same (except with different mount paths).

0) defaultuploadrootfolder: \\\{development vault server}\M$\PTC\Vaults\defaultuploadrootfolder

1) defaultsystemrootfolder: \\\{development vault server}\M$\PTC\Vaults\defaultsystemrootfolder

2) defaultsystemrootfolder2: \\\{development vault server}\N$\PTC\Vaults\defaultsystemrootfolder2

 

Assuming you already cloned the file vaults from production to development locations, your rehost script snippet will look like this.

 

### FileVault Settings ###
target.fv.required=true
source.fv.path.0=\\\{production vault server}\D$\PTC\Vaults\defaultuploadrootfolder
staging.fv.path.0=\\\{development vault server}\M$\PTC\Vaults\defaultuploadrootfolder
target.fv.path.0=\\\{development vault server}\M$\PTC\Vaults\defaultuploadrootfolder
source.fv.path.1=\\\{production vault server}\D$\PTC\Vaults\defaultsystemrootfolder
staging.fv.path.1=\\\{development vault server}\M$\PTC\Vaults\defaultsystemrootfolder
target.fv.path.1=\\\{development vault server}\M$\PTC\Vaults\defaultsystemrootfolder
source.fv.path.2=\\\{production vault server}\E$\PTC\Vaults\defaultsystemrootfolder2
staging.fv.path.2=\\\{development vault server}\N$\PTC\Vaults\defaultsystemrootfolder2
target.fv.path.2=\\\{development vault server}\N$\PTC\Vaults\defaultsystemrootfolder2


### Vault Host Settings ###
source.fv.hostname.0=windchill.acme.com
target.fv.hostname.0=windchill-dev.acme.com

 

If the file vaults are on the local server and in the same paths, then just make all three values match.  Or try excluding them entirely and just populating the Vault Host Settings.

 

### FileVault Settings ###
target.fv.required=true
source.fv.path.0=D:\PTC\Vaults\defaultuploadrootfolder
staging.fv.path.0=D:\PTC\Vaults\defaultuploadrootfolder
target.fv.path.0=D:\PTC\Vaults\defaultuploadrootfolder
source.fv.path.1=D:\PTC\Vaults\defaultsystemrootfolder
staging.fv.path.1=D:\PTC\Vaults\defaultsystemrootfolder
target.fv.path.1=D:\PTC\Vaults\defaultsystemrootfolder
source.fv.path.2=E:\PTC\Vaults\defaultsystemrootfolder2
staging.fv.path.2=E:\PTC\Vaults\defaultsystemrootfolder2
target.fv.path.2=E:\PTC\Vaults\defaultsystemrootfolder2


### Vault Host Settings ###
source.fv.hostname.0=windchill.acme.com
target.fv.hostname.0=windchill-dev.acme.com

 

I believe setting staging.fv.path.# is optional if the staging and final location are the same.  The rehost guide will say for certain.

S
sandy0077-BedrockAuthor
7-Bedrock
August 29, 2025

Hi @mmeadows-3 thank you for brief explanation.

 

I have few more questions.

 

1. the vault is configured on the same server where application is installed. so the path you have mentioned in the 2nd scenario will be applicable right?  and also the vault folder should be copied from prod to dev server ? 

sandy007_0-1756475363598.png

 

2. what are the efficient ways to copy the vault drive (80GBs) from production to development windchill servers (both are hosted on different VMs). Eg. below both the drives are for vaulting for production.

 

sandy007_1-1756475529262.png

 

Thanks.

 

M
mmeadows-316-Pearl
16-Pearl
August 30, 2025

1. Yes.

Per your images, it appears the system is using the default upload vault and it resides inside the Windchill load point.  The master vault has a read-only root folder mount on the E drive and a read-write root folder mount on the F drive?  The clearer picture would be the mount paths from Site > Utilities > Vault Configuration > Site > Master > Root Folders.

 

Provided drive letters and paths are not changing, you can just change the host names and not worry about path mappings.

 

### Vault Host Settings ###
source.fv.hostname.0={(as DB user) select hostname from FvHost where hostname not in ('masterDefault');}
target.fv.hostname.0={match syntax of source (server name or FQDN)}

 

Observations...

A. You can also skip file vault rehosting in the rehosting script and just do it by hand through the the Site > Utilities > Vault Configuration page.  If you are doing it just once, do it by hand (3 minutes effort).  If you are planning to rehost the dev system regularly, invest the time to use the rehosting script.  Really, in your situation, assuming all the drives and paths don't change, all you are doing is renaming the master site's host. In Dev, after finishing the rehosting script, select Site > Utilities > Vault Configuration > Sites > Master > Hosts > double click on FQDN and rename it to the Dev server's name.

 

B. Always remove unreferenced files from production before cloning the database and file vaults to reduce the amount of content to copy.  The database and file vaults must be in sync for a clean rehosting.

 

C. Using the default upload vault is a good practice.  Leaving the default upload vault mapped to the OOTB default location is not recommended.  PTC's perspective is they "own" the Windchill load point and it is their prerogative to change it at any time through software updates and upgrades.  They have never moved the OOTB file vaults location and likely won't.  But we should adhere to their perspective and place the file vaults somewhere outside of the Windchill_12.0 folder like D:\PTC\Vaults.  Using the OOTB file vaults mappings also impacts temporary backup restore point copies of the Windchill load point.  The current configuration unnecessarily includes however much content is in the default upload vault.

 

D. For an identical clone (what you are doing), all the file vaults need to be cloned to the Dev environment.  Otherwise, Windchill will throw errors when a developer tries to retrieve data.

 

E. If disk space is an issue, the rehosting script can perform a partial vaults content rehosting, but it is terribly tedious to setup.  I've used it before and relocated all my Development file vaults to D:\PTC\Vaults, eliminating additional vault partitions: E and F.  Windchill needs the full folder structure for each root folder.  The content files are only necessary when attempting to open content objects.  The greatest challenge is copying administrative content objects like templates and other site/org level content.  The entire process is just messy.

 

 

2. Through the Windows UI, use robocopy.

First, remove unreferenced files from production.  Then run Robocopy.

Minimize robocopy logging will product the fastest robocopy command to clone Windchill file vault data .

robocopy  /mir /mt:128 /ns /nc /ndl /nfl /np /r:1 /w:1 /log:C:\temp\robocopy.log {source path} {target path} /xd .unreferenced MOUNT_VALIDATION_DATA

 

IT can do full server clones and may have block-level copy capabilities (e.g. restore from backup) that would be faster for a single volume.  But it usually takes longer to get a response out of IT than it does to run Robocopy to completion.  Depending on your infrastructure, robocopy can clone 80 GB in just a few minutes and 2 TB in less than an hour.

Terms & ConditionsCookie settingsAccessibility statement