Showing results for 
Search instead for 
Do you mean 

Cloning PROD TC environment on a regular basis

We have a desire to create a new Teamcenter environment, which we would call SUPPORT. It would be a full clone of our production environment (config, data model, volume data, etc) with regular (weekly?) refreshes to keep it in sync with PROD. It would be used by our engineering users to develop new NX automations and processes without polluting data. The SUPPORT environment would not need to be architecturally identical to PROD, but should be identical from a configuration and content perspective.


We are on TC 10.1 running on .NET and MS SQL.


Is anyone doing this now, and would you willing to share your recommendations with me?


Re: Cloning PROD TC environment on a regular basis

There are a lot of people doing this now and is a standard practice to have a DEV to TST to PRD deployment methodology. While it is a good practice to have TST (or SERVICE) be architecturally the same as PRD to avoid deployment issues related to the architecture, it is not mandatory. They can be dissimilar as long as you make corrections to FMS to accommodate any distributed volumes. GTAC has some good documentation on how to clone an environment and the newest releases of Teamcenter are clone capable through TEM. Although they are restricted from moving content back up the chain to PRD. Many of us "services" type people have our own method (proprietary) for cloning environments. Start with GTAC (or TEM in 11.2.x).

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Cloning PROD TC environment on a regular basis

Thanks Randy. We do indeed have a DEV -> TEST -> UAT -> PROD environment chain in our Teamcenter development lifecycle. UAT is end-user acceptance testing and is architecturally identical to PROD.


What we are really wanting is a SUPPORT environment, that comes after PROD in the above chain. it's just like prod, updated ... daily? weekly? ... that can be used to diagnose production issues with production data, and also to allow the business to 'experiment' with their own data, and we don't want them in our DEV/TEST/UAT environments because they are NOT configured like PROD (that's where we are updating the data model, creating new workflows, etc).


So not only do I want to clone an environment, at least far as configuration goes, but also update the content. Clearly, jiggering around the volume stuff would be a part of that. Our PROD environment has three remote volumes overseas and I'm not sure we want to duplicate that in SUPPORT (although we did in UAT).


Re: Cloning PROD TC environment on a regular basis

The process is identical to cloning the TST environment. Instead of being part of your deployment cycle it will live outside. Just like a Training (TRN) environment lives outside the cycle. TRN may be updated every six months and then "reset" every week after training is completed. SUPPORT would be cloned every week (wiping out any work done the previous week). Your main challenge is going to be resyncing the volumes (especially from the ones overseas). Replacing the database is fairly straight forward. After replacing the database then you have to reset a handful of preferences. But since most of your cloning chores were completed during the "initial" cloning then the "delta" cloning shouldn't be too much to handle on a weekly basis. The delta cloning can probably even be scripted.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2

Re: Cloning PROD TC environment on a regular basis

Do a backup & Recovery Process


  1. Take backup of Prod database, volume, tcdata folders. 
  2. Install a new database and create new instance name(tceng_prod) same as prod. Match file size of db & log files. During the creation of database, there will be errors regarding the user (infodba). This error can be neglected. If there is not sufficient space need to shrienk db.
  3. Intstall fresh TC server & created new tcdata. Apply Patch.
  4. Copy prod tc_data files except profilevars. Do not merge folders but delete old files first.
  5. Copy volume files to new volume
  6. Restore Database from prod  backup files
    1. - open default database as different
    2. If you get db in use erroe change to single user in file properties of database.
  7. In organization modify new server path for volume first then change new path with no moving files.
  8. Modify site ID  in database using attached ppt.

Command for changing site id

UPDATE POM_BOOT SET site = old site id

Remember to also update this site ID in fsc master wherever this is used as import site.

  1. Update trans vol id as per backupxmlinfo

Check transient volume entry in fmsmaster file.

<fsc id="FSC_cinsun4_v10002a1" address="http://cinsun4:44021">

<transientvolume id="f4986a4ab9b155d11da1afceb35f55ac" root="/m/v10002/transientVolume_v10002a" />


  1. Check tc variables Transient_Volume_RootDir environment variable, Transient_Volume_Installation_Location environment variable/preference
  2. Check transientvolumeid  using backup_xmlinfo -u=infodba -p=infodba -g=dba

Default transient vol ID & tran vol ID should be same and update same in fms master from backupinfo.

  1. Scan volume in using temp install.
  2. Update preferances –
    1. Fsc_url
    2. fms bootstrap
    3. transientvolumeinstallationlocation
    4. default transient server

While changing value be careful to press modify twice in value fiels and for preference itself.

  1. Restart fms
  2. Update client fsc parent
  3. Test dataset creation & whole.

Re: Cloning PROD TC environment on a regular basis

Your process is incomplete. But has MOST of the major steps listed. Also your ppt attachment mentioned in step 8 is missing.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Evaluating:AW 3.2