We have 4 sites (2 US, 1 NL, 1 TW)
NL is the main site.
Main reason to consolidate to 1 site is Global Change management. We do however have many NX users round the globe too.
We are looking into best practices here. So use VDI/Remote desktop or Rich Client (AWC) using Cache and store and forward.
All sites have the same configuration and TC version, that should not be a problem.
Formal data is synchronized accross the sites. Design data is not :-)
Any experienecs and tips are welcome to join the discussion here!
The easiest to maintain is VDI, since updating Tc is really cumbersome if you need to migrate multiple sites at once.
Production: NX10.0.3, VERICUT 8.0, FBM, MRL 3.1.4 | TcUA 10.1 MP7 Patch 0 (10.1.7.0) | TcVis 10.1
Development: VB.NET, Tcl/Tk Testing: NX11.0 EAP, NX12.0 EAP
How to Get the Most from Your Signature in the Community
The site consolidation tools are your best friend here, anything that employs low-level tcxml, which includes cvs2tcxml. Jamie Griffis is the current reigning champion with csv2tcxml and provides terrific advice and support to the community. The site consolidation tools require authorization\certification which can only be obtained by attending the Siemens week-long class.
Consolidating to NL is a great choice and having remote FSC's configured for store and forward to support NX is also perfect.
The client flavors should either be scripted w/TEM as a silent install, configured in OTW (distributed across local and remote FSC's running RMI/Distro services as appropriate), or entirely within Active Workspace (pushes the envelop here).
Avoiding Dispatcher for store and forward volume syncing is less hassle. Use move_volume_files as a scheduled task or cron to maintain better quality control and dependability.
Of course these are not the only strategies you need to consider but do answer the major questions you'll have during the site consolidation. There are a lot more once you step into the weeds.
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
I agree with Randy and have already done all of what he's proposing for the company I work for.
I doubly agree with the recommendation to not use the Dispatcher Store and Forward and use a scripted move_volume_files utility instead. I've tried the S&F, and it was a PITA. Now I use move_volume_files on a scheduled task, and there have been no problems.
Thanks Randy, appreciate your feedback and suggestions, sure will take this!
But what about a first step, how to come to a consolidated database.
We maintain our 4 sites (configuration wise) in a well structured way. Configuration is maintained using SVN and all sites are equal with respect to this configuration.
Even users are defined on all sites (still using the "manual" tolling like create_user). Groups also are available on all sites. The only thing we do not maintain is membership in groups.
Official parts (with BOM, drawings, etc) are unique globally. because we have a number generator outside TC (in SAP) which makes sure the parts created at each site are unique.
And our NL site is the hub, containing all these offical parts, since scripting at night takes care on replicating and synchronzing this data.
Simple thought could be, just get rid of the export records and you have consolidated most data :-)
There is however quite some local design data not being replicated. So this at least must be looked into too.
And most important, end user experience. You can cache and store forward the volume data, but working with meta data goes direct to the central database.
We wonder how people experience this, working with structures like MPP or Change Objects.
Our US sites are in San Diego and Wilton (CT). latency ~160ms and ~100ms from NL Veldhoven.
Would be nice to hear about this.
User experience will certainly be impacted if they are currently using better latencies and you make them go to higher latencies.
For example, we have users that have two Teamcenter environments to connect to: one hosted in the US and one hosted in Germany. The US latency is <1ms for LAN users and ~30-40ms for remote WAN users. The Germany latency is over 100ms. The performance difference is VERY noticable to the users. What might have taken a minute or two in one system takes upwards of 20 minutes in the other. Yes, it works but the users groan when they have to use the slower one.
NX 11.0.1.mp01 | SW 2016 | TcUA 11.2.3
Can you explain or give examples in what you mean with :
Rich Client only. S&F wasn't part of my point about performance issue regarding latency and user experience since the FCCs are populated in the users computers for best read performance and have local volumes to save their data (for best save performance) that are then forwarded/moved to the final volume later.
I was mainly referring to the point that users will notice a performance degradation when if they go from a low latency environment to a higher one. It's a relative issue. Although 100+ms latencies are considered acceptable by IT folks and any end user that has only ever known 100+ ms latencies, those users that are accustomed to lower latencies will indeed notice the difference when made to use a higher latency.