Setting up a secured vault in a remote location

[Manav_Pampher]

I am using Windchill PDMLink Release 11.1 and Datecode with CPS M020-CPS27

Hi,

Our Windchill environment is hosted in Netherlands.
We need to setup a product/project container in our windchill environment. The data within this container is supposed to be stored (cached and mastered) only in UK.
We are exploring setting up a local vault in UK or a replica file server in UK, but there are some challenges related to this.
We need advise on what is the best PTC recommended approach for this requirement.

[BenLoosli]

A replica vault will still upload files to the main server.

You would have to setup a separate vault server and establish rules that only certain files must be stored in the new vault.

Can others in the company still access or see the UK only files?

[Manav_Pampher]

Hi @BenLoosli 

Others in the company can not access or see UK only files.

[mmeadows-3]

What are the content sharing rules between the Netherlands and UK?

• Just share the Windchill database?
• UK content is exclusive to UK but Netherlands content is accessible to Netherlands and UK?
• UK content is exclusive to UK and Netherlands content is exclusive to Netherlands?
• Other?

[Manav_Pampher]

Hi @mmeadows-3 

In our environment, most of the data is being shared across UK and Netherlands.

There is only one program in UK for which we will be creating a separate container.

The data for this container only needs to reside in UK.

Meta data sharing to NL is acceptable.

[mmeadows-3]

I think the terminology you want is Remote Master Vault.

Remote Master Vault – In release 9.1, new functionality was added that allows
master vaults to be configured at remote sites (see What's New in Windchill
9.1 for more information). Each master vault is a primary repository with
original content that must be backed up and recovered in synchronization with
the primary repositories at the main site. 

The PDF illustrates how it works architecturally.

1. Create separate master vaults in the UK and Netherlands.

• Define vaulting rules so anything created in the UK products/libraries/projects go to the UK master vault.
• Define vaulting rules so anything created in the Netherlands products/libraries/projects go to the Netherlands master vault.

2. Create a replica vault on the UK replica server for files replicated from the Netherlands.

• Define replication rules or use predictive replication to copy files from the Netherlands master vault to the UK replica vault.

3. Create a replica upload cache vault on both master and replica server for files uploaded by local users.

• Set the user preference (Vaulting and Replication > Preferred File Server) for all users, especially UK users.

windchill wt.preference.SetPreferenceUtility -u wcadmin -p wcadmin -name /wt/content/contentCacheSite -value {vault name} -user {username}

Otherwise, a UK user pointing to "master" will upload to the Netherlands' cache vault.

Note: Creating dedicated replica cache vaults isn't required.  You can mark each master vault as the default cache vault for the site.

However, automatic vault cleanup only functions against replica vaults.  Remove unreferenced files against master vaults must be performed manually and can take a long time for larger root folder structures.

Implementing a replica upload cache vault helps keep the master vaults clean.

Setting the preference is required.

[mmeadows-3]

If there are other replica servers already in play and you need to reset your users' preferred file server preference...

-- Report all defined Preferred File Server values not set to 'main'
select wtu.name, pd.name, pi.value, pi.idA2A2
from WTUser wtu, PreferenceInstance pi, PreferenceDefinition pd 
where wtu.idA2A2=pi.idA3B4 and pi.idA3A4=pd.idA2A2 and pd.name='/wt/content/contentCacheSite' and not pi.value='main'
order by pi.value, wtu.name;

-- Delete all defined Preferred File Server values not set to 'main'
delete from PreferenceInstance where idA2A2 in (select pi.idA2A2
from WTUser wtu, PreferenceInstance pi, PreferenceDefinition pd 
where wtu.idA2A2=pi.idA3B4 and pi.idA3A4=pd.idA2A2 and pd.name='/wt/content/contentCacheSite' and not pi.value='main');

-- Confirm only 'main' remain
select wtu.name, pd.name, pi.value, pi.idA2A2
from WTUser wtu, PreferenceInstance pi, PreferenceDefinition pd 
where wtu.idA2A2=pi.idA3B4 and pi.idA3A4=pd.idA2A2 and pd.name='/wt/content/contentCacheSite'
order by pi.value, wtu.name;
-- Note: Only returns entries where the user has overridden the default value of preferred file server.
-- If not listed, the user is inheriting the default 'main' value.

[rhart]

Another option is to configure security labels, you can define a separate site principle (system user account) for each vault then add the principal to the security label group. Data with NL security label are uploaded to NL cache/vault by principal. Data with UK eyes only label are uploaded to UK vault by UK principal. Data with UK label can’t go to the NL vault because the NL principal can’t access it.

[mmeadows-3]

Setting up security labels can be fun, but @rhart offers a better solution than relying on the user's preferred file server (a preference the users can change).