I'm writing this entry to share my experiences with remote master vaults and publishing. My company migrated data into a single instance of Windchill from several different Intralink systems from design centers all around the world. One of the remote design centers was large and would be sending a lot of data over the WAN to our existing single Windchill master vault. We planned to install a file (replication) server at the remote location, but we also investigated adding a second master vault to the system at this remote site. In the end, we went with a second master vault since most of that content would only be used by the design center where the remote server and vault were. We also had the IT infrastructure there to manage the server and vault.
Benefits to remote master vault: 1. When we migrated their data initially from Intralink, we didn't have to move it to the master around the world, either over the WAN or by shipping a storage device. Throughout the migration process, the large amount of data never had to be moved out of the LAN. We later replicated latest iterations of each version to a replica vault on the main server, but replicating only latest significantly reduced volume. 2. WAN traffic can be reduced and optimized going forward after initial migration.
Challenges to a remote master vault: 1. Backups must now be performed on a schedule on the remote master as well as the central master vault. This is usually an easy obstacle to overcome. 2. Extra effort is required to setup vaulting and replication rules. 3. Remote or Distributed File Server (DFS) publishing must be setup for content in the remote vault or all the large content files end up being moved to the publishing workers which are probably near your master/central server across the WAN. If remote publishing isn't used, you are defeating the purpose of a remote master.
DFS Publishing only works with file synchronization capable workers, e.g. Creo Parametric workers. A rule is used to ensure that content from the remote site is always published on the remote workers, but I have seen content from the remote site publish on the main workers when the user doesn't have his preferred file server set to the remote site. The preferred file server setting for the user initiating the publishing seems to override the publishing rule and the preferred file server of the publishing user (specified in the auth.properties file) created during the DFS setup process.
In general, my experience with remote master vaults has been positive. We haven't experienced any problems with it, and it does reduce WAN traffic while users are active on the system. We end up replicating most of the data to our main site replica vault, but since we schedule that during off-hours, the impact on user performance is not a problem. Remote publishing does seem to reduce the need to copy the heavy content files across the WAN for the sole purpose of publishing, but I'm not sure it eliminates it completely. It seems as though there are some files that still must be copied across the WAN, either before or after publishing. We also use the UploadToFileServerHook described here: https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS110300. Implementing this allows the lightweight published files to be stored in the remote server vault instead of being copied back to the main master vault after publishing, but it increases the time to process each publishing job. Possibly due to communication required between the main server and the remote worker, publishing on the remote worker takes 2-3 times longer than it does on the worker that is close to the main server (on the same LAN). A thorough analysis of the network traffic hasn't been performed, so I can't say precisely how much WAN traffic has been reduced over publishing on the main workers.
The PTC Vaulting and Replication Tech Brief contains a detailed explanation of the Windchill vaulting capabilities: http://support.ptc.com/WCMS/files/123336/en/WindchillVaultReplication.pdf
