System - Admin TC

Teamcenter 14.
System
Administration
Teamcenter 14.0
PLM00102 - 14.0
Unpublished work. © 2021 Siemens
This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software, Inc., its
subsidiaries or its affiliates (collectively, "Siemens"), or its licensors. Access to and use of this information is strictly limited as set
forth in Customer's applicable agreement with Siemens. This material may not be copied, distributed, or otherwise disclosed
outside of Customer's facilities without the express written permission of Siemens, and may not be used in any way not
expressly authorized by Siemens.
This document is for information and instruction purposes only. Siemens reserves the right to make changes in specifications
and other information contained in this publication without prior notice, and the reader should, in all cases, consult Siemens to
determine whether any changes have been made. Representations about products, features or functionality in this document
constitute technical information, not a warranty or guarantee, and shall not give rise to any liability of Siemens whatsoever.
Siemens disclaims all warranties including, without limitation, the implied warranties of merchantability and fitness for a
particular purpose. In particular, Siemens does not warrant that the operation of the products will be uninterrupted or error
free.
The terms and conditions governing the sale and licensing of Siemens products are set forth in written agreements between
Siemens and its customers. Siemens' End User License Agreement and Universal Contract Agreement may be viewed at: https://
www.sw.siemens.com/en-US/sw-terms/
TRADEMARKS: The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or other parties. No
one is permitted to use these Marks without the prior written consent of Siemens or the owner of the Marks, as applicable. The
use herein of third party Marks is not an attempt to indicate Siemens as a source of a product, but is intended to indicate a
product from, or associated with, a particular third party. A list of Siemens' trademarks may be viewed at:
www.plm.automation.siemens.com/global/en/legal/trademarks.html. The registered trademark Linux® is used pursuant to a
sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.
About Siemens Digital Industries Software

Siemens Digital Industries Software is a leading global provider of product life cycle management (PLM) software and services
with 7 million licensed seats and 71,000 customers worldwide. Headquartered in Plano, Texas, Siemens Digital Industries
Software works collaboratively with companies to deliver open solutions that help them turn more ideas into successful
products. For more information on Siemens Digital Industries Software products and services, visit www.siemens.com/plm.
Support Center: support.sw.siemens.com
Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form

Contents
Teamcenter system administration 1-1
Maintaining Teamcenter servers

Scheduled maintenance for Teamcenter servers ───────────────── 2-1
Useful administration tools ─────────────────────────────── 2-3
Using process daemons ───────────────────────────────── 2-4
Set Oracle-dependent services to automatically restart ───────────── 2-5
Application process monitoring ──────────────────────────── 2-5
Maintaining the database server

Maintaining the Oracle database ─────────────────────────── 3-1
Tune the Oracle database ─────────────────────────────────── 3-1
Set the Oracle environment ────────────────────────────────── 3-1
Oracle services (Windows systems) ───────────────────────────── 3-3
Oracle processes (Linux systems) ─────────────────────────────── 3-9
Oracle database security (Windows systems) ─────────────────────── 3-16
Oracle database management ──────────────────────────────── 3-16
Delete Oracle databases (Windows systems) ─────────────────────── 3-18
Oracle semaphores (Linux systems) ──────────────────────────── 3-19
NLS_LANG environment variable ────────────────────────────── 3-22
Oracle initialization parameter files ───────────────────────────── 3-23
Oracle online documentation ──────────────────────────────── 3-25
Oracle Net implementation ────────────────────────────── 3-25
Oracle Net features ────────────────────────────────────── 3-25
Oracle Net configuration files ──────────────────────────────── 3-26
Oracle Net Configuration Assistant ───────────────────────────── 3-27
Oracle Net service resolution on Teamcenter clients ────────────────── 3-27
Maintaining the Microsoft SQL Server database ───────────────── 3-28
Tune the Microsoft SQL Server database ────────────────────────── 3-28
Start the SQL Server service ───────────────────────────────── 3-28
Shut down the SQL Server service ───────────────────────────── 3-29
SQL Server database security ──────────────────────────────── 3-29
Delete the SQL Server database ─────────────────────────────── 3-29
View the SQL Server error logs ─────────────────────────────── 3-29
Server manager
What is a server manager? ─────────────────────────────── 4-1
Overview of installing the server manager ───────────────────── 4-2
Teamcenter Management Console ────────────────────────── 4-2
What is the Teamcenter Management Console? ────────────────────── 4-2
Install the Teamcenter Management Console ─────────────────────── 4-4
System Administration, Teamcenter 14.0 PLM00102 14.0 3

© 2021 Siemens
Configure the web app server for a Teamcenter Management Console web tier
component ─────────────────────────────────────── 4-6
Launch the Teamcenter Management Console ────────────────────── 4-11
Run the Teamcenter Management Console as a service ──────────────── 4-13
Modify settings of the Teamcenter Management Console ─────────────── 4-17
Administering pools with the Teamcenter Management Console ─────────── 4-18
Configure pool manager monitoring with the Teamcenter Management Console ─ 4-22
Configure server monitoring with the Teamcenter Management Console ────── 4-25
Administer logging levels with the Teamcenter Management Console ─────── 4-29
Administer the web tier with the Teamcenter Management Console ───────── 4-32
Administer tcserver instances in the Teamcenter Management Console ────── 4-34
Inactivate and activate a server pool ──────────────────────────── 4-36
Administer TcServer timeouts in the Teamcenter Management Console ────── 4-38
Administer embedded LDAP for Teamcenter Management Console ───────── 4-40
Server manager prerequisites ───────────────────────────── 4-54
Server manager properties files ─────────────────────────── 4-55
Overview of server manager property files ──────────────────────── 4-55
Server manager pool-specific configuration tuning ─────────────────── 4-56
Server manager database password ──────────────────────────── 4-63
Server manager monitoring ────────────────────────────── 4-63
Introduction to server manager monitoring ──────────────────────── 4-63
Pool manager monitoring ────────────────────────────────── 4-64
Teamcenter server monitoring ─────────────────────────────── 4-71
Server manager logging ──────────────────────────────── 4-77
Server manager logging levels ─────────────────────────────── 4-77
Configure server manager logging ───────────────────────────── 4-78
Restarting warm servers ──────────────────────────────── 4-80
Server Manager Troubleshooting ─────────────────────────── 4-81
Windows desktop heap may cause hang of TcServer processes ──────────── 4-81
Suse Linux UserTasksMax setting may need tuning ─────────────────── 4-82
Parse errors warning in Oracle trace log ────────────────────────── 4-82
Running the server manager on a machine separate from the corporate server
───────────────────────────────────────────── 4-83
File Management System

Introduction to File Management System ────────────────────── 5-1
Benefits of using FMS ─────────────────────────────────── 5-2
FMS components ────────────────────────────────────── 5-3
FMS server cache ──────────────────────────────────────── 5-3
FMS client cache ───────────────────────────────────────── 5-4
FMS configuration files ────────────────────────────────── 5-6
Introduction to FMS configuration files ─────────────────────────── 5-6
Editing FMS configuration files ──────────────────────────────── 5-6
FMS primary configuration file ──────────────────────────────── 5-7
FMS server configuration file ───────────────────────────────── 5-9
FMS client configuration file ───────────────────────────────── 5-20
Sizing FMS fast cache ────────────────────────────────── 5-27
4 PLM00102 14.0 System Administration, Teamcenter 14.0

© 2021 Siemens
Contents
Administering FMS ──────────────────────────────────── 5-28

Introduction to administering FMS ───────────────────────────── 5-28
Administering FSCs ────────────────────────────────────── 5-28
Administering FCCs ────────────────────────────────────── 5-40
Auditing FSCs ────────────────────────────────────────── 5-51
Configuring FMS ──────────────────────────────────────── 5-61
Administering transient volumes ────────────────────────────── 5-91
Administering volumes ──────────────────────────────────── 5-97
Load balancing FMS ───────────────────────────────────── 5-118
Using external hardware devices for load balancing ────────────────── 5-121
FMS client maps ─────────────────────────────────────── 5-127
Accessing multiple databases through a single FCC ────────────────── 5-131
Compressing FMS files ─────────────────────────────────── 5-134
Installing and configuring Data Share Manager ───────────────────── 5-137
Routing FSCs between sites ──────────────────────────────── 5-148
Accessing remote volumes using aliases (shared network) ────────────── 5-149
FMS monitoring ─────────────────────────────────────── 5-152
Verify that files are not corrupted during transmission ──────────────── 5-163
Enable SHA-256 digest algorithm for the ticket digest ───────────────── 5-166
Enable MD5 encryption for the ticket digest ─────────────────────── 5-167
Enable use of FIPS 140-2 cryptography in FMS ───────────────────── 5-167
Improving FSC cache performance ───────────────────────── 5-168
Sample FMS configurations ───────────────────────────── 5-169
About the sample FMS configurations ────────────────────────── 5-169
Sample LAN configurations ───────────────────────────────── 5-169
Remote user WAN configurations ───────────────────────────── 5-180
FSC primary server load balancing ──────────────────────────── 5-190
FCC LAN client failover configuration ─────────────────────────── 5-192
FSC clientmap DNS suffix configuration ───────────────────────── 5-195
FCC external load balancing configuration ─────────────────────── 5-198
FSC volume load balancing of FMS data configuration ──────────────── 5-201
FSC volume failover configuration ──────────────────────────── 5-202
FSC remote cache failover configuration ───────────────────────── 5-204
Alternate FSC remote cache failover configuration ─────────────────── 5-208
FSC remote multiple-level cache failover configuration ──────────────── 5-213
FSC remote multiple-level hot cache failover configuration ───────────── 5-219
FSC group import multisite routing configuration ─────────────────── 5-225
FMS shared network configuration ──────────────────────────── 5-227
Volume Management application

Getting started with Volume Management ───────────────────── 6-1
Introduction to Volume Management ──────────────────────────── 6-1
Before you begin ───────────────────────────────────────── 6-2
Volume Management interface ──────────────────────────────── 6-3
Configuring Volume Management ────────────────────────────── 6-8
Basic concepts about Volume Management ──────────────────────── 6-10
Basic tasks for Volume Management ──────────────────────────── 6-13
Monitoring volumes ─────────────────────────────────── 6-14

© 2021 Siemens
Introduction to monitoring volumes ──────────────────────────── 6-14
Retrieving volume information ─────────────────────────────── 6-15
Retrieving user information for a volume ───────────────────────── 6-16
Retrieving volume usage information ─────────────────────────── 6-18
How to monitor volumes ─────────────────────────────────── 6-20
Reallocate volume resources ───────────────────────────────── 6-22
Defining migration policies ────────────────────────────── 6-24
Migration policy options ─────────────────────────────────── 6-24
Define a VM policy by filters and metadata ──────────────────────── 6-26
Define a VM policy by watermark levels ────────────────────────── 6-28
Define a VM policy by moving all files ─────────────────────────── 6-29
Define an HSM policy to purge after migration ────────────────────── 6-30
Define an HSM policy to purge at watermark levels ─────────────────── 6-32
Define a Volume Management policy based on an existing policy ────────── 6-33
Deactivate a migration policy in Volume Management ───────────────── 6-34
Migrating volume data ───────────────────────────────── 6-34
Introduction to migrating volume data ─────────────────────────── 6-34
Preview migration results ─────────────────────────────────── 6-36
Migrate VM policy data using FMS-based migration ─────────────────── 6-36
Migrate VM policy data using basic migration ────────────────────── 6-37
Migrate HSM policy data using basic migration ────────────────────── 6-39
Migrate HSM policy data using API-based migration ─────────────────── 6-40
Volume Management migrated file set format ────────────────────── 6-41
Volume Management migration reports ────────────────────── 6-44
Introduction to generating volume migration reports ────────────────── 6-44
Generate a VM policy report ───────────────────────────────── 6-45
Generate an HSM policy report ─────────────────────────────── 6-46
Generate a report on all policies ────────────────────────────── 6-46
Administering Teamcenter client communication system (TCCS)

Introduction to Teamcenter client communication system (TCCS) ─────── 7-1
Tools to configure TCCS ───────────────────────────────── 7-3
Configure TCCS for rich client (two-tier and four-tier) ────────────── 7-3
Create shared or private TCCS configurations ─────────────────── 7-4
Configure TCCS for forward proxy ─────────────────────────── 7-5
Configure TCCS for reverse proxy form-based authentication ───────── 7-7
Configure multiple TCCS environments ─────────────────────── 7-9
Configure TCCS for Kerberos ────────────────────────────── 7-12
Configure TCCS for SSL ───────────────────────────────── 7-14
Modify four-tier server connection settings ──────────────────── 7-15
Modify FCC parent settings ────────────────────────────── 7-15
Find Security Services settings for use in TCCS ────────────────── 7-16
TCCS configuration files ──────────────────────────────── 7-17
Orientation to TCCS configuration files ────────────────────────── 7-17
tccs.xml file ─────────────────────────────────────────── 7-18
fwdproxy_cfg.properties file ───────────────────────────────── 7-21
reverseproxy_config.xml file ───────────────────────────────── 7-23

© 2021 Siemens
Contents
TCCS and container applications ─────────────────────────── 7-23

Administering the TCCS container ───────────────────────────── 7-23
Administering the Teamcenter server proxy ─────────────────────── 7-24
Administering the FCC for TCCS ─────────────────────────────── 7-25
Administering TcMEM ───────────────────────────────────── 7-26
Administering proxy support for clients not integrated with TCCS ────── 7-26
TCCS logging ─────────────────────────────────────── 7-27
Configuring external management of passwords

Enabling external password management for Teamcenter ─────────── 8-1
Configuring Teamcenter clients for Security Services ────────────── 8-1
Configuring load balancer timeouts ────────────────────────── 8-3
Configuring Teamcenter mail and instant messaging

Configuring Teamcenter mail ────────────────────────────── 9-1
Configuring Teamcenter to use email servers requiring authentication ─── 9-2
Configuring instant messaging ───────────────────────────── 9-3
Configuring Teamcenter email polling

What is Teamcenter email polling? ───────────────────────── 10-1
Configure email polling types ───────────────────────────── 10-2
Create an email polling rule ────────────────────────────── 10-3
Configure user email account settings ─────────────────────── 10-5
Configure Dispatcher for email polling ─────────────────────── 10-7
Start or schedule email polling ──────────────────────────── 10-8
Teamcenter email polling preferences ─────────────────────── 10-9
Configuring Teamcenter notes and parametric requirements

Configuring standard notes and custom notes ────────────────── 11-1
Configure standard note creation authority ──────────────────── 11-1
Set the delimiter that separates parameters in standard note text ───── 11-1
Enable attachment of multiple revisions of a parametric requirement ─── 11-2
Configure the behavior of custom notes ────────────────────── 11-2
Teamcenter licenses
Licensing overview: seats, features, and bundles ──────────────── 12-1
How license use is calculated ───────────────────────────── 12-3
Federated license servers ─────────────────────────────── 12-5
Global and regional licenses ────────────────────────────── 12-6
Teamcenter licensing preferences ───────────────────────── 12-10
Configure failover license servers ───────────────────────── 12-11
Managing Teamcenter licenses ─────────────────────────── 12-11
Create a license server reference ───────────────────────────── 12-11
Change the Teamcenter default license server ───────────────────── 12-12

© 2021 Siemens
Set a default license server for a site ─────────────────────────── 12-13
Assign Teamcenter licenses to users ─────────────────────────── 12-14
Releasing checked out licenses ────────────────────────────── 12-16
Monitor seat license level violations ─────────────────────────── 12-16
Reporting license usage ──────────────────────────────── 12-17
License usage information logged in Teamcenter ─────────────────── 12-17
Generate Teamcenter license reports ─────────────────────────── 12-18
Report seat licenses in use on a server ────────────────────────── 12-19
License usage report ───────────────────────────────────── 12-20
Module usage report ──────────────────────────────────── 12-22
License login (location) report ─────────────────────────────── 12-23
Configuring access to administrative applications and utilities

Using Authorization to control access to applications and utilities ──────
13-1
Authorization interface ───────────────────────────────── 13-2
How Authorization works with group hierarchies ──────────────── 13-2
Default authorization rules and Authorization ────────────────── 13-3
Where can I limit access using Authorization? ────────────────── 13-3
Create Authorization rules for applications and utilities ──────────── 13-4
Configure access to utilities by group or by role in group ─────────── 13-5
Sharing authorization rules with other Teamcenter sites ─────────── 13-5
Importing and exporting Authorization rules ─────────────────────── 13-5
Export authorization rules ────────────────────────────────── 13-5
Import authorization rules ────────────────────────────────── 13-6
Backing up and recovering a Teamcenter environment

Backing up a Teamcenter environment ─────────────────────── 14-1
Overview of the integrated backup and recovery process ─────────── 14-2
Oracle Recovery Manager (RMAN) ────────────────────────── 14-4
Introduction to the Oracle Recovery Manager (RMAN) ───────────────── 14-4
Benefits of RMAN ─────────────────────────────────────── 14-5
Features of RMAN ─────────────────────────────────────── 14-7
ARCHIVELOG mode considerations ───────────────────────────── 14-8
Restoring purged files ────────────────────────────────── 14-8
Single file recovery (SFR) ─────────────────────────────────── 14-8
Single file recovery object model ────────────────────────────── 14-9
Single file recovery in Teamcenter rich client ────────────────────── 14-10
Single file recovery query ────────────────────────────────── 14-11
Alternative hot backup and recovery procedures ──────────────── 14-11
Back up and restore SQL Server database files ───────────────────── 14-11
Back up and restore Teamcenter volumes ──────────────────────── 14-13
Backup with SQL Server Virtual Device Interface (VDI) ──────────────── 14-13
Import, Export, and Report Administration Data

What is administration data? ───────────────────────────── 15-1
Videos: Managing Administration Data ─────────────────────── 15-2

© 2021 Siemens
Contents
Manage administration data across environments ──────────────────── 15-2

Copy and compare administration data across environments ───────────── 15-3
Compare administration data before an upgrade ──────────────────── 15-3
Tools for managing administration data ────────────────────── 15-4
Example tasks and processes for managing site behavior ─────────── 15-5
Reconcile differences in administration data between Teamcenter sites ─ 15-6
Exporting administration data ──────────────────────────── 15-7
Why would I export administration data? ───────────────────────── 15-7
Export administration data using the admin_data_export utility ─────────── 15-8
Export full administration data using TEM ───────────────────────── 15-8
Export partial administration data using TEM ─────────────────────── 15-9
Considerations for partial export of administration data ─────────────── 15-12
Importing administration data ─────────────────────────── 15-15
Why would I import administration data? ──────────────────────── 15-15
Perform a dry run import of administration data using TEM ───────────── 15-16
Perform a dry run import of administration data using the admin_data_import utility
────────────────────────────────────────────── 15-17
Import administration data using TEM ────────────────────────── 15-18
Import administration data using the admin_data_import utility ────────── 15-19
Postprocess imported volume objects ────────────────────────── 15-20
Administration data import merge options ─────────────────────── 15-21
Style sheet import behavior ──────────────────────────────── 15-22
Modifying an administration data package ─────────────────────── 15-25
Import a modified administration data package ──────────────────── 15-26
Reporting administration data ──────────────────────────── 15-26
What administration data reports are available? ──────────────────── 15-26
Administration Data Documentation report ─────────────────────── 15-27
Administration Data Comparison report ───────────────────────── 15-28
Administration Data Import (dry run) report ────────────────────── 15-31
Administration Data Import (history) report ─────────────────────── 15-31
Cryptography and FIPS compliance in Teamcenter server 16-1
Encryption key management

Teamcenter Key Manager ─────────────────────────────── 17-1
Installing Teamcenter Key Manager ───────────────────────── 17-1
Installing a secondary Teamcenter Key Manager server ──────────── 17-5
Administering Teamcenter Key Manager ────────────────────── 17-7
Key Manager administration ───────────────────────────────── 17-7
Managing policies ─────────────────────────────────────── 17-9
Managing secret keys ──────────────────────────────────── 17-10
Managing certificates ──────────────────────────────────── 17-12
Managing a secondary key manager server ─────────────────────── 17-13
Back up Teamcenter Key Manager data files ────────────────────── 17-14
Starting and stopping Teamcenter Key Manager services ─────────────── 17-14
Starting and stopping Teamcenter Key Manager daemons ────────────── 17-15
Installing and uninstalling Teamcenter Key Manager services ──────────── 17-16

© 2021 Siemens
Granting group access to a Teamcenter Key Manager satellite ──────────── 17-17
Updating property values in bulk

Process for updating property values in bulk ─────────────────── 18-1
Using the tc_attribute_bulk_update utility arguments to update property values
in bulk ─────────────────────────────────────── 18-2
Using an XML input file to update property values in bulk ─────────── 18-5
Performance statistics ────────────────────────────────── 18-8
Best practices for updating property values in bulk ─────────────── 18-8
Configuring Teamcenter for performance

Configuring the four-tier architecture for performance ───────────── 19-1
Techniques for improving four-tier performance ───────────────────── 19-1
Managing server memory ────────────────────────────────── 19-1
Shared memory ──────────────────────────────────────── 19-8
Sharing a TcServer instance with multiple applications ──────────────── 19-14
Tuning the web tier ───────────────────────────────────── 19-14
Configuring the rich client for startup performance ────────────── 19-21
Overview of configuring the rich client for startup performance ────────── 19-21
Configuring the FCC file warmer ───────────────────────────── 19-22
Configuring TCCS to start when users log on to a Windows operating system ── 19-25
Setting the PATH and AUX_PATH environment variables for enhanced performance
────────────────────────────────────────────── 19-28
Might deleting my rich client cache improve performance? ───────────── 19-28
What can I do to improve my startup performance? ────────────────── 19-29
POM_timestamp maintenance ─────────────────────────── 19-31
Cleaning the backpointer table after upgrade ────────────────── 19-32
Improve Eclipse expression evaluation ────────────────────── 19-33
Edit a Teamcenter registry file

What is Registry Editor? ───────────────────────────────── 20-1
Registry Editor interface ──────────────────────────────── 20-1
Registry files in Teamcenter ────────────────────────────── 20-2
Open a Teamcenter registry file ─────────────────────────── 20-5
Modify a registry file ────────────────────────────────── 20-5
Logging
Introduction to logging ───────────────────────────────── 21-1
Logging for business logic servers ────────────────────────── 21-1
System log files ───────────────────────────────────────── 21-1
Configuring business logic server logging ─────────────────────────21-2
Configure logging with the logger.properties file ────────────────────
21-2
Debugging using business logic server logging ─────────────────────21-3
Logging for Teamcenter tiers ───────────────────────────── 21-3
Overview of logging for Teamcenter tiers ───────────────────────── 21-3
Web tier logging ──────────────────────────────────────── 21-6

© 2021 Siemens
Contents
Enterprise tier logging ──────────────────────────────────── 21-7

Resource tier logging ───────────────────────────────────── 21-9
Dispatcher logging ────────────────────────────────────── 21-10
Performance journaling ──────────────────────────────── 21-11
Finding error codes ─────────────────────────────────── 21-11
Rich client tweaks

Configure rich client web browser home page and window ────────── 22-1
Configuring forms ──────────────────────────────────── 22-1
Master forms ────────────────────────────────────────── 22-1
Configure edit and view for forms ───────────────────────────── 22-2
Hiding commands in Rich Client ─────────────────────────── 22-2
Controlling command visibility ─────────────────────────────── 22-2
Command Suppression interface ────────────────────────────── 22-5
Suppress menu bar commands ─────────────────────────────── 22-7
Suppress context menu commands ──────────────────────────── 22-8
Inheritance of group command suppression ─────────────────────── 22-9
Manually create preferences to suppress commands in the rich client ─────── 22-10
Enable Command Suppression for a custom application ─────────────── 22-11

© 2021 Siemens
© 2021 Siemens
1. Teamcenter system administration
Once Teamcenter is deployed, Teamcenter system administrators maintain the environment.
Administrators can perform maintenance tasks using command line utilities, rich client perspectives,
Active Workspace workspaces, or various dedicated administration consoles.
Where do I go from here?
Teamcenter Administrator
Task Teamcenter help Active Workspace help
Maintain Teamcenter Scheduled maintenance for Teamcenter Documented fully in the
business logic servers servers Teamcenter help.
What is a server manager?
Maintain the database Oracle Documented fully in the
server Teamcenter help.
MS SQL Server
Manage Teamcenter Introduction to File Management System Documented fully in the
files and volumes Teamcenter help.
Introduction to Volume Management
Configure system-wide Introduction to Teamcenter client Documented fully in the
foundation communication system (TCCS) Teamcenter help.
functionality
System Administration, Teamcenter 14.0 PLM00102 14.0 1-1

© 2021 Siemens
1. Teamcenter system administration
Teamcenter Administrator
Enabling external password management for
Teamcenter
Configuring Teamcenter mail
What is Teamcenter email polling?
Configuring standard notes and custom
notes
Manage environment Licensing overview: seats, features, and Using workspaces to control
and application licenses bundles access to commands and
pages
Using Authorization to control access to
applications and utilities
Guard against system Backing up a Teamcenter environment Documented fully in the
and data loss Teamcenter help.
Cryptography and FIPS compliance in
Teamcenter server
Teamcenter Key Manager
Update property values in bulk
Review and improve Techniques for improving four-tier Active Workspace logging
system performance performance
The Active Admin
What is Registry Editor? workspace
Introduction to logging
What is administration data?
Maintain Teamcenter Rich client tweaks Configuring the Active
clients Workspace client
Controlling command visibility
Master forms
Manage Teamcenter Import, Export, and Report Administration Documented fully in the
behaviors Data Teamcenter help.
1-2 PLM00102 14.0 System Administration, Teamcenter 14.0

© 2021 Siemens
2. Maintaining Teamcenter servers
Scheduled maintenance for Teamcenter servers
Run the following maintenance utilities on Teamcenter servers as scheduled for daily, weekly, or
monthly frequency.
To maximize system up-time, set the weekly maintenance window for Teamcenter servers and
applications to a particular day and time each week. Changes that require taking the system off-line,
such as service account password reset, certificate renewal, and database re-indexing, should be done
during this window. Any change outside the maintenance window that requires taking the system off-
line should require business and production manager approval.
Run Daily
clearlocks
Clears dead process locks from the database. Dead process locks typically occur when a Teamcenter
session terminates abnormally. Process locks are set on an object when it is being modified or
deleted. If a Teamcenter session does not terminate gracefully (by logging off), these locks can
remain in place.
Run Weekly
dataset_cleanup
Repairs corrupted datasets and removes orphaned revision anchors. Run during off-hours. A dataset
is identified as corrupt if any of the following are found:
• The dataset has no reference to an imanFile object.
• The dataset has a reference to an imanFile corresponding operating system file that does not
exist and the dataset is not archived.
• The dataset is an orphan (that is, the dataset refers to the anchor, but the anchor does not go to
the dataset).
• The anchor refers to datasets that do not exist.
• The anchor size is 0.

index_verifier
Detects missing indexes and describes how to create the indexes.
purge_datasets
Removes old dataset versions from Teamcenter database. Normally,Teamcenter keeps a fixed limit
of dataset versions in the database that is controlled by the AE_dataset_default_keep_limit

© 2021 Siemens
preference. The purge_datasets utility can be run during normal working hours, with users logged
on to the system, and can process approximately 500 anchors per hour. A listing is produced that
shows each dataset purged, along with the owning user and group.
purge_invalid_subscriptions
Reports or deletes invalid and expired subscription objects.
purge_volumes
Unlocks files left behind in the Teamcenter volume after associated Teamcenter objects are deleted,
so that the files can be deleted from the volume.
Files are left behind if, during a Teamcenter session, a user deletes an object, but does not have the
necessary privileges at the operating system level in the Teamcenter volume to delete the
associated file.
report_volume
Reports on the available volumes as part of general housekeeping. Use this utility to create a
checklist of volumes for the users. The path does not include the network node name.
review_volumes
Generates a report file describing volume usage by various groups and users, as well as any
unreferenced operating system files, missing operating system files, and unreferenced Teamcenter
files. Unreferenced operating system files can be deleted at the time a report file is generated or at a
later time using a previously generated report file as an input. The report file format is plain text
(ASCII) and can be manually edited to not delete certain files. Simply remove any file names that
you do not want to delete before using the report file as input. You can also save any deleted files to
a ZIP format compressed file.
verify_tasks
Finds all corrupted Change Admin (CM) tasks, jobs, and other associated internal task model objects
in order to delete them from the database. If a corrupted object, such as a job, is referenced in a
folder, the reference is removed and the job is deleted
Run Monthly
audit_archive
Searches the database for audit log records based on input criteria. Once it finds the records to
archive, it processes the archive. If the -delete_record argument is specified, the utility deletes the
audit log records. Audit log entries with an audit definition with a day value of -l are not archived
because -l indicates that the log record is permanent.
cleanup_recovery_table
Locates and removes all recipe objects resulting from time-out sessions and client crashes.
Teamcenter recipe objects are used to facilitate transparent recovery when a TcServer instance
crashes. Typically, recipe objects are deleted when users log off. But during client crashes or session
time-outs, recipe objects may remain in the database if the session or objects are not recovered.

© 2021 Siemens
Useful administration tools
Useful administration tools

Following are some utilities that may be beneficial when performing maintenance activities:
• am_install_tree
Installs the Access Manager tree into the database.
• backup_modes
Sets the Teamcenter TCFS process in different modes. Blobby volume mode is used for Teamcenter
hot backup.
• backup_xmlinfo
Generates File Management System (FMS) ID tags for transient volumes in Teamcenter. Also creates
XML files for volume FMS IDs in the folder from where it is run.
• clearlocks
Clears dead processes from the database. The -verbose option is recommended. Use the -
assert_all_dead argument with extreme caution.
• dataset_cleanup
Removes unreferenced dataset objects from the database. Run this utility periodically to clean up
orphaned database objects
• index_verifier
Verifies indexes on database tables. Custom indexes added to the database using the install utility
can also be tracked using this tool.
• make_user
Create Person, User, Group, and Role objects in the Teamcenter Organization application.
• purge_datasets
Removes old versions of datasets from the database. Run this utility periodically on the Teamcenter
database.
• purge_invalid_subscriptions
Removes invalid subscriptions on objects from the Teamcenter database. Run this utility periodically
to clean up invalid subscription objects from the Teamcenter database.
• purge_volumes
Removes unreferenced files from the operating system. These files are not attached to any valid
dataset in the Teamcenter database. Run this utility periodically to clean up files on the operating
system to increase disk space.
• report_volume
Lists the operating system paths of all existing Teamcenter volumes. The path does not include the
network node name.

© 2021 Siemens
• reset_user_home_folder
Repairs corruption that may occur when deleting a user from the database. (The corruption redirects
the user's home folder, mailbox folder, and new stuff folder to the folder of the individual performing
the deletion.)
• review_volumes
Displays detailed information about Teamcenter volumes and allows you to remove unreferenced
operating system files from these volumes.
• verify_tasks
Finds all corrupted CM tasks, jobs, and other associated internal task model objects to delete them
from the database. If a corrupted object (such as a job) is referenced in a folder, the reference is
removed and the job is deleted.
Using process daemons

Process daemons are small programs used to perform system processes. Use Teamcenter process
daemons to manage system events, configure data sharing, monitor user subscriptions to system
events, and monitor user inboxes for overdue tasks.
Process daemons include the following:
• Action Manager
Dispatches events that have a specified execution time or subscription events that have failed to
process.
• Subscription Manager
Monitors the event queue for TcEvent objects.
• Task Manager
Checks a user's inbox for tasks that have passed their due date. If such a task is found, the daemon
notifies the delegated recipients and marks the task as late.
The frequency of the daemon's monitoring is controlled by setting the TASK_MONITOR_SLEEP_TIME
preference. To kill the daemon at any time, create an empty file as TC_ROOT\logs
\taskmonitor_graceful_exit.tmp.
• Tessellation Manager
Tessellates UGMASTER and UGALTREP datasets to the JT (DirectModel) dataset and attaches the JT
dataset back to the item revision and UGMASTER and UGALTREP datasets. Installing the Tessellation
service is required to create the tessellated representations in Repeatable Digital Validation (RDV) that
enable users of the Design Context application to quickly visualize components in context. The
tessellated representations are created during the workflow release process, ensuring that JT files of
the DirectModel datasets are updated as the NX files are released.
• Shared Metadata Cache Service

Synchronizes the shared server metadata memory cache.

© 2021 Siemens
Set Oracle-dependent services to automatically restart
You can install process daemons from Teamcenter Environment Manager (TEM) during installation or
maintenance. In the Features panel, under Server Enhancements > Database Daemons select the
daemon features to install.
Note:
You can provide additional security for process daemons by placing passwords in an encrypted file.
The daemons must then be configured to run under an operating system user ID with read
permissions on this password file.
Set Oracle-dependent services to automatically restart

The following services may not automatically restart after a server reboot. They are dependent on the
Oracle service (for example, OracleServiceTC), a dependency that cannot be established when
installing the services.
• Action Manager service
• Shared Metadata Cache service
• Subscription Manager service
• Task Monitor service
• Tessellation service
Set the dependency using the service depend command. For example, run the following command for
the actionmgrd service:
sc config actionmgrd depend=OracleServiceTC
To see service names on Windows systems, open the Control Panel and choose Administrative
Tools→Services.
Application process monitoring

Teamcenter runs various processes to support functions. Monitoring these processes is critical for
ensuring system availability to the end user.
The following table lists the processes to be monitored on the server tier they run on. If any of the
processes running as a Windows service is down, the Windows Event Viewer is updated with an error
log with information on date, time, error type, source (process), and server name. This information
should be read by automated (log reading) tasks to determine if a service is down and generate critical
event notification for the Teamcenter support group.

© 2021 Siemens
Source (in event Typical log file

Process Service name viewer) Server tier location
FMS local service Teamcenter FSC EventID is 7034 File management TEMP\fms.log
service and the volume servers
description
contains the
Teamcenter
service name
FMS remote Teamcenter FSC EventID is 7034 File management TEMP\fms.log

service service and the cache remote
description service
contains the
Teamcenter
service name
TCFS Teamcenter EventID is 7034 Teamcenter file TEMP\tcfs.syslog

Secure File and the management
Management description service
Service (TCFS) contains the
Teamcenter
service name
Subscription Teamcenter In Application tab Application TEMP

Manager Subscription with Source as business logic \subscription
Manager Service Subscriptionmgrd server manager.syslog
Action Manager Teamcenter Action In Application tab Application TEMP

Manager Service with Source as business logic \actionmanager.s
actionmgrd server yslog
License Manager UGS license server The service should License manager NA
(ugslmd) be up and running server
ugslmd
TcWeb tier TcWeb tier The Source is Application NA

TcWebTier and business logic
the Event Type is server
Error or Critical

© 2021 Siemens
3. Maintaining the database server
Maintaining the Oracle database
Tune the Oracle database
For best performance, maintain and tune Oracle database settings and services for your site. Tuning any
database management system is an iterative process requiring careful record keeping and patience to
measure, make configuration changes, and measure again, until optimal performance is achieved.
Set the Oracle environment
Manually set the Oracle environment
Before running Oracle database administration utilities, you must set the ORACLE_HOME and
ORACLE_SID environment variables. Oracle Corporation recommends that you do not define Oracle
environment variables in the system environment scope. Rather, define them manually when you use
Oracle utilities. Defining Oracle environment variables at the system environment scope can cause
conflict when running multiple versions of Oracle on the same machine.
Note:
Do not set ORACLE_HOME on SUSE Linux platforms.
Environment variable Description
ORACLE_HOME This environment variable must be set before any of the commands
are started. ORACLE_HOME must be set to the path of the top-level
(root) directory containing the Oracle application files.
Note:
Be consistent with the setting of ORACLE_HOME for a
database. Certain database functions fail if this variable is set
incorrectly, even if it is set to a valid path to the Oracle home
directory (for example, a symbolic link). ORACLE_HOME must

© 2021 Siemens
Environment variable Description
always be set to the same value as it was when the database

was created.
ORACLE_SID This environment variable is used to distinguish each unique

database instance and therefore must be set to the database instance
that you want to maintain or administer.
To manually set the Oracle environment, enter one of the following sets of commands:
Windows systems:
set ORACLE_HOME=ORACLE_HOME
set ORACLE_SID=tc
Linux systems:
export ORACLE_HOME=ORACLE_HOME
export ORACLE_SID=tc
Replace ORACLE_HOME with the path to Oracle. All examples assume that the database SID is tc.
Manually set the PATH environment variable for Oracle
It is also useful to add the Oracle bin directory to the PATH environment variable to allow Oracle scripts
and utilities to be run from the command line without adding a directory path qualification. Additionally,
many of the Oracle administration scripts require this as they often invoke other Oracle commands
without using a fully qualified directory path name.
To add the Oracle bin directory to the PATH environment variable, enter one of the following
commands:
Windows systems:
set PATH=%PATH%;%ORACLE_HOME%\bin
Linux systems:
export PATH=$PATH:$ORACLE_HOME/bin

© 2021 Siemens
Manually set the shared library path for Oracle (Linux systems)
Manually set the shared library path for Oracle (Linux systems)
Certain Oracle executables use shared library. To run these programs, set the platform specific, shared
library path environment variable to include the Oracle lib directory.
Consider defining ORACLE_HOME, ORACLE_SID, PATH, and shared library path in this manner in the
logon startup scripts of the Oracle user (.cshrc for C shell users, .profile for Bourne or Korn shell users).
Oracle services (Windows systems)
Introduction to Oracle services for Windows systems
There are two types of services associated with running an Oracle database: Oracle listener and
database instance. Both types must be running on the system when running Teamcenter.
Process Description
Oracle listener The Oracle listener (OracleTNSListener) service monitors database

connections from remote clients. This is a SQL*Net V2/Net process
and is required for Teamcenter to connect. Under SQL*Net V2/Net,
several listeners may run on the same system, each listening for
connect requests to particular databases. Each listener must be
configured to listen on a different port. Even if Teamcenter is run on
the Oracle server, it is necessary to start this service because all
Teamcenter database requests use the remote connect mechanism.
Database instance There is one Oracle database service for an Oracle database instance.
It must be running for Teamcenter to function properly. The service
is:
OracleServiceSID
SID represents the database instance system identifier.
Starting the instance of an Oracle database is referred to as initializing a database instance. To initialize
a database instance, use the Oracle SQL*Plus utility to manually start one database instance defined by
the ORACLE_SID environment variable.
Caution:
Never shut down a database instance by killing database processes from the Windows Task
Manager. Oracle databases require orderly shutdowns to ensure that all necessary database
transactions are completed. Failure to observe this may result in the corruption of the database.
Manual termination of processes also prevents the Oracle Relational Database Management

© 2021 Siemens
System (RDBMS) from releasing memory that is no longer needed, and could require additional
database recovery procedures at the next database startup.
Use the Oracle SQL*Plus utility to stop a single database instance defined by the ORACLE_SID
environment variable.
Manually start Oracle services (Windows systems)
Before manually starting Oracle Services (Windows systems)
These instructions for manually starting the Oracle listener and database services are applicable only if a
service or instance is not configured to start automatically when the system is restarted or if a service or
instance terminates unexpectedly.
Note:
You cannot start all database instances at the same time after the system is started. To start all
database instances at the same time, configure each database individually to start automatically
following a system restart.
Start the Oracle listener (Windows systems)
You can start the listener service either from the Services dialog box in the Windows Control Panel or
manually from a command prompt.
Note:
This example shows the startup of a listener service called LISTENER. More than one listener
service can be run on a system and each listener should be defined in a configuration file called
listener.ora.
• Control panel startup
1. Log on to the operating as a user with administrator privilege.
2. In the Windows Services dialog box, select the service named Oraclehome-nameTNSListener.
3. Click Start.
4. Verify that the OracleTNSListener service is running by checking the Windows Services dialog
box for the following entry:
Oraclehome-nameTNSListener Started startup-mode
startup-mode is either Automatic or Manual.

© 2021 Siemens
Start Oracle database services (Windows systems)
5. Click Close.
• Manual startup
1. Log on to the operating system as a user with administrator privilege.
2. Manually set the Oracle environment:
set ORACLE_HOME=Oracle-home-path
3. Start the listener service:
%ORACLE_HOME%\bin\lsnrctl start LISTENER
4. Verify that the OracleTNSListener service is running by checking the Windows Services dialog
box for the following entry:
Oraclehome-nameTNSListener Started startup-mode
Start Oracle database services (Windows systems)
2. In the Windows Services dialog box, select the service named OracleServiceSID (SID is the
instance system identifier, for example, tc).
3. Click Start.
4. Verify that the OracleServiceSID service is running by checking the Windows Services dialog box
for the following entry:
OracleServiceSID Started startup-mode
5. Click Close.
Initialize an Oracle database instance using SQL*Plus utility (Windows systems)
1. Log on to the operating system as a user with administrator privilege. To connect as internal
(without a password), this account must be part of ORA_DBA Windows local group.
2. Manually set the Oracle environment by entering one of the following sets of commands:

© 2021 Siemens
set ORACLE_SID=tc
3. Start the Oracle SQL*Plus utility:
%ORACLE_HOME%\bin\sqlplus
4. Log on to SQL. At the SQLPLUS prompt, type the following command:
connect / as sysdba
The following system message is displayed:
Connected to an idle instance.
5. At the SQLPLUS prompt, type the following command:
startup
A system message similar to the following is displayed:
ORACLE instance started.

Total System Global Area 35042572 bytes
Fixed Size 70924 bytes
Variable Size 30294016 bytes
Database Buffers 4505600 bytes
Redo Buffers 172032 bytes
Database mounted.
Database opened.
6. The Oracle database is initialized. Exit the Oracle SQL*Plus utility by entering the following at the
SQLPLUS prompt:
exit
Manually stop Oracle services (Windows systems)
Stop the Oracle listener (Windows systems)
The listener service can be shut down either from the Services dialog window in the Windows Control
Panel or manually from a command prompt.
Note:
This example shows the shutdown of a listener service called LISTENER. More than one listener
service can be run on a system and each listener should be defined in a configuration file called
listener.ora.

© 2021 Siemens
Stop Oracle database services (Windows systems)
• Control panel shutdown
2. In the Windows Services dialog box, select the service named Oraclehome-nameTNSListener.
3. Click Stop.
4. Verify that the OracleTNSListener service has stopped running by checking the Windows
Services dialog box for the following entry:
Oraclehome-nameTNSListener startup-mode
5. Click Close.
• Manual shutdown
(without a password), this account must be part of ORA_DBA Windows local group.
2. Manually set the Oracle environment:
3. Stop the OracleTNSListener service:
%ORACLE_HOME%\bin\lsnrctl stop LISTENER
4. Verify that the OracleTNSListener service has stopped running by checking the Windows
Services dialog box for the following entry:
Oraclehome-nameTNSListener startup-mode
Stop Oracle database services (Windows systems)
2. In the Windows Services dialog box, select the service named OracleServiceSID (SID is the
instance system identifier, for example, tc).
3. Click Stop.

© 2021 Siemens
4. Verify that the OracleServiceSID service is running by checking the Windows Services dialog box
for the following entry:
OracleServiceSID startup-mode
5. Click Close.
Shut down an Oracle database instance using SQL*Plus (Windows systems)
(without a password), this account must be part of the Windows ORA_DBA local group.
2. Manually set the Oracle environment by entering the following commands:
set ORACLE_SID=tc
connect / as sysdba
Connected.
shutdown
A system message similar to the following is displayed:
Database closed.
Database dismounted.
ORACLE instance shut down.
6. The Oracle database is shut down. Exit the SQL*Plus utility by entering the following command at
the SQLPLUS prompt:
exit

© 2021 Siemens
Automate Oracle Service startup and shutdown (Windows systems)
Automate Oracle Service startup and shutdown (Windows systems)
Oracle services automatically start when the system is restarted and shut down when the system is shut
down.
Note:
Oracle automatically shuts down Oracle databases when you shut down the Windows operating
system. No configuration is required.
The Oracle listener service is configured to start automatically when the system is restarted during the
Oracle installation process:
2. Choose Start→Control Panel→Administrative Tools→Services.
3. Select the desired service, for example, Oraclehome-nameTNSListener for the Oracle listener
service or OracleServiceSID (SID is the instance system identifier, for example tc).
4. Verify the startup mode of the service is running by checking the Windows Services dialog box for
the following entry:
service-name status startup-mode
service-name is the name of the selected service, status is either Started if the service is running or
blank if it is inactive, and startup-mode is the current startup mode.
5. If the startup mode is not Automatic, click Startup in the Services dialog box, change the Startup
Type to Automatic, and click OK.
6. Click Close.
Oracle processes (Linux systems)
Introduction to Oracle processes for Linux systems
There are two types of processes associated with running an Oracle database: Oracle listener and
database instance. Both types must be running on the system when running Teamcenter.
Process Description
Oracle listener The Oracle listener (tnslsnr) process monitors database connections
from remote clients. This is a SQL*Net V2/Net process and is required
for Teamcenter to connect. Under SQL*Net V2/Net, several listeners

© 2021 Siemens
Process Description
may run on the same system, each listening for connect requests to
particular databases. Even if Teamcenter is run on the Oracle server,
it is necessary to start this process because all Teamcenter database
requests use the remote connect mechanism.
Database instance Database processes are associated with a particular Oracle database
instance. There are six processes associated with each database
instance when it is first started. The processes are:
• ora_pmon_SID
Process monitor; performs Oracle process recovery when a user
process fails.
• ora_dbw0_SID
Database writer process; writes dirty Oracle buffers to disk.
• ora_ckpt_SID
Checkpoint process; updates the headers of all Oracle data files to
record the details of the checkpoint.
• ora_smon_SID
System monitor process; performs Oracle instance recovery at
instance startup.
• ora_reco_SID
Oracle recovery process; process used with distributed database
configuration that automatically resolves failures involving
distributed transactions.
• ora_lgwr_SID
Log writer process; writes the Oracle redo log buffer to a redo log
file on disk.
SID represents the database instance system identifier.
Starting these processes on an Oracle database server is referred to as initializing a database instance.
Use one of the following methods to initialize a database instance:
• To start all database instances flagged in the oratab file, use the Oracle dbstart utility. Only those
instances marked with a Y flag are started.
• To start a single database instance defined by the ORACLE_SID environment variable, use the Oracle
SQL*Plus utility.
All databases instances present on the system should be listed in the oratab configuration file. This file
is located in the /var/opt/oracle directory on Solaris systems and in the /etc directory on all other
platforms. Each instance should be listed on a separate line and conform to the following format:
ORACLE_SID:ORACLE_HOME:FLAG

© 2021 Siemens
Start the Oracle listener process (Linux systems)
ORACLE_SID is the system identifier of the instance (for example tc), ORACLE_HOME is the Oracle home
directory associated with that instance (for example, /u01/app/oracle/product/oracle-version), and
FLAG is Y or N. These flags are used by the Oracle dbstart and dbshut utilities to determine which
instances to start or stop.
Caution:
Never shut down a database instance by killing database processes or by restarting the system.
Oracle databases require orderly shutdowns to ensure that all necessary database transactions are
completed. Failure to observe this may result in the corruption of the database. Manual
termination of processes also prevents the Oracle Relational Database Management System
(RDBMS) from releasing memory that is no longer needed, and could require additional database
recovery procedures at the next database startup.
There are two methods for shutting down a database instance:
• Use the Oracle dbshut utility to shut down all database instances flagged in the oratab file. Only
those instances marked with a Y flag are stopped.
• Use the Oracle SQL*Plus utility to stop a single database instance defined by the ORACLE_SID
Manually start Oracle processes (Linux systems)
Start the Oracle listener process (Linux systems)
This example shows the startup of a listener process called LISTENER. More than one listener process
can be run on a system. Each listener should be defined in a configuration file called listener.ora.
Manually start the tnslsnr process by performing the following procedure:
1. Log on to the operating system as oracle, or switch user to oracle by typing su - oracle followed by
the oracle password.
2. Manually set the Oracle environment by typing one of the following commands:
export ORACLE_HOME=Oracle-home-path
3. Start tnslsnr by typing the following command:
$ORACLE_HOME/bin/lsnrctl start LISTENER
4. Verify that tnslsnr is running by typing the following command:
ps -ef | grep tnslsnr

© 2021 Siemens
The following process information is displayed:
oracle 1833 1 80 date time tnslsnr -inherit LISTENER
Replace date and time with the operating system date and time that tnslsnr was started.
Initialize all flagged Oracle database instances using dbstart (Linux systems)
1. Log on to the operating system as oracle, or switch user to oracle by typing the following
command, followed by the oracle password:
su - oracle
3. Start all Oracle database instances flagged in the oratab file by typing the following command:
$ORACLE_HOME/bin/dbstart
4. Verify that the database processes are running by typing the following command:
ps -ef | grep ora
The following process information is displayed for each database instance:
oracle 1830 1 80 date time ora_dbw0_tc

oracle 1831 1 80 date time ora_pmon_tc
oracle 1832 1 80 date time ora_lgwr_tc
oracle 1833 1 80 date time ora_smon_tc
oracle 1832 1 80 date time ora_reco_tc
oracle 1833 1 80 date time ora_ckpt_tc
Replace date and time with the operating system date and time that the database process was
started. This example shows the background database processes associated with an Oracle
instance called tc.
Initialize an Oracle database instance using SQL*Plus utility (Linux systems)
su - oracle
2. Manually set the Oracle environment by typing one of the following sets of commands:

© 2021 Siemens
Stop the Oracle listener (Linux systems)
$ORACLE_HOME/bin/sqlplus
connect / as sysdba
Connected.
startup

Database mounted.
Database opened.
6. The Oracle database is initialized. Exit the Oracle SQL*Plus utility by entering the following at the
SQLPLUS prompt:
exit
Manually stop Oracle processes (Linux systems)
Stop the Oracle listener (Linux systems)
This example shows the shutdown of a listener process called LISTENER. More than one listener process
may be run on a system and each listener should be defined in a configuration file called listener.ora.
1. Log on to the operating system as oracle, or switch user to oracle by entering su - oracle followed
by the oracle password.

© 2021 Siemens
3. Stop tnslsnr by typing the following command:
$ORACLE_HOME/bin/lsnrctl stop listener
4. Verify that the tnslsnr process is no longer running by entering the following command:
ps -ef | grep -v grep | grep tnslsnr
There should be no output returned by this command.
Shut down all flagged Oracle database instances using dbshut (Linux systems)
1. Log on to the operating system as oracle, or switch user to oracle by entering the following
su - oracle
2. Manually set the Oracle environment by entering one of the following commands:
3. Stop all Oracle database instances flagged in the oratab file:
$ORACLE_HOME/bin/dbshut
4. Verify that the database processes are no longer running:
ps -ef | grep -v grep | grep ora
There should be no output returned by this command.
Shut down an Oracle database instance using SQL*Plus (Linux systems)
su - oracle

© 2021 Siemens
Automate Oracle startup processes (Linux systems)
connect / as sysdba
Connected.
shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
6. The Oracle database is shut down. Exit the SQL*Plus utility by typing the following command at the
SQLPLUS prompt:
exit
Automate Oracle startup and shutdown processes (Linux systems)
Automate Oracle startup processes (Linux systems)
Most system administrators find it helpful to automatically start and stop the Oracle processes when
starting and stopping the system, respectively. This ensures a graceful and orderly shutdown of Oracle
processes.
Automatic startup of Oracle server and database processes is achieved by scripting startup commands so
that they are started automatically each time the system is restarted. There are two methods of doing
this:
• Modify an existing system run control (rc) script to include the startup commands.
• Create a new system rc script using sample scripts provided by Siemens Digital Industries Software.
Automate Oracle shutdown processes (Linux systems)
Automatic shutdown of Oracle server and database processes is achieved by scripting shutdown
commands so that they are run automatically each time the system is shutdown. There are two methods
of doing this:
• Modify an existing system run control (rc) script to include the shutdown commands

© 2021 Siemens
• Create a new system rc script using sample scripts provided by Siemens Digital Industries Software
Oracle database security (Windows systems)
With Oracle, the Oracle internal account does not require a password. It uses Windows native
authentication, by using Windows user logon credentials to authenticate privileged database users.
During installation of Oracle server software, the Oracle Universal Installer creates the Windows local
ORA_DBA group and adds your Windows user name to this group, giving you SYSDBA privilege. For
anyone else to connect as internal without a password, the Windows user name must be added
manually to this ORA_DBA Windows group.
If you connect to a database using sqlplus, and connect as internal, and the database requests a
password, check whether your Windows user name is part of the Windows local ORA_DBA group and
that the Oracle server ORACLE_HOME\network\admin\sqlnet.ora file has the
SQLNET.AUTHENTICATION_SERVICES parameter set to NTS.
Note:
If you use an Oracle database and want to change the password Teamcenter uses to connect to
the database, you must temporarily set the TC_DB_CONNECT environment variable and then re-
encrypt the password.
Oracle database management
View Oracle database information (Windows systems)
You can view and control the size and content of the Oracle database.
The following SQL commands are provided to view general database information. Prior to entering any
SQL statements, you must run the Oracle SQL*Plus utility as follows:
2. Manually set the Oracle environment by typing the following commands:
set ORACLE_SID=tc
connect db-user/password

© 2021 Siemens
View Oracle database information (Linux systems)
Replace db-user with the Teamcenter database user name; replace password with the database
user password.
5. The following system message is displayed:
Connected.
6. Issue any of the following commands to obtain desired information about your database.
• To list a summary of the Teamcenter database files, type the following command from the
SQLPLUS prompt:
select * from sys.dba_data_files;
• To list available space in the tablespace in bytes, type the following command from the SQLPLUS
prompt:
select sum (bytes) from sys.dba_free_space where tablespace_name=’IDATA’;
• To list available space in the SYSTEM tablespace in bytes, type the following command from the
SQLPLUS prompt:
select sum (bytes) from sys.dba_free_space where tablespace_name =’SYSTEM’;
7. To exit the SQL*Plus utility, type the following command from the SQLPLUS prompt:
exit
View Oracle database information (Linux systems)
You can view and control the size and content of the Oracle database.
The following SQL commands are provided to view general database information. Prior to entering any
SQL statements, you must run the Oracle SQL*Plus utility as follows:
su - oracle
2. Manually set the Oracle environment by typing the following commands:

© 2021 Siemens
connect db-user/password
Replace db-user with the Teamcenter database user name; replace password with the database
user password.
5. The following system message is displayed:
Connected.
6. Issue any of the following commands to obtain desired information about your database.
• To list a summary of the Teamcenter database files, type the following command from the
SQLPLUS prompt:
select * from sys.dba_data_files;
• To list available space in the tablespace in bytes, type the following command from the SQLPLUS
prompt:
select sum (bytes) from sys.dba_free_space where tablespace_name=’IDATA’;
• To list available space in the SYSTEM tablespace in bytes, type the following command from the
SQLPLUS prompt:
select sum (bytes) from sys.dba_free_space where tablespace_name =’SYSTEM’;
7. To exit the SQL*Plus utility, type the following command from the SQLPLUS prompt:
exit
Delete Oracle databases (Windows systems)
You can delete Oracle databases from a server using the Oracle Database Configuration Assistant.
Remove the Oracle database services and files as follows:
2. Choose Start→All Programs→Oraclehome-name→Database Configuration Assistant.
3. Select Delete a database and click Next.
4. Select the database to be deleted (for example, TC) and click Finish.
All the database files and administrator files are deleted.

© 2021 Siemens
Introduction to Linux semaphores in Oracle
You may need to manually remove remaining files relating to this database instance from the
ORACLE_HOME\database directory. These files have the instance identifier as parts of their
names, for example, iniiman0.ora, strtiman.cmd, imandb1.lst, imandb3.lst, and imandb3.sql.
Oracle semaphores (Linux systems)
Introduction to Linux semaphores in Oracle
Linux semaphores are designed to allow processes to synchronize execution by allowing only one
process to perform an operation on the semaphore at a time. The other processes sleep until the
semaphores values are either incremented or reset to 0.
Linux semaphores are integer-valued objects set aside by the operating system that can be incremented
or decremented automatically. They are designed to allow processes to synchronize execution by
allowing only one process to perform an operation on the semaphore at a time. The other processes
sleep until the semaphores values are either incremented or reset to 0.
Linux typically uses many semaphores and allocates them to the system in sets. When the Linux kernel is
configured, the following semaphore parameters are rigidly set and cannot be changed without
rebuilding the Linux kernel and restarting the system:
• Maximum number of semaphores (SEMMNS)

The Linux kernel parameter SEMMNS is used to specify the maximum number of semaphores in the
system.
To increase this parameter, set SEMMNS to the sum of the PROCESSES parameter for each Oracle
database, adding the largest one twice, then add an additional 10 for each database. For example:
ORACLE_SID=A, PROCESSES=100
ORACLE_SID=B, PROCESSES=100
ORACLE_SID=C, PROCESSES=200
The value for SEMMNS is calculated as follows:
SEMMNS=[(A=100) + (B=100) + [(C=200) * 2] + [(# of instances=3) * 10] = 630
See the operating system documentation for instructions about allocating semaphores and rebuilding
the Linux kernel.
• Maximum number of semaphores per set (SEMMSL)

The Linux semaphore kernel parameter SEMMSL is used to specify the number of maximum number
of semaphores in a semaphore set. To increase this parameter, set SEMMSL to 10 plus the largest
PROCESSES parameter of any Oracle database on the system. The PROCESSES parameter can be
found in each initsid.ora file, located in the ORACLE_HOME/dbs directory.

© 2021 Siemens
Oracle use of Linux semaphores
Oracle uses semaphores to control concurrency between all the background processes (pmon, smon,
dbw0, lgwr, reco, ckpt, and oracle shadows) and to control communication between the user process
and shadow process.
Typing ipcs -sb in a shell displays a list of semaphores allocated to the system at the moment. This list
includes all the semaphore sets allocated, their identifying number, the owner, and the number of
semaphores in each set.
Occasionally, unexpected termination of Oracle processes leaves semaphore resources locked. If the
database is not running, but ipcs -sb lists semaphore sets owned by oracle, these must be reallocated. If
this is not done, semaphore resources may not be sufficient to allow restarting the database.
Freeing semaphore sets is done by either using the ipcrm command or by restarting the system.
Normally, system administrators do not want to restart the system only to free semaphore resources.
Semaphore sets can be freed one at a time by performing the following procedure:
Warning:
Do not attempt to reallocate semaphore resources from Oracle if the Oracle server process
(orasrv) is running. Corrupted data may result.
1. Log on as root.
2. Type the following command to display a list of semaphores owned by oracle:
ipcs -sb |grep ora
3. Free each semaphore set by typing:
ipcrm -s ID
Replace ID with the set identifying number from semaphores listed in step 2.
4. Repeat step 3 until all semaphores owned by Oracle are reallocated.
Common Linux semaphore problems in Oracle
Oracle problems and errors involving Linux semaphores often indicate insufficient or improperly
configured semaphore resources on that Linux system. Semaphore resources may need to be optimized
before Oracle runs properly.
• Semaphore problems during startup

Oracle allocates all the semaphores it needs for the background processes at database startup. The
Oracle init.ora processes parameter determines the number of semaphores that will be allocated for

© 2021 Siemens
Common Linux semaphore problems in Oracle
Oracle use. If Oracle requires more semaphores than are allowed in one set, additional sets are
allocated to Oracle. The following error codes are common startup errors.
Error Cause
ORA-7251 spcre: semget error, No semaphores are configured, or every

could not allocate any semaphores semaphore is currently allocated.
ORA-7252 spcre: semget error, The first full set of semaphores was
could not allocate semaphores successfully allocated, but additional sets could
not be allocated.
ORA-7279 spcre: semget error, The system is attempting to allocate the first
unable to get first semaphore set set of semaphores. The system either does not
have sufficient semaphore resources or too
many semaphores or semaphore sets are
already allocated.
The corrective actions for all three of the preceding errors are the same:
1. Check semaphores in use. Verify all unused semaphores are reallocated.
2. Rebuild Linux kernel to allocate additional semaphore resources.
• Semaphore during shutdown abort

When a shutdown abort is performed, Oracle background processes are killed and semaphore sets are
reallocated, without waiting for the user processes to finish. The following error codes are common
shutdown abort errors:
• ORA-7264 spwat: semop error, unable to decrement semaphore
• ORA-7265 sppst: semop error, unable to increment semaphore
Cause Action
One or both of these error codes is displayed as This is an effective (though ungraceful) way of
a result of the following scenario: after a letting the users know that the database has
shutdown abort, one or more users ends a been shut down with the abort option.
request to the database and the request
process dies. This occurs because the attempt
to increment or decrement the semaphore
fails.

© 2021 Siemens
NLS_LANG environment variable
The NLS_LANG environment variable is an Oracle variable used to define language, locale, and
character set properties.
When you perform Oracle export or import, you must set the NLS_LANG environment variable. The
NLS_LANG environment variable controls character-set conversion between the source database and
the target database. The NLS_LANG environment variable has the following format:
NLS_LANG=language_territory.character-set
For example:
NLS_LANG=AMERICAN_AMERICA.US7ASCII
For export and import, only the character-set portion is important. For language_territory, you can
always use AMERICAN_AMERICA.
You must set the NLS_LANG environment variable explicitly.
Note:
If you do not explicitly set NLS_LANG, the system uses the default value. On Linux systems, the
default NLS_LANG value is AMERICAN_AMERICA.US7ASCII, which may cause export or import to
issue warnings or errors. On Windows systems, the default NLS_LANG is obtained from the
following Windows registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEid
id is 0, 1, 2, and so forth. The setting in the registry for the character set reflects the character set
you selected when you created the database using Oracle DBCA.
• Set NLS_LANG for export

When using Oracle export, set the character set on the NLS_LANG environment variable to the same
character set as the database you are exporting. No conversion occurs, and the export file is created
in the same character set as the original database. If you plan to import the file into a database with a
different character set, you can postpone the conversion until the import.
To determine the character set of the current database, type the following command in SQL*Plus:
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
• Set NLS_LANG for import

When using Oracle import, setting the NLS_LANG environment variable depends on whether the
source database and target database use the same character set:
• If the source database and target database use the same character set, set the NLS_LANG
environment variable to use that character set.

© 2021 Siemens
Oracle initialization parameter files
• If the source database and target database use different character sets, leave the character set part
of NLS_LANG the same on both export and import. Set it either to the same character set as the
source database (preferred) or to the same character set as the target database. Conversion occurs
only once, either on export or on import.
To determine the character set of the current database, type the following command in SQL*Plus:
select value from nls_database_parameters where parameter='NLS_CHARACTERSET';
Oracle initialization parameter files
You can start Oracle instances using either of two initialization files: an ASCII text file or a binary file. The
binary file is called the server parameter file (SPFILE). The server parameter file is stored on the database
server; changes applied to the instance parameters are persistent across all startups and shutdowns.
The default server parameter file is named spfileSID.ora and is located in the following directory:
Windows systems:
ORACLE_HOME\database
Linux systems:
ORACLE_HOME/dbs
The default ASCII text file is named initSID.ora and is located in the following directory:
Windows systems:
ORACLE_BASE/admin/ORACLE_SID/pfile
Linux systems:
ORACLE_BASE\admin\ORACLE_SID\pfile
You can also start Oracle instances using a specified ASCII text file or server parameter file, rather than
the default file, or without specifying a file.
• Example: specifying no initialization file

The following example starts an Oracle instance without specifying a file:
sqlplus /nolog
SQL> connect / as sysdba
SQL> startup

© 2021 Siemens
Oracle first searches for the spfileSID.ora file. If it does not exist, Oracle searches for the spfile.ora
file. If neither exists, Oracle uses the initSID.ora file. If none of these files exist, Oracle displays
messages similar to the following example:
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file 'D:\ORA101\DATABASE\INITORA101.ORA'
• Example: specifying ASCII text file

The following example starts an Oracle instance using the initSID.ora file:
SQL> startup pfile=d:\ora101\database\initORA101.ora

Database mounted.
Database opened.
This option is not available if you are using a server parameter file. If you try to start an Oracle
instance using this option and specifying a server parameter file, Oracle displays the following error
message:
SQL> startup spfile=d:\ora101\database\spfileORA101.ora

SP2-0714: invalid combination of STARTUP options
If you start the database by specifying an ASCII text file, the spfile parameter is displayed as empty:
SQL> show parameter spfile

NAME TYPE VALUE
--------------------------------- ----------- -----------
spfile string
• Example: specifying server parameter file

To start an Oracle instance using a server parameter file, you must use an initSID.ora file in which you
specify only the spfile parameter:
Windows systems:
spfile=d:/ora101/database/spfiletest.ora
SQL> startup pfile=d:/ora101/database/inittest.ora
Linux systems:
spfile=d:\ora101\database\spfiletest.ora
SQL> startup pfile=d:\ora101\database\inittest.ora


© 2021 Siemens
Oracle online documentation

Database mounted.
Database opened.
To determine whether you used the server parameter file, enter the following command in SQL*Plus:
SQL> show parameter spfile

NAME TYPE VALUE
------------------------------ ----------- ---------------------------------
spfile string d:\ora101\database\spfiletest.ora
Changing a parameter in the server parameter file depends on whether the parameter is static or
dynamic. Changes to static parameters do not take effect until the database is restarted. Dynamic
parameters can be changed while the database is running and do not require restarting the database.
To change a dynamic parameter:
SQL> alter system set open_cursors=400;

System altered.
To change a static parameter, qualify the command with scope=spfile:
SQL> alter system set processes=200 scope=spfile;

System altered.
Oracle online documentation
Oracle online documentation is included on a separate CD-ROM. Documentation is available in both

hypertext markup language (HTML) and portable document format (PDF) formats. To view Oracle online
documentation directly from the Documentation CD-ROM, click the index.html file.
Oracle Net implementation
Oracle Net features
Oracle Net uses its own set of configuration files and processes to listen for and accept database
connection requests. The process which listens for connect requests is the tnslsnr (Linux) or the
OracleTNSListener service (Windows). Several listener processes may be configured on a system if
required. The connect string used by an Oracle client to make a remote connection request uses a short
alias to represent a larger collection of server connect information. This information is referred to as the
connect descriptor.
The following is an example of a connect descriptor on Linux:
test=(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(COMMUNITY=IMANTCP)

© 2021 Siemens
(PROTOCOL=TCP)
(HOST=infosun32)
(PORT=1521)
)
)
(CONNECT_DATA=
(SID=imandev)
)
The following is an example of a connect descriptor on Windows:
test=(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(COMMUNITY=TCP.world)
(PROTOCOL=TCP)
(HOST=infosun32)
(PORT=1521)
)
)
(CONNECT_DATA=
(SID=test)
)
)
test is the alias for this connect descriptor. Using the tcdba user as an example, the resulting connect
string within Oracle would be:
tcdba/tcdba@test
The community defined in the above descriptor indicates the group of nodes to which this system
belongs. Communities are used by Oracle to indicate like groups of nodes for use with the Multi-Protocol
Interchange, which allows nodes on different types of networks (for example, TCP/IP, SPX) to
communicate.
Oracle Net configuration files
Oracle Net may be configured via several files, but only two are mandatory files:
• The listener.ora file must reside on the Oracle server. It contains configuration data for running the
tnslsnr listener process (Linux) and OracleTNSListener Windows service (Windows) including a list of
databases for which it should listen for connection requests.
• The tnsnames.ora file must reside on an Oracle client. It contains the connect descriptors and their
aliases for the databases to which this client connects. This file must also reside on an Oracle server.
On Windows, Siemens Digital Industries Software also configures the sqlnet.ora file, which must reside
on the Oracle server and client and contains additional configuration parameters.

© 2021 Siemens
Oracle Net Configuration Assistant
There are other files that can be created but if they do not exist, Oracle assumes defaults. Additionally,
certain files only apply to products and functions which Teamcenter is not likely to use. These files may
reside in several locations.
The search path that Oracle uses to locate these files on Linux is as follows:
HOME/.file-name.ora
TNS_ADMIN/file-name.ora
ORACLE_HOME/network/admin/file-name.ora
The search path that Oracle uses to locate these files on Windows is as follows:
file-name.ora in the current directory

TNS_ADMIN\file-name.ora
ORACLE_HOME\network\admin\file-name.ora
TNS_ADMIN is an environment variable that can point to any directory on the system where you want
to keep these files.
• On Windows, file-name.ora implies the listener.ora, tnsnames.ora and sqlnet.ora files.
• On Linux, file-name.ora implies both the listener.ora and tnsnames.ora files. Note that in the case of
the HOME directory location, these files are hidden.
Oracle Net Configuration Assistant
Due to the complexity of the configuration files, Oracle Corporation recommends that customers do not
build or edit the files manually. Oracle Corporation supplies a product called Oracle Net Configuration
Assistant, which allows you to enter information about the functions of various nodes on your network
and then builds the configuration files for each of those nodes and a generic set of files for all possible
client nodes.
On Windows, the files it generates must be copied to the appropriate nodes manually (usually using
ftp).
Oracle Net service resolution on Teamcenter clients
Under Oracle Net, there is a requirement that each Oracle client have some means of translating the
service alias supplied in the database connect string into its equivalent connect descriptor.
• On Windows, Teamcenter accomplishes this by creating a copy of the tnsnames.ora and sqlnet.ora
files in the Teamcenter data directory during installation and setting the value of the TNS_ADMIN
environment variable to %TC_DATA% in the tc_profilevars.bat file, to force Teamcenter to use this
file.

© 2021 Siemens
• On Linux, Teamcenter accomplishes this by creating a copy of the tnsnames.ora file in the
Teamcenter data directory during installation and setting the value of the TNS_ADMIN environment
variable to $TC_DATA in the tc_profilevars file, to force Teamcenter to use this file.
The Teamcenter data directory was chosen as the location for this file as it makes the file immediately
visible to all Teamcenter clients who want to use this database and because this directory is guaranteed
writable by the installer.
The tnsnames.ora file contains one entry—the entry for the database associated with that Teamcenter
data directory. This file is regenerated every time the data directory is reconfigured.
You can override the setting of the TNS_ADMIN environment variable from the external environment or
commented out in the TC_DATA\tc_profilevars file, depending on the requirements of the site.
Caution:
If you maintain copies of the Oracle Net configuration files in various locations in the system, be
careful not to duplicate service aliases within those files. Duplication of service aliases could lead
to connection to the wrong database and can result in lost or corrupted data. Ensure that the
TNS_ADMIN environment variable is set correctly before running Teamcenter Integration for
NX/NX Integration.
Maintaining the Microsoft SQL Server database
Tune the Microsoft SQL Server database
For best performance, maintain and tune Microsoft SQL Server database settings and services for your
site. Tuning any database management system is an iterative process requiring careful record keeping
and patience to measure, make configuration changes, and measure again, until optimal performance is
achieved.
Start the SQL Server service
1. Log on to the operating system as a user with administrator privileges.
2. Open the Windows Control Panel.
3. From the Control Panel, Administrative Tools→Services.
4. From the list of services, select SQL SERVER (MSSQLSERVER) and click Start.
5. To verify that the SQL Server service is running, check the Status column. When the service is
running, the status is Started.

© 2021 Siemens
Shut down the SQL Server service
Shut down the SQL Server service
1. Log on to the operating system as a user with administrator privileges.
2. Open the Windows Control Panel.
3. From the Control Panel, double-click Services.
4. From the list of services, select MS SQLSERVER and click Stop.
5. To verify that the SQL Server service has stopped, check the Status column. When the service not
running, the status is blank.
SQL Server database security
SQL Server operates in one of two security (authentication) modes:
• Windows authentication mode

Windows authentication mode allows a user to connect through a Windows user account.
• Mixed mode
Mixed mode allows users to connect to an instance of SQL Server using either Windows
authentication or SQL Server authentication. Users who connect through a Windows user account can
use trusted connections in either Windows authentication mode or mixed mode.
Siemens Digital Industries Software recommends using mixed mode authentication, where the user is
required to input a database user logon ID and password to be able to connect to the SQL Server.
Delete the SQL Server database
If a Teamcenter database is corrupted beyond repair, the simplest solution may be to delete all
information from the database and start again.
1. Start SQL Server Enterprise Manager and expand Microsoft SQL Servers→SQL Server
group→Local Server.
2. Select and right-click the Database menu under LOCAL.
3. Select the corrupted database and delete it.
View the SQL Server error logs
You can view the SQL Server error log using SQL Server Management Studio or any text editor.
1. Expand a server group and then expand a server.

© 2021 Siemens
2. Expand Management and then expand SQL Server Logs.
3. Double-click the SQL Server log.

Error log information is displayed in the details pane.

© 2021 Siemens
4. Server manager
What is a server manager?
A server manager (sometimes called a pool manager) is a tool to manage system resources in a four-tier
Teamcenter environment. The server manager enables you to maximize server availability while
minimizing resource requirements.
The Teamcenter Management Console server manager administration interface enables you to
manage the server pool and individual servers from within a web browser. In addition to managing the
server pool and individual servers, the Teamcenter Management Console includes the capability to set
logging and monitoring parameters, which otherwise must be set manually in individual XML files.
Server manager task Out-of-the-box tools for administering the server manager task
Manage the server pool or The Teamcenter Management Console.

individual servers
Monitor for critical events • The Teamcenter Management Console.
• Various server manager monitoring files.
Manage server manager • The Teamcenter Management Console.

logging
• The log4j.xml file for an individual server, the logger.properties
file for all servers in the server pool.
Using third-party applications to view or manage server manager administration data
You can use third-party applications to view server manager administration data in a more
comprehensive manner than is available in the out-of-the-box Teamcenter server manager
administration interfaces. Some examples of third-party applications include the following.
JConsole A monitoring tool complying to Java Management Extensions (JMX) specifications.

JConsole uses Java Virtual Machine (Java VM) to provide information about the
performance and resource consumption of applications running on the Java platform.
This tool is included in the Java development kit (JDK).

Java A monitoring tool that provides a visual interface for viewing detailed information
VisualVM about Java applications while they are running on a Java Virtual Machine (JVM), and
for troubleshooting and profiling these applications. Various stand-alone tools, such as
JConsole, jstat, jinfo, jstack, and jmap, are part of Java VisualVM.

© 2021 Siemens
4. Server manager
This tool is included in the Java development kit (JDK).

HP A comprehensive management solution that monitors, controls, automates corrective
Operations actions, and reports on the health of all parts of the managed IT infrastructure.
Manager
Overview of installing the server manager

1. Install the server manager (for Linux Server or Windows Server as appropriate).
In Teamcenter Environment Manager (TEM), you can install the server manager from the Features
panel under the Server Enhancements category.
2. Install the Teamcenter web tier.
Use the Teamcenter Web Application Manager insweb command to generate the Teamcenter web
tier application (WAR file).
Deploy the WAR file using a web application server tool such as WebSphere or WebLogic.
3. Ensure that the server manager service or daemon is running.
Example:
On a Windows system, choose Start→Control Panel→Administrative Tools→Services and
select Teamcenter Server Manager. You can also manually run the server manager service
by running the following executable:
TC_ROOT\pool_manager\confs\configuration-namemgrstart.bat
Teamcenter Management Console
What is the Teamcenter Management Console?
The Teamcenter Management Console is a secure web interface for dynamically managing and
monitoring server-side components such as the server manager and the web tier. Changes made in the
console affect running Teamcenter components; when components are stopped and restarted,
configurations reset to the values contained in the respective configuration files. For security, this
console supports SSL.
Note that the console supports a Java-based web tier, but does not support a .NET (IIS) web tier.
You can use the console to do the following in your Teamcenter four-tier deployments:

© 2021 Siemens
What is the Teamcenter Management Console?
Management task Capabilities

Administer server manager You can change global pool configurations and pool-specific
pools. configurations. You can perform server manager operations such as
restart warm servers and shut down the server manager.
Administer Teamcenter You can view server information and perform server operations. For
tcserver instances. example, you can change logging options for showing syslog file and
journal output. You can also search tcserver instances based on filter
options.
Administer server manager You can enable monitoring, configure monitoring metrics to a certain
monitoring and tcserver threshold level, and configure responders for events notifications.
monitoring (also known as
tcserver monitoring is part of the server manager because the server
server monitoring).
manager manages the tcserver instances in a pool. Monitoring exposes a
set of metrics that are applicable to its component (for example, the
server manager or tcserver instance).
Administer web tier View and configure web tier pool, logging, and settings.
monitoring.
Dynamically change the You can change logger levels for the server manager, web tier, and
priority of logger levels. tcserver instances.
Administrators can use the console to access many Teamcenter management tasks from a single page.
The console resembles web application server consoles. It has tabbed pages allowing administrators to
manage different aspects of Teamcenter.

© 2021 Siemens
4. Server manager
The web-based Teamcenter Management Console replaced the JMX-based server manager and web tier
HTML adapter as of Teamcenter release 11.2. The older interface formerly available at http://
hostname:8082 is obsolete.
Install the Teamcenter Management Console
1. In the Features panel of Teamcenter Environment Manager (TEM), under Server Enhancements
select Teamcenter Management Console and click Next until you reach the Management
Console LDAP Configurations panel.
2. On the Management Console LDAP Configurations panel, do this:
a. Select one of Use Embedded LDAP or Use External LDAP.
b. Enter parameters for the selected LDAP.

Use Embedded LDAP
Supplies an embedded lightweight directory access protocol (LDAP) to facilitate
authentication and authorization. There is no support for multiple embedded LDAP
servers. If you use embedded LDAP, then both the Teamcenter Management Console and
the server manager must reside on the same host.
Use External LDAP
Allows you to point to your own LDAP server. For failover purposes, multiple external
LDAPs are supported. To support failover, the multiple LDAP servers must have similar
LDAP configurations.
Parameter Description
Protocol Select the type of security protocol: ldap, ldaps (secure ldap), or tls
(transport layer security).
Host Type the name where the stand-alone LDAP server resides.
Port Type the port used by the LDAP instance to listen for connections.
Partition Type the unique name of the LDAP partition.
Users Type the name for the list of users to receive LDAP permission.
The default value is ou=Users.
User Object Type the class for the users to receive LDAP permission.
Class
The default value is inetOrgPerson.

© 2021 Siemens
Install the Teamcenter Management Console
User Type the attribute that users must have to receive LDAP permission.
Attribute
User Filter Type the LDAP-formatted filter to narrow the pool of authorized
(optional) users. Use the following format:
(attribute1=value1)(attributeN=valueN)
c. Click Next.
3. In the JMX Configuration panel, for each of the server components that you want to view in the
Teamcenter Management Console, add the component and enter its parameter values.
If you add a Web Tier component here, then you will later need to configure its web app server.
Type Select one of Server Manager or Web Tier.
ID Type the ID of the component.

For example, type PoolA for the default server manager pool or
Teamcenter1 for the default web tier.
Tip:
Obtain the server manager pool name from the smgrPoolId value in
the TC_ROOTinstall\configuration.xml file. Obtain the web tier ID
from the Web Application Manager used to create the web tier
application.
Host Type the host name of the machine running the server.
JMX RMI Port Type the JMX RMI port number for the server.
To find the correct JMX port for your web server, see your web server
documentation.
Note:
For JBoss web tier configuration, use default port 9999.

© 2021 Siemens
4. Server manager
For Tomcat, WebLogic, and WebSphere, use default port 8089.
4. In the Communication Configuration panel, do one of the following:
• Accept the default port 8083.
• Select the Enable SSL check box and enter parameters to use secure communication.
Https Port Type the port to be used for HTTPS communication.
KeyStore Type the full path and file name to the keystore file.
KeyStore Type Type the file extension for the keystore.
KeyStore Type the password to the keystore.

Password
KeyManager Type the manager password to the keystore.

Password
5. After you enter all the installation information, in the Confirmation panel click Start to install the
Teamcenter Management Console.
Configure the web app server for a Teamcenter Management Console web
tier component
If, when the Teamcenter Management Console was installed, in the JMX Configuration panel a Web
Tier component was added, then the web application server for the component must be configured to
allow authenticated remote JMX connection. Authentication is typically accomplished using LDAP.
Note that this procedure applies only to a Java-based web tier; the console does not support a .NET (IIS)
web tier.
Use the following procedures to enable remote JMX connection. The procedure steps vary depending on
the web application server software, such as JBoss, Tomcat, WebLogic, or WebSphere.

© 2021 Siemens
Configure the web app server for a Teamcenter Management Console web tier component
JBoss
JBOSS Enterprise Edition implements its own JMX connector with built-in security to allow JMX Remote
Connection. This built-in security does not use the LDAP server used by the Teamcenter Management
Console.
Note:
Siemens Digital Industries Software certifies only JBoss Enterprise Application Platform versions of
JBoss. Mapping to appropriate WildFly versions should work, but is not directly tested or certified.
When running in stand-alone mode, the native management endpoint runs with the default port 9999.
To access this native management securely, a management user in the ManagementRealm realm is
required.
1. Edit the JBoss standalone.xml configuration file. The file resides in the JBOSS_HOME/standalone/
configuration directory.
• In the section interface, on the line for the inet-address, change the value from the default
local host ip address (127.0.0.1) to the actual host name of the machine on which JBoss is
running.
• In the section socket-binding-group, add the new socket binding:
• In the section management-interfaces, add native-interface ManagementRealm and its

socket binding.
2. Add a user by running the JBOSS_HOME/bin/add-user.sh script (Linux) or JBOSS_HOME\bin\add-

user.bat script (Windows).

© 2021 Siemens
4. Server manager
This utility prompts you for the following information:
For this
parameter Do this
Type Select Management User.
Realm Enter the name of the realm used to secure the management interface.
The default is ManagementRealm.
Username Type the user name to be created.
Password Type the password for the user.
Groups Type the group names that the user should be part of.
The default is leave blank, for no groups.
User connects Type no.

process to
another
process?
Tip:
There is no management user created by default in JBoss. You can add the same user
accounts in JBoss as those in the LDAP repository used by the Teamcenter Management
Console.
Teamcenter Management Console attempts to connect to JBoss Remote Management using its
credentials.
• If the same user exists in JBoss Management, then a silent logon occurs in the Teamcenter
Management Console.
• If not, then the Teamcenter Management Console prompts a logon challenge to connect JBOSS
Enterprise Edition Remote Management.
3. Restart JBoss.
4. To allow the Teamcenter Management Console to connect to JBoss JMX Remote Management,
JBoss Client Library is required.
a. Stop the Teamcenter Management Console if it is running.

© 2021 Siemens
Configure the web app server for a Teamcenter Management Console web tier component
b. Open the Teamcenter Management Console com.teamcenter.jeti.mgmt.jmx.jboss-

[Teamcenter version].jar bundle that resides in the TC_ROOT/mgmt_console/container/
bundles directory using any utility (for example, 7zip).
Inside the bundle, add a new folder called lib and add the jboss-cli-client.jar to this new
folder. The jboss-cli-client.jar file can be found in the JBOSS_HOME/bin/client directory.
c. Restart the Teamcenter Management Console.
Tomcat or WebLogic
1. Create an ldap.config file with the following content:
MgmtLdapConfig {
com.sun.security.auth.module.LdapLoginModule REQUIRED
userProvider="ldap://localhost:15389/ou=Users,ou=Management,ou=JETI,
dc=Teamcenter,dc=PLM,o=Siemens"
authIdentity="uid={USERNAME},ou=Users,ou=Management,ou=JETI,
dc=Teamcenter,dc=PLM,o=Siemens"
authzIdentity=controlRole
useSSL=false
debug=false;
};
Note:
Ensure that the LDAP settings are configured properly (for example, the LDAP protocol, host,
port, and so on.)
2. Establish the ldap.config file depending on the web app server and operating system.
For this
combination Do this
Tomcat on Red a. Place the ldap.config file in your Tomcat root directory. For example, /
Hat Enterprise apps/apache-tomcat-<version>.
Linux
b. Modify the Tomcat startup configuration (catalina.sh) to include the
following JAVA_OPTS variable:
JAVA_OPTS="-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.login.config=MgmtLdapConfig
-Djava.security.auth.login.config=<PATH>/ldap.config
-Dcom.sun.management.jmxremote.ssl=false"
export JAVA_OPTS
Tomcat on a. Place the ldap.config file in your Tomcat root directory.

other than Red

© 2021 Siemens
4. Server manager
For this
combination Do this
Hat Enterprise b. Modify the Tomcat startup configuration to add the following
Linux JAVA_OPTS variable:
set "JAVA_OPTS=%JAVA_OPTS%
-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.ssl=false
-Djava.security.auth.login.config=Tomcat-root-directory
\ldap.config"
How you add the options varies depending on how Tomcat is installed.
• If Tomcat is installed as a Windows service, then the configuration

changes can be made by using the configuration utility.
• Otherwise, you must locate the corresponding startup scripts and

modify the JVM arguments shown in the preceding example. For
example, add the Java arguments in doStart function of the
catalina.bat file.
WebLogic a. Place the ldap.config file in your WebLogic domain directory.
b. Modify the startWebLogic.cmd file to add the following

JAVA_OPTIONS. Add the new lines before the call "%DOMAIN_HOME
%\bin\startWebLogic.cmd" %* line:
set JAVA_OPTIONS=%JAVA_OPTIONS%
-Djava.security.auth.login.config=ldap.config
-Djavax.management.builder.initial=weblogic.management.jmx.
mbeanserver.
WLSMBeanServerBuilder
3. Restart the web app server.
Note:
Restart WebLogic by running the startWebLogic.cmd file.

© 2021 Siemens
Launch the Teamcenter Management Console
WebSphere
The Teamcenter Management Console does not support secured remote JMX connection to WebSphere
due to vendor issues. However, it is possible to configure WebSphere for an unsecured JMX remote
connection.
1. Log on to the WebSphere administration console and navigate to the configuration tab of the
server instance on which the Teamcenter web tier is deployed.
2. In the Server Infrastructure setting group, expand Java and Process Management and click
Process definition.
3. In the Additional Properties setting group, click Java Virtual machine.
4. Within the Generic JVM arguments input field, add the following JVM arguments:
-Djavax.management.builder.initial=
-Dcom.sun.management.jmxremote.authenticate=false
5. Save and apply the changes and restart the server.
Launch the Teamcenter Management Console
After you install the Teamcenter Management Console, perform the following steps to launch the
console.
Note:
If the Teamcenter Management Console settings are changed in Teamcenter Environment
Manager (TEM), such as by adding or removing server components, then you must clear the JETI
Management cache for the changes to reliably take effect.
1. At a system command prompt, set the current directory to the following path as appropriate for the
operating system.
Operating system Directory path

Windows TC_ROOT\mgmt_console\container\bin\
Linux TC_ROOT/mgmt_console/container/bin/
2. To start JETI Management, run the following command as appropriate for the operating system:

© 2021 Siemens
4. Server manager
Operating system Command

Windows TC_ROOT\mgmt_console\container\bin\trun
Linux ./trun
Tip:
On Linux platforms, to run the Teamcenter Management Console in background, you would
expect to run the following command:
nohup ./trun &
However, trun does not support the nohup command well, and you must use the following
command instead:
./start
In other words, the start script should be used to achieve the same goal. Additionally, the
start script writes the terminal output to the following file, an equivalent to the nohup.out
file generated by the nohup command:
TC_ROOT/mgmt_console/container/data/karaf.out
3. To launch the console, in your web browser enter the following URL:
http://host:8083/mgmt/console
If you encounter difficulties displaying the Teamcenter Management Console in a Windows

Internet Explorer browser, then disable the Internet Explorer Compatibility View setting, restart
the browser, and reopen the Teamcenter Management Console.
4. Enter your login credentials and click Sign in.
If this is the first time the console is run, then do the following to establish a secure password.
a. Type admin for the user name and admin for the password and click Sign in.
A prompt to change the password appears.
b. In the prompt to change the password, click OK.
c. In the Change Password dialog box, change the password from admin to another password
and click Save.
The password must be a minimum of 8 characters in length and cannot contain the string
admin.

© 2021 Siemens
Run the Teamcenter Management Console as a service
The console is displayed.
Stopping and restarting JETI Management, clearing the cache
1. To stop JETI Management, in the JETI Management console window press Ctrl+D.
Alternatively, run the following command as appropriate for the operating system.

Windows stop
Linux ./stop
2. To restart JETI Management and clear the JETI Management cache, run the following command as
appropriate for the operating system.

Windows trun -clean
Linux ./trun -clean
An alternative method for clearing the cache is to stop JETI Management and then manually delete all
the entries in the following directory:
Operating system Directory

Windows TC_ROOT\mgmt_console\container\data
Linux TC_ROOT/mgmt_console/container/data
Teamcenter Environment Manager (TEM) only installs the Teamcenter Management Console in console
mode. Perform the following steps to run the Teamcenter Management Console as a Windows service
or as a Linux service.
• Windows

© 2021 Siemens
4. Server manager
1. Start the Teamcenter Management Console on Windows.
2. At a command prompt, type the following command:
feature:install wrapper
This provides a new command to install Apache Karaf as a Windows service, for example:
karaf@JETIMgmt()> feature:install wrapper
3. At a command prompt, type the following command:
wrapper:install -s AUTO_START -n service-name

-d display_service_name -D service_description
For example:
karaf@JETIMgmt()> wrapper:install -s AUTO_START -n Tc-Mgmt-Console-Container

-d Tc-Mgmt-Console-Container -D "Teamcenter Management Console"
Following is an example of the output:
Creating file:
D:\workdir\user_tc\out\rt\mgmt_console\container\bin
\Tc-Mgmt-Console-Container-wrapper.exe
Creating file:
D:\workdir\user_tc\out\rt\mgmt_console\container\bin\..\etc
\Tc-Mgmt-Console-Container-wrapper.conf
Creating file:
\Tc-Mgmt-Console-Container-service.bat
Creating file:
D:\workdir\user_tc\out\rt\mgmt_console\container\lib\wrapper.dll
Creating file:
D:\workdir\user_tc\out\rt\mgmt_console\container\lib\karaf-wrapper.jar
Creating file:
D:\workdir\user_tc\out\rt\mgmt_console\container\lib\karaf-wrapper-main.jar
Setup complete. You may wish to tweak the JVM properties in the wrapper
configuration file:
D:\workdir\user_tc\out\rt\mgmt_console\container\bin\..\etc
\Tc-Mgmt-Console-Container-wrapper.conf
before installing and starting the service.
MS Windows system detected:

To install the service, run:
C:>D:\workdir\user_tc\out\rt\mgmt_console\container\bin
\Tc-Mgmt-Console-Container-service.bat install
Once installed, to start the service run:

C:> net start "Tc-Mgmt-Console-Container"
Once running, to stop the service run:

C:> net stop "Tc-Mgmt-Console-Container"

© 2021 Siemens
Once stopped, to remove the installed the service run:

C:> D:\workdir\user_tc\out\rt\mgmt_console\container\bin
\Tc-Mgmt-Console-Container-service.bat remove
4. After setup is completed, follow the instructions to install and start the service on Windows.
For example, to install the Windows service, use a command similar to the following:
\Tc-Mgmt-Console-Container-service.bat install
To start the Windows service, use a command similar to the following:
net start "Tc-Mgmt-Console-Container"
• Linux
1. Start the Teamcenter Management Console on Linux as root user.
2. Press the Enter key to bring up a Karaf command prompt.
Example:
karaf@JETIMgmt()>
3. At the Karaf command prompt, press the tab key to list all possible commands.
4. Type the following:
5. At the Karaf command prompt, press the tab key again to list all possible commands.
You will see the wrapper:install command.
Example:
6. Using the following pattern, type the command to set up your service:
wrapper:install -s AUTO_START -n service-name

-d display_service_name -D service_description
For example:

© 2021 Siemens
4. Server manager
karaf@JETIMgmt> wrapper:install -s AUTO_START -n Tc_MgmtConsole_Lnx_Service

-d Tc_MgmtConsole_Lnx -D "Teamcenter Management Console"
Following is an example of the output:
Creating file:
/apps/tc/ora/TR/mgmt_console/container/bin/Tc_MgmtConsole_Lnx_Service-wrapper
Creating file:
/apps/tc/ora/TR/mgmt_console/container/bin/Tc_MgmtConsole_Lnx_Service-service
Creating file:
/apps/tc/ora/TR/mgmt_console/container/etc/
Tc_MgmtConsole_Lnx_Service-wrapper.conf
Creating file:
/apps/tc/ora/TR/mgmt_console/container/lib/libwrapper.so
Creating file:
/apps/tc/ora/TR/mgmt_console/container/lib/karaf-wrapper.jar
Setup complete.
You may wish to tweak the JVM properties in the wrapper configuration file:
/apps/tc/ora/TR/mgmt_console/container/etc/
Tc_MgmtConsole_Lnx_Service-wrapper.conf
before installing and starting the service.
The way the service is installed depends upon your flavor of Linux.
On Redhat/Fedora/CentOS Systems:
To install the service:
$ ln -s /apps/tc/ora/TR/mgmt_console/container/bin/
Tc_MgmtConsole_Lnx_Service-service/etc/init.d/
$ chkconfig Tc_MgmtConsole_Lnx_Service-service --add
To start the service when the machine is rebooted:

$ chkconfig Tc_MgmtConsole_Lnx_Service-service on
To disable starting the service when the machine is rebooted:

$ chkconfig Tc_MgmtConsole_Lnx_Service-service off
To start the service:

$ service Tc_MgmtConsole_Lnx_Service-service start
To stop the service:

$ service Tc_MgmtConsole_Lnx_Service-service stop
To uninstall the service:

$ chkconfig Tc_MgmtConsole_Lnx_Service-service --del
$ rm /etc/init.d/Tc_MgmtConsole_Lnx_Service-service
On Ubuntu/Debian Systems:
To install the service:
$ ln -s /apps/tc/ora/TR/mgmt_console/container/bin/
To start the service when the machine is rebooted:

$ update-rc.d Tc_MgmtConsole_Lnx_Service-service defaults
To disable starting the service when the machine is rebooted:

$ update-rc.d -f Tc_MgmtConsole_Lnx_Service-service remove
To start the service:

© 2021 Siemens
Modify settings of the Teamcenter Management Console
$/etc/init.d/Tc_MgmtConsole_Lnx_Service-service start
To stop the service:

$/etc/init.d/Tc_MgmtConsole_Lnx_Service-service stop
To uninstall the service:

$ rm /etc/init.d/Tc_MgmtConsole_Lnx_Service-service
7. After setup is completed, follow the instructions to install and start the service based on your
Linux operating system.
For example, on SUSE Linux, enter the following command to install the service:
linux-host:/apps/tc/ora/TR/mgmt_console/container # ln
-s /apps/tc/ora/TR/mgmt_console/container/bin/
linux-host:/apps/tc/ora/TR/mgmt_console/container # chkconfig
Tc_MgmtConsole_Lnx_Service-service --add
Following is an example of the output to add the service:
Note: This output shows SysV services only and does not include native systemd
services.
SysV configuration data might be overridden by native systemd configuration.
If you want to list systemd services use 'systemctl list-unit-files'.

To see services enabled on particular target use
'systemctl list-dependencies [target]'.
Tc_MgmtConsole_Lnx_Service-service 0:off 1:off 2:on 3:on 4:off 5:on 6:off
To start the service, use a command similar to the following:
linux-host:/apps/tc/ora/TR/mgmt_console/container # service
Tc_MgmtConsole_Lnx_Service-service start
Modify settings of the Teamcenter Management Console
1. Stop JETI Management in one of these ways:
• In the JETI Management console window, press Ctrl+D.
• Run the following command:
TC_ROOT\mgmt_console\container\bin\stop
2. Launch Teamcenter Environment Manager (TEM). In the Maintenance panel, select Configuration
Manager and click Next.
3. In the Configuration maintenance panel, select Perform maintenance on an existing

configuration and click Next.

© 2021 Siemens
4. Server manager
4. In the Old Configuration panel, select the configuration you want to change and click Next.
5. In the Feature Maintenance panel, under Teamcenter Management Console select Modify
settings and click Next.
6. Make changes as needed to the settings. The available panels are the same as those used to install
the Teamcenter Management Console.
7. After you make changes, click Next in TEM until you arrive at the Confirmation panel. Click Start
to install the changes.
8. Run the following command to stop JETI Management:
TC_ROOT\mgmt_console\container\bin\stop
9. Run the following command to start JETI Management and to clean out the old settings:
TC_ROOT\mgmt_console\container\bin\trun -clean
10. Type the following URL in your web browser to run the Teamcenter Management Console:
http://host:8083/mgmt/console
The changes you made in TEM should be reflected in the console.
Tip:
If the changes do not appear, there may have been a problem with cleaning out JETI
Management information using the trun -clean command. To clean out this information, you
can remove the files from the following directory:
TC_ROOT\mgmt_console\container\data\*.*
After removing these files, restart JETI Management.
Administering pools with the Teamcenter Management Console
You can use the Teamcenter Management Console to administer active Teamcenter server pools. To
make persistent pool configuration changes, modify the respective TC_ROOT\pool_manager\confs
\<config_name>\serverPool.properties file.
1. Launch the Teamcenter Management Console.
The default address is http://host:8083/mgmt/console
2. Under Server Manager, select the server pool you want to administer.

© 2021 Siemens
The Status page of the console displays information for the selected pool.
3. Click the Operation tab or Config tab to show available actions and settings. The following
illustrations show the available actions and settings on the tab pages and sub-pages.
Operation tab
Shutdown Terminate the manager, all of its servers, and TECS with the MUX. Wait for
Wait active servers to finish their current request.
Shutdown Terminate the manager, all of its servers, and TECS with the MUX. Do not wait
Immediately for active servers to finish their current request.

© 2021 Siemens
4. Server manager
Restart Restart all warm servers in all pools, so that all unassigned warm servers have
Warm a current configuration.
Servers
The Restart Warm Servers operation terminates existing warm TcServers
(TcServers that are unassigned but ready for use). The Server Manager then
spawns new TcServers with the latest configuration, included changes such
as server side preference updates.
Show On a new page, show the manager's stored cluster data.
Cluster Data
Config tab
Various configuration settings are available on three sub-pages: Pool Config, Advanced Pool
Config, and Global Pool Config. To change the selected pool's configuration values, edit the
values on a page and then click Submit on that page.
Changes made on the Global Pool Config page apply to all pools.

© 2021 Siemens

© 2021 Siemens
4. Server manager
Configure pool manager monitoring with the Teamcenter Management

Console
This procedure describes how to configure pool manager monitoring with the Teamcenter
Management Console. You can also configure pool manager monitoring with a configuration file.
The following dynamic changes are temporary. To make persistent changes, modify the TC_ROOT
\pool_manager\confs\<config_name>\poolMonitorConfig.xml file.
1. Start the Teamcenter Management Console.
By default, the address is http://host:8083/mgmt/console.
3. Click Manager Monitoring.
This view lists the monitoring mode and all the metrics available for monitoring.
4. Set the Master Monitoring Mode value to one of the following:
• Off
Disables monitoring of all the metrics listed in the file.
• Disable Alerts
Enables monitoring of all the metrics listed in the file, but disables all notifications of critical
events regardless of individual notification settings on any metric.

© 2021 Siemens
Configure pool manager monitoring with the Teamcenter Management Console
• Normal
Enables monitoring of all the metrics listed in the file.
5. Configure responders.
a. Click EmailResponder1.
(Optional) To be notified when criteria reaches the specified threshold, specify from whom, to
whom, and how frequently email notification of critical events are sent by setting the
following EmailResponder1 values. All EmailResponder1 values in all child monitoring
metrics must match the values set here.
• From_address
Specify the address from which the notification emails are sent.
• To_address
Specify the address to which the notification emails are sent. You can specify multiple email
addresses separated by semicolons (;).
• Host_address
Specify the server host from which the email notifications are sent. In a large deployment
(for example, with multiple server managers) the host address identifies the location of the
critical events.
• Suppression_period
Specify the amount of time (in seconds) to suppress email notification of critical events.
b. Click Apply.
c. Click LoggerResponder1.

© 2021 Siemens
4. Server manager
(Optional) To be notified when criteria reaches the specified threshold, specify to whom, and
to which file, critical events are logged by setting the following LoggerResponder values. All
LoggerResponder values in all child monitoring metrics must match the LoggerResponder
values set here.
• Log_filename
Specify the name of the file to which critical events are logged.
Specify the amount of time (in minutes) to suppress logging of critical events to the log file.
d. Click Apply.
6. Configure monitoring of any of the server manager metrics listed under the Metrics heading.
a. Click the desired metric (for example, ColdServers). Hover the mouse on each metric to learn
about the metric.
Click Events to see events that have occurred for a metric. Hover the mouse over the events
to view information about the possible causes and recommended actions for the event.

© 2021 Siemens
Configure server monitoring with the Teamcenter Management Console
b. Set the value for the mode (the Configure_mode attribute) to one of the following:
• Off
Specifies that no metric data is collected.
• Collect
Specifies that metric data is collected and displayed in the console view.
This is the default setting.
• Alert
Specifies that metric data is collected and displayed in the console view. Email notifications
are sent when critical events occur.
c. (Optional) To be notified when the criteria reaches the specified threshold, specify the
EmailResponder1 and LoggerResponder1 values for the Responder Ids attribute.
By default, these values are set to EmailResponder1 and LoggerResponder1. If you have
configured multiple EmailResponder IDs, make sure you specify the desired
EmailResponder.
d. Set the remaining values to specify criteria that must be met to initiate a critical event for the
metric.
e. After specifying values for each monitoring metric, click Apply.
Administrators can use the following procedure to configure monitoring and alerts of various server
events.

© 2021 Siemens
4. Server manager
Changes made in the Server Monitoring view are persisted in the TC_DATA\serverMonitorConfig.xml
file.
The default address is http://host:8083/mgmt/console.
2. Click Server Monitoring.
This view lists the master monitoring mode, the event metrics available for monitoring, and
responders that can be used for notification of a critical event.
3. Set the Master Monitoring Mode value to one of the following:
Value Description
Off Disables monitoring of all the metrics listed in the file.
DisableAlerts Enables monitoring of all the metrics listed in the file, but disables all
notifications of critical events regardless of individual notification settings
on any metric.
Normal Enables monitoring of all the metrics listed in the file.

© 2021 Siemens
4. To configure monitoring of a server event type (or metric), under the Metrics heading, click the
desired metric and set its values.
Example:
a. Click Deadlocks.
b. Set values for the metric.
Value Description
Deadlocks Select one of the following.
Value Description
Off No metric data is collected.
Collect Metric data is collected and

displayed in the console view.
Alert Metric data is collected and

displayed in the console view.
Notifications are initiated when
critical events occur.
Threshold Enter the event quantity at which to initiate a critical event

Value notification.

© 2021 Siemens
4. Server manager
Value Description
History Max Enter the event quantity at which to stop logging entries.
Entries
Responder In the list, the active critical event alert notification

Ids responders for the metric are highlighted. To select a
responder, click its name. Use Ctrl+click to select multiple
responders.
c. Click Apply.
5. Configure the responders that can be used for alert notification of a critical event.
Example:
To configure email notification, click EmailResponder1 and set the values. When you finish
specifying values, click Apply.
Value Description
From_address The address from which notification emails are sent.
To_address The address to which notification emails are sent. You can
specify multiple email addresses separated by semicolons
(;).
Host_address The server host from which the email notifications are
sent. In a large deployment (for example, with multiple

© 2021 Siemens
Administer logging levels with the Teamcenter Management Console
Value Description
server managers) the host address identifies the location

of the critical events.
Suppression_period The amount of time (in seconds) to suppress email

notification of critical events.
Example:
To configure logging of critical events, click LoggerResponder1 and set the following values.
When you finish specifying values, click Apply.
Value Description
Log_filename The name of the file to which critical events are logged.
Suppression_period The amount of time (in seconds) to suppress logging of

critical events to the log file.
You can change logging levels dynamically for server manager pools, the web tier, or tcserver instances.
The following dynamic changes are temporary. To make persistent changes, modify the TC_ROOT
\pool_manager\confs\<config_name>\log4j2.xml file.
Select the component, click Log Levels, browse to the element for which you want to change the
logging, and click the arrow on the box to select a different log level.

© 2021 Siemens
4. Server manager
The bold text in the priority level indicates the level is configured explicitly, for example, INFO in the
following example. The entries with an asterisk indicate that the priority level is inherited from its
parent, for example, ERROR*.
Perform the following steps to learn how to navigate to the logging for each type of component (server
manager, web tier, and tcserver).
2. Under Server Manager, select a server pool and click Log Levels.
3. To access logging for the web tier, select the web tier instance and click Log Levels.

© 2021 Siemens
4. Perform the following steps to access logging for a tcserver instance:
a. Select TcServer and click the Search button.
The available instances are displayed.
b. Select a tcserver instance.
c. Click Logging to set the kind of logging you want for the selected instance.

© 2021 Siemens
4. Server manager
d. Click Log Levels to change the levels for Teamcenter elements in the selected tcserver
instance.
Administer the web tier with the Teamcenter Management Console
The following dynamic changes are temporary. To make persistent changes to the webtier configuration
(for example, resource adapter), modify the setting in the Web Application Manager (insweb),
regenerate tc.war, and redeploy it in the application server.
The web tier monitoring files webMonitorConfig.xml and webMonitorConfigInfo.xml reside inside tc.war
file (WEB-INF\lib\mldcfg.jar). An administrator can extract webMonitorConfig.xml and
webMonitorConfigInfo.xml files and place them in the root folder of the application server, or update
the webMonitorConfig.xml file inside the tc.war file.
The web tier configuration file log4j2.xml resides inside tc.war file (WEB-INF\lib\mldcfg.jar). An
administrator can extract this log4j2.xml file and place it in the root folder of the application server or
update this log4j2.xml file inside the tc.war file.

© 2021 Siemens
Administer the web tier with the Teamcenter Management Console
2. Under Web Tier, select the web tier server you want to administer.
3. Select Resource Adapter to administer the web tier. Click Resource Adapter Operations to
manage the web tier pool.
4. Select Log Levels to change logging for the web tier.
5. Select Monitoring to monitor the web tier metrics.
See Web tier monitoring metrics for more information about the metrics.

© 2021 Siemens
4. Server manager
Administer tcserver instances in the Teamcenter Management Console
tcserver instances are logical business logic servers in the server pool. Use the TcServer component in
the Teamcenter Management Console to dynamically configure and monitor these servers.
Dynamic changes to tcserver log level are temporary. To make persistent changes to the tcserver log
level persisted, an administrator can modify the tcserver logger in the TC_DATA\logger.properties or
TC_DATA\logger.debug.properties file.
2. Select TcServer and click the Search button.
The available server instances are displayed along with related information such as their process
IDs, modes, and status. Each server's lifecycle stage is also displayed. Lifecycle has the following
stages:
Warming The server has started, but is not ready.

Ready The server is ready to be assigned to a user.
Assigning The server is in the process of being assigned to a user.
Assigned The server is assigned to a user session.
3. Select a tcserver instance.

© 2021 Siemens
Administer tcserver instances in the Teamcenter Management Console
4. Select Logging or Log Levels to change logging for the server instance.
Click Logging to view and change the active logging options for the selected tcserver instance.
The following options are useful for troubleshooting:
• Show Syslog
Displays the most recent portions of the tcserver system log in a separate browser.
• Config for modules

Shows each Teamcenter module known to the journaling system. Select the modules for which
journaling is active.
• Show Journal
Displays the most recent parts of the journal file in a separate browser.

© 2021 Siemens
4. Server manager
5. Select Monitoring to view the server instance settings.
Tip:
Many of the settings are read-only because the master settings are configured in the server
pool.
Inactivate and activate a server pool
Inactivating a running server pool prevents it from accepting new connections. After notifying users
who are connected to the pool to close down or re-login, the administrator can perform maintenance
tasks, such as perform patch install or system level maintenance, and then later reactivate the pool.
Existing server assignments in the pool continue to serve clients and can be managed as usual, as long
as the pool is still running.
This procedure describes how use the Teamcenter Management Console to inactivate and activate a
running server pool.

© 2021 Siemens
Inactivate and activate a server pool
The Status tab of the console displays information on the selected pool. An Active Status of true
means the pool is available for TcServer assignments to new Teamcenter login requests.
3. To change the Active Status value, click the Operation tab and then click the Activate or
Inactivate button as appropriate.
4. To confirm the change in status, click the Status tab and check the value of Active Status.

© 2021 Siemens
4. Server manager
Administer TcServer timeouts in the Teamcenter Management Console
The server manager may timeout (terminate) idle TcServer instances. A TcServer instance is considered
idle if it does not receive any requests from the client application.
Use the Global Pool Config tab to dynamically configure Teamcenter server timeout values. To reach
the tab, choose Server Manager>[pool name]>Config>Global Pool Config.
When you modify timeout values on the Global Pool Config tab and then click Submit, the timeout
values are immediately applied to all Server Manager pools and all TcServer instances in the cluster. To
make persistent changes to the TcServer timeout values, an administrator can modify the respective
setting in TC_ROOT\pool_manager\confs\<config_name>\serverPool.properties file.
How server manager computes timeout application
The server manager computes the timeout value to apply to a server instance based on a combination of
the server pool load, the instance's server mode, and the applicable timeout parameter value. Hard and
Soft timeout parameters specify a range of timeout values for each of three server modes.
Server
Situation mode Result of timing out the server
The client has made unsaved edits. Edit Changes are lost.

© 2021 Siemens
Administer TcServer timeouts in the Teamcenter Management Console
Server
Situation mode Result of timing out the server
Example:
Structure Manager uses edit mode
to allow users to edit a BOM
structure through multiple
operations that change temporary
data in the server and client until
the user saves the data.
The client has cached data in its Read A performance or functional issue may occur, but
working memory, but no edits are no loss of edits occurs.
unsaved.
The cost of timing out a TcServer in Read mode is
the time a user has to spend to get back to the
state in existence at the time the server was
timed out.
No persistent data is cached in memory. Stateless No performance, functional issue, or loss of data
occurs.
The only cost of timing out a TcServer in Stateless
mode is the cost of a server assignment and
authentication when the client does become
active again.
Edit and Read mode occur mostly with rich client and NX. Stateless mode occurs mostly with Active
Workspace client.
The server manager never applies timeout values that are longer than the Hard values. Therefore, each
Soft value should be set less than or equal to the corresponding Hard value. As the count of TcServer
instances exceeds the Process Target value, the server manager incrementally reduces the timeout
value it applies, from the Hard value to the Soft value. The total number of TcServer instances includes
both assigned and warm processes. When the count reaches 110% of Process Target, the server
manager fully applies the Soft timeout value.
If the total count of TcServers reaches 95% of Process Max (PROCESS_MAX), the server manager further
incrementally reduces timeout values. This reduction proceeds to as low as 20% of the Soft timeout
values.
The following table describes the additional timeout parameters that appear on the Global Pool Config
tab:

© 2021 Siemens
4. Server manager
This parameter Configures this

Process Max Per The maximum number of running processes (server instances) allowed per user.
User
User Timeout If a user hits the limit defined by the Process Max Per User value, the timeout
Stateless value applied to stateless server instances that are assigned to the user.
Query Timeout The maximum time a server is allowed to process a single request. If this time is
exceeded, the server is terminated.
A value of 0 turns off the query timeout, allowing a server to continue processing
a request indefinitely.
Example log messages
The server manager logs messages for automated changes in idle timeout values and when a TcServer
does timeout:
PoolA.00041.ServerStarter4Tier - Adjust idle timeouts to 60% of soft

timeouts:
PoolA.00041.ServerStarter4Tier - Edit idle timeout: 04:48:00 (17280s)
PoolA.00041.ServerStarter4Tier - Read idle timeout: 04:48:00 (17280s)
PoolA.00041.ServerStarter4Tier - Stateless idle timeout: 12:00 (720s)
...
vcl6006.96233728.tcserver93.2 - TcServer tcserver93@PoolA@81958@vcl6006
stateless idle timeout.
removed.
finished.
Each TcServer instance also records in the syslog changes to the idle timeouts and when the TcServer
does timeout:
EDIT IDLE timeout limit: 04:48:00 (17280s)

READ IDLE timeout limit: 04:48:00 (17280s)
STATELESS IDLE timeout limit: 12:00 (720s)
...
Exceeded the STATELESS IDLE timeout limit: 720 seconds
Administer embedded LDAP for Teamcenter Management Console
Introduction to administering embedded LDAP for the Teamcenter Management Console
Lightweight directory access protocol (LDAP) is a protocol that facilitates user authentication and
authorization. You must use LDAP to provide authorization for user access to the Teamcenter
Management Console.

© 2021 Siemens
Install and configure Apache Directory Studio for use with embedded LDAP
When you install the Teamcenter Management Console, the Use Embedded LDAP option is selected
by default on the Management Console LDAP Configurations panel in Teamcenter Environment
Manager (TEM). You can use this embedded LDAP to manage user authentication instead of having to
use your own external LDAP system.
To administer the embedded LDAP, you can use Apache Directory Studio provided in the Teamcenter
installation source at additional_applications\ApacheDirectoryStudio. Apache Directory Studio is an
optional tool. After you install and configure Apache Directory Studio, you can define users and
passwords used by the embedded LDAP to permit access to the Teamcenter Management Console.
The embedded LDAP only has one user account created by default (admin) to access the Teamcenter
Management Console. The Teamcenter administrator can add additional users to access the console (for
example, user1, user2, and so on). In addition, you can also set password policies such as the minimum
password length, password reset at first-time logon, password aging, the requirement of special
characters on passwords, blacklist passwords, and so on.
Use Apache Directory Studio to administer users and passwords for the Teamcenter Management
Console embedded lightweight directory access protocol (LDAP).
1. In the Teamcenter installation source, browse to the additional_applications

\ApacheDirectoryStudio directory.
• Windows systems
Run the ApacheDirectoryStudio-platform-version.exe file.
• Linux systems
Extract the ApacheDirectoryStudio-platform-version.tar.gz file and run the resulting installable
file.
2. Follow the prompts to install Apache Directory Studio.
Apache Directory Studio stores its information in the following directories:
• Windows systems
user-home-directory\.ApacheDirectoryStudio\.metadata\
• Linux systems
$HOME/.ApacheDirectoryStudio/.metadata/
3. Run Apache Directory Studio.
• Windows systems
Run the installed-location\Apache Directory Studio\Apache Directory Studio.exe file.
• Linux systems

© 2021 Siemens
4. Server manager
Run the installed-location/ApacheDirectoryStudio-platform-version/ApacheDirectoryStudio file.
4. In the Apache Directory Studio user interface, open the Connections tab and click the New
Connection button.
5. In the Network Parameter dialog box, create a connection to the embedded LDAP.

© 2021 Siemens
a. In the Connection Name box, type a name to identify this connection.
b. In the Hostname box, type the name of the host where the embedded LDAP is installed. This
is the same host where the Teamcenter Management Console is installed.
c. In the Port box, type 15389. This is the default port for the embedded LDAP.
d. In the Encryption method box, select the required encryption of the target LDAP. The default
for embedded LDAP is No encryption. (Do not select Use StartTLS extension because
StartTLS is not supported in the embedded LDAP.)
e. In the Provider box, select Apace Directory LDAP Client API.
f. Click Check Network Parameter to ensure that the connection works.
g. Click Next.
6. In the Authentication dialog box, configure security for the connection.
a. In the Authentication Method box, select Simple Authentication.
b. In the Bind DN or user box, select uid=admin,ou=system.

© 2021 Siemens
4. Server manager
c. Clear the Save password check box. If it is not selected, a password prompt appears every
time you open the connection.
Tip:
It is good policy to force logon with a password each time a connection is accessed. This
prevents unauthorized access to the system.
d. Click Finish.
You are prompted to enter the default password. Enter the default password secret and click
OK.
The connection appears in the Connections view of Apache Directory Studio. The Open
Connection button is gray, indicating the connection is open.
Tip:
If you want to change the values of the connection, right-click the connection and
choose Properties.
e. After you create the connection, you must change the password so that the default password
is no longer used. Choose the following path in the LDAP Browser view:
ou=system→
uid=admin
Double-click the userPassword attribute.

© 2021 Siemens
Set password policies for embedded LDAP
f. Type a new password in the Enter New Password box. Click the arrow in the Select Hash
Method box to select an encryption method. Siemens Digital Industries Software
recommends at a minimum that you use the SHA-256 method. When done, click OK.
g. After creating an LDAP connection, you can use the LDAP Browser view to set password
policies for the embedded LDAP.
If you use embedded lightweight directory access protocol (LDAP) to provide authorization for user
access to the Teamcenter Management Console, use Apache Directory Studio to administer passwords
for the embedded LDAP.

© 2021 Siemens
4. Server manager
1. Ensure that JETI Management is running. JETI Management must be running to work with
embedded LDAP.
Run the following command to start JETI Management:
TC_ROOT\mgmt_console\container\bin\trun
2. Install and configure Apache Directory Studio.
3. Run Apache Directory Studio. For example, run the installed-location\Apache Directory Studio
\Apache Directory Studio.exe file.
4. To view the default password policy settings provided by Apache Directory Studio, choose the
following path in the LDAP Browser view:
ou=config→
ads-directoryServiceId=default→
ou=interceptors→
ads-interceptorId=authenticationInterceptor→
ou=passwordPolicies→
ads-pwdId=default
The default Apache Directory Studio (ads) password policy attributes are displayed. For a
description of all Apache Directory Studio password policy entries, see Apache Directory help.

© 2021 Siemens
Tip:
Because the ads-pwdmustchange attribute is set to TRUE, LDAP forces users to change their
password upon the first logon after a new Teamcenter user is created or after the password
is modified for a Teamcenter user by an LDAP administrator.
5. The default embedded LDAP is extended with additional Teamcenter password policy features in
the authenticationInterceptorTc interceptor.
To view these Teamcenter password policy settings, choose the following path in the LDAP
Browser view:
ou=config→
ads-directoryServiceId=default→
ou=interceptors→
ads-interceptorId=authenticationInterceptorTc→
ou=passwordPolicies→
ads-pwdId=default
The Teamcenter password policy settings are displayed.

© 2021 Siemens
4. Server manager
6. By default, tc-pwdnotifyemailserver is the only Teamcenter-specific password policy attribute

shown. To add more Teamcenter policy entries, click the New Attribute button on the view
toolbar.
7. In the New Attribute dialog box, click the arrow in the Attribute type box to see a list of available
attributes.

© 2021 Siemens
Add Teamcenter users to embedded LDAP
Following are some of the available Teamcenter attributes:
• tc-pwdBlacklist (Optional)
Specifies a list of blacklisted passwords.
• tc-pwdLockNotifyEmails (Optional)
Specifies a list of email addresses to send notifications to regarding Teamcenter users locked out
of their accounts.
• tc-pwdNotifyEmailServer (Required)
Specifies the name of an email server to be used when sending password policy-related email
notifications.
• pc-pwdPatternsBlacklist (Optional)
Specifies a list of entries that are not allowed to be part of a password.
• tc-pwdRegEx (Optional)
Specifies a regular expression identifying a required password pattern.
8. Any changes to password policies requires you to restart the Teamcenter Management Console
before the policy can take effect.
9. After changing password policies, you can use the LDAP Browser view to add Teamcenter users
to embedded LDAP.
If you use embedded lightweight directory access protocol (LDAP) to provide authorization for user
access to the Teamcenter Management Console, use Apache Directory Studio to add users to the
embedded LDAP.
1. Ensure that JETI Management is running. JETI Management must be running to work with
embedded LDAP.
Run the following command to start JETI Management:
TC_ROOT\mgmt_console\container\bin\trun
2. Install and configure Apache Directory Studio.
3. Run Apache Directory Studio. For example, run the installed-location\Apache Directory Studio
\Apache Directory Studio.exe file.
4. To view the available Teamcenter users, choose the following path in the LDAP Browser view:

© 2021 Siemens
4. Server manager
ou=Management,ou=JETI,dc=Teamcenter,dc=PLM,o=Siemens→
ou=Users
Tip:
If a user is locked out of the system, you can unlock them by deleting the
pwdAccountLockedTime attribute on the user. To unlock the user, right-click the user,
choose Fetch→Fetch Operational Attributes, right-click the pwdAccountLockedTime
attribute, and choose Delete Value.
5. To add a new user, right-click the ou=Users entry and choose New→New Entry.
6. Ensure that Create entry from scratch is selected and click Next.

© 2021 Siemens
7. In the Available object classes box, type inetOrgPerson and click Add to move it to the Selected
object classes pane. Click Next.
8. In the RDN box, type uid. Type the user's name in the = box and click Next.
The user name must be in a typical user name format and should not have spaces. For example,
user Bob Smith should have a user name like bsmith.

© 2021 Siemens
4. Server manager
9. Type the user name in the cn and sn value boxes.
10. Click the New Attribute button on the view toolbar.
11. In the Attribute type box, type userPassword and click Next.

© 2021 Siemens
12. Click Finish.
The New Password dialog box is displayed.
Type the user's password in the Enter New Password box. In the Select Hash Method box, select
the method you want to use to encrypt the password. Siemens Digital Industries Software
recommends at a minimum that you use the SHA-256 method.
13. Click OK.
The userPassword attribute is displayed.

© 2021 Siemens
4. Server manager
14. Click Finish.
The new user is displayed in the LDAP Browser view.
Server manager prerequisites

Before using the server manager, you must:

© 2021 Siemens
Overview of server manager property files
1. Install the server manager.

In Teamcenter Environment Manager (TEM), you can install the server manager from the Features
panel under the Server Enhancements category.
2. Configure pool-specific properties.

Once server pools are configured, each individual machine should have its pool-specific
configuration tuned. This is of particular concern if individual machines differ greatly in the
number and power of CPUs. The pool-specific parameters are set in the TC_ROOT\pool_manager
\serverPooldatabase-name.properties file.
3. (Optional) Configure web tier administration.

By default, administering of web tier metrics and logging behavior is disabled. Enable
administration of web tier metrics and logging by resetting the mode attribute in the
pref_export.xml file.
4. Ensure that the server manager service or daemon is running.

The server manager service or daemon is necessary to enable four-tier rich clients to connect to the
corporate server.
Example:
On a Windows system, choose Start→Control Panel→Administrative Tools→Services and
select Teamcenter Server Manager. You can also manually run the server manager service
by running the following executable:
TC_ROOT\pool_manager\confs\configuration-namemgrstart.bat
Tip:
To verify that the server manager is running, launch the server manager user interface from a
web browser. For example, to start the interface, use the http://host-name:8083/mgmt/
console address.
Server manager properties files
Overview of server manager property files
The following property files configure server manager behavior.
• serverPool.properties
Performs pool-specific tuning of each individual machine. Pool-specific tuning is of particular
importance if machines differ greatly in the number and power of CPUs.
This file is stored in the TC_ROOT/pool_manager/confs/configuration-name directory.
• pref_export.xml
Configures web tier metrics and logging behavior.

© 2021 Siemens
4. Server manager
This file is stored in the TC_ROOT/pool_manager/confs/configuration-name directory.
Server manager pool-specific configuration tuning
Server manager pool-specific tuning parameters
Tune the server manager configuration to make the best use of specific system resources to maximize
server availability while minimizing resources.
Each individual machine should have its pool-specific configuration tuned. This is of particular concern if
each individual machine differs greatly in the number and power of its CPUs from each other.
The pool-specific parameters are set in the TC_ROOT\pool_manager\confs\configuration-name

\serverPool.properties file.
The following parameters most likely require tuning:
• PROCESS_TARGET
Provides a time profile of minimum numbers of Teamcenter servers to have running on the machine.
• PROCESS_CREATION_DELAY
Determines the interval of time (in milliseconds) between starting each additional TcServer process
to join the pool. (This parameter does not explicitly appear in the file by default but can be added
manually.)
• PROCESS_MAX
Sets the upper limit on number of running Teamcenter server processes. For highly scaled up
deployments on Suse Linux, please review Suse Linux UserTasksMax setting may need tuning.
• PROCESS_WARM
Sets the desired number of prestarted but unassigned Teamcenter servers.
Additional parameters provide the following information. Typically, the default settings are adequate
and do not require additional tuning. Many of these parameters do not appear in the file by default, but
can be added manually.
• ACQUIRE_REENTRANT_LOCK_TIMEOUT
Determines the amount of time (in milliseconds) the manager waits before giving up when
attempting to lock its internal data object regarding a server process. The default setting is 100.
• ENABLE_SERVER_HEARTBEAT (deprecated as of Teamcenter 12.4)

Determines whether server heartbeats are enabled. Server heartbeats are the time (in seconds)
between license heartbeat calls sent from the manager to each Teamcenter server. The default
setting is 0 (off). Enable heartbeats by setting to any nonzero value.
• LOGINS_PER_MINUTE
Determines the number of logins per minute allowed to the pool. The default setting is 0 (unlimited).

© 2021 Siemens
Server manager pool-specific tuning parameters
• MAX_POOL_PROCESSING_INTERVAL
Determines the maximum time (in milliseconds) any given manager processing thread sleeps before
checking for additional work. The default setting is 600000 (10 minutes).
• MIN_POOL_PROCESSING_INTERVAL
Determines the minimum amount of time (in milliseconds) any given manager processing thread
sleeps before checking for additional work. The default setting is 1000.
• POOL_ID
Determines the ID of the server pool. The default setting is PoolA.
• PROCESS_READY_TIMEOUT
Determines the time (in seconds) the manager waits for a Teamcenter server to report that it is ready
before terminating the server process. The default setting is 300.
• SERVER_EXECUTABLE
Specifies the path to the tcserver executable file. The default setting is TC_ROOT\bin\tcserver.exe.
• SERVER_HEARTBEAT_INTERVAL (deprecated as of Teamcenter 12.4)

Determines the time (in seconds) between license heartbeat calls sent from the manager to each
Teamcenter server. The default setting is 720.
• SERVER_HOST
Defines the host name (or IP address) on which the Teamcenter server listens for connections. Store
and forward is useful on machines with multiple network interfaces. By default, this parameter is
unset, causing the server to select an arbitrary network interface from the available network
interfaces.
• SERVER_PARAMETERS
Defines additional command line parameters supplied when starting a Teamcenter server process.
The default setting is -ORBNegotiateCodesets 0.
• SERVER_RETRY_LIMIT
Determines the number of times the manager retries sending a message (for example, a license
heartbeat) to a Teamcenter server before giving up. The default setting is 2.
• SERVER_RETRY_WAIT_PERIOD
Determines the delay (in milliseconds) between retry attempts when sending a message to a
Teamcenter server. The default setting is 1000.
• THREAD_POOL_INVOKING_SERVERS
Determines the maximum size of the pool of threads used for sending messages to Teamcenter
servers and performing other miscellaneous tasks in the manager. The default setting is 500.

© 2021 Siemens
4. Server manager
Setting the PROCESS_CREATION_DELAY parameter
Tip:
Siemens Digital Industries Software recommends that you start your tuning process start by
specifying an optimal setting for the PROCESS_CREATION_DELAY parameter. The
PROCESS_CREATION_DELAY parameter is the most important pool server parameter for
preventing CPU overload due to starting new server processes. It is critical that creating new
Teamcenter server processes in response to logon demand does not overwhelm the processing
resources available on the pool server machine.
When logon demand requires that the pool manager create a new server process and add it to the pool,
the server pool PROCESS_CREATION_DELAY parameter value list determines the interval of time (in
milliseconds) the pool manager waits before attempting to create a new TcServer process. The default
value for the parameter is the list 2000 2000 8000 16000 30000 60000.
Example:
If the most recent attempt to create a Teamcenter server processes succeeded, then the pool
manager waits the first interval in the list before attempting to create a new server process. If the
attempt to create a new process fails, then the manager increments a failure count, waits the
second interval in the list, and then again attempts to create a new server process. If a second
attempt fails, then the pool manager increments the failure count and waits the third interval in
the list (default value is 8000 milliseconds) before a third attempt.
When an attempt to start a server process succeeds, the failure count resets to zero, and for the
next creation attempt, the pool manager waits the first value in the list.
Out of the box, the PROCESS_CREATION_DELAY parameter value is not explicitly present in the
serverPool.properties file. To override the default, use the following procedure to find your own
optimal first value and explicitly add the parameter to the file.
1. For your specific installation configuration and machine, measure the amount of operating system
processing resources consumed by a Teamcenter server process started and added to the warm
pool.
This can be done simply by looking at the processing resources consumed by a server in a newly
started up (but unused) pool.
This amount can be expressed as [warmCPUSec] in units of CPU seconds.
2. Determine what fraction of the machine can be dedicated to creating a new server process in
response to logon demand during the peak usage of the system.
Siemens Digital Industries Software recommends you choose a fraction between 0.4 and 0.7.
This fraction can be expressed as [warmFraction] (unitless). A lower value for this fraction reserves
more of the machine processing resources for concurrent nonstartup activity.

© 2021 Siemens
Setting the PROCESS_MAX parameter
3. Determine how many CPUs are on the machine ([numCPUs]).
4. Calculate the optimum process creation delay in units of milliseconds (mSec) as follows:
[optimumDelay]=([warmCPUSec]*[1000 mSec/Sec])/([warmFraction]*[numCPUs])
Example:
[warmCPUSec] = 8 seconds
[warmFraction] = 0.6
[num_CPUs] = 2
[optimumDelay] = (8 * 1000) / (0.6 * 2) = 6667
5. Add the PROCESS_CREATION_DELAY parameter with a value list of increasing delays to the
serverPool.properties file, starting with the optimum (or slightly under) delay, and additional
delays ramping up to about 60000 milliseconds.
Example:
PROCESS_CREATION_DELAY = 6667 7000 12000 24000 40000 60000
Note:
In our example of a low-powered machine where each server launch occupies a core for eight
seconds, the machine is overloaded if the pool manager needs to start at least two Teamcenter
server processes at the default rate of one every four seconds, even with no actual request
processing. Therefore, setting the PROCESS_CREATION_DELAY parameter to greater than the
default values list is critical to avoid overloading the machine.
Setting the PROCESS_MAX parameter
The PROCESS_MAX parameter in the serverPool.properties file sets the upper limit on number of
running Teamcenter server processes. The only concern for limiting the maximum number of
Teamcenter servers on a machine may be memory consumption. The incremental free memory per
server can be expected to vary from installation to installation but is on the order of 30 megabytes.
Determine the maximum amount of RAM on the machine that you want to provide to the Teamcenter
servers in the pool. This can be expressed as [maxTCmem] in gigabytes.
Set PROCESS_MAX = [maxTCmem] * [1024 MB/GB] / [30 MB].
For example:
[maxTCmem] = 4 Gig
PROCESS_MAX = 4 * 1024 / 30 = 136

© 2021 Siemens
4. Server manager
Setting the PROCESS_TARGET parameter
The PROCESS_TARGET parameter in the serverPool.properties file provides a time profile of minimum
numbers of Teamcenter servers to have running on the machine. PROCESS_TARGET is a series of
comma-delimited local time and pool minimum pairs.
For example:
0700 20, 0730 50, 1100 20, 1300 50, 1900 10
This specifies that at 0700 local time, the pool manager should ensure that a minimum of 20
Teamcenter servers are in the pool, and at 0730 at least 50, and so on, until 1900 when the pool
minimum drops to 10.
A second example is the single pair 0000 5. This specifies that the pool manager maintain a minimum of
5 at all times.
It is desirable that this time profile be a reasonably good estimate of the number of servers needed by
user demand. This can be estimated by occasionally monitoring the number of servers assigned to users
throughout a representative workday. If this profile is well configured, the value of tuning the next
parameter, PROCESS_WARM, becomes low.
When choosing the time to set a new minimum, realize that it takes time (based upon
PROCESS_CREATION_DELAY) to ramp up from one level to another much higher level. For example, if it
is determined that there should be a minimum of 200 at time 1300, and the previous minimum was
100, and PROCESS_CREATION_DELAY has been tuned to 5000 milliseconds, then it could take about
(200 – 100) * 5000 = 500,000 milliseconds = 500 seconds = 8.3 minutes to ramp up the additional 100
processes. Thus the limit should be configured to 200 at around time 1250 to ensure 200 are all warm
or in use at time 1300.
Setting the PROCESS_WARM parameter
The PROCESS_WARM parameter in the serverPool.properties file sets the desired number of prestarted
but unassigned Teamcenter servers.
A warm Teamcenter server is one that has been started and established its database connection, and
then is held in readiness for a user for logon. If there are no warm Teamcenter servers, a new logon
attempt displays a message that a server is not available, and to try later.
It takes a certain amount of processing to start up a new Teamcenter server process to the point it can
be added to the warm pool. A major part of this processing can be consumed simply by loading the
shared libraries into the process. Different machines consume different amounts of processing resources
do to this. Other factors can also come into play. On Solaris, for example, loading the shared libraries
over NFS paths can consume more processing resources than loading them from local disks.
The PROCESS_WARM parameter is the most difficult to optimize, because it requires an estimate of the
burst rate of logons that may occur.

© 2021 Siemens
Setting the PROCESS_WARM parameter
If the PROCESS_WARM value is set too low, users in the rear of a burst of logon requests may encounter
the tcserver is not available, try again later message, and a later logon will be
successful.
To minimize this situation, the PROCESS_WARM value can be increased.
As defined at the start, PROCESS_WARM is a desired number of Teamcenter servers to be warm, but not
assigned.
This configuration value comes into play if the sum of assigned servers + PROCESS_WARM is greater
than the PROCESS_TARGET for that time of day. In this case, the pool manager responds to a logon
(which moves a server state from warm to assigned) by starting one or more servers (not to exceed the
rate dictated by PROCESS_CREATION_DELAY) to make up the PROCESS_WARM deficit.
A burst of logon requests begins in a state with the warm pool fully populated, extends until the warm
pool is again fully populated, and contains one or more logon intervals faster than the rate dictated by
the PROCESS_CREATION_DELAY.
A new Teamcenter server takes a minimum of [warmCPUSec] seconds to become available, and then
servers are added to the pool at a maximum rate of one per the setting in the
PROCESS_CREATION_DELAY parameter.
The following graphic illustrates an assignment burst that starts at time T1, and continues until it
exhausts the number of available warm servers sometime later during the time new servers are being
added to the pool.
The number of Teamcenter servers added as warm per second after the delay [warmCPUSec] is (1000
mSec/Sec) / PROCESS_CREATION_DELAY. Keep in mind the following:
• If the burst interval is less than [warmCPUSec], a burst of logons greater than PROCESS_WARM
encounters an empty warm pool.

© 2021 Siemens
4. Server manager
• If the burst interval is greater than [warmCPUSec], a burst of logons greater than PROCESS_WARM +
(1000 * ([burst_interval] – [warmCPUSec])) / PROCESS_CREATION_DELAY encounters an empty
warm pool.
Typically, you do not need to perform this level of detailed analysis on pool logon demands. Note that:
• Large PROCESS_CREATION_DELAY values should prompt you to configure larger PROCESS_WARM

pools.
Note:
Large PROCESS_CREATION_DELAY values should be configured for low numbers of server CPUs
or long values of [warmCPUSec]. If you chose a low fraction of the machine to be used to start
up new servers to compute optimum PROCESS_CREATION_DELAY, you may want to configure
a larger PROCESS_WARM value to compensate for the longer startup delays.
• Excessive occurrences of low or exhausted warm margins should prompt either an upward
adjustment of the PROCESS_WARM value, the PROCESS_TARGET minimum for that time of day, or
both.
Tuning considerations for the Active Workspace indexer
In some cases, settings in clients rely on the number of warmed servers. For example, in Active
Workspace, the tc.maxConnections parameter specifies the maximum number of connections between
the Teamcenter server and the indexer to be open at a given time and controls the quickness of the
indexing process through parallelization of steps. This value should be less than the number of warmed-
up Teamcenter servers available in the pool. For example, if you have 100 warmed-up servers in the
pool manager, you may want to set the tc.maxConnections value to 50 to provide an adequate number
of maximum connections.
During a period of heavy indexing, such as the first time the indexer is run, first check that the
Teamcenter server pools have sufficient servers to handle the indexing load in addition to other loads
such as from interactive user sessions. For example, if the tc.maxConnections parameter is set to 50,
the indexer needs 50 available warm servers. This can be achieved by increasing the PROCESS_TARGET
parameter of the server pools to prestart an appropriate number of servers.
If you use Active Workspace, you can change the value of the tc.maxConnections parameter using
Teamcenter Environment Manager (TEM). In the Feature Maintenance panel, select Update Active
Workspace Indexer settings, and click Next until you reach the Active Workspace Indexer Settings
panel. Click Advanced to set the maximum connections in the Maximum Teamcenter Connections
box.
To set the maximum connections value dynamically during the indexing run, perform the following
command from the FTS_INDEXER_HOME directory (TC_ROOT\TcFTSIndexer\bin):
runTcFTSIndexer -maxConnections=connections

© 2021 Siemens
Server manager database password
Server manager database password
When the server manager is installed, the supplied server manager database password is obfuscated
and added to the serverPool.properties file. In case the database password is changed, use the
mgradmin.bat utility to obfuscate the new password and replace the one stored in the properties file.
1. Open a Windows command prompt as an administrator.
2. Change directory to the TC_ROOT\pool_manager\confs\<confName> directory.
3. Enter the following command:
mgradmin.bat -password
4. At the prompt, enter the new Server Manager Database password and then press Enter.
The utility obfuscates the password and updates the serverPool.properties file.
Server manager monitoring
Introduction to server manager monitoring
In a four-tier environment, you can monitor critical event data and (optionally) receive notification when
critical events exceed specified thresholds. This information is useful for determining the cause of an
issue, as well as allowing you to take corrective action.
Different critical events can be monitored for the following elements of the Teamcenter system.
• Web tier
Monitor web tier server events such as abandoned servers, no servers available, and so forth.
• Server pool
Monitor pool manager events such as login time, server crashes, and various types of server time-
outs.
• Teamcenter servers
Monitor server events on specific Teamcenter servers such as out of memory errors, long running
queries, and memory use.
• File Management System (FMS) components

Monitor Multi-Site events such as global memory pool events, route events, and ticket events.
• Translation components
Monitor translation events such as dispatcher client events, dispatcher scheduler events, and
dispatcher module events.

© 2021 Siemens
4. Server manager
You can configure monitoring behavior for each of these Teamcenter elements from either an
administrative interface or from XML configuration files.
Both configuration methods require you to first define the EmailResponder element (specifying how
and where email notification is set) and the LoggerResponder element (where critical event data is
logged). You can then set values for the different types of critical events of which you want to be
notified.
Control the frequency of email notifications and event logging by specifying suppression periods.
Example:
You have configured the monitoring of business logic server crashes to send email notification
when server crashes exceed 10 in 600 seconds.
At 10:00, you set suppression of this notification to 4 hours.
At 10:05, the notification threshold is met. Email notification is sent. The suppression clock starts
to count down.
The notification threshold is reached 22 times between 10:20 and 13:50. Notification is
suppressed each time.
At 14:00 the suppression clock reaches it 4-hour threshold. Another notification threshold is met
for business logic server crashes at 14:20. Email notification is sent. Once again, the suppression
clock starts.
Tip:
You should review all monitoring settings, ensuring the thresholds are set correctly for your site.
If you do not know the optimum monitoring setting for any given critical event, set the value to
Collect. Collect the data and review to determine normal activity levels. Then set threshold values
slightly higher than normal activity levels.
Pool manager monitoring
Pool manager monitoring metrics
Configure pool manager monitoring using either:
• TC_ROOT/pool_manager/confs/configuration-name/poolMonitorConfig.xml
• Teamcenter Management Console
You can configure the following metrics to provide specified levels of monitoring for specified threshold
levels. Optionally, you can receive email notification when specified metrics cross specified thresholds.

© 2021 Siemens
Pool manager monitoring metrics
Metric Description
Login Time The response time for users logging on through the server
manager to the server.
Edit Mode Timeouts The number of assigned servers in edit mode that are timed
out.
Read Mode Timeouts The number of assigned servers in read mode that are timed
out.
Stateless Mode Timeouts The number of assigned servers in stateless mode that are
timed out.
Query Timeouts The number of assigned servers performing queries that are
timed out.
Business Logic Server Crashes The number of each server crash in the server pool.
Cold Servers The number of servers launched but not reporting back in a
specified amount of time.
Pool Capacity Timeouts The number of servers terminated by the server manager
before its configured amount of time, due to insufficient
capacity in the server pool.
Grave Events Fatal or unexpected errors occurring in the server manager.
Log Level The duration and log level that is applied to the target logger
when triggered by an alert.
Metric Mode The list of target metrics that are collected when triggered by
automatic alerts.
Monitoring Notification The list of registered client listeners to notify when a system
alert occurs.
Tip:
• You should review all monitoring settings, ensuring the thresholds are set correctly for your site.

© 2021 Siemens
4. Server manager
COLLECT. Collect the data and review to determine normal activity levels. Then set notification
values slightly higher than normal activity levels.
• The contents of the email notifications are generated from the poolMonitorConfigInfo.xml file
(located in the TC_ROOT/pool_manager/confs/configuration-name directory). This is a
companion file to the poolMonitorConfig.xml file. For a complete list of possible causes and
recommended actions for server manager monitoring, see this file.
Configure pool monitoring with the poolMonitorConfig.xml file
This procedure describes how to configure pool monitoring with a configuration file. You can also
configure pool monitoring with the server manager interface.
1. Open the TC_ROOT/pool_manager/confs/configuration-name/poolMonitorConfig.xml file.
2. At the top of the file, set mode to one of the following:
• Normal
• Disable_Alerts
events, regardless of individual notification settings on any metric.
• Off
3. (Optional) To be notified when criteria reaches the specified threshold, specify from whom, to
whom, and how frequently email notification of critical events are sent by setting the following
EmailResponder values. For example:
<EmailResponder id="EmailResponder1">
<protocol value="smtp"/>
<hostAddress value="CHANGE_TO_VALID_SMTP_HOST"/>
<fromAddress value="CHANGE_TO_VALID_ADDRESS" />
<toAddress value="CHANGE_TO_VALID_ADDRESS" />
<suppressionPeriod value="120"/>
<emailFormat value="html"/>
</EmailResponder>
You can specify more than one EmailResponder id value.

All EmailResponder id values in all subsequent monitoring metrics in this file must match one of
the EmailResponder id values set here.
• EmailResponder id

© 2021 Siemens
Configure pool monitoring with the poolMonitorConfig.xml file
Specify an identification for this email responder. Multiple email responders can be configured,
in which case, the identifiers must be unique.
• protocol
Specify the email protocol by which notifications are sent. The only supported protocol is SMTP.
• hostAddress
Specify the server host from which the email notifications are sent. In a large deployment (with
multiple server managers, or the web tier running on different hosts) the host address identifies
the location of the critical events.
• fromAddress
• toAddress
Specify the address to which the notification emails are sent.
• suppressionPeriod
• emailFormat
Specify the format in which the email is delivered. Valid values are html and text.
4. (Optional) To be notified when criteria reaches the specified threshold, specify to whom, and to
which file, critical events are logged by setting the following LoggerResponder values. For
example:
<LoggerResponder id="LoggerResponder1">
<logFileName value="ServerManagerMonitoring.log" />
</LoggerResponder>
All LoggerResponder values in all subsequent monitoring metrics in this file must match the
LoggerResponder id value set here.
• LoggerResponder id
Specify an identification for this logger responder. Multiple logger responders can be configured,
• logFileName
Specify the amount of time (in seconds) to suppress logging of critical events to the log file.
5. Configure the criteria for a critical event for any of the metrics in the file by:

© 2021 Siemens
4. Server manager
a. Specifying a particular EmailResponder, if desired.
b. Specifying a particular LoggerResponder, if desired.
c. Setting the metric’s monitoring mode to one of the following:
• Collect
Collect metric data and display results in the server manager administrative interfaces
for this metric.
• Alert
When critical events occur, collect metric data, send email notifications (set up with
EmailResponder values), write messages to log files (set up with LoggerResponder
values), and display results in the server manager administrative interfaces for this metric.
Log file messages and email notifications are only issued when monitoring mode is set to
Alert.
• Off
No metric data is collected.
d. Setting the remaining values to specify criteria that must be met to initiate a critical event for
the metric.
6. Save the file.

Server manager monitoring is enabled for the metrics you configured.
Sample poolMonitorConfig.xml file
In the following example, two EmailResponder elements are configured. The majority of email
notifications are sent to admin1@company.com, but email notifications regarding Teamcenter server
crashes and grave events are sent to admin2@company.com. Information regarding pool capacity and
query time-outs is only collected; no email notifications are sent.
<?xml version="1.0" encoding="UTF-8"?>



<ApplicationConfig mode="Normal" version="1.0" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance"
xsi:noNamespaceSchemaLocation="healthMonitorV1.0.xsd">
<RespondersConfig>

© 2021 Siemens
Sample poolMonitorConfig.xml file
<hostAddress value="svc1smtp.company.com"/>
<fromAddress value="tcsys@company.com" />
<toAddress value="admin1@company.com" />
</EmailResponder>
</EmailResponder>
<logFileName value="ServerManagerMonitoring.log" />
</LoggerResponder>
</RespondersConfig>
<MetricsConfig>
<Metric name="Login Time" id="LoginTime" maxEntries="100" mode="Alert"
metricType="double"
description="Average time taken for user to login during recent time period">
<ThresholdWithPeriod minEvents="3">
<ThresholdValue name="AverageTime" value="60"
description="Average time of the login request" />
<ThresholdPeriod name="TimePeriodInSec" value="600"
description="Periods for which login time will be monitored." />
</ThresholdWithPeriod>
<Responders>
<ResponderRef id="EmailResponder1"/>
<ResponderRef id="LoggerResponder1"/>
</Responders>
</Metric>
<Metric name="Edit Mode Timeouts" id="EditModeTimeouts" maxEntries="100" mode="Alert"
metricType="integer"
description="Edit mode timeouts may result in lost user data.">
<ThresholdWithPeriod>
<ThresholdValue name="NumberOfEditModeTimeOuts" value="10"
description="If number of timeouts exceeds this limit, notify the
administrator." />
description="Periods for which timeouts will be monitored." />
<Responders>
</Responders>
</Metric>
<Metric name="Read Mode Timeouts" id="ReadModeTimeouts" maxEntries="100" mode="Alert"
description="Read mode timeouts may force Rich Client users to restart client
sessions.">
<ThresholdValue name="NumberOfReadModeTimeOuts" value="10"
administrator." />

© 2021 Siemens
4. Server manager
<Responders>
</Responders>
</Metric>
<Metric name="Stateless Mode Timeouts" id="StatelessModeTimeouts" maxEntries="100"
mode="Alert" metricType="integer"
description="Stateless mode timeouts generally have low impact on users and are a
good way
to control resource consumption in the server pool. However, an excessive rate
might lead
to high CPU consumption due to continually starting new servers.">
<ThresholdValue name="NumberOfStatelessModeTimeOuts" value="10"
administrator." />
<Responders>
</Responders>
</Metric>
<Metric name="Query Timeouts" id="QueryTimeouts" maxEntries="100" mode="Collect"
description="A query time out indicates that a single server request has taken longer
than the configured timeout. ">
<ThresholdValue name="NumberOfQueryTimeOuts" value="10"
administrator." />
<Responders>
</Responders>
</Metric>
<Metric name="Business Logic Server Crashes" id="TcServerCrashes" maxEntries="100"
mode="Alert" metricType="integer"
description="Number of tcservers that have crashed for any reason.">
<ThresholdValue name="NumberOfCrashes" value="10"
description="If number of crashes exceeds this limit, notify the
administrator." />
<Responders>
</Responders>
</Metric>
<Metric name="Cold Servers" id="ColdServers" maxEntries="100" mode="Alert"
description="A cold server is one that did not report back to the server manager
within the
configured time period (Default: 5 mins) after being started.">

© 2021 Siemens
Teamcenter server monitoring metrics
<ThresholdValue name="NumberOfColdServers" value="10"
description="If number of cold servers exceeds this limit, notify
administrator." />
description="Periods for which cold servers will be monitored." />
<Responders>
</Responders>
</Metric>
<Metric name="Pool Capacity Timeouts" id="PoolCapacityTimeouts" maxEntries="100"
mode="Collect" metricType="integer"
description="Servers are being terminated by the manager before their normal timeout
period
due to insufficient capacity in the server pool.">
<ThresholdValue name="NumberOfPoolCapacityTimeouts" value="10"
description="If number of pool capacity timeouts exceeds this limit, notify the
administrator." />
description="Periods for which pool capacity timeouts will be monitored." />
<Responders>
</Responders>
</Metric>
<Metric name="Grave Events" id="GraveEvents" maxEntries="100" mode="Alert"
description="Something has happened causing the server manager to malfunction.">
<Responders>
</Responders>
</Metric>
</MetricsConfig>
</ApplicationConfig>
Teamcenter server monitoring
Teamcenter server monitoring metrics
Configure Teamcenter server monitoring using either:
• TC_DATA\serverMonitorConfig.xml
• Teamcenter Management Console
You can configure the following metrics to provide specified levels of monitoring for specified threshold
levels. Optionally, you can receive email notification when specified metrics cross specified thresholds.

© 2021 Siemens
4. Server manager
Metric Description Comment
Deadlocks Report when the Deadlock errors should be rare, and

Teamcenter server are often transparent if handled on
encounters a database retry. To get more information on the
deadlock error. Teamcenter operation involved,
enable monitoring if deadlock errors
are found in database server logs.
VeryLongRunningQueries Report SQL, elapsed time Avoid enabling during upgrade,

and operation when either: where many queries are expected to
be slow. This metric could be useful
• Individual query time is when slow query is intermittent, and
more than the “slow” so finding the Teamcenter operation
criterion. context offers further clues on origin.
The default "slow" criterion value is
• An SQL statement 10 seconds. This value can be
matches a pattern overridden using the TC_SLOW_SQL
contained in the environment variable.
POM_SQL_PLAN
DBConnectionLosses Report when the database This metric is useful if a network issue
connection is lost. is intermittent and unexpected (that
is, the network issue is not due to
firewall / idle-connection tidy-up or
other expected event).
PomLocks Report Teamcenter object Enable this metric only for testing
locks at the end of an SOA sessions and debugging information.
operation.
POMRetries Report Teamcenter This event may happen frequently in

operations where database busy environments and may be
level functions failed to get expected, so the metric is only
a lock and retried. appropriate for testing.
Tip:
• You should review all monitoring settings, ensuring the thresholds are set correctly for your site.
Collect. Collect the data and review to determine normal activity levels. Then set notification

© 2021 Siemens
Configure server monitoring with the serverMonitorConfig.xml file
• The contents of the email notifications are generated from the TC_DATA/
serverMonitorConfigInfo.xml file. This is a companion file to the serverMonitorConfig.xml
file. For a complete list of possible causes and recommended actions for Teamcenter server
monitoring, see this file.
Configure server monitoring with the serverMonitorConfig.xml file
To configure server monitoring with a configuration file, edit the TC_DATA/serverMonitorConfig.xml

file provided as a template for configuring server monitoring.
1. Open the serverMonitorConfig.xml file.
2. In the ApplicationConfig tag near the beginning of the file, set the mode attribute to one of the
following:
• Normal
• Disable_Alerts
• Off
EmailResponder values. For example:
<protocol value = "smtp"/>
<hostAddress value ="CHANGE_TO_VALID_SMTP_HOST"/>
<fromAddress value = "CHANGE_TO_VALID_ADDRESS" />
<toAddress value = "CHANGE_TO_VALID_ADDRESS" />
<suppressionPeriod value = "43200"/>
<emailFormat value = "html" />
</EmailResponder>
You can specify more than one EmailResponder id.


© 2021 Siemens
4. Server manager
• protocol
• hostAddress
• fromAddress
• toAddress
• emailFormat
which file, critical events are logged by setting the following LoggerResponder values. For
example:
<LoggerResponder id ="LoggerResponder1">
<logFileName value = "TcServerMonitoring.log" />
<suppressionPeriod value = "1000"/>
</LoggerResponder>
in which case the identifiers must be unique.
• logFileName

© 2021 Siemens
Server monitoring system alerts
• Collect
for this metric.
• Alert
values), and display results in the server manager administrative interfaces for this metric.
Log file messages and email notifications are only issued when monitoring mode is set to
Alert.
• Off
the metric.
6. Save the file.

Server monitoring is enabled for the metrics you configured.
Server monitoring system alerts
Client applications can register their implementation of standard JMX notification listeners with the JMX
monitoring system. When a monitoring system alert occurs, registered listeners issue a notification that
contains the following information:
• Source
The object name that generated the notification. The client application uses this source to
communicate with the component that raised the alert to request additional information about the
alert.
• Sequence number
An incremental integer used to order notifications.
• A string that indicates the monitoring component that raised the alert in a Java component format,
for example"
com.teamcenter.mld.healthmonitoring.ServerManager.threshold
• Message
A summary of the alert from the originating metric, for example:
Teamcenter Alert: Business Logic Server Crashes exceeded threshold.

© 2021 Siemens
4. Server manager
• User data
A string containing the MetricID value.
The client can request the following additional information about the alert:
• AlertSummary data
This is information specific to the alert raised.
• AlertSubject data
• AlertEventData data
• MetricID value
Defined in the webtierMonitorConfig.xml file. This file is located in the deployed .war file in the lib
\mldcfg.jar file.
• MetricName value
Defined in the webtierMonitorConfig.xml file.
• MetricDescription data
Defined in the webtierMonitorConfig.xml file.
• PossibleCauses data
Defined in the webtierMonitorConfigInfo.xml file.
• RecommendedActions data
Defined in the webtierMonitorConfigInfo.xml file.
Server manager automatic metric collection
You can enable automatic collection of metrics based on the occurrence of an alert. When the alert
occurs, all events for the metric are captured and stored in memory. The maximum number of records to
keep in memory is configured by the maxEntries attribute in the webtierMonitorConfigInfo.xml file.
After collection is initiated, it remains in effect until you manually change the monitor mode for the
metric to any other supported mode.
The following is a sample configuration for automatic collection of DBConnectionLosses and Deadlock
metrics when the POMRetries alert occurs:
<MetricModeController id=" MetricModeController1">

<targetedMetrics>
<MetricId value="DBConnectionLosses"/>
<MetricId value="DeadLock"/>
</targetedMetrics>
</MetricModeController>
<Metric name=" POMRetries" id=" POMRetries" >

© 2021 Siemens
Server manager automatic log level change
<Responders>
<ResponderRef id="MetricModeController1" />
</Responders>
</Metric >
If the mode for a metric is already set to Collect or Alert, subsequent alerts are ignored.
Server manager automatic log level change
You can configure the a logger to automatically change log level to a specific value when an alert
occurs. If multiple instances of a responder have different target levels for a logger, the logger is set the
highest value (larger number) using the following order:
1. FATAL
2. ERROR
3. WARN
4. INFO
5. DEBUG
6. TRACE
If you specify a log level for a logger that has been adjusted due to an alert on a metric, your value
supersedes the responder setting and clears any log level changes in queue due to the alert. The
following is a sample configuration for automatic log level change to Debug for the
LogLeverController1 responder with a duration of 1000 seconds:
<LogLevelController id="LogLevelController1">
<targetedLevel value="Debug"/>
<duration value ="1000"/>
<targetedLoggers>
<loggerName value="Teamcenter.pom"/>
<loggerName value="Teamcenter.bom"/>
</targetedLoggers>
</LogLevelController>
Server manager logging
Server manager logging levels
In a four-tier environment, you can dynamically change logging levels for the web tier, server manager,
and Teamcenter servers.

© 2021 Siemens
4. Server manager
Logging level Description
FATAL Logs only severe error events that cause the application to abort. This is
the least verbose logging level.
ERROR Logs error events that may allow the application to continue running.
WARN Logs potentially harmful situations, such as incomplete configuration,

use of deprecated APIs, poor use of APIs, and other run-time situations
that are undesirable or unexpected but do not prevent correct
execution.
INFO Logs informational messages highlighting the progress of the

application at a coarse-grained level.
DEBUG Logs fine-grained informational events that are useful for debugging an
application.
TRACE Logs detailed information, tracing any significant step of execution.

This is the most verbose logging level.
Configure server manager logging
There are two methods available to change logging levels for the server manager.
• Use the log4j.xml file, stored in the TC_ROOT/pool_manager/confs/configuration-name directory.

This method permanently changes logging levels for the server manager after the server manager is
restarted. Changes persist until modified again in the file.
Note:
To make persistent changes to logging levels for all servers in the server pool, use the TC_ROOT/
data/logger.properties file.
• Use the Teamcenter Management Console.

This method dynamically changes logging levels for the server manager until the server manager is
restarted. This method is useful to test sandbox environments, as it sets logging levels temporarily.
Perform the following steps to configure server manager logging using the Teamcenter Management
Console:

© 2021 Siemens
Configure server manager logging
The list of loggers is displayed under the Log Levels heading.
2. Browse to the logger whose logging level you want to configure.
3. Click the arrow in the box to select a new logging level, for example, DEBUG.
The logging level for the selected logger is changed for the server manager until the server
manager is restarted.

© 2021 Siemens
4. Server manager
Restarting warm servers

Click the Restart Warm Servers button to recycle warm servers in all server manager pools without
shutting down the server manager. This is useful for updating cached values on a warm server.
The Restart Warm Servers button can be found in the Teamcenter Management Console under the
Operations link.
Example:
In a four-tier configuration, Host A and Host B use a common Teamcenter database.
Changes made to preferences with a protection scope of Site on Host A affect all existing
Teamcenter server processes running on Host A. Because Host B caches such preferences when it
starts, the changes to these preferences are not received by Host B if it was running when the
changes are made through Host A. The changes are not immediately received by Host B.
In a four-tier environment, the server manager can be configured with additional warm servers,
ready for use by the next user to log on. Warm servers cache preferences when they are started.
If warm servers are configured, and Host B logs off and then logs on through a warm server, Host
B still does not receive the preference changes because the warm server cached the preference
settings when it started.
To ensure that all hosts receive the latest information at logon, use the Restart Warm Servers
button. This operation stops and restarts all warm servers, ensuring each warm server receives the
latest preference settings.
If you use this functionality to restart most (or all) the warm servers at your site, this task should be
performed with very few users on the system. Otherwise, there is a risk that no warm servers are
available during the short time it takes to recycle the servers.
Example:
The server manager is configured to support 100 users during 08:00 to 17:00. At 07:55, there are
no users on the system; therefore, there are 100 warm servers available. Choosing to recycle all
100 servers at 07:55, in order to refresh cached server values, may not allow sufficient time for
the servers to restart by 08:00. Any users attempting to log on before the servers have restarted
receive a message that no server is available.

© 2021 Siemens
Windows desktop heap may cause hang of TcServer processes
Server Manager Troubleshooting
Windows desktop heap may cause hang of TcServer processes
If you are planning to run large numbers of processes using Microsoft Services, you will likely run out of
non-interactive desktop heap resources.
A limitation exists in the size of the Windows desktop heap that effectively limits the number of
processes that the server manager can manage. When this particular heap allocation is consumed,
processes may hang in several ways (including during execution of a child process). If the TcServer
process hangs after spawning any new subprocess, the client appears hung to the user.
Everything may work fine on a system that is not heavily populated with large numbers of TcServer
processes. The size of the desktop heap is independent of the amount of RAM installed.
The size of the desktop heap is by default smaller for processes started with services, so this is more
likely to be encountered when Teamcenter server manager is started as a service.
The Microsoft Ntdebugging Blog article Desktop Heap Overview provides more information regarding
this resource.
On some operating systems, a default non-interactive heap setting of 768 for the SharedSection
settings results in limitations of about 100 TcServer processes for a server pool started as a Windows
service.
If you encounter this limitation when running the server manager pool as a service, you can work
around it by starting the server manager from a user console. The desktop heap SharedSection registry
values associated with an interactive window are by default many times larger than the SharedSection
associated with a non-interactive window service. For example, on a Windows 7 machine, the value is:
SharedSection=1024,20480,768
If you have no other recourse, you may carefully modify the controlling registry values per the Microsoft
Knowledge Base article 184802.
Caution:
Pay close attention to the risks of modifying these particular registry values spelled out in the
article. If not done properly, you may have to reinstall the operating system (OS).
You should only edit the third value of the SharedSection value, which is the value associated with non-
interactive desktop heap. If you run a 32-bit OS (only applicable for earlier versions of Teamcenter on
32-bit), the boot.ini setting of /3GB for a 32-bit OS should not be used with modifications to this
registry setting, because it causes the first value of the SharedSection (for SessionViewSize) to be
ignored. Setting /3GB after this registry has been edited may make the system unusable.

© 2021 Siemens
4. Server manager
When editing this registry value, Siemens Digital Industries Software recommends that the third value
for non-interactive desktop be increased in small increments such as 512 until the processes started
with services run well. You should not have to increase it larger than the second value of the
SharedSection that applies to interactive desktop heap.
Suse Linux UserTasksMax setting may need tuning
Suse Linux systems limit the number of concurrent processes/threads used by a given OS user via the
UserTasksMax setting. In highly scaled up deployments, Teamcenter may encroach on this limit due to
the number of TcServer processes that run concurrently. The TcServer process can use up to 6
concurrent threads, and thus a Teamcenter installation that is configured to support a maximum of
2,000 processes (PROCESS_MAX) can consume up to 12,000 threads. If UserTasksMax is set to the
default value 12,288, few threads are available for other processes started by this OS user and may
result in abnormal behavior for some processes that cannot acquire threads.
Parse errors warning in Oracle trace log
If the Teamcenter database is in Oracle, and any JMX client including the Teamcenter Management
Console frequently queries the state of Teamcenter servers, then the Oracle trace log may show a parse
errors warning related to Server Manager SQL. This is caused by the JDBC driver appending a row ID to
the query.
For example:
2021-01-29T20:10:15.281248-05:00
WARNING: too many parse errors, count=426 SQL hash=0x60c18596
PARSE ERROR: ospid=8560, error=937 for statement:
2021-01-29T20:10:15.282248-05:00 select rowid as
"__Oracle_JDBC_internal_ROWID__", COUNT(*) as ELEMENT_COUNT FROM
SERVERS_1773957227_357170909 WHERE POOL_ID = 'PoolA'
Additional information: hd=00007FF8E079EEE8 phd=00007FF8ECA7D748
flg=0x20 cisid=94 sid=94 ciuid=94 uid=94 sqlid=c7yd2hjhc31cq
...Current username=TCCLUSTERDB
...Application: JDBC Thin Client Action:
2021-01-29T20:11:32.725724-05:00 WARNING: too many parse errors,

count=312 SQL hash=0x96b6d88d
PARSE ERROR: ospid=10028, error=937 for statement:
2021-01-29T20:11:32.725724-05:00 select rowid as
"__Oracle_JDBC_internal_ROWID__", COUNT(*) as ELEMENT_COUNT FROM
SERVERS_1773957227_357170909 WHERE POOL_ID = 'PoolA' AND STATE =
'warming'
Additional information: hd=00007FF8EA954610 phd=00007FF8EC900930
flg=0x20 cisid=94 sid=94 ciuid=94 uid=94 sqlid=0bbcb7abbdq4d
...Current username=TCCLUSTERDB
...Application: JDBC Thin Client Action:

© 2021 Siemens
Running the server manager on a machine separate from the corporate server
The parse errors do not affect performance.
To eliminate the parse errors warning, the workaround suggested by Oracle is to set the following
parameter on the Oracle server: _kks_parse_error_warning=0
This setting is available for Oracle Database version 12.2 and later.
1. Login to SQLPlus using a system administrator account.
2. Run the following command:
alter system set "_kks_parse_error_warning"=0 scope=both;
Running the server manager on a machine separate from the

corporate server
If you install the Teamcenter server manager (pool manager) on a machine other than the corporate
server, the pool manager machine must have the same data model as the corporate server machine. To
accomplish this, use Teamcenter Environment Manager (TEM) to select the same features on the pool
manager machine. This ensures that the pool manager machine has an up-to-date TC_DATA directory
and binary files. If the TC_DATA directory is shared, this same process is still required to keep the binary
files synchronized.
Operations such as patching, upgrading, and installation of custom or Teamcenter data models (and
updates to those data models) must be performed on the pool manager server machine after being
done on the corporate server machine. This process ensures that the pool manager machine is
synchronized with the corporate server machine.

© 2021 Siemens
4. Server manager

© 2021 Siemens
5. File Management System
Introduction to File Management System
Teamcenter's File Management System (FMS) is a file storage, caching, distribution, and access system.
FMS provides global, secure, high performance and scalable file management.
Use FMS to centralize data storage volumes on reliable backup file servers, while keeping data close to
users in shared data caches. This enables centralized storage and wide distribution of file assets to the
needed locations within a single standard file management system. FMS provides WAN acceleration to
effectively move large files across WAN assets.
FMS pulls files on demand as users request them. FMS efficiently transfers files across a wide area
network (WAN). Also, FMS can locate caches closer to end user machines, for example, FMS server
caches (FSCs). FMS uses a file GUID, a business neutral identifier for file contents, to determine when to
pull a file from its local cache, rather than retrieving the file across a network from the vault’s underlying
file system. Every file in a Teamcenter vault has a single file GUID associated with every replicated copy
of the file. If you move, copy, reassign to a new owner, or rename the file, its file GUID remains the
same. However, if you change the file content by one bit or change its language encoding, a new file
GUID must be created to describe the file’s new contents.
Note:
Siemens Digital Industries Software reserves the right to change FMS behavior in the future to
enhance performance or improve reliability.
FMS consists of two main components:
• FMS server cache (FSC)

Provides a shared, secure, server-level cache. It uploads and downloads files to other FSCs and to
client caches.
An FSC can provide one or more modes of behavior, where each mode manages a type of data
including volume files, cache files, transient files, and configuration files. A particular FSC can
perform any or all of these functions simultaneously depending on your FMS configuration. All FSCs
provide at least one mode in a properly configured FSC topology.
You define configuration, volume, and transient file modes explicitly in the FMS configuration files
using XML statements. Cache server functionality is installed on each FSC but is only used if the FSC
does not have direct access to volume files.
• FMS client cache (FCC)

Provides a private user-level cache, just as Web browsers provide a read file cache. The FCC provides a
high-performance cache for both downloaded and uploaded files. The FCC provides proxy interfaces
to client programs and connectivity to the server caches and volumes.
Any files captured by the FCC do not change, for either download or upload, and for either whole files
or partial files. All file copies and file segment copies are identical throughout the system and never
updated. New file versions are checked into the system with a new GUID, but a file with an existing

© 2021 Siemens
GUID in the FMS system never changes. Therefore, there are no issues with file change or cache
consistency.
FCCs also provide access to the transient volume for the business server in a Teamcenter two-tier
configuration. The business server writes or reads temporary files directly to a disk directory, and the
rich clients access those files using the standard FCC interfaces. This provides client independence
from the system configuration and ensures that client programs operate the same in both two-tier
and four-tier mode for file access functions.
Benefits of using FMS

The benefits of using FMS include:
• Data distribution
Administrators can distribute copies of data closer to end users by using FMS server caches at remote
locations. FMS cache servers can be distributed worldwide, while retaining FMS volume data in
central storage.
• Multisite support
FMS enables file transfer directly between servers in two different PLM systems, eliminating the need
for an intermediate transfer directory.
• All network configurations supported

FMS supports LAN, WAN, and firewall configurations.
• Common caching system

FMS caches all data for all clients and provides standard interfaces for file access across client and
server programs. FMS eliminates the need for client specific caches.
• Pull-through caching
FMS automatically caches data at the locations needed, based on what data users read and write to
the system.
• No single point of failure

FMS provides the capability to administer a fully redundant configuration of configuration servers,
volume servers, and cache servers. FMS routing algorithms automatically search for an alternate path
in the case of a connection failure.
• Primary configuration server

FMS provides the capability to administer the FMS deployment configuration with a single primary
(master) configuration file. FMS automatically distributes the configuration file to all FMS client and
server processes.
• Managed caches
The FMS client and server caches are self-purging. The least recently accessed data is purged first.
• Secure server caches

© 2021 Siemens
FMS server cache
FMS servers do not permit any direct access to cached file data. FMS permits file data access when the
requestor presents a valid security ticket.
• Secure volume servers

FMS servers do not permit any direct access to volume file data. FMS permits file data access only
when the requestor presents a valid security ticket.
• Private user caches

FMS automatically caches data downloaded or uploaded by Visualization clients in a private user
cache, providing fast access to recently accessed files. The user cache automatically purges data to fit
within a maximum size.
• Streamed data delivery

FMS streams data from volumes down to clients through any number of cache servers. Data becomes
available to the user as soon as the first bits stream in, through any number of cache servers as
needed. FMS also streams data from the client all the way to the volume on upload.
• Segment file cache and delivery

FMS allows applications to transfer only specific parts of a file, improving the overall transfer time and
conserving network bandwidth.
FMS components
FMS server cache
The FMS server cache (FSC) is the name of the FMS server cache server process. The FSC is a shared,
secure, server level cache. It uploads and downloads files to other FSCs and to FCCs.
An FSC can provide one or more modes of behavior, where each mode manages a type of data including
volume files, cache files, transient files, and configuration files. A particular FSC can perform any or all
of these functions simultaneously depending on your FMS configuration. All FSCs provide at least one
mode in a properly configured FSC topology.
You define configuration, volume and transient file modes explicitly in the FMS configuration files using
XML statements. Cache server functionality is installed on each FSC, but is only used if the FSC does not
have direct access to volume files. The various FSC modes are as follows:
• Configuration server (optional)

One or more FSCs may be designated as a configuration server. An FSC configuration server reads the
fmsmaster_fscid.xml configuration file and distributes that information to other FSCs and/or clients.
The FSC configuration topology can be a single FSC or a tree of FSCs. The FSC configuration topology
is separate from the FSC routing topology.
• Volume server (optional)

An FSC may contain zero or more mounted volumes. An FSC serves volume data by reading/writing
the file directly from local or mounted disk, and writing/reading that data onto a TCP port in HTTP
protocol.

© 2021 Siemens
• Cache server (conditional)

An FSC caches any data not directly available in a volume mounted on that FSC. An FSC routes and
caches data from other FSCs if it does not have direct access to the volume containing the file.
• Transient file server (for Teamcenter four-tier configurations only, on each business logic server. Use
FCC in transient file server mode with Teamcenter two-tier configurations).
Each business logic server in four-tier mode writes and reads data from a temporary disk location. The
FSC provides the capability to deliver this temporary data to or from the client. Each business logic
server should have an FSC transient server to deliver the temporary data.
The transient volume directory must reside on the same machine as the FSC and the Pool Server
Manager.
FSC basic functions are:
• Segment read file cache

The FSC stores all file downloads as 16K file fragments in the read segment cache. Whole files are not
stored. The segment cache uses the FMS fast cache. No purge policies are needed for the fast cache; it
automatically purges file segments as needed.
• Segment write file cache

The FSC stores all file uploads as 16K file fragments in the write segment cache. Whole files are not
stored.
• WAN acceleration (optional)

The FCC provides the capability to accelerate file downloads over high latency or noisy WAN lines.
Required software is shipped as part of the base FMS install.
• Server configuration
The FSC reads and distributes FMS configuration data across site FSCs and FCC processes.
• Client configuration
The FSC processes the client configuration, analyzes the configuration, computes the configuration
download for each client, and provides this information as a bootstrap download when the FCC
process initializes.
• Failover (configuration dependent)

The FSC provides the capability to failover to alternate FSCs upon failure of a specific FSC. Failover is
provided for access to both FSC configuration servers and FSC file servers.
• Whole file cache (WFC)

The files are whole files on the disk and not in a virtual memory mapped disk space.
FMS client cache
The FMS client cache (FCC) is the name of the FMS client cache server process. The FCC runs within the
Teamcenter client communication (TCCS) module. The FCC provides a private user-level cache, just as
web browsers provide a read file cache. The FCC provides a high performance cache for both

© 2021 Siemens
FMS client cache
downloaded and uploaded files. The FCC provides proxy interfaces to client programs and connectivity
to the server caches and volumes.
Any files captured by the FCC do not change, for either download or upload, and for either whole files or
partial files. All file copies and file segment copies are identical through out the system, and never
updated. New file versions are checked into the system with a new GUID, but a file with an existing
GUID in the FMS system never changes. Thus, there are no issues with file change or cache consistency.
The FCC can act as a transient volume for the business server in a Teamcenter two-tier configuration.
The business server writes or reads temporary files directly to a disk directory, and the rich clients access
those files via the standard FCC interfaces. This provides client independence from the system
configuration, and ensures that client programs operate the same in both two-tier and four-tier mode
for file access functions.
FCC basic functions are as follows:
• Whole file read cache

The FCC caches downloaded whole files in a whole file read cache. Most applications access a whole
file at a time, including Teamcenter rich client, Microsoft Office products, 2D viewers, and others.
• Whole file write cache

The FCC caches uploaded whole files in a whole file write cache. All rich client applications upload
completely new files through this cache. Files are never changed once they are uploaded to the
system, there are only new files. The cache is always consistent.
• Segment read file cache

The FCC caches file fragments read by smart clients. These clients are FMS aware, and call a specific
FCC programming interface in order to reduce the amount of data downloaded to the client for
processing and display.
• WAN acceleration (optional)

The FCC provides the capability to accelerate file downloads over high latency or noisy WAN lines.
Required software is shipped as part of the base FMS install.
• Managed cache
The FCC automatically purges old cache data based on configuration parameters. Separate sizing
parameters are provided for each cache type including whole file read, whole file write, and segment
file read.
The FCC reads a local fcc.xml configuration file and uses this information to bootstrap a server based
configuration download. This provides the capability to centrally manage FCC configuration
parameters with a minimum amount of configuration data installed on the client.
• Failover (configuration dependent)

The FCC provides the capability to fail over to alternate FSCs on failure of a specific FSC. Failover is
provided for access to both FSC configuration servers and FSC file servers. FSC configuration servers

© 2021 Siemens
are initially used to download the FCC configuration. Once the FCC configuration is downloaded, the
FCC uses the FSC file servers specified in the downloaded configuration.
FMS configuration files
Introduction to FMS configuration files
FMS uses the following files to configure server-client file handling:
• FMS primary configuration file (FSC_HOME/fmsmaster_fscid.xml)

See the FSC_HOME/fmsmaster.xml.template file for all available elements.
• FMS server configuration file (FSC_HOME/fsc.xml)

See the FSC_HOME/fsc.xml.template file for all available elements.
• FMS client configuration file (FMS_HOME/fcc.xml)

See the FMS_HOME/fcc.xml.template file for all available elements.
• FMS server configuration properties file (FMS_HOME\fsc.properties)

See the FSC_HOME/fsc.properties.template file for all available elements.
The fmsmaster_fscid.xml and fsc.xml files are located in the FSC_HOME directory (for example,
TC_ROOT\fsc). The fcc.xml file is located in the FMS_HOME directory (for example, TC_ROOT\tccs).
Grammatical elements provided within the FMS configuration files syntax are as follows:
• Substitution elements
Use substitution elements such as $HOME within string values to simplify parameter specifications
within the configuration file.
• Directory paths
Directory paths may use either local computer conventions with forward or reverse slashes, or UNC
style conventions such as //server1/share/volume1.
• Windows/Linux parameter values

Specify separate Windows and Linux parameter values by using a vertical or character, for example,
$HOME/FscCache|/tmp/FscCache.
Editing FMS configuration files
FMS configuration files are XML files containing structures that must adhere to rules defined in their
document type definition (DTD) files. If you are an administrator who edits XML files for use in
Teamcenter, Siemens Digital Industries Software strongly recommends that you have training in XML
editing and DTD files.

© 2021 Siemens
FMS primary configuration file
If any edits in a configuration violate the rules in the file's DTD, when you attempt to reload the file, the
following error is reported:
Error, server returned status code: 400, status message:

CONFIGURATION_PARSE_ERROR_UNKNOWN_DETAILS_2
This message means the configuration file does not parse properly as defined by the DTD. Every
configuration file declares the name of its particular DTD file in the DOCTYPE element found in the
second line of the file.
Example:
<!DOCTYPE fmsworld SYSTEM "fmsmasterconfig.dtd">
If you encounter such an error, examine the details in the error message and correct the configuration
file so that it parses correctly. You may need to examine the DTD file to learn which parsing rules were
violated.
Find the DTD files in the FSC_HOME\fmsutil.jar file in the com\teamcenter\fms\config directory. The
available DTD files include:
• fmsmasterconfig.dtd
Specifies the DTD for FMS primary configuration files.
• fscconfig.dtd
Specifies the DTD for FSC configuration files.
• fccconfig.dtd
Specifies the DTD for FCC configuration files.
FMS primary configuration file
The FMS primary configuration file (fmsmaster_fscid.xml) is used to manage the FMS configuration.
This file contains routing information and the FSC and FCC defaults. The fmsmaster_fscid.xml file is
located in the FSC_HOME directory. See the FSC_HOME/fmsmaster.xml.template file for all available
elements.
<fmsworld>
<fmsenterprise id="-2041102867" volumestate="normal">
<fccdefaults>
<property name="FCC_CacheLocation" value="$HOME/FCCCache|/tmp/$USER/FCCCache"
overridable="true" />
<property name="FCC_HashBlockPages" value="6144" overridable="true" />
<property name="FCC_LogFile" value="$HOME/fcc.log|/tmp/$USER/fcc.log"
<property name="FCC_MaxExtentFileSizeMegabytes" value="256" overridable="true" />
<property name="FCC_MaxExtentFiles" value="11" overridable="true" />
<property name="FCC_MaxReadCacheSize" value="1000M" overridable="true" />
<property name="FCC_MaxWriteCacheSize" value="1000M" overridable="true" />
<property name="FCC_MaximumNumberOfFilePages" value="28672" overridable="true" />

© 2021 Siemens
<property name="FCC_MaximumNumberOfSegments" value="10688" overridable="true" />

</fccdefaults>
<fscgroup id="mygroup">
<fsc id="FSC_host_username" address="http://SVI6W181:4544" ismaster="true">
<volume id="00e45192597a86573ded" enterpriseid="-2041102867"
root="d:\apps\Siemens\volume" priority="0" />
<transientvolume id="5cf7a2f2b2420b719e8961896b2e6674" enterpriseid="-2041102867"
root="C:\\Temp\\transientVolume_tc_username_tc101_0508" />
</fsc>
<clientmap cidr="0.0.0.0/0">
<assignedfsc fscid="FSC_host_username" priority="0" />
</clientmap>
<clientmap cidr="0::0/0">
<assignedfsc fscid="FSC_host_username" priority="0" />
</clientmap>
</fscgroup>
</fmsenterprise>
</fmsworld>
A basic FMS primary configuration file contains the following elements:
• fmsworld
This element is the containing XML element.
• fmsenterprise
Contains the primary configuration content, including the FMS topology and the FSC and FCC
parameter defaults.
May be followed by a <ticketdigest value="SHA-256" /> tag as part of enabling SHA-256
digest algorithm for tickets.
• fccdefaults
Contains the parameter defaults for all the site FSCs and indicates which of these parameters can be
overridden by a particular FCC installation.
• fscGroup
Contains a list of all the FSCs installed as part of a LAN configuration. One or more groups can be
defined. FSCs within a defined group cannot be deployed across a WAN. FMS assumes that file
transfers between two FSCs within an FSC group are directly routed with no WAN acceleration.
• volume (optional)
Describes where the FSC mounts volumes. An FSC may mount one or more volumes.
• transientvolume (optional)
Specifies the temporary directory used by Teamcenter business servers for writing and reading
temporary files in four-tier configurations. Users access these files using the Teamcenter rich client.
Note:
Do not use the following symbols as delimiter characters within an fmsenterprise ID, fscGroup
ID, or fsc ID:

© 2021 Siemens
Overview of the FMS server configuration file
• Slash (/)
• Question mark (?)
• Equal sign (=)
• Number sign (#)
FMS server configuration file
The FMS server configuration file (fsc.xml) is installed for each server. This file identifies the server
configuration within the system. Optionally, it can override FSC and FCC parameter defaults specified in
the fmsmaster_fscid.xml file. The fsc.xml file is located in the FSC_HOME directory. See the FSC_HOME/
fsc.xml.template file for all available elements.

<!DOCTYPE fscconfig SYSTEM "fscconfig.dtd">
<fscconfig>
<fscdefaults>


<property name="FSC_ReadCacheLocation" value="$HOME\FSCCache|/tmp/FSCCache"
overridable="true"/>
<property name="FSC_WriteCacheLocation" value="$HOME\FSCCache|/tmp/FSCCache"
<property name="FSC_WholeFileCacheLocation" value="$HOME\FSCCache|/tmp/FSCCache"
<property name="FSC_LogFile" value="$HOME\$FSC_ID.log|/tmp/$FSC_ID.log"


<property name="FSC_LogLevel" value="WARN" overridable="true"/>
<property name="FSC_TraceLevel" value="2" overridable="true"/>


<property name="FSC_MaximumReadCacheFilePages" value="40960" overridable="true"/>
<property name="FSC_MaximumReadCacheSegments" value="9216" overridable="true"/>
<property name="FSC_ReadCacheHashBlockPages" value="2048" overridable="true"/>
<property name="FSC_MaximumReadCacheExtentFiles" value="3" overridable="true"/>
<property name="FSC_MaximumReadCacheExtentFileSizeMegabytes" value="256"


<property name="FSC_MaximumWriteCacheFilePages" value="40960" overridable="true"/>
<property name="FSC_MaximumWriteCacheSegments" value="9216" overridable="true"/>
<property name="FSC_WriteCacheHashBlockPages" value="2048" overridable="true"/>
<property name="FSC_MaximumWriteCacheExtentFiles" value="3" overridable="true"/>
<property name="FSC_MaximumWriteCacheExtentFileSizeMegabytes" value="256"

© 2021 Siemens


<property name="FSC_FilesPerWholeFileCacheDir" value="0" overridable="true"/>
<property name="FSC_DiskPercentFreeGoal" value="30" overridable="true"/>
<property name="FSC_WholeFilePurgePeriodMinutes" value="240" overridable="true"/>

































© 2021 Siemens


































</fscdefaults>

© 2021 Siemens





<fscmaster serves="true"/>
<fsc id="myfsc"/>
</fscconfig>
A basic FSC configuration file contains the following elements:
• fscconfig
This element is the outer containing XML element.
• fscdefaults
Defines or overrides FSC default values from the primary configuration file (fmsmaster_fscid.xml).
• fmsmaster
Specifies the location from which to download FMS configuration information. The location can be
either the disk location of the fmsmaster_fscid.xml file or the address of another FSC.
Downloaded FMS configuration information results from the merge of the fmsmaster_fscid.xml file
and the fsc.xml file of the FSC from which the configuration is downloaded.
Resulting FSC configuration information results from the merge of the fmsmaster_fscid.xml file and
the local fsc.xml file of the FSC from which the configuration is downloaded.
FSC configuration paths can branch and can be any depth. You can specify more than one FSC for
configuration download to provide configuration server failover.
• fsc
Specifies the identity of the installed FSC. This identity must match an FSC defined in the primary
configuration file and be within an FSC group.
Note:
fccdefaults elements have been deprecated from fsc.xml.
Place fccdefaults elements in fmsmaster.xml, as they apply to the configuration of clients
assigned to the FSC in question using the clientmap. A complete set of each FSC's fccdefaults
parameter defaults (not including those set in the client's fcc.xml file) is available from any FSC
configuration server. This is not the case when fccdefaults elements are placed in an fsc.xml
configuration file, so Siemens Digital Industries Software recommends not placing any fccdefaults
elements in fsc.xml.

© 2021 Siemens
General FSC configuration parameters
General FSC configuration parameters
The following table lists some of the parameters defined in the FMS server configuration file
(FSC_HOME/fsc.xml). See the FSC_HOME/fsc.xml.template file for all available elements.
Name Default value Description
FSC_DelayedVolumeValidation false Enables delayed file store validation and

allows offline volumes.
By default, an FSC validates all disk locations

before starting and before a configuration
reload. Validation fails if any disk locations
are unavailable.
Set this element to true if your site has a very

large number of disk locations. This defers
disk validation to a background thread,
reducing start up time. And access to offline
disk locations return an error indicating an
offline condition, rather than file not found.
FSC_EnableMonitoring true Not used.
FSC_LogFile $HOME\$FSC_ID.log|tmp/ Defines the name of the FSC log file. The
$FSC_ID.log value to the left of | is used for Windows
hosts. The value to the right of | is used for
Linux hosts.
This parameter is ignored as of Teamcenter

2007.1 when changes were made to logging
functionality. See the log.properties file.
FSC_LogLevel WARN Defines at which log level the server runs.

Valid values are FATAL, ERROR, WARN, INFO,
and DEBUG.
Warning:
Never run a production environment

in DEBUG mode.
FSC_MaximumConnectionIdleTimeMs 90000 Sets the outgoing connection time-out (in

milliseconds). This is essentially a write time-
out. If the connection sends less than one
byte of data to the recipient in this amount of
time, it is closed.
FSC_MaximumHttpsConnectionIdleTimeM 90000 Sets the idle connection time-out (in

s milliseconds). This is essentially a garbage
connection cleanup. This parameter replaces
the
FSC_MaximumHttpConnectionIdleTimeMs
parameter but only for HTTPS connections. If
a secure (HTTPS) connection is not used for
this amount of time, it is closed.

© 2021 Siemens
FSC_MaximumThreadIdleTimeMs 10000 Defines the amount of time (in milliseconds)

a thread in the service pool remains idle
before it is removed and destroyed.
This parameter is subject to the value of the

FSC_MinimumThreads parameter.
FSC_MaximumThreads 255 Defines the maximum number of threads the

server uses to service incoming requests.
FSC_MinimumThreads 5 Defines the minimum number of threads the

server retains to service incoming requests.
FSC_TraceLevel 2 Ignored. Tracing is not enabled.
FSC_TransferRemoteMetadataFile true Enables the transfer of metadata files used

for data transmission verification.
FSC_UploadTimeoutMs 30000 Defines the amount of time (in milliseconds)

an upload attempt waits to connect before
failing over to another route, or failing the
operation if no other route exists.
FSC whole file cache parameters
The following table lists the whole file cache parameters defined in the FMS server configuration file
FSC_WholeFileCacheLocation $HOME/FSCCache| Specifies the absolute paths to the root

/scratch/FSCCache directory of each partition containing the FSC
whole cache files. The operating system’s file
system manages this storage by partition. Only
one path should appear on each media
partition.
Directory permissions should be limited to the
authorized user ID/account.
You can map multiple partitions in this

parameter, for example:
<property
name="FSC_WholeFileCacheLocatio
n"
value="E:\Wholefilecache,F:\Who
lefilecache,G:\Wholefilecache,"
Each partition's root path is separated by either

a comma or a platform-specific path separator
character (; on Windows or : on Linux). All

© 2021 Siemens
FSC whole file cache parameters
cache partitions must be within 10% of each

others' size.
Note:
If you add or remove partitions, you

must run the FSCWholeFileCacheUtil
utility with the -redistrib argument to
redistribute the cache contents among
the new partition spaces before
changing the fmsmaster.xml
configuration file and relaunching a new
FSC instance. Otherwise, the existing
partitions continue to own all of the
slots, and no files are eligible for storage
in the added partitions.
FSC_FilesPerWholeFileCacheDir 0 Specifies the maximum number of files per

whole file cache subdirectory.
Valid values are 1024 through 10240. Set to 0

to disable the whole file cache.
If the number of files stored in the subdirectory

exceeds the configured amount, files are
automatically purged to the maximum number
of files specified.
FSC_DiskPercentFreeGoal 30 Specifies the percentage of free disk space on

the disk containing the whole file cache.
Valid values are 0 through 100.
When free disk space falls below the specified

value, files are automatically purged until the
specified percentage of free disk space is
reached.
FSC_MaxCacheAgeDays 3650 Specifies (in days) the maximum time a file is

not accessed. Cache files not accessed in the
specified time are purged from the whole file
cache.
Valid values are 0 through 3650.
Any files not accessed within the specified time

are purged during the next scheduled purge.
FSC_WholeFilePurge 240 Specifies the time (in minutes) between

PeriodMinutes background cache purge cycles.
Valid values are 0 through 10080. Set to 0 to

run the background purge process
continuously.

© 2021 Siemens
If a background purge cycle exceeds the

specified time, one more purge cycles are
skipped as necessary to maintain the specified
schedule.
FSC_WholeFilePurgeInitial 0 Specifies the time (in minutes) to wait after

WaitMinutes starting the FSC before starting the first
background cache purge cycle.
Valid values are -1 through 2880. Set to -1 to

disable the background purge process.
To run the background cache purge cycle as an

overnight cron job, set this parameter to -1 to
disable the automatic background cache purge,
and then use a cron job to run the
purgeFSCWholeFileCache script. The script is
generated by the FSC on startup and stored in
the FSC cache directory. The script uses the
FSCWholeFileCacheUtil command line utility
to purge the cache.
FSC read cache parameters
The following table lists the read cache parameters defined in the FMS server configuration file
FSC_ReadCache $HOME\FSCCache|/tmp/FSCCache Defines the read cache location. The

Location value is entered through Teamcenter
Environment Manager during FSC
installation.
Modify the value either by running

Teamcenter Environment Manager in
maintenance mode or by manually
editing the fmsmaster_fscid.xml file.
All cache directories must be on a local

hard disk. Cache directories cannot be
on a file share directory or a mapped
drive.
FSC_MaximumReadCache 40960 Defines maximum number of file pages

FilePages in the read cache.
FSC_MaximumReadCache 9216 Defines the maximum number of read

Segments cache segments.

© 2021 Siemens
FSC write cache parameters
FSC_ReadCacheHash 2048 Defines the maximum number of hash

BlockPages block pages. Each hash block contains
128 hash entries.
FSC_MaximumReadCache 3 Defines the maximum number of read

ExtentFiles cache extent files.
FSC_MaximumReadCache 256 Defines the size (in megabytes) of read

ExtentFileSizeMegabytes cache extent files.
FSC_ReadCache age Ignored. Reserved for future use.

PurgePolicy
FSC write cache parameters
The following table lists the write cache parameters defined in the FMS server configuration file
(FMS_HOME/fsc.xml). See the FSC_HOME/fsc.xml.template file for all available elements.
FSC_WriteCacheLocation $HOME\FSCCache|/tmp/FSCCache Defines the write cache location. The

value is entered through Teamcenter
Environment Manager during FSC
installation.
Modify the value either by running

Teamcenter Environment Manager in
maintenance mode or by manually
editing the fmsmaster_fscid.xml file.
All cache directories must be on a local

hard disk. Cache directories cannot be on
a file share directory or a mapped drive.
FSC_MaximumWriteCache 40960 Defines maximum number of file pages

FilePages in the write cache.
FSC_MaximumWriteCache 9216 Defines the maximum number of write

Segments cache segments.
FSC_WriteCacheHash 2048 Defines the maximum number of hash

BlockPages block pages. Each hash block contains
128 hash entries.
FSC_MaximumWriteCache 3 Defines the maximum number of write

ExtentFiles cache extent files.

© 2021 Siemens
FSC_MaximumWriteCache 256 Defines the size (in megabytes) of write

ExtentFileSizeMegabytes cache extent files.
FSC_WriteCache age Ignored. Reserved for future use.

PurgePolicy
FSC internal cache parameters for idle file handles
The following table lists the internal cache parameters defined in the FMS server configuration file
FSC_MaximumIdleFile 100 Defines the maximum number of idle file handles

Handles the server can cache.
FSC_MaximumIdleFile 5 Defines the maximum number of cached idle file

HandlesPerFile handles allowed for a single file.
FSC_MaximumIdleFile 10000 Defines the amount of time (in milliseconds) an

HandleAgeMs idle file handle remains open before being closed.
Siemens Digital Industries Software recommends
the value be set between 1000 to 10000 ms.
FSC internal cache parameters for ticket caches
The following table lists the internal cache parameters for ticket caches defined in the FMS server
configuration file (FSC_HOME/fsc.xml). See the FSC_HOME/fsc.xml.template file for all available
elements.
FSC_MaximumCached 500 Defines the maximum number of valid tickets

Tickets cached. Use this parameter to reduce the need to
revalidate a valid ticket on a repeated request.
FSC WAN acceleration tuning parameters
Use the following parameters in the specified configuration files to tune FSC WAN acceleration.
Additionally, use the FSC_MaximumWANDownloadSockets environment variable to control the
number of sockets used for WAN acceleration downloads.

© 2021 Siemens
FSC WAN acceleration tuning parameters
FSC_WANThreshold 256K Defines the minimum file size allowed for the FSC to use WAN
acceleration for file downloads. The minimum value is 32K.
Reducing the value may improve performance when processing
relatively small files.
Specify this value in the FSC configuration file or in the

fscdefaults section of the FMS primary configuration file.
For example:
<property name="FSC_WANThreshold"
value="256K" overridable="true"/>
FSC_WANChunkSize 256K The maximum file chunk size (from 32K to 2M) that the FSC is
allowed to request. Increasing this value reduces the number of
parallel requests, which may result in performance improvements
when bandwidth is limited.

For example:
<property name="FSC_WANChunkSize"
value="256K" overridable="true"/>
FSC_DoNotCompressExtensi File types to be excluded from being compressed during download

ons when the FSC is using WAN acceleration. All files of the specified
types are processed without using WAN acceleration. Increase
performance by not attempting to compress files that are already
compressed.

For example:
<property
name="FSC_DoNotCompressExtensions"
value="xlsm,xlsx,z,zip"
maxpipes 10 The number of sockets (from 2 to 10) the FSC opens for a file
download when using WAN acceleration. Decreasing this value
allows for more requests to be handled simultaneously. Increasing
this value allows processes to be processed more quickly.
Setting Maxpipes to 1 effectively disables WAN acceleration.
Specify this value in the linkparameters section of the FMS

primary configuration file. For example:

© 2021 Siemens
<linkparameters fromgroup="mygroup"
togroup="cacheGroup" transport="wan"
maxpipes="5" />
Specifying an invalid value resets the parameter value to the nearest valid value.
FMS client configuration file
Overview of the FMS client configuration file
The FMS client configuration file (FMS_HOME/fcc.xml) is installed for each client. This file identifies the
file server used to download the FCC configuration. Typically, the downloaded configuration information
contains FCC routing information and default parameter values. The fcc.xml file is installed at
FMS_HOME (for example, TC_ROOT\tccs). See the FMS_HOME/fcc.xml.template file for all available
elements.

<!DOCTYPE fccconfig SYSTEM "fccconfig.dtd">
<fccconfig version="1.3.2">
<fccdefaults>















































</fccdefaults>

<parentfsc address="localhost:4444" priority="0"/>
</fccconfig>
A basic FCC configuration file contains the following elements:
• fccconfig
This element is the outer containing XML element.
• fccdefaults (optional)
Defines or overrides FCC default parameters downloaded from the parent FSC, if these parameters
may be overridden.
• parentfsc

© 2021 Siemens
Specifies which FSC to download the FMS configuration information from. You may specify multiple
parent FSCs to provide failover.
General FCC configuration parameters
The following table lists general parameters defined in the FMS client configuration file (FMS_HOME/
fcc.xml). See the FMS_HOME/fcc.xml.template file for all available elements.
FCC_LogFile $HOME\fcc.log|/tmp/ Defines the name of the FCC log file. The value to
$USER/fcc.log the left of | is used for Windows hosts. The value
to the right of | is used for Linux hosts.
FCC_LogLevel WARNING Defines the FCC logging level. Valid values, in

order of increasing detail, are OFF, ERROR,
WARNING, INFO, CONFIG, TRACE, FINE and ALL.
SEVERE can be used as a synonym for ERROR.
TRACE, FINE and ALL enable the FCC_TraceLevel

filter to reduce output density.
FCC_TraceLevel Defines the FCC trace filtering level, allowing you

to filter the log output to specific diagnostic
areas. Valid values are PERF, CACHE, CLIENT,
FSC, and ADMIN.
Enter a combination of any of these values,

separated by |, for example:
CACHE|CLIENT|FSC|ADMIN
Note:
PERF outputs requested information in

only enough detail to replay a series of
events for diagnostic purposes. Defining
this value invalidates all other values for
this parameter.
FCC_WANThreshold 256K Defines the minimum file size allowed for the FCC
to use WAN acceleration for FSC downloads. The
minimum value is 32K. Reducing the value may
improve performance when processing relatively
small files.
FCC_MaxWANSources 10 Defines the maximum number of network sockets

(from 2 to 10) that can be used for each file
download. Decreasing this value allows more
requests to be handled simultaneously. Increasing

© 2021 Siemens
General FCC configuration parameters
this value allows processes to be processed more

quickly.
FCC_WANChunkSize 256K Defines the maximum size of a file segment (or

chunk) the FCC is allowed to request. The
minimum size is 32K. The maximum size is 5M.
Raising this value reduces the number of parallel
requests, which may result in performance
improvements when bandwidth is limited.
FCC_ProxyPipeName \\.\pipe\FMSClientPipe| Defines the base name of the set of FIFOs (pipes)
/tmp/FMSClientPipe used to communicate with the FCCClientProxy.
The value must exactly match the value of the
FCC_PROXYPIPENAME environment variable set
in the client application environment.
The value to the left of | is used for Windows

hosts. The value to the right of | is used for Linux
hosts.
Note:
Siemens Digital Industries Software

recommends you do not set this
parameter except under certain
circumstances where it may be required. If
you have questions, contact your Siemens
Digital Industries Software representative.
FCC_FSCConnectionRetry 5000 Defines how often (in milliseconds) the FCC

Interval attempts to reconnect to FSCs it has determined
are offline or malfunctioning.
FCC_StatusFrequency 1000 Defines how often (in milliseconds) the FCC sends
status callback messages to the client during a
lengthy transport operation.
FCC_EnableDirectFSC true Determines whether the FCC routes data requests

Routing on volumes mounted within the local FCC group
to FSCs which mount these volumes.
If set to false, the FCC routes all requests to an

assigned FSC for forwarding to the appropriate
volume server.
FCC_IdleTimeoutMinutes Not applicable. This parameter is obsolete. Use the maxidletime

attribute in the tccs.xml file instead; setting the

© 2021 Siemens
idle time out for TCCS and all its contained

applications, including the FCC.
FCC_TransientFileFSCSource ticketuri Determines whether to use the uniform resource

identifier (URI) contained in every transient file
ticket.
Note:
If your network uses IPv6 (128-bit)

addresses, use the hostname in URIs and
do not use the literal addresses, so the
domain name system (DNS) can
determine which IP address should be
used.
Transient file ticket URIs are defined with the

Default_Transient_Server preference, which
specifies a default transient file server location.
This parameter applies only to a four-tier transient
file accessed using an FCC. It is ignored during
two-tier transient file access and regular volume
access.
If set to ticketuri, the FCC routes four-tier
transient file requests using the ticket URI list,
failing over to the directfscroutes list and then
the assignedfsc list.
If set to parentfsc, the FCC ignores the ticket URI

list, and routes four-tier transient file requests
using only the information obtained from the
parentfsc element (such as the directfscroutes
list and the assignedfsc list).
FCC cache parameters
The following table lists the values in the FMS_HOME/fcc.xml file available for FCC common cache
parameters. See the FMS_HOME/fcc.xml.template file for all available elements.
FCC_CacheLocation $HOME\FCCCache|/tmp/FCCCache Defines the FCC root cache location.

Each user's FCC cache is in a separate
subdirectory below this location.
The value to the left of | is used for

Windows hosts. The value to the right of
| is used for Linux hosts.

© 2021 Siemens
FCC cache parameters
The following table lists the values available for FCC whole file cache parameters.
FCC_CacheTableHashSize 1000 Deprecated.
Defined the initial size of the internal FCC GUID lookup table.
FCC_WholeFileCache 30 Defines the number of FCC whole file cache subdirectories.

Subdirectories
FCC_MaxWriteCacheSize 1G Defines the maximum size (in bytes) of the FCC whole file write
cache. Use the suffixes K, M, G and T to represent kilobytes,
megabytes, gigabytes, and terabytes, respectively.
FCC_MaxReadCacheSize 1G Defines the maximum size (in bytes) of the FCC whole file read
cache. Use the suffixes K, M, G and T to represent kilobytes,
megabytes, gigabytes, and terabytes, respectively.
FCC_MaximumRead 180 Defines the maximum idle age (in days) of a file in the FCC whole
CacheAge file read cache. Files that have not been accessed in longer than
the time period defined are removed from the cache.
FCC_MinimumRead 240 Defines the minimum read cache age (in minutes). The FCC
CacheAgeMinutes deletes files from its WholeFileReadCache only if they have not
been accessed within the specified amount of time.
The minimum value is one minute.
Note:
Setting this parameter to a very high value makes the FCC

whole file read cache purge ineffective.
FCC_MaximumWrite 180 Defines the maximum idle age (in days) of a file in the FCC whole
CacheAge file write cache. Files that have not been accessed in longer than
the time period defined are removed from the cache.
FCC_MinimumWrite 10 Defines the minimum write cache age (in minutes). The FCC
CacheAgeMinutes deletes files from its WholeFileWriteCache only if they have not
been accessed within the specified amount of time.
The minimum value is one minute.
Note:
Setting this parameter to a very high value makes the FCC

whole file write cache purge ineffective.

© 2021 Siemens
FCC_ReadCachePurgeSize 25 Defines the minimum percentage of free space purged when the
Percentage FCC whole file read cache becomes full.
For example, if set to 25, when the cache reaches 100% of its
maximum size, the FCC begins to purge the least recently
accessed files until the cache size is reduced to 75% or less of its
maximum size.
FCC_WriteCachePurgeSize 25 Defines the minimum percentage of free space purged when the
Percentage FCC whole file write cache becomes full.
For example, if set to 25, when the cache reaches 100% of its
maximum size, the FCC begins to purge the least recently
accessed files until the cache size is reduced to 75% or less of its
maximum size.
FCC_MinimumBackground 5 Allows prioritizing of background processing of whole file cache

IdleTimeSeconds population requests. The FCC begins background processing of
cache population requests only after it is free of foreground client
data requests for the specified amount of time (in seconds).
Once cache population begins, received foreground data

requests do not interrupt a file download already in progress,
they can introduce delays before the background cache
population process progresses to the next file.
Disable this behavior by setting this parameter to 0.
Note:
Setting this parameter to a very high value makes the
background cache file population functionality ineffective.
FCC_MaxBackground 3 Defines the maximum number of times a background whole file

Retries cache population request is retried due to a recoverable error.
(Unrecoverable errors are not retried.) If the file is not
successfully downloaded after the maximum number of retries,
the request is discarded.
Disable this behavior by setting this parameter to 0. The request

is immediately discarded.
Note:
Setting this parameter to a very high value can degrade

FCC performance, requiring it to continually retry
downloads that fail in a manner that is not obviously
unrecoverable.
The following table lists the values in the fcc.xml file available for FCC segment cache parameters.

© 2021 Siemens
Sizing FMS fast cache
FCC_MaximumNumberOf 40960 Defines the maximum number of header files.

FilePages
FCC_MaximumNumberOf 512 Defines the number of data segments in the base segment file.
Segments This number does not include extents.
FCC_HashBlockPages 2048 Defines the maximum number of hash block pages. Each hash
block contains 128 hash entries.
FCC_MaxExtentFiles 32 Defines the maximum number of extant files.
FCC_MaxExtentFileSize 16 Defines the maximum size (in megabytes) of each extent file.
Megabytes This number is rounded to a multiple of 16 megabytes.
For example, a value of 258 results in 256 megabytes of segment

data per extent file. The value of 256M represents 256 million
megabytes, which is out of range.
Sizing FMS fast cache

The File Management System (FMS) fast cache is used by every FMS client cache (FCC) and FMS server
cache (FSC) to store segment data. This is by default the primary cache in the FSC. It is the portion of the
FCC where excerpted partial file data is stored. This cache is frequently used in conjunction with a whole
file cache, which stores complete files.
Use the FMS cache sizing tool to determine your cache size requirements. The tool can be found in a ZIP
file in the TC_ROOT\fsc\bin directory, and the latest version is always available from Customer Support.
The tool consists of a Microsoft Word instruction document and a Microsoft Excel spreadsheet.
Following are the contents of the FMSCacheSizingTool_Ver_version.zip file:
FMSCacheSizingTool_Instructions_vversion.zip
FMSCacheSizingTool_Ver_version.xlsx
FMSCacheSizingTool_Ver_versionmacros.xlsx
The tool’s output is applicable to all versions of FMS, subject to the documented limitations of each
version. For example, using the sizing tool does not make the FMS fast cache support 64-bit
configurations when used in conjunction with a 32-bit Java run time.

© 2021 Siemens
Administering FMS
Introduction to administering FMS
An initial installation of Teamcenter using Teamcenter Environment Manager (TEM) provides a single
FSC that mounts to a single volume; a typical configuration for small deployment. During installation,
TEM prompts for the appropriate parameters, creates the .xml configuration files, and installs and starts
the FSC. Using this method, the FSC is installed under a local user account.
After FMS is installed, you can start/stop an FSC so that you can you add volumes. You can also
customize your FMS configuration after the initial installation.
Teamcenter File Management System (FMS) supports UTF-8 encoding. Client applications can use
existing 8-bit encoding (native), UTF-8 encoding (8-bit Unicode), or Unicode (wchar) APIs. The UTF-8
and Unicode (wchar) FCC and FSC and UTF-8 APIs operate consistently with any client locale or native
encoding. Once a client application migrates to the new Unicode APIs, the native encodings of the FCC
and FSC no longer need to match that of the Unicode client application.
Administering FSCs
Introduction to administering FSCs
The fscadmin utility monitors and controls FSC servers. Use this utility to check the status of a server,
perform a shutdown, modify logging levels, query performance counters, and to clear or inspect caches.
You can also use this utility to route these administrative commands from one FSC to any other FSCs in
the local network.
In some cases, you need to manage your FMS file server caches. For example, when you make a change
to the FSC_HOME/fmsmaster_fscid.xml file on the primary host, you must restart all FSCs. To manually
change your FMS configuration, you may need to install and/or uninstall components.
Manage your FSC on Windows
Following are tools to assist you in administering your FMS configuration running on Windows.
Before running any of these tools, ensure the JAVA_HOME and FSC_HOME environment variables are
set to the correct paths. (FSC_HOME is typically set to the fsc directory in your Teamcenter installation,
for example, TC_ROOT\fsc).
• Start the FSC.
• When FSC is installed using Teamcenter Environment Manager (TEM), FSC is installed as a Windows
service. To view the service, choose Start→Control Panel→Administrative
Tools→Services→Teamcenter FSC Service fscid).
Replace fscid with the FSC ID defined in the FSC_HOME\fsc.xml file.
To start the service, right-click the service and choose Start.

© 2021 Siemens
Manage your FSC on Windows
• If FSC is not installed as a Windows service, install the FSC service using the installfsc batch script
by completing the following steps:
1. From a Teamcenter command prompt, change to the FSC_HOME directory.

To open a Teamcenter command prompt, choose Start→Programs→Teamcenter
version→configuration-name Command Prompt.
2. Run installfsc %JAVA_HOME% %FSC_HOME% fscid.

Replace fscid with the FSC ID defined in the FSC_HOME\fsc.xml file. If JAVA_HOME or
FSC_HOME contains spaces, they must be quoted on the command line.
Example:
c:\apps\Siemens\Teamcenter10\fsc>installfsc "C:\Program Files\Java\jre7"

"D:\apps\Siemens\Teamcenter10\fsc" FSC_SVI6W181_user1
• To verify the FSC is running, at a Teamcenter command prompt, enter the following from the
FSC_HOME directory:
fscadmin -s http://hostname:port fsc-ID/status
Example:
c:\apps\Siemens\Teamcenter10\fsc>fscadmin -s
http://SVI6W181:4544 FSC_SVI6W181_user1/status
• To check the status of the read cache, enter the following:
fscadmin -s http://hostname:port fsc-ID/cachesummary/read
Example:
http://SVI6W181:4544 FSC_SVI6W181_user1/cachesummary/read
• To check the status of the write cache, enter the following:
fscadmin -s http://hostname:port fsc-ID/cachesummary/write
Example:
http://SVI6W181:4544 FSC_SVI6W181_user1/cachesummary/write
• To check the FSC performance, enter the following:
fscadmin -s http://hostname:port fsc-ID/perfcounters
Example:

© 2021 Siemens
http://SVI6W181:4544 FSC_SVI6W181_user1/perfcounters
• To stop the FSC, enter the following:
fscadmin -s http://hostname:port fsc-ID/stop
Example:
http://SVI6W181:4544 FSC_SVI6W181_user1/stop
Manage your FSC on Linux
Following are tools to assist you in administering your FMS configuration running on Linux:
• To verify the FSC is running, enter the following:
%./fscadmin.sh -s http://hostname:port fsc-ID/status
Example:
%./fscadmin.sh -s http://EVALSUN8:4544 FSC_EVALSUN8_user1/status
• To check the status of the read cache, enter the following:
%./fscadmin.sh -s http://hostname:port fsc-ID/cachesummary/read
Example:
%./fscadmin.sh -s http://EVALSUN8:4544 FSC_EVALSUN8_user1/cachesummary/read
• To check the status of the write cache, enter the following:
%./fscadmin.sh -s http://hostname:port fsc-ID/cachesummary/write
Example:
%./fscadmin.sh -s http://EVALSUN8:4544 FSC_EVALSUN8_user1/cachesummary/write
• To stop the FSC, enter the following:
%./fscadmin.sh -s http://hostname:port fsc-ID/stop
Example:
%./fscadmin.sh -s http://EVALSUN8:4544 FSC_EVALSUN8_user1/stop

© 2021 Siemens
Query the FSC performance counters
The FSC can fail to start after a reboot of Linux systems. This can occur when other services upon which
the FSC depends have not yet started.
For example, the ypbind service can take additional time to start. Because the ypbind service was not
operational when the FSC attempted to start, the su operation failed to switch to the user required to
start the FSC.
In this case, correct the reason the ypbind service launches slowly. Because Siemens Digital Industries
Software is not directly contributing to the slow launch of the ypbind service, the resolution must be
investigated by your IT department on a case-by-case basis. One workaround is to add a pause in the
startup script. A sleep value of 120 seconds is sufficient in test systems. The sleep command must be
added to the startup script in the rcname.d directory. Do not modify the rc scripts under the TC_ROOT
directory; these are not the scripts first called.
Note:
Renaming the rc script in the rcname.d directory to force the service to boot later in the boot
order does not provide sufficient time to allow the ypbind service to start in test systems.
Use the fscadmin utility to query the FSC performance counters:
http://cyi6w387:4544 FSC_cyi6w387_user1/perfcounters
Performance counters provide insight into the working of the file system cache. There are a number of
FSC performance counters available.
LocalReadPartialFile
Min - 0
Max - 0
Avg - 0
Successes - 0
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,654 UTC - cyi6w387 -
name=Throughput,units=Bytes/Sec,gauge=0 : 128 avg=0 {0/0 (0)} span=60000 rate
basis=1000
name=Size,units=Bytes,count=0 : 0 avg=0 {0/0 (0)}
name=GetRequestCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=HeadRequestCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=TransactionRate,units=Transactions/Sec,gauge=0 : 128 avg=0 {0/0 (0)} span=60000
rate basis=1000
LocalTransfer
Min - 0
Max - 0
Avg - 0

© 2021 Siemens
Successes - 0
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,654 UTC - cyi6w387 -
basis=1000
name=Upload,units=Bytes,count=0 : 0 avg=0 {0/0 (0)}
rate basis=1000
LocalReadWholeFile
Min - 18
Max - 1345
Avg - 297
Successes - 8
Failures - 0
KBytes - 29164
AdHoc:
2012/04/19-20:10:13,655 UTC - cyi6w387 -
basis=1000
name=Size,units=Bytes,count=29864040 : 8 avg=3733005 {2335/17774751 (5840329)}
name=HeadRequestCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=Simultaneous Open,units=Transactions,gauge=0 : 8 avg=0 {0/0 (0)}
rate basis=1000
LocalWrite
Min - 0
Max - 0
Avg - 0
Successes - 0
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,655 UTC - cyi6w387 -
name=Append,units=Bytes,count=0 : 0 avg=0 {0/0 (0)}
name=Upload,units=Bytes,count=0 : 0 avg=0 {0/0 (0)}
name=RollbackCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
Ticketing
Min - 0
Max - 1
Avg - 1
Successes - 16
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,655 UTC - cyi6w387 -
name=TicketTimeParseErrorCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=MissingCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=ExpiredTicketCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=InvalidTicketCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=OnURLCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=InHeaderCount,units=Transactions,count=16 : 16 avg=1 {1/1 (0)}
name=TicketCacheMissCount,units=Transactions,count=16 : 16 avg=1 {1/1 (0)}
name=TicketCacheHitCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}

© 2021 Siemens
name=ValidTicketCount,units=Transactions,count=16 : 16 avg=1 {1/1 (0)}
LoadFSCCache
Min - 0
Max - 0
Avg - 0
Successes - 0
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,655 UTC - cyi6w387 -
name=InvalidTicketsReceived,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=WaitingDownloads,units=Transactions,gauge=0 : 0 avg=0 {0/0 (0)}
name=SuccessDownloads,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=FailedDownloads,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=ValidTicketsReceived,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
LocalAdminRead
Min - 0
Max - 126
Avg - 13
Successes - 10
Failures - 0
KBytes - 0
AdHoc:
2012/04/19-20:10:13,655 UTC - cyi6w387 -
name=FCCDefaultsCount,units=Transactions,count=3 : 3 avg=1 {1/1 (0)}
basis=1000
name=FMSMasterFileCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=PutRequestCount,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
name=FMSMasterMD5Count,units=Transactions,count=0 : 0 avg=0 {0/0 (0)}
rate basis=1000
localReadTotal
Rate - 0 bytes/sec
ReadSegmentCacheStats
MapName - FSC_cyi6w387_kimc-FSCReadMap
HashBlockPages - 32
HashEntries - 4096
HashTableSize - 16384
MaxExtentFiles - 0
MaxExtentSegments - 0
MaxFilePages - 512
MaxSegmentExtentMBs - 0
MaxSegments - 623
MaxTotalSegments - 623
SegmentEntries - 18432
SegmentExtentFileSize - 16
SegmentExtentFileSizeBytes - 16777216
SegmentExtentsPerFile - 1024
SegmentFileSize - 10207232
HeaderPercentFull - 0
NumExtentFiles - 0
NumExtentSegments - 0
NumFiles - 0

© 2021 Siemens
NumFreeFilePages - 512
NumFreeSegmentEntries - 623
NumHits - 0
NumMisses - 0
NumUsedFilePages - 0
NumUsedSegmentEntries - 0
SegmentPercentFull - 0
WriteSegmentCacheStats
MapName - FSC_cyi6w387_kimc-FSCWriteMap
HashBlockPages - 32
HashEntries - 4096
HashTableSize - 16384
MaxExtentFiles - 0
MaxExtentSegments - 0
MaxFilePages - 512
MaxSegmentExtentMBs - 0
MaxSegments - 623
MaxTotalSegments - 623
SegmentEntries - 18432
SegmentExtentFileSize - 16
SegmentExtentFileSizeBytes - 16777216
SegmentExtentsPerFile - 1024
SegmentFileSize - 10207232
HeaderPercentFull - 0
NumExtentFiles - 0
NumExtentSegments - 0
NumFiles - 0
NumFreeFilePages - 512
NumFreeSegmentEntries - 623
NumHits - 0
NumMisses - 0
NumUsedFilePages - 0
NumUsedSegmentEntries - 0
SegmentPercentFull - 0
Configure an FSC manually
1. Run the backup_xmlinfo utility, located in the TC_BIN directory. The output is the backup.xml file,
stored in the directory from which you ran the backup_xmlinfo utility.
2. Review the backup.xml file to determine the enterpriseID, volumeUid, and the wntPath or
unixPath.
Enter the values from the following parameters into the appropriate parameters within the
FSC_HOME\fmsmaster_fscid.xml file.
Parameter in backup.xml file Parameter in fmsmaster_fscid.xml file

enterpriseID fmsenterprise id
volumeUid volume id
wntPath volume id root
unixPath transient id root

© 2021 Siemens
Maintaining the FSC whole file cache
3. Edit the FSC_hostname_user and fcc.xml files, if necessary. For example, if you are changing cache
locations.
4. Stop and restart the FSC process.
Maintaining the FSC whole file cache
You can configure either traditional FSC storage or an NFS style storage for FSC whole files known as
whole file cache (WFC). (FSC/JT segments are still stored in FSC segment cache.) Whole file cache stores
a copy of the file on the disk.
To maintain the whole file cache:
• To configure whole file cache, set the whole file cache parameters in the FSC_HOME
\fschostname_user.xml file and the fcc.xml files.
• To monitor whole file cache, use the fscadmin utility with the whole options (for example,
cachesummary/whole, cachedetail/whole, clearcache/whole, and purgecache/whole).
• To purge files from the whole file cache, run the FSCWholeFileCacheUtil utility stored in the
FSC_HOME\bin directory. Purge the cache based on file age, subdirectory size, and/or available disk
space. This utility also purges misplaced files.
The benefits of whole file cache for IT data storage deployments are:
• You can use NFS or other network storage for the FSC whole file cache. The files are whole files on a
disk and not in a virtual memory mapped disk space. You no longer need a local disk or a special card
to make the network disk appear local to the operating system.
• You can use platforms such as HP for large FSC whole file caches. Platforms that previously had issues
with the segment cache or virtual memory mapping can be used with large FSC whole file caches by
using the NFS style whole file disk storage (although JT segments that are not whole file are still
stored in the segment cache). Whole JT files can be prepopulated to avoid segment caching.
• You can use redundant disk storage (or RAID) rather than dual FSC caches. You can still run two FSCs
for high availability off of the network storage.
Though multiple file system caches can share the same whole file cache, no more than one FSC
should be responsible for purging the shared cache. When managing a shared whole file cache, purge
the shared cache using either of the following methods:
• Disable purging on all but one of the FSCs. (This is the typical deployment.)
• Disable purging on all FSCs and configure a purge job to run as an external cron job (Linux) or
Scheduled Task (Windows).
• FSC whole file cache reliability is increased to OS level file reliability. Loss of a directory entry now
results in single file loss, improving the durability and reliability of the whole file cache.

© 2021 Siemens
• You can do a disk copy to transfer an FSC cache, or copy the FSC whole file cache to a DVD and mail it.
A background garbage collection process runs to prune the whole file cache. The cycle on this may be
several hours for very large FSC whole file caches.
Copying the FSC whole file cache
You can copy all or part of the whole file cache using operating system commands, and then transfer
the data electronically or physically to another site. This is useful when setting up a deployment site.
Copying the whole file cache from a test environment to a deployment environment reduces the time it
takes to populate the cache and improves performance.
This procedure works best when both FSCs belong to the same enterprise ID, providing superior
performance over a WAN.
If the FSCs belong to different enterprises, follow these best practices:
• Set up a Multi-Site configuration between the two enterprises.
• Replicate the ImanFile objects belonging to the owning site as stubs at the remote site.
Note:
Massive WFC (Whole File Cache) sometimes can be spread across different physical disk partitions.
The WFC copy works if both the source and destination have the same WFC configuration (the
same number of disk partitions and the same number of hash directories).

© 2021 Siemens
Selective file caching
Selective file caching
Selective file caching prevents designated datasets from being cached on specific, intermediate FSC
servers. Doing so may be important for site security, political geography, or other reasons definable in
terms that Teamcenter business logic can apply. Servers so designated are referred to as restricted
servers.
By default, FMS caches most files on each intermediate FSC server. (There are exceptions for transient
file data and administrative command results.) Selective file caching lets you designate files that will not
be cached on these servers. Be aware of the following items when enabling selective file caching:
• FSC servers participating in selective file caching must run a version of FMS that supports selective file
caching:
• When enabling selective file caching in Multi-Site Collaboration configurations, do not attempt to
enable selective caching across Teamcenter sites. Each Teamcenter site should be configured for
selective file caching within its own File Management System. All participating sites configured for
selective file caching should have a similar set of caching rules. That is, conditions and FSC lists should
be the same.
• Enabling selective file caching does not impact how files are cached in the user’s FMS Client Cache
(FCC). Client caches cannot be associated with any restricted FSC ID or wildcard.
Enable selective file caching
Use the following steps to configure your site for selective file caching.
1. Make the following updates to the fmsmaster.xml and fsc.xml files:
• Ensure FSC IDs contain only letters, numeric digits, underscores ("_"), and hyphens ("-").
Specifically, remove or change any of the following characters in any of the FSC IDs:
• Commas (",")
• Colons (":")
• Semicolons (";")
• Apostrophes ("'")
• Question marks ("?")
• Asterisks ("*")
• Any characters that cannot be used as part of a file name, such as horizontal tabs and
quotation marks.

© 2021 Siemens
• Any characters or character sequences that may interfere with the parsing of regular
expressions. For example, "[0-9]".
• For any combination of FSC ID lists that will be deployed as part of the site's selective file caching
implementation, shorten any FSC IDs that would collectively exceed 512 bytes of escaped,
comma-separated, URL-encoded UTF-8 text. If shortening is problematic, consider using the
asterisk ("*") character as a wildcard to represent all FSCs.
2. Using the Business Modeler IDE, set up the custom business rules by which selective file caching
will work at your site.
Conditions return true if the dataset is to be cached. Conditions return false if the dataset is not to
be cached.
• Fnd0DatasetShouldFSCCacheThisDataset condition
This condition defines the dataset instances that are not cached on restricted FSC servers, using
the Dataset_Selective_File_Caching_Rule_Condition_And_Blacklist preference. By default,
the condition is set to isTrue(), specifying that all datasets are to be cached. Override this
condition with a custom template defining the business rules for your site's selective file caching.
The definition of this condition depends entirely on your site's security requirements. As an
example, the following expression returns true for all datasets with an IP classification set to
anything other than "top-secret".
o != NULL AND o.ip_classification != "top-secret"
Note:
Always add a check for o != NULL before accessing any field on the "o" object. Doing so
ensures that files not associated with any dataset object are restricted by the FSC deny list
configured in the rule preferences. Without this check, evaluating the condition on a file
not associated with any dataset object could cause unexpected results.
• Additional {DatasetType}ShouldFSCCacheThisDataset conditions

The {DatasetType}_Selective_File_Caching_Rule_Condition_And_Blacklist preferences define
dataset type-specific instances that are not cached on restricted FSC servers. Each applies to
datasets of the type specified by {DatasetType}, for example, TextShouldFSCCacheThisDataset
or MSWordShouldFSCCacheThisDataset. The dataset type-specific preferences override the
default Dataset_Selective_File_Caching_Rule_Condition_And_Blacklist preference, but only
for datasets of the type that appears in the preference name. These conditions do not exist by
default, so must be created.
The definitions of these conditions depend entirely on your site's security requirements. The key
requirements for a signature are that it should take a dataset object as input and the expression
should include the check for o != NULL before accessing any field on the "o" object as shown
in the earlier example for Fnd0DatasetShouldFSCCacheThisDataset.
3. Log on to Teamcenter as an administrator with dba privileges, using the rich client to set the
following preferences:
• FMS_Enable_Selective_File_Caching

© 2021 Siemens
Enable selective file caching
Determines if selective file caching is enabled. Set FMS_Enable_Selective_File_Caching to true

to enable selective file caching. (This preference is visible and accessible only to Teamcenter
administrators.)
• Dataset_Selective_File_Caching_Rule_Condition_And_Blacklist
Specifies the condition that handles files for any dataset type, unless overridden by other type-
specific {DatasetType}_Selective_File_Caching_Rule_Condition_And_Blacklist preferences. By
default, this preference is set to Fnd0DatasetShouldFSCCacheThisDataset:*. If the COTS
condition name in this preference is changed, that condition must be defined in the Business
Modeler IDE.
• {DatasetType}_Selective_File_Caching_Rule_Condition_And_Blacklist
Specify the conditions to be evaluated to determine the dataset type-specific instances that are
not cached on the specified FSC servers.
Note:
These preferences should be created with system protection scope and their names hidden
to be accessible only by Teamcenter administrators.
For each dataset type, set the following values:
• Dataset Type
Set to the type of data, for example, Text or MSWord.
• Restricted FSCs
In a comma-separated list, list the FSC ID of each server on which the dataset type should not
be cached. The "*" wildcard can represent all FSCs. Limit the list of restricted sites to ten sites
or fewer for each {DatasetType}_Selective_File_Caching_Rule_Condition_And_Blacklist
preference.
• Dataset Condition
Set to the dataset type-specific condition for this dataset type, for example,
TextShouldFSCCacheThisDataset or MSWordShouldFSCCacheThisDataset.
Example:
Preference: Text_Selective_File_Caching_Rule_Condition_And_Blacklist
Preference value:
TextShouldFSCCacheThisDataset:FSC_NYC1,FSC_NYC2,FSC_LA1,FSC_Lon1
Or
Preference: Word_Selective_File_Caching_Rule_Condition_And_Blacklist
Preference value: WordShouldFSCCacheThisDataset:*

© 2021 Siemens
Note:
Recall that the FSC lists in the preferences are denylists. Sensitive datasets of the type
specified by the preference name are not cached on the specified FSCs.
4. Restart the pool server to deploy the changes to all Teamcenter server instances.
Administering FCCs
Introduction to administering FCCs
The FMS client cache (FCC) is a private user-level cache. It provides a high-performance cache for both
downloaded and uploaded files. The FCC provides proxy interfaces to client programs and connectivity
to the server caches and volumes.
Files captured by the FCC do not change for download or upload, for neither whole files nor partial files.
All file copies and file segment copies are identical throughout the system and are never updated. New
file versions are checked into the system with a new GUID, but a file with an existing GUID in the FMS
system never changes. Therefore, there are no issues with file change or cache consistency.
FCCs provide access to the transient volume for the business server in a Teamcenter two-tier
configuration. The business server writes or reads temporary files directly to a disk directory. The rich
clients access those files using the standard FCC interfaces. This approach provides client independence
from the system configuration and ensures that client programs operate the same in both two-tier and
four-tier mode for file access functions.
TCCS considerations
As of Teamcenter 9.0, FCC runs within the Teamcenter client communication system (TCCS)
container, which also contains the TcServerProxy and TcModelEventManager applications.
Starting, stopping, and restarting any of these applications cause the entire TCCS service (including
all applications within the container) to start, stop, or restart.
Stopping an FCC
It is important that you shut down TCCS/FCC in a prescribed manner. Not following one of several
recommended methods can result in FCC and TCCS errors.
You are strongly advised not to use an operating system kill command to shut down a TCCS/FCC
instance unless safer methods have failed.
Restarting an FCC
You may need to restart a TCCS/FCC instance when:
• You have changed FCC cache parameters that require a restart.

For information about which cache parameters require an FCC restart, see Elements requiring a
restart of an FCC.

© 2021 Siemens
Shutting down a TCCS/FCC instance
• A TCCS/FCC process executing in memory is not responding to pipe connection attempts. For
example, when all of the following events occur:
• The FMS_HOME\bin\fccstat -status command reports that the FCC is offline.
• The FMS_HOME\bin\fccstat -start command cannot start the FCC.
• The FMS_HOMEstartfcc.bat reports that the FCC cache is locked.
• The TCCS container needs restarting for non-FCC reasons.

Reconfiguring an FCC
There are three ways to reconfigure an FCC. Each method involves a different level of user
interaction and a different set of restrictions.
WAN acceleration
WAN acceleration improves file download performance across WAN assets by splitting larger files
into smaller pieces, downloading the pieces simultaneously, and reconstructing the files in the
cache before passing the file to the client. See Enabling and tuning WAN acceleration for
instructions on implementing WAN acceleration.
Shutting down a TCCS/FCC instance
Whenever you stop a TCCS/FCC instance, it is important that the shutdown process is as clean as
possible. You may want to stop a TCCS/FCC instance because:
• It is no longer needed.
• You need to stop and restart the instance to receive new configuration information.
Regardless of why you stop an FCC, remember that the FCC runs within the TCCS container process.
Stopping an FCC also stops the TcServerProxy and TcMEM processes.
Before stopping a TCCS/FCC instance, close all client applications and wait 10 seconds.
Note:
Siemens Digital Industries Software does not recommend using the operating system kill
command or the Windows Task Manager to stop an FCC unless safer methods have failed. Doing
so can cause issues with the FMS fast cache, the FCC cache lock, the TCCS process lock, and any
active FCC/TcServerProxy/TcMEM transactions.
Warning:
On Windows 7 and later, JRE shutdown hooks are not honored, preventing the FCC from closing
cleanly. If the TCCS/FCC instance remains running when users log off (or shut down) these
operating systems, the FCC segment cache may be corrupted.

© 2021 Siemens
Siemens Digital Industries Software recommends you add the fccstat -kill command to all user
logoff scripts and to any relevant Windows shutdown scripts for Teamcenter clients running on
these operating systems.
The following methods for stopping an FCC are listed in the order by which they reduce the risk of
corrupting the cache or creating a stuck lock file. If after stopping an FCC, it does not properly restart,
reset the user’s FCC environment.
• Method 1
• Run FMS_HOME\bin\fccstat -stop.
This method stops a TCCS/FCC instance if it is idle.

The system confirms that the user has shut down all the attached client processes before stopping the
TCCS.
If non-idle clients are connected to the FCC or other TCCS applications, a message appears and the
FCC is not stopped. If you receive this message, confirm that all client applications are disconnected
from FCC/TCCS, wait 10 seconds, and retry.
Note:
An FCC client is non-idle if it holds an open FCC file handle, an open segment cache handle, or
an open pipe connection that has made a request within the past 5 to 10 seconds.
This method is effective 90 percent of the time and results in the cleanest possible shutdown. The
FCC can be restarted afterward with no data loss.
• Method 2
• Run FMS_HOME\bin\fccstat -kill.
This method stops a TCCS/FCC if it is idle or non-idle, as long as it is responsive to pipe commands.
The system does not confirm that the user has shut down all the attached client processes before
stopping the FCC. The system does not display a message that other client applications are connected.
Any transactions in progress at the time the FCC is terminated may fail. This can have a negative
effect on the connected client applications.
This method is effective 99 percent of the time. The FCC can typically be restarted afterward with no
data loss.
• Method 3
If a TCCS/FCC instance is not responsive to FCC pipe commands, it may report FCC Offline though
the TCCS/FCC process is running. In this situation, use the tspstat or tcmemstat utility to stop the
shared TCCS process.
• Method 4 (only if TCCS/FCC running in foreground)

© 2021 Siemens
When do I need to restart the FCC?
• Press Ctrl+C in the FCC foreground window.

The foreground window is available from the interface only if TCCS/FCC is running in a visible
command prompt window or shell. (This is not usually the case.)
• Alternatively, close the TCCS command prompt window (Windows only).
Note:
If the FCC is running in a hidden window, and you have system tools access, you can locate the
hidden FCC window and send it a WM_CLOSE message (Windows only).
This method is highly effective and usually results in a clean shutdown of the FCC.
• Method 5 (Linux only)
• Run the operating system kill command without the -9 option.
This method stops an FCC if it is idle or non-idle, even when it is not responsive to pipe commands.
This method stops the FCC as cleanly as possible. The effect is similar to method 2, but it is possible
that file handles become stuck or that cache states are lost.
• Method 6 (Linux only)
• Run the operating system kill command with the -9 option.
This method performs a hard stop on the FCC. Usually, the contents of the FCC fast cache (segment
cache) are lost. Occasionally, the FCC lock file becomes stuck.
• Method 7 (Windows only)
• From the Task Manager, select the user’s FCC process and click End Process.
This method performs a hard stop on the FCC. Usually, the contents of the FCC fast cache (segment
cache) are lost. Occasionally, the FCC lock file becomes stuck.
Restarting an FCC
When do I need to restart the FCC?
Restart the FCC when:
• You changed FCC elements that require a restart.

For information about which FCC elements require a restart, see Elements requiring a restart of an
FCC.

© 2021 Siemens
• A TCCS/FCC process executing in memory is not responding to pipe connection attempts. For
example, when all of the following events occur:
• The $FMS_HOME/bin/fccstat -status command reports that the FCC is offline.
• The $FMS_HOME/bin/fccstat -start command cannot start the FCC.
• The $FMS_HOME/startfcc.bat reports that the FCC cache is locked.
• The TCCS container needs restarting for non-FCC reasons.
Restart an FCC manually
Any change to the FCC properties file requires a manual restart of the FCC.
Some changes to FCC elements cannot be automatically propagated to the FCC when you reconfigure
the FMS primary configuration file (fmsmaster_fscid.xml) or local FCC file (fcc.xml). When you
reconfigure these elements, you must manually stop and restart the FCC. All FCC applications and the
FCC must be shut down and then restarted.
1. Close all client applications.
2. Wait 10 seconds.
3. Run FMS_HOME\bin\fccstat -restart.
If this method does not work, stop and restart the FCC:
1. Stop the FCC.
2. Run FMS_HOME\bin\fccstat -start.
Note:
Remember that the FCC runs within the TCCS container process. Stopping an FCC also stops the
TcServerProxy and TcMEM processes.
Elements requiring a restart of an FCC
If any of the following parameters are changed, the FCC must be restarted to read the new settings:
• General elements
The following general FCC elements require a manual restart of the FCC:
FCC_ProxyPipeName
FCC_CacheLocation

© 2021 Siemens
Reset a user’s environment
FCC_StatusFrequency
• Logging elements
The following FCC logging elements require a manual restart of the FCC:
FCC_LogFile
FCC_LogLevel
FCC_TraceLevel
• Whole file cache elements

The following FCC whole file cache elements require a manual restart of the FCC:
FCC_WholeFileCacheSubdirectories
FCC_CacheTableHashSize
FCC_MaxWriteCacheSize
FCC_MaxReadCacheSize
FCC_MaximumReadCacheAge
FCC_MaximumWriteCacheAge
FCC_ReadCachePurgeSizePercentage
FCC_WriteCachePurgeSizePercentage
• Segment cache elements

The following FCC segment cache elements require a manual restart of the FCC:
FCC_MaximumNumberOfFilePages
FCC_MaximumNumberOfSegments
FCC_HashBlockPages
FCC_MaxExtentFiles
FCC_MaxExtentFileSizeMegabytes
Reset a user’s environment
1. Stop all client applications that use FMS.
2. Stop the FCC process.
3. Reset the user’s system environment using one of the following methods:
• On a single-user machine, restart (or shut down and reboot) the operating system.
• On a multiuser machine, log off and log back on.

If you cannot restart the FCC because of locked file handles, warn other users that the machine
must be rebooted, then reboot the operating system.
4. Remove the following files from the user’s FCC cache directory (for example, Users\user-name
\FCCCache\username). Corruption in any of these files can prevent the FCC from restarting:

© 2021 Siemens
• fcc.lck
• fms.hsh
• fms.mf
• fms.seg
• All files beginning with fms.ext (cache extent files)
5. Remove the TCCS lock file, stored in the Users\.user-name_lock_host-name directory.

The file name is TCCS_CONFIG.lck. By default, the TCCS_CONFIG environment variable is set to
Teamcenter.
For example:
C:\Users\smith\.smith_lock_host123\Teamcenter.lck
Reconfiguring an FCC
There are three ways to reconfigure an FMS client cache (FCC). Each method involves a different level of
user interaction and a different set of restrictions.
• Automatic reconfiguration of the FCC

Automatic reconfiguration of the FCC occurs when changes are made to the fmsmaster_fscid.xml file
and the primary FMS file server cache (FSC) configuration server is reconfigured. Not all FCC changes
are reconfigured automatically.
Many changes to FMS client cache (FCC) elements are automatically propagated to the FCC when you
reconfigure the FMS primary configuration file (fmsmaster_fscid.xml).
For example, the FCC detects when changes are made to the following FCCDefault parameters in the
primary configuration file and reconfigures itself accordingly, without interrupting FCC client
application service:
• FCC_TransientFileFSCSource
• FCC_EnableDirectFSCRouting
• FCC_WanThreshold
• FCC_MaxWANSources
• FCC_FSCConnectionRetryInterval
The FCC also detects when changes are made to the following FCC configuration elements in the
primary configuration file and reconfigures itself accordingly, without interrupting FCC client
application service:
• FCCDefaultssite

© 2021 Siemens
Using the FCC assignment mode element to override default client mapping behavior
• parentfsc
• assignment
• assignedfsc elements within the clientmap element
• directfscroute elements generated by the parentfsc file from resource elements in the primary
configuration file
• directtransientvolume elements generated by the parentfsc file from resource elements in the
primary configuration file
• Manual reconfiguration of the FCC

Manual reconfiguration of the FCC is required when changes are made to the local fcc.xml file when
the FCC is processing commands for one or more applications.
The FMS client cache (FCC) responds to reconfiguration requests made through the fccstat utility,
attempting to reconfigure without loss of service to the client workstation or to applications
connected to the FCC.
However, there are situations in which the FCC cannot be reconfigured automatically. Changes made
in the local fcc.xml file while the FCC is processing commands for one or more applications require a
manual FCC reconfiguration.
• Run the fccstat utility with the -reconfig argument.

Changes are applied from your local fcc.xml files and from any parentfsc configurations.
• Restart the FCC

Restarting the FCC is required when an immutable parameter (such as cache size) is changed in the
fmsmaster_fscid.xml file or the fcc.xml file. Clients receive changes to immutable parameters when
their FCCs are restarted.
Using the FCC assignment mode element to override default client mapping behavior
A client mapping is a list of assignedfsc elements appropriate for a particular client’s IP address and/or
domain name. The assignedfsc element is found in the fmsmaster_fscid.xml file.
Static client mapping is not always appropriate, because it is possible for a client to change network
contexts without changing its IP address or domain name.
Example:
A user takes a company laptop from the office to a hotel room. The FMS server cache (FSC) is
inaccessible because the client has moved outside the company firewall. To access company data
from the public side of the firewall, the user must use a different FSC server (or at least a different
access address) than the server used in the office.

© 2021 Siemens
Example:
A user takes a company laptop from the office to a remote location. At the remote location, the
client continues accessing data over a WAN, using the client mapped assignedfsc elements, even
though the data is now more readily accessible from an FSC in a local satellite office. This is
inefficient, as the WAN connection is slower than accessing the data from the FSC servers in the
same office.
It is possible, but inconvenient, to reconfigure the clientmap elements in the fmsmaster_fscid.xml file
for each client machine (and propagate dynamic changes to several clientmap settings throughout the
entire FMS system) each time a Teamcenter client is relocated on the network.
It is more efficient to change the default assignment mode setting (in the fcc.xml file) from clientmap
to parentfsc.
• clientmap
With this setting, FCC data requests are routed to the assignedfsc elements specified within the
clientmap section of the fmsmaster_fscid.xml configuration file. The FCC downloads the list of
assignedfsc elements from the parentfsc element when it starts.
An assignedfsc element represents an FMS server that distributes Teamcenter data to clients that
have no direct access to the FSCs serving the origin volume.
Each clientmap section typically contains one to three assignedfsc elements. The assignedfsc
elements represent FMS cache or data servers.
• parentfsc
Use this setting when the default client mapping setting is not efficient.
With this setting, the parentfsc list is used as the assignedfsc list. FCC data requests are routed to the
list of parentfsc elements specified in the fcc.xml configuration file.
A parentfsc element represents an FSC server that distributes FMS configuration settings to clients
upon request. Each fcc.xml file typically contains one to three parentfsc elements.
The following fcc.xml sample code illustrates an appropriate assignment mode setting for a client in a
hotel room.
<parentfsc address="https://plm.vpnaccess.newyork.mycompany.net:4318"
transport="wan"/>
<assignment mode="parentfsc"/>
The following fcc.xml sample code illustrates an appropriate assignment mode setting for a client in a
remote satellite office.
<parentfsc address="http://plm1.product.india.mycompany.net:4545"
priority="0"/>
<parentfsc address="http://plm2.product.india.mycompany.net:4545"
priority="0"/>
<parentfsc address="http://backup.plm.product.india.mycompany.net:4545"
priority="1"/>

© 2021 Siemens
Why am I getting errors after modifying the FCC configuration?
Note:
For legacy client mapping, use the iptoparent setting in the fcc.properties file:
com.teamcenter.fms.clientcache.iptoparent=false
The default setting is true, which causes the FCC to send its IP to the parentfsc list. The FSC maps
the FCC client by the IP as determined at the client.
Setting iptoparent to false inhibits the client IP on the parentfsc client mapping request. The FSC
maps the FCC client by the IP address on which the request arrives at the parentfsc. This is often
an IP router, firewall, or proxy server at the parent FSC's location.
Why am I getting errors after modifying the FCC configuration?
The following list discusses typical FCC modifications which result in errors:
• Modified a routing or connection element in the fcc.xml file, and then did not run the
$FMS_HOME/bin/fccstat -reconfig command.
Changes made in the local fcc.xml file while the FCC is processing commands for one or more
applications require a manual FCC reconfiguration.
• Modified an FCC element that required an FCC restart. The effects of the change are not applied until
the FCC is restarted.
For a list of the FCC elements that require a manual restart, see Elements requiring a restart of an
FCC.
• Improperly shutting down an FCC may generate cache or lock errors upon restart.
Clear these errors by restarting the user’s FCC environment.
Other FCC modifications incompletely applied may generate other errors. Most error messages provide
suggestions for how to correct the problem. Check the FCC log and Teamcenter system logs for error
messages.
Why am I getting errors after removing the FCC?
If you remove the cache files, the cache is empty when FCC restarts. This can generate errors in two
areas:
• You cannot create new cache files on the local hard disk due to permission settings, lack of disk space,
or configuration mistakes.
Fixing the underlying issue typically resolves the FCC error.
• You cannot repopulate the cache because the FMS system from which the data originated is not
accessible on the network.
If the data is no longer available from the PLM volumes, you must find a new data source. Fixing the
underlying network access problem typically resolves the FCC error.

© 2021 Siemens
Why am I getting errors after using the kill command to stop FCC processes?
Siemens Digital Industries Software does not recommend using the operating system kill command or
the Windows Task Manager to stop an FCC unless safer methods have failed. Doing so can cause issues
with the FMS fast cache, the FCC cache lock, and active FCC transactions.
For recommended methods of stopping an FCC, see Shutting down a TCCS/FCC instance
If you use one of these methods to stop an FCC and receive errors, you must reset the user’s FCC
environment.
Set file buffer size to optimize file transfer rate
If you find that the transfer of large files is sluggish, you can optimize the file transfer rate by adding the
following buffer parameters to the fcc.properties file:
• buffSize
Sets the internal buffer size which is used to read data from the file system and the segment
caches. For peak I/O efficiency, this value should always be a multiple of 16KB and also always a
multiple of the file system sector size.
Following is the commented text for this parameter in the fcc.properties.template file:
# FCC internal buffer size.

# Default value is 64K.
# Value should be in 16K increments.
# Minimum is 16K.
# (The setting name you see here is correct; this information is
internally
# associated with the FMS server cache (FSC) connections.)
#
#com.teamcenter.fms.servercache.FSCConstants.buffSize=64K
• sockBuffSize
Controls the Transmission Control Protocol (TCP) window size in the Java TCP stack, which is used for
reading and writing data from network connections. This size must exceed the BDP (bandwidth delay
product) of the network connection in order to prevent acknowledgment (ACK) response throttling
caused by the TCP window filling with unacknowledged data. To calculate the BDP of a network
connection, multiply the round-trip latency (seconds) by the network bandwidth (bytes per second). A
factor of about 2:1 is needed for reliable high-performance operation.
Following is the commented text for this parameter in the fcc.properties.template file:
# Socket buffer size override.

# Default value is (com.teamcenter.fms.servercache.FSCConstants.buffSize * 2) +
1024.
# The value 0 disables setting the socket buffer sizes (uses system default).
# Minimum value is 8K (excluding the 0 case).
# (The setting name you see here is correct; this information is internally
# associated with the FMS server cache (FSC) connections.)

© 2021 Siemens
Introduction to auditing FSCs
#
#com.teamcenter.fms.servercache.FSCConstants.sockBuffSize=129K
Tip:
To add these parameters to the fcc.properties file, open the fcc.properties file in the FMS_HOME
directory. Copy the parameter to the file and remove the comment character (#) from the line
containing the parameter. If the fcc.properties file does not exist, copy the fcc.properties.template
file to the FMS_HOME directory and rename it as fcc.properties.
The buffSize and sockBuffSize parameters can also appear in the fsc.properties file, the
fsc.clientagent.properties file, or the fscadmin.properties.template file.
When determining the socket buffer size, use the largest BDP of all of the other FMS modules (FSCs and
FCCs) to which this FMS module connects. For example, an FSC server that connects to clients over a
BDP=600MB LAN and other FSCs over a BDP=100KB WAN should use the 600MB LAN value to determine
the socket buffer size.
The socket buffer size is typically set to twice the internal buffer size plus a little more. This is reflected in
the default value. The internal buffer size should be a little less than half of the socket buffer size, but
nonetheless, a convenient multiple of the local disk sector size. This value should definitely never be
more than the socket buffer size. The minimum socket buffer size should be determined by the local
hard disk rather than the network connection (which functions correctly when the TCP window size is
too big).
Consider this example:
Round-trip latency = 750ms

Bandwidth = 400 Mbits/sec
BDP = 750ms * (400 Mbits/sec) * (1 sec/1000 ms) * (1 byte/10 bits) = 300000 / 10000 = 30 MBytes
If the BDP is 30 MBytes, make the socket buffer size a little larger, and the socket buffer size roughly half
of that. But 15 MB (half of the BDP) is not a multiple of the hard disk sector size (4MB in this hypothetical
case), so make the internal buffer size 16 MB. This makes the socket buffer size about (twice 16 is 32
MB, plus a little more), or say, 33 MB.
Note:
For the byte/bits setting, allow 10 bits per byte to account for 8 data bits plus start/stop bits on
network media.
Auditing FSCs
Introduction to auditing FSCs
Teamcenter provides flexible and detailed auditing of FSC access and operations. The primary purpose
of this auditing functionality is to track system access for security purposes. It also allows monitoring of

© 2021 Siemens
the servers for operational purposes and can be used to debug or verify complex FMS system
interactions.
After FSC audit logging is configured, the audit logs are written to FSC_HOME\logs\FSC\process
\fscid_audit.log files.
As server requests are processed, each request is identified by a transaction ID. The audit log output is
generated as the requests are processed by the server. A single request/transaction can propagate across
various FSC servers. However, they are easily identified and correlated in all of the participating FSC
audit log files.
You can import the audit log information into standard text or word processors for correlation and
examination.
Teamcenter provides configurable audit points for different types of processing:
• Request
Identified by request in the audit log. It is at the top of the request processing chain before any
routing within the server. It can render HTTP request information, the transaction ID, and ticket
information if it is provided with the request. Request information can include HTTP request headers,
remote address, and so forth.
• Primary operation start

Identified by priopstart text in the audit log. This is the primary operation starting audit point. It
signals a ticketed operation start event. It can render the same information as the request audit point.
It includes a short description of the operation indicating how the request is being processed.
• Primary operation stop

Identified by priopstop text in the audit log. This is encountered once a primary request is finished
processing. All request and operation start renderers are available as well as operation stop and
response renderers.
• Subordinate operation start

Identified by subopstart text in the audit log. This is a subordinate operation starting audit point. It
can render the same information as the request audit point. It includes a short description of the
operation indicating how the request is being processed. Tickets in subordinate operations may differ
from the tickets used in primary operation tickets.
• Subordinate operation stop

Identified by subopstop in the audit log. This is processed once a subordinate operation is finished
processing. All request and operation start renderers are available as well as operation stop and
response renderers.
• Web operation start

Identified by webopstart text in the audit log. This is a simple web server-like operation start audit
point, such as a configuration download, favicon request, or other non-ticketed requests. It can
render request information, such as a header, remote address, and the transaction ID. The operation
indicates how the request is processed.

© 2021 Siemens
Enable FSC audit logging
• Web operation stop

Identified by webopstop text in the audit log. This is processed after a simple web server-like
operation has finished processing. All operation start renderers are available as well as operation stop
and response renderers.
If all audit points are enabled, the simplest request generates at least three audit log outputs. Ticketed
requests include request, priopstart, and priopstop audit points. Non-ticketed requests include
request, webopstart, and webopstop audit points.
You can configure only the audit points desired. You can also configure only the information of interest
for output. For example, for minimal output, all audit points can be disabled except for priopstop and
webopstop. This provides information on each request without generating multiple output lines for
each request. This does not show subordinate operations because they are not a concern.
Enable FSC audit logging
You must configure audit logging in the fmsmaster file and cycle the configurations for them to take
effect. Audit logs can become huge very quickly; therefore, tuning the log4j configuration and
providing buffering after you enable logging can prevent disk space and performance issues.
1. Determine the audit points and fields/renderers that address your security or operational concerns.
2. Define the format to use for each audit point by adding log properties to the fscdefaults
elements in the fmsmaster configuration file. The configurations must be cycled to take effect.
3. Enable the audit loggers using fscadmin commands, for example:
fscadmin -s http://myserver:4544 FSC_MYSERVER_user1
4. Inspect the logs to ensure the formats are parsed as expected.
5. Run some sample use cases to verify the output is sufficient.
6. Modify the log4j.xml file to permanently set the audit logger level to info and tune the log4j
configuration if required.
FSC audit log properties
There is one fscdefaults element property used to configure the field delimiter in the audit file output,
and seven fscdefaults properties used to configure each audit point output. Any audit point that does
not contain a value does not generate output.
To allow the FSCs to consume the same tools, all FSCs in the system must share the same audit log
configuration. Ensure that all FSCs use the same audit configuration by defining the fscdefaults
elements at the fmsenterprise level in the fmsmaster_fscid.xml configuration file; then set the
overridable attribute on the properties to false.

© 2021 Siemens
• FSC_AuditLogDelimiter
Specifies the delimiter used to separate audit field output in the audit log file. This can be a single or
multicharacter value. The default value is the unique |,| character sequence. This is used because it is
not found in any of the data and therefore is reliable when used to separate fields.
• FSC_AuditLogRequestFormat
Specifies a comma-separated list of format specifications (or renderers) for the request audit point.
• FSC_AuditLogPrimaryOperationStartFormat
Specifies a comma-separated list of format specifications for the primary operation start audit point.
Primary relates to ticketed operations.
• FSC_AuditLogPrimaryOperationStopFormat
Specifies a comma-separated list of format specifications for the primary operation stop audit point.
• FSC_AuditLogSubordinateOperationStartFormat
Specifies a comma-separated list of format specifications for the subordinate operation start audit
point.
• FSC_AuditLogSubordinateOperationStopFormat
Specifies a comma-separated list of format specifications for the subordinate operation stop audit
point.
• FSC_AuditLogWebOperationStartFormat
Specifies a comma-separated list of format specifications for the web operation start audit point.
These are non-ticketed requests, for example, FCC configuration downloads.
• FSC_AuditLogWebOperationStopFormat
Specifies a comma-separated list of format specifications for the web operation stop audit point.
The following example fscdefaults element shows the use of log properties:
fscdefault example:
<fscdefaults>

<property name="FSC_AuditLogDelimiter" value="|,|" overridable="false"/>
<property name="FSC_AuditLogRequestFormat" value="Text(request),
PrimaryTransactionID,
RequestRemoteAddr, RequestHeader(X-Route), RequestHeader(User-Agent),
RequestLine, RequestHeader(Range)" overridable="false"/>
<property name="FSC_AuditLogPrimaryOperationStartFormat" value="Text(priopstart),
PrimaryTransactionID, Operation, RequestMethod, RequestRemoteAddr,
RequestHeader(X-Route), RequestHeader(User-Agent), RequestHeader(Range),
TicketVersion, TicketAccessMethodNice, TicketIsBinaryNice,
TicketSignature,
TicketExpiresTime, TicketUserID, TicketSiteID, TicketGUID,
TicketFilestoreIDs, TicketRelativePath" overridable="false"/>
<property name="FSC_AuditLogPrimaryOperationStopFormat" value="Text(priopstop),
PrimaryTransactionID, StatusCode, Message,
ResponseHeader(Content-Encoding),
TargetBytes, ActualBytes, ResponseStreamStatus, DeltaMS"

© 2021 Siemens
FSC audit log format specifications
overridable="false"/>
<property name="FSC_AuditLogSubordinateOperationStartFormat"
value="Text(subopstart),
TransactionID, Operation, TicketVersion, TicketAccessMethodNice,
TicketIsBinaryNice, TicketSignature, TicketExpiresTime, TicketUserID,
TicketSiteID, TicketGUID, TicketFilestoreIDs, TicketRelativePath"
<property name="FSC_AuditLogSubordinateOperationStopFormat" value="Text(subopstop),
TransactionID, StatusCode, Message, DeltaMS" overridable="false"/>
<property name="FSC_AuditLogWebOperationStartFormat" value="Text(webopstart),
PrimaryTransactionID, Operation, RequestMethod, RequestRemoteAddr,
RequestHeader(User-Agent), RequestLine" overridable="false"/>
<property name="FSC_AuditLogWebOperationStopFormat" value="Text(webopstop),
PrimaryTransactionID, StatusCode, Message,
ResponseHeader(Content-Encoding),
TargetBytes, ActualBytes, ResponseStreamStatus, DeltaMS"
</fscdefaults>
Format specifications, also known as field renderers, determine the content of the log file. Some are
simple and render a single value into the log. These values may come from transactional information,
request or response headers, or even a string constant. Others are more complex and provide some
analysis. For an example, see the ResponseStreamStatus field renderer. Any renderer can be specified
in any audit point but may not be able to produce useful information. They are grouped depending on
how they are intended to be used.
• General renderers
Available on all audit points.
Text(...) Renders the constant value provided between the parentheses. All white space is
ignored. This is used to identify the audit point type. Examples are priopstart,
subopstop, and so forth, but could be anything in your environment.
• Request related renderers

Available on all audit points.
RequestLine Renders the HTTP request line as presented to the server.
RequestMethod Renders the HTTP request method (PUT, GET, POST, and so forth).
RequestRemoteAddr Renders the request (client) IP address.
RequestHeader(…) Renders the value of any request header. The request name is provided
between the parentheses.
PrimaryTransactionID Shows the base (primary) transaction ID that can be used to track and
correlate a request though the FMS system.
• Ticket related renderers

Available whenever a ticket is available at the given audit point.

© 2021 Siemens
TicketAccessMethod Renders the numeric access the ticket provides (2, 4, and so forth; see
TicketAccessMethodNice).
TicketAccessMethodNi Renders the numeric access the ticket provides (see
ce TicketAccessMethod) into easily understood access names: READ,
WRITE, ADMINREAD, ADMINWRITE.
TicketExpiresTime Renders the ticket expiry time in coordinated universal time (UTC).
TicketFileName Renders the file name included in the ticket if there is one.
TicketFilestoreIDs Renders the list of filestore IDs (volume IDs) referenced in the ticket.
TicketGUID Renders the file GUID.
TicketIsBinary Renders the binary flag for the ticket as T or F (see TicketIsBinaryNice).
TicketIsBinaryNice Renders the binary flag (see TicketIsBinary) for the ticket in a string as
TEXT or BINARY.
TicketRaw Renders the entire content of the ticket.
TicketRawURLEncoded Renders the entire content of the ticket in URL encoded form.
TicketRelativePath Renders the relative path and file name included in the ticket based from
the volume root.
TicketSignature Renders the signature of the ticket.
TicketSiteID Renders the site ID that generated the ticket. This is the same as the
fmsenterprise ID.
TicketUserID Renders the user ID (userid value) that generated the ticket.
TicketVersion Renders the ticket version related to the encryption key as v100, F100, or
M050.
• General operation renderers

Available on stop and start audit points.
Operation Renders a short description of the operation the FSC is performing.
TransactionID For subordinate audit points, renders the transaction ID of the subordinate action
with additional decoration to identify the nth subordinate call. For primary audit
points, it is the same as the PrimaryTransactionID renderer.
• Operation stop renderers

Available on stop audit points.
DeltaMS Renders the delta time in milliseconds from start to stop audit points.
StatusCode Renders the resulting status code; it may be an HTTP status or an FSC error code.
Message Renders the resulting message; it may be the HTTP status message or some form of
error text.

© 2021 Siemens
TargetBytes Renders the target bytes of the operation. If the value is not known, the output is
-1.
ActualBytes Renders the actual bytes of the operation. If the value is not known, the output is
-1.
• Response related renderers that require a complete HTTP response

Available only on priopstop and webopstop audit points.
ResponseHeader(...) Renders the value of any HTTP response header. The name is provided
between the parentheses.
ResponseStreamStatus Renders the status of the response stream. This renderer attempts to
detect if a client’s stream was downloaded completely or truncated. The
possible outputs are UNKNOWN, COMPLETE, or TRUNCATED.
Any renderer can be included in any audit point output, although it may not be useful. Format errors,
such as unknown renderer names (misspellings), do not cause configuration load errors, but the audit
log output contains FORMATERROR in the problem fields.
Fields that do not have required information present, such as ticket-related renderers when no ticket is
present, generally result in null in the output for that field in the audit log.
The first output to the audit log writes the current formatting for all enabled audit points. The
formatting is also output whenever the audit configuration changes. It does not contain information
about audit points that have no formatting configured and are therefore disabled.
The following is a sample audit log format output:
INFO - 2012/01/26-07:54:51,365 UTC - myhost123 - Active audit entry formats:
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(request)|,|PrimaryTransactionID

|,|RequestRemoteAddr|,|RequestHeader(X-Route)|,|RequestHeader(User-Agent)|,|RequestLine|,
|RequestHeader(Range)|,|
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(priopstart)|,|PrimaryTransactio

nID|,|Operation|,|RequestMethod|,|RequestRemoteAddr|,|RequestHeader(X-Route)|,|RequestHea
der(User-Agent)|,|RequestHeader(Range)|,|TicketVersion|,|TicketAccessMethodNice|,|TicketI
sBinaryNice|,|TicketSignature|,|TicketExpiresTime|,|TicketUserID|,|TicketSiteID|,|TicketG
UID|,|TicketFilestoreIDs|,|TicketRelativePath|,|
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(priopstop)|,|PrimaryTransaction

ID|,|StatusCode|,|Message|,|ResponseHeader(Content-Encoding)|,|TargetBytes|,|ActualBytes|
,|ResponseStreamStatus|,|DeltaMS|,|
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(subopstart)|,|TransactionID|,|O

peration|,|TicketVersion|,|TicketAccessMethodNice|,|TicketIsBinaryNice|,|TicketSignature|
,|TicketExpiresTime|,|TicketUserID|,|TicketSiteID|,|TicketGUID|,|TicketFilestoreIDs|,|Tic
ketRelativePath|,|
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(subopstop)|,|TransactionID|,|St

atusCode|,|Message|,|DeltaMS|,|

© 2021 Siemens
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(webopstart)|,|PrimaryTransactio

nID|,|Operation|,|RequestMethod|,|RequestRemoteAddr|,|RequestHeader(User-Agent)|,|Request
Line|,|
INFO - 2012/01/26-07:54:51,378 UTC - myhost123 - |,|Text(webopstop)|,|PrimaryTransaction

ID|,|StatusCode|,|Message|,|ResponseHeader(Content-Encoding)|,|TargetBytes|,|ActualBytes|
,|ResponseStreamStatus|,|DeltaMS|,|
The following is sample audit log output based on the previous configuration:
INFO - 2012/01/26-07:54:51,379 UTC - myhost123 - |,|request|,|(-7316198962075068416)fsc

_s6|,|127.0.0.1|,|null|,|FMS-FSCJavaClientProxy/8.2 (bd:20120119)|,|GET /mapClientIPToFS
Cs?client= HTTP/1.1|,|null|,|
INFO - 2012/01/26-07:54:51,380 UTC - myhost123 - |,|webopstart|,|(-7316198962075068416)

fsc_s6|,|BootstrapHandler|,|GET|,|127.0.0.1|,|FMS-FSCJavaClientProxy/8.2 (bd:20120119)|,
|GET /mapClientIPToFSCs?client= HTTP/1.1|,|
INFO - 2012/01/26-07:54:51,381 UTC - myhost123 - |,|webopstop|,|(-7316198962075068416)f

sc_s6|,|200|,|OK|,|null|,|57|,|57|,|COMPLETE|,|1|,|
INFO - 2012/01/26-07:54:51,384 UTC - myhost123 - |,|request|,|(-7316198962075068415)fsc

_s6|,|127.0.0.1|,|null|,|FMS-FSCAdmin/8.2 (bd:20120125) Java/1.5.0_11|,|GET / HTTP/1.1|,
|null|,|
INFO - 2012/01/26-07:54:51,385 UTC - myhost123 - |,|priopstart|,|(-7316198962075068415)

fsc_s6|,|CacheCommands$ClearCommand|,|GET|,|127.0.0.1|,|null|,|FMS-FSCAdmin/8.2 (bd:2012
0125) Java/1.5.0_11|,|null|,|v100|,|ADMINREAD|,|BINARY|,|739388a12ef48c3473e19bd78049661
6b989cf3b8bab1f5d5dfd0bb22a7d71db|,|2012/01/26 07:56:51|,|FSCAdmin|,||,|noguid
|,|[]|,|./clearcache|,|
INFO - 2012/01/26-07:54:51,388 UTC - myhost123 - |,|priopstop|,|(-7316198962075068415)f

sc_s6|,|200|,|OK|,|null|,|17|,|17|,|COMPLETE|,|3|,|
INFO - 2012/01/26-07:55:14,180 UTC - myhost123 - |,|request|,|(-362480191128027786)fsc_

s7[1]>fsc_s6|,|127.0.0.1|,|fms.teamcenter.com^fsc_s7,fms.teamcenter.com^fsc_s6|,|FMS-FSC
/8.2 (bd:20120125) Java/1.5.0_11|,|GET /tc/fms/fms.teamcenter.com/g2/fsc_s6 HTTP/1.1|,|n
ull|,|
INFO - 2012/01/26-07:55:14,180 UTC - myhost123 - |,|priopstart|,|(-362480191128027786)f

sc_s7[1]>fsc_s6|,|CoordinatorVolumeState|,|GET|,|127.0.0.1|,|fms.teamcenter.com^fsc_s7,f
ms.teamcenter.com^fsc_s6|,|FMS-FSC/8.2 (bd:20120125) Java/1.5.0_11|,|null|,|v100|,|ADMIN
READ|,|BINARY|,|ca124695734bb33ee6e65ba0fdbc087587214de0b43d8da2c2eb8353a3d92e89|,|2012/
01/26 07:57:11|,|nouser|,||,| |,|[]|,|fsc_s6/config/volum
estate/nvargs/action=get;enterpriseid=fms.teamcenter.com|,|
INFO - 2012/01/26-07:55:14,181 UTC - myhost123 - |,|priopstop|,|(-362480191128027786)fs

c_s7[1]>fsc_s6|,|200|,|OK|,|null|,|6|,|6|,|COMPLETE|,|1|,|
The following figure shows a sample format specification for a primary start operation that can be used
to track access to a dataset files by users, the associated portion of the format output, and the resulting
portion in the log file output for a sample transaction.

© 2021 Siemens
FSC audit log transaction IDs
The TicketFileName and TicketUserID renders are added to the format specification as shown in the
top section. This results in the user ID and accessed file name values in the output file as shown in the
bottom section. You may also notice the file name value appears in the output for the
TicketRelativePath render, making it unnecessary to include the TicketFileName render in this
instance.
FSC audit log transaction IDs
Transaction IDs are the key to associating all the audit information together across the FMS network.
Early in the request processing, the FSC looks for a transaction ID in the request headers. If it finds one,
it appends the local FSC ID and uses that as its base transaction ID. If a previous one is not found, it
increments an internal count and appends its FSC ID. The internal count starts based on a secure
random number.
There is no guarantee duplicate IDs are not generated, but given the range of a 64-bit value collisions,
duplicates are very rare and even more unlikely in close proximity in time. When you search for
transactions, if a collision occurs, the timestamps can be used to identify the different transactions.
Any suboperation appends [n+1] to the end of each transaction ID. A transaction ID supplies exact
information on how a request is routed though the network. The following is an example of how a
transaction ID propagates through a number of servers and shows the resulting transaction ID
information.
Given the following FSCs:

© 2021 Siemens
FSC_emdbangfms_tcdba
FSC_spandfms_tcdba
FSC_flodup_tcdba
FSC_yagmlsp_tcdba
FSC_wndisxk_tcdba
1. The first FSC (FSC_emdbangfms_tcdba) generates a new ID.
(342342349932)FSC_emdbangfms_tcdba
It then performs a subordinate operation (subop), appends [1] to the transaction ID, and sends the
request.
(342342349932)FSC_emdbangfms_tcdba[1]
2. The next FSC (FSC_spandfms_tcdba) receives and joins the existing transaction ID.
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba
It then performs a subop.
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]
3. A third FSC (FSC_flodup_tcdba) receives and joins the existing transaction ID.
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]>FSC_flodup_tcdba
It then performs a subop.
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]>FSC_flodup_tcdba[1]
And another subop.
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]>FSC_flodup_tcdba[2]
4. The forth FSC (FSC_yagmlsp_tcdba) received the prior subop ([1]).
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]>FSC_flodup_tcdba[1]>
FSC_yagmlsp_tcdba
5. A fifth FSC (FSC_wndisxk_tcdba) received the prior subop ([2]).
(342342349932)FSC_emdbangfms_tcdba[1]>FSC_spandfms_tcdba[1]>FSC_flodup_tcdba[2]>
FSC_wndisxk_tcdba
This shows that the transaction ID on any server provides an indication of the path through the network.

© 2021 Siemens
Introduction to configuring FMS for HTTPS
Even if intermediate FSCs do not have auditing enabled, transaction IDs are still generated or
propagated along with the requests.
Configuring FMS
Configuring FMS for HTTPS
Introduction to configuring FMS for HTTPS
You can configure File Management System (FMS) to use either the hypertext transfer (HTTP) protocol
or a secure server layer (HTTPS) protocol. You set the protocol during installation from Teamcenter
Environment Manager (TEM), using the FSC Non-Master Settings panel and the Proxy tab in the File
Client Cache panel. HTTPS creates a secure channel over an insecure network. This protection method
uses verified and trusted server certificates, private keys (your keystore), and public keys (the certificate
signing request).
If you select HTTPS as your protocol during Teamcenter installation, you are prompted to supply the
appropriate proxy, host, and port information. You are also asked whether you want to add the URL of
the local host to the list of servers defined in the Fms_BootStrap_Urls preference. Your only
postinstallation tasks are generating a keystore and key entry and generating a certificate signing
request. (If you upgrade from a previous version of Teamcenter, you must transfer all the HTTPS
certificate information to the upgraded Teamcenter installation.)
If you select HTTP as your protocol during Teamcenter installation, but sometime after installation, you
must configure FMS to use HTTPS, you must:
• Use a trusted certificate to generate a keystore and key entry.
• Generate a certificate signing request (CSR).
• Modify the FMS primary configuration file to reflect the new HTTPS addresses.
• Add the URL of the local HTTPS host to the list of servers defined in the Fms_BootStrap_Urls
preference.
• Update any installed FCCs.
The protection inherent in HTTPS is based on a major certificate authority guaranteeing that your web
server is the entity it claims. This is accomplished by your site providing a valid certificate indicating it
was signed by a trusted authority. To work with a trusted authority you must:
• Create a key pair, keeping the private key secret.
• Generate a CSR.
Trusted certificates are purchased from third-party certificate vendors, such as VeriSign or Thawte.

© 2021 Siemens
Note:
Using untrusted (self-signed) certificates requires additional configuration to either import the
certificate into the client certificate keystores, or to modify FMS properties to permit clients to
connect to servers using self-signed certificates. Siemens Digital Industries Software does not
recommend using self-signed certificates.
Configure FMS for HTTPS
You can configure FMS to use either the hypertext transfer (HTTP) protocol or a secure server layer
(HTTPS) protocol. You set the protocol during installation from the FSC Non-Master Settings and FCC
Settings panels in Teamcenter Environment Manager (TEM).
Note:
If you chose the HTTPS protocol for FMS during installation, you are prompted to supply the
appropriate proxy, host, and port information. You are also asked whether you want to add the
URL of the local host to the list of servers defined in the Fms_BootStrap_Urls preference.
The only post installation tasks required to implement HTTPS is generating a keystore and key
entry and generating a certificate signing request.
If you chose the HTTP protocol for FMS during installation and now want to use the HTTPS protocol, you
must:
• Modify the FMS primary configuration file to reflect the new HTTPS addresses.
The fmsmaster_fscid.xml is located in the TC_ROOT\fsc directory.
Update the fsc address in the FMS primary configuration file as follows:

<fmsworld>
<fmsenterprise id="471539747">
<fsc id="FSC_myhost_userid"
address="https://myhost.mycompany.com:4545">
<volume id="139747566d871c1b2023"
root="/mnt/disk1/tcapps/tc/TC_VOL/volume1"/>
<transientvolume id="ce8399515feada2dee4c3e79b955d8ba"
root="/tmp/transientVolume_tc_userid"/>
</fsc>
<clientmap subnet="127.0.0.1" mask="0.0.0.0">
<assignedfsc fscid="FSC_myhost_userid"/>
</clientmap>
</fscgroup>
</fmsenterprise>
</fmsworld>
• Add the URL of the local HTTPS host to the list of servers defined in the Fms_BootStrap_Urls
preference.

© 2021 Siemens
Keystores and key entries
• Update any installed FCCs.

FCC installations contain configuration files that point to FSC servers. When you change the FSC
servers to support HTTPS, you must also revise the parentfsc address in the fcc.xml file to the new
protocol. The fcc.xml file is located in the FMS_HOME directory (for example, TC_ROOT\tccs).
1. In the fcc.xml file, update the parent FSC address. For example:
<parentfsc address="https://myhost.mycompany.com:4545/tc/fms/471539747"/>
2. Restart the system.
Keystores and key entries
To implement HTTPS for FMS, you must generate a keystore and key entry, and then generate a
certificate signing request (CSR) from the private key.
Siemens Digital Industries Software recommends using a trusted certificate, purchased from a third-
party vendor, when configuring FMS to use HTTPS.
Note:
The certificate authority's root certificates for your purchased certificates must include standard
distributions of Sun Microsystems' Java run-time environment. This is usually the case for
certificates purchased from well-known certificate authorities.
Use the following elements to create a keystore.
Element Description
keystore Specifies the keystore file name.
This is the Java-based storage standard. Public and private keys are stored in an
encrypted keystore. Individual keys within this cryptographic storage may also
have individual password protection.
keystore.password Specifies the keystore password. The password is required to open or manage
the keystore.
The standard entry is changeit.
FSC_myhost Specifies an alias name for the certificate.
The certificate is bound to the host; name it accordingly. A similar convention
FSC_host_userid is used by installers to name configuration files.
FSC_myhost.password Specifies the certificate (alias) password required to retrieve the certificate.
FSC_myhost.csr Specifies the name of the certificate signing request (CSR) file. The file contains
the CSR information and is sent to the signing authority.
FSC_myhost.cer Specifies the certificate file. This is the file returned by the signing authority.

© 2021 Siemens
Use the trusted certificate to create a keystore in your FSC_HOME directory.
Generate a keystore and key entry
1. Run the following command to create a keystore and private key in your FSC_HOME directory:
>keytool -genkey -keystore keystore -keyalg RSA -alias FSC_myhost
2. Complete each question prompted by the command. For example:
>keytool -genkey -keystore keystore -keyalg RSA -alias FSC_myhost

Enter keystore password: keystore.password
What is your first and last name?
[Unknown]: myhost.mydomain.com
What is the name of your organizational unit?
[Unknown]: mycompany
What is the name of your organization?
[Unknown]: mycompany
What is the name of your City or Locality?
[Unknown]: mycity
What is the name of your State or Province?
[Unknown]: mystate
What is the two-letter country code for this unit?
[Unknown]: my
Is CN=myhost.mydomain.com, OU=mycompany, O=mycompany, L=mycity, ST=mystate, C=my correct?
[no]: yes
Enter key password for <FSC_myhost>
(RETURN if same as keystore password): FSC_myhost.password
3. Run the following command to confirm that you can read the file and view the key entry:
>keytool -list -keystore keystore
>keytool -list -keystore keystore

Keystore type: jks

Keystore provider: SUN
Your keystore contains 1 entry
fsc_myhost, Nov 8, 2007, keyEntry,

Certificate fingerprint (MD5): 59:B6:2D:38:24:16:45:1B:47:2A:E9:06:55:80:B3:C6
5. Create a copy of the keystore file and keep it in a secure location.
Caution:
The private key stored in the keystore is not recoverable if the file or passwords are lost.

© 2021 Siemens
Create a certificate signing request (CSR)
Create a certificate signing request (CSR)
The certificate signing request (CSR) is the message sent from your site to a certificate authority in order
to apply for a digital identity certificate. The CSR is the public key generated on your server that validates
your web server/organization data when you request a certificate from your third-party certificate
vendor.
After creating a CSR, follow the process required by your certificate signing authority to obtain your
signed certificate.
1. Run the following command to create a CSR from your private key:
>keytool -certreq -keystore keystore -alias FSC_myhost -file FSC_myhost.csr
>keytool -certreq -keystore keystore -alias FSC_myhost -file FSC_myhost.csr

Enter key password for <FSC_myhost> FSC_myhost.password
3. Locate the CSR file. This is the file you must submit to the certificate signing authority. For
example:
-----BEGIN NEW CERTIFICATE REQUEST-----

MIIBtjCCAR8CAQAwdjELMAkGA1UEBhMCbXkxEDAOBgNVBAgTB215c3RhdGUxDzANBgNVBAcTBm15
Y2l0eTESMBAGA1UEChMJbXljb21wYW55MRIwEAYDVQQLEwlteWNvbXBhbnkxHDAaBgNVBAmTE215
aG9zdC5teWRvbWFpbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJ0h3iF8KBEN2UKw
hw1dw+RlxGwcsptLA3EI+6rAKa32dg/4FY89zBcUG02413X0BxQWcsRznYWFDJHLK4En7I2xeJNs
ORwJfBeF9yW6d4lzaWA6LATFr5T3DHafF6mSRNPl+739mpGuQr44AXBQWqZoOMhecc+n/ErekMlZ
dgWTAgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQCQJTqujL7GIXz0is0fUoAxtCydMiX1BeVHU+l/
IqcTh4BX8V3vJmm+kHwwKn3yeih+WJzYmDdNh/uaKxO7txyFdPPDd1bdIosFc4XIZwys0jFKwGqf
MUjB9wgaKgHSRQTtCOPBEO/ClLjm8ocFNQBWysYVevAZQAmEMp90BxBt/Q==
-----END NEW CERTIFICATE REQUEST-----
Importing certificates into the FSC keystore
After obtaining the signed certificate from your certificate signing authority, you must import it into the
keystore.
1. Run the following command to import the signed certificate:
>keytool -import -trustcacerts -keystore keystore -file FSC_myhost.cer -alias FSC_myhost
>keytool -import -trustcacerts -keystore keystore -file FSC_myhost.cer -alias FSC_myhost

Enter key password for FSC_myhost FSC_myhost.password

© 2021 Siemens
3. Verify the keystore.FSC_host_userid file in the FSC_HOME directory. The keystore must contain
the private key and certificate for the local machine. For example:
myhost> keytool -list -v -keystore

keystore.FSC_myhost_userid.jks -storepass keystore.FSC_myhost_userid.password
Keystore type: jks

Keystore provider: SUN
Your keystore contains 1 entries
Alias name: myhost.mycompany.com

Creation date: Jan 23, 2008
Entry type: keyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=myhost.mycompany.com, OU=QA, O=YOUR Corp, L=Plano, ST=Texas, C=US
Issuer: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA,
OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape,
C=ZA Serial number: 485099dcc36d1ea9d773ba153022a951
Valid from: Thu Jan 10 16:44:38 CST 2008 until: Thu Mar 27 13:20:25 CDT 2008 Certificate
fingerprints:
MD5: 86:7E:16:59:99:E6:6F:B6:27:9B:92:19:E7:65:EB:A2
SHA1: 6A:D1:64:7A:0A:E1:CB:62:D3:EF:91:BF:E9:A0:CE:AF:A3:3D:E4:1E
Certificate[2]:
Owner: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA,
OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town,
ST=Western Cape, C=ZA, Issuer: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium
Server CA
OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape,
C=ZA Serial number: 1
Valid from: Wed Jul 31 19:00:00 CDT 1996 until: Thu Dec 31 17:59:59 CST 2020 Certificate
fingerprints:
MD5: 06:9F:69:79:16:66:90:02:1B:8C:8C:A2:C3:07:6F:3A
SHA1: 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A
*******************************************
*******************************************
4. Update the fsc.FSC_host_userid.properties file in the FSC_HOME directory with the keystore and
key entry information. For example:
# fsc.FSC_myhost_userid.properties
com.teamcenter.fms.servercache.keystore.file=${FMS_HOME}/keystore.FSC_myhost_userid.jks
com.teamcenter.fms.servercache.keystore.password=keystore.FSC_myhost_userid.password
com.teamcenter.fms.servercache.keystore.ssl.certificate.password=
keystore.FSC_myhost_userid.password
# these are not needed for 1-way SSL
javax.net.ssl.keyStore=${FMS_HOME}/keystore.FSC_myhost_userid.jks
javax.net.ssl.keyStorePassword=keystore.FSC_myhost_userid.password
javax.net.ssl.trustStore=${FMS_HOME}/keystore.FSC_myhost_userid.jks
javax.net.ssl.trustStorePassword=keystore.FSC_myhost_userid.password

© 2021 Siemens
Best practices for configuring PKI authentication for FMS
Configuring PKI authentication for FMS
Best practices for configuring PKI authentication for FMS
You can configure public key infrastructure (PKI) authentication for FMS to authorize fscadmin
commands. This authentication prevents offsite administrators (such as administrators at supplier sites)
from performing unauthorized FSC administrative commands.
Use PKI authentication to specify which fscadmin commands require additional signing, allowing you to
control the functionality available for specified servers and installations.
Use the following best practices for optimal security.
• Password conventions
Use strong passwords.
Do not use passwords vulnerable to dictionary attacks.
Do not use password patterns that can be easily guessed if one password is compromised.
Use different passwords for each keystore and key.
Use only encrypted passwords in property files.
Use only characters that can be reliably and repeatedly typed (or cut/pasted) into command shells;
avoid characters that make this difficult.
• Keystore conventions
The keystore type must be JCEKS; the keystore file extension must be .jceks.
Use meaningful names, such as trusted.jceks and supplier.jceks and fsc.fscid.signing.jceks.
In each keystore, for each keystorealias element defined in the fmsmaster configuration file, place
either the private key or the public certificate. Each private key requires that a password entry in the
properties file is deployed along with the keystore.
Place only private keys in keystores you plan to deploy to trusted sites.
Consider the keystore and its associated properties file as a pair and name them accordingly, for
example, fsc.fscid.signing.jceks and fsc.fscid.properties.
Siemens Digital Industries Software recommends using scripts to manage keystores, generate key
pairs, export public certificates, and import the public certificates to other keystores. Keep scripts in a
secure location.
• Naming conventions
Use no spaces, commas, equal signs, or colons in the names of keystore aliases.
Use no spaces or commas in the names of policy IDs.
Siemens Digital Industries Software recommends adding a system identifier to aliases, such as the
system ID or site ID. Doing so ensures that over time, as signatures are passed between sites, the
aliases continue to be unique and traceable to the owning site.
Restricting selected fscadmin commands for PKI authentication
Before selecting fscadmin commands for additional authentication, you must first:
• Determine which fscadmin commands you want to restrict.

© 2021 Siemens
This example requires additional authentication for the filestoredetail and cachedetail commands.
• Determine the policy names associated with the restricted commands.

This example defines a single policy (trustedadmin) for both commands. Policy names are arbitrary,
but should be meaningful, such as siteadmins or supplieradmins.
• Determine the key/certificate aliases used to assert a policy.

This example uses ent123.trustedadmin. You can use different keys/certificates for each installation,
though this requires significant keystore management.
The keytool used in this example is from Java JDK 1.5.
1. Create the trusted keystore to hold the private keys.
In this example, this is the keystore deployed to trusted servers and installations.
a. Determine the keystore name.
In this example, the keystore name is trusted.jceks
b. Determine the password used for the keystores.
In this example, the password is trusted.jceks.lp7qZF.password.
c. Determine the password used for individual keys.
In this example, the password is trustedadmin.5oDHfVV.password.
d. Use the keytool to create the keystore and key. For example:
> keytool -storetype jceks -keystore trusted.jceks -storepass trusted.jceks.lp7qZF.password

-genkey -v -keyalg RSA -alias "ent123.trustedadmin" -keypass trustedadmin.5oDHfVV.password
-validity 9999 -dname "CN=FMS trusted admin policy site ent123, OU=org unit, O=org, L=c,
ST=st, C=cc"
Generating 1,024 bit RSA key pair and self-signed certificate (MD5WithRSA)
for: CN=FMS trusted admin policy site ent123, OU=org unit, O=org, L=c, ST=st, C=cc
[Storing trusted.jceks]
e. Use the keytool to export the public certificate. For example:

-export -v -alias "ent123.trustedadmin" -keypass trustedadmin.5oDHfVV.password
-file ent123.trustedadmin.cer
Certificate stored in file <ent123.trustedadmin.cer>
f. Use the keytool to list the contents of the keystore. For example:

© 2021 Siemens

-list -v
Keystore type: jceks

Keystore provider: SunJCE
Alias name: ent123.trustedadmin

Creation date: Jul 10, 2009
Certificate[1]:
Owner: CN=FMS trusted admin policy site ent123, OU=org unit, O=org, L=c, ST=st, C=cc
Issuer: CN=FMS trusted admin policy site ent123, OU=org unit, O=org, L=c, ST=st, C=cc
Serial number: 4a578037
Valid from: Fri Jul 10 13:53:59 EDT 2009 until: Mon Nov 24 12:53:59 EST 2036
Certificate fingerprints:
MD5: 66:6F:67:55:09:CA:04:69:52:76:C8:49:30:30:75:F0
SHA1: E4:74:66:DD:54:C2:0D:4B:D2:AD:74:EA:65:69:89:C7:0F:16:71:49
*******************************************
*******************************************
2. Create the untrusted keystore to contain only public certificates.
In this example, this is the keystore deployed to untrusted servers and installations (such as
supplier sites).
a. Determine the keystore name.
In this example, the keystore name is untrusted.jceks
b. Determine the passwords used for the keystores.
In this example, the password is untrusted.jceks.2TLiFD.password.
c. Use the keytool to create and import the public certificate. For example:
> keytool -storetype jceks -keystore untrusted.jceks -storepass

untrusted.jceks.2TLiFD.password
-import -v -noprompt -trustcacerts -alias "ent123.trustedadmin" -file ent123.trustedadmin.cer
Certificate was added to keystore

[Storing untrusted.jceks]
d. Use the keytool to list the contents of the keystore. For example:
> keytool -storetype jceks -keystore untrusted.jceks -storepass

untrusted.jceks.2TLiFD.password -list -v


© 2021 Siemens

Entry type: trustedCertEntry
MD5: 66:6F:67:55:09:CA:04:69:52:76:C8:49:30:30:75:F0
*******************************************
*******************************************
3. Create and/or modify the FSC property files.
a. Encrypt the keystore and key/alias password values using the passwordtool script. For
example:
> passwordtool -encrypt trusted.jceks.lp7qZF.password
fcLxB/oeZ+IeNnP/vofAqFpDqmJdSyaU0y+EHU0ffRc=
> passwordtool -encrypt trustedadmin.5oDHfVV.password
Bpg2TLiFDni3bT4xS4kyIaLvz5TWGLQ/GPTJN2r5T3s=
> passwordtool -encrypt untrusted.jceks.2TLiFD.password
J168VL0QG4bTbJpcls57lqwc3P42GhTnXWfogeoVWs0=
b. Add the following properties to the fsc.fscid.properties file for trusted installations:
# signing keystore file and password

com.teamcenter.fms.signing.keystore.file=trusted.jceks
com.teamcenter.fms.signing.keystore.epassword=fcLxB/oeZ+IeNnP/vofAqFpDqmJdSyaU0y+EHU0ffRc=
# key password(s) property name form: com.teamcenter.fms.signing.<alias>.epassword
com.teamcenter.fms.signing.ent123.trustedadmin.epassword=Bpg2TLiFDni3bT4xS4kyIaLvz5TWGLQ/
GPTJN2r5T3s=
c. Add the following properties to the fsc.fscid.properties file for untrusted installations:

com.teamcenter.fms.signing.keystore.file=untrusted.jceks
com.teamcenter.fms.signing.keystore.epassword=J168VL0QG4bTbJpcls57lqwc3P42GhTnXWfogeoVWs0=
# none...

© 2021 Siemens
4. Create and/or modify the fscadmin property files by adding the following properties to the
fscadmin.properties file for trusted installations. (No properties need be added for untrusted
installations.)

# default admin ticket signing alias
com.teamcenter.fms.signing.fscadmin.default.alias=ent123.trustedadmin
com.teamcenter.fms.signing.ent123.trustedadmin.epassword=Bpg2TLiFDni3bT4xS4kyIaLvz5TWGLQ/
GPTJN2r5T3s=
5. Modify the fmsmaster configuration file.
a. Add the following elements under the last fmsenterprise element in the file (or after the final
multisiteexport element, if any exist).
In this example, the fscadminpolicies element maps fscadmin commands to policies. The
policy element maps policies to the keystore aliases (in this case, to the keys/certificates).
<fmsworld>
...
<fmsenterprise id="ent123">
...

<policy id="trustedadmin" keystorealiases="ent123.trustedadmin"/>

<fscadminpolicies cmds="filestoredetail,cachedetail" policyids="trustedadmin"/>
...
b. Reload the fmsmaster configuration file by stopping and starting the FSC service or by issuing
an fscadmin config reload command. For example:
> fscadmin -s http://cii6w223:7168 ./config/reload
Initial configuration hash: 9a727fb3215fc5f9bf289cb4db0b164f

Configuration reload successful.
Final configuration hash: efed77c0315fc5f9bf289cb4db0b164f
The fmsmaster configuration file, FSC properties, and signing keystores are read each time
the configuration file is reloaded.
c. Verify the available keys/certificates. Trusted installations should have access to private keys
and public certificates. Untrusted installations should only have access to public certificates.
Use the fscadmin command to perform the verification. For example:
> fscadmin -s http://cii6w223:7168 ./keystoreinfo
Keystore info:
# of private keys: 1, aliases: [ent123.trustedadmin]

© 2021 Siemens
# of secret keys: 0, aliases: []

# of certificates: 1, aliases: [ent123.trustedadmin]
d. Check in the FSC log files. For example:
...
INFO - 2009/07/10-18:38:55,500 UTC - cii6w223 - Keystore info:
# of secret keys: 0, aliases: []
...
6. Test to confirm the selected FSC commands are restricted. The FSC allows an fscadmin command
when a required signature for any certificate for any policy associated with the fscadmin
command is present.
If a required signature is not present, or cannot be validated, the fscadmin command is denied.
a. Use a trusted fscadmin command in a trusted installation. For example:
> fscadmin -s http://cii6w223:7168 ./filestoredetail
*** volume filestores:

*** transient volume filestores:
*** accesson filestores:
Filestore Details: testvolarh---sy2a----bHA, root: e:\workdir\FMSShare\FMSTestExplodedWar
\cr.txt, Len: 771999, Last modified: Mar 18 17:07 EST 2005, Last access: Jul 09 17:17 EDT 009
\crlf.txt, Len: 776010, Last modified: Mar 18 17:06 EST 2005, Last access: Jul 09 17:17 EDT
2009
\FMS_User_Doc_Java.doc, Len: 403456, Last modified: Mar 12 09:23 EDT 2007,
Last access: Mar 19 14:25 EDT 2009
\index.html, Len: 18372, Last modified: Dec 10 15:35:22 EST 2008, Last access: Jul 09
09:09:55 EDT 2009
...
\testfiles - empty
\testvol - empty
Dirs: 270, Files: 9009, Bytes: 19719498212
b. Use a trusted fscadmin command in an untrusted installation. For example:
> fscadmin -s http://cii6w223:7168 ./filestoredetail
Error, server returned status code: 400, status message:

ERROR_SIGNATURE_MISSING_1{filestoredetail}
After confirming the selected fscadmin commands are restricted, manage PKI authorization by:
• Storing a backup of your keystores and passwords in a safe location.
• Creating new keys/certificates and deploying the new keys if you suspect a private key is
compromised.

© 2021 Siemens
Protect the FMS encryption key
• Creating new keystores, creating new keys/certificates, using new passwords, and deploying the new
keystores and property values if you suspect a password is compromised. This causes all previous keys
and passwords to cease working.
For improved security, you can move the FMS encryption key from a clear text file to an encrypted,
password-protected keystore file. Use the keygen script to import the key file into a keystore and the
passwordtool script to generate encrypted passwords based on a clear text password.
The keytool used in this example is from Java JDK 1.5.
Note:
The following procedure describes server-side use. However, if you set up Teamcenter to use
encryption, the JREs on the clients require access to the keystore. For client-side use (two-tier,
four-tier, Teamcenter Environment Manager, and so on), you must make the keystore available to
all clients. For example, put the certificates and keys into the keystore, make the keystore available
in a network location, and propagate the keystore to the clients where it is accessible to the client
JREs.
1. Create the signing keystore to hold the FMS encryption key.
a. Determine the key alias under which you want to store the FMS key.
In this example, the key alias is ent123.tickets.
b. Determine the keystore name.
In this example, the keystore name is trusted.jceks.
c. Determine the passwords used for the keystore.
In this example, the password is trusted.jceks.lp7qZF.password.
d. Determine the password used for the FMS encryption key.
In this example, the password is ent123.tickets.z3nYsY.password.
2. Use the keygen script to create the keystore and key.
In this example, a new key is created. Alternatively, you can import an existing key.
> keygen 128
5706c8eebd67eb754544ab720f08d95b

© 2021 Siemens
3. Import the key. For example:
> keygen -importseckey -keystore trusted.jceks -storepass trusted.jceks.lp7qZF.password

-alias ent123.tickets -keypass ent123.tickets.z3nYsY.password -key
5706c8eebd67eb754544ab720f08d95b
Nothing is returned if it worked.
4. Use the keytool to list the contents of the keystore. For example:

-list -v

Your keystore contains 2 entries
Alias name: ent123.tickets

*******************************************
*******************************************

Certificate[1]:
MD5: 66:6F:67:55:09:CA:04:69:52:76:C8:49:30:30:75:F0
*******************************************
*******************************************
5. Use the keygen script to import the key file into the keystore. For example:
> keygen -importseckey -keystore keystorefilename -storepass keystore.password
-alias alias [-overwrite] [-keypass key.password] [[-k keyfile] | [-key asciihexkey]]

keystore filename must end in .jceks (SecretKeys can only be stored in jceks keystores)
[-keypass key.password] is optional (defaults to storepass value)
[-overwrite] is optional, by default will not allow overwriting an existing key
Either [-k keyfile] or [-key asciihexkey] are required
6. Update any other keystores used by the system.

© 2021 Siemens
7. Create and/or modify the FSC property files.
a. Encrypt the keystore and key/alias password values using the passwordtool script. For
example:
> passwordtool -encrypt trusted.jceks.lp7qZF.password
fcLxB/oeZ+IeNnP/vofAqFpDqmJdSyaU0y+EHU0ffRc=
> passwordtool -encrypt ent123.tickets.z3nYsY.password
vhTHTCLYz9BxE8TN4MpLFNIFkIrDMCfU7mh+pYbqfcw=
b. Add the following properties to the fsc.fscid.properties file:

com.teamcenter.fms.signing.ent123.tickets.epassword=vhTHTCLYz9BxE8TN4MpLFNIFkIrDMCfU7mh
+pYbqfcw=
8. In the fmsmaster configuration file, add the following elements under fscadminpolicies and
before fscdefaults. For example:
<fmsworld>
...
<fmsenterprise id="ent123">
...

...
<ticket version="M050" keystorealias="ent123.tickets" />
<ticket version="v100" keystorealias="ent123.tickets" />
<ticket version="F100" keystorealias="ent123.tickets" />
The system uses the keystorealias attribute to retrieve the password from the properties file and
access the key in the keystore.
9. Confirm the accuracy of the configuration by reloading the fmsmaster configuration file. The FSC
cannot reload the configuration if the ticketing aliases or keys are unavailable for any reason. For
example:
> fscadmin -s http://cii6w223:4544 ./config/reload
Initial configuration hash: efed77c0315fc5f9bf289cb4db0b164f

Configuration reload successful.
Final configuration hash: ac718b9778cbcfebcabea266b3c1155a
10. Restart the FSC.
The ticketing keys are applied.

© 2021 Siemens
11. Create and/or modify the fscadmin property file by adding the following properties. Use the same
encrypted passwords as generated previously. For example:

# default fms ticket signing alias
com.teamcenter.fms.signing.tickets.alias=ent123.tickets
com.teamcenter.fms.signing.ent123.tickets.epassword=vhTHTCLYz9BxE8TN4MpLFNIFkIrDMCfU7mh
+pYbqfcw=
12. Use the fscadmin command to confirm that the keys/certificates are available. For example:
Keystore info:
# of secret keys: 1, aliases: [ent123.tickets]
13. Check in the FSC log files. For example:
...
INFO - 2009/07/10-18:38:55,500 UTC - cii6w223 - Keystore info:
# of secret keys: 1, aliases: [ent123.tickets]
...
Any keys that cannot be loaded are listed in the FSC log files. For example:
java.security.UnrecoverableEntryException
at java.security.KeyStoreSpi.engineGetEntry(KeyStoreSpi.java:455)
at java.security.KeyStore.getEntry(KeyStore.java:1218)
...
14. Verify that the key has been moved by running the FSC. If the FSC runs normally, reports that the
secret key is available, and the fscadmin command works, then the move is successful.
If the configuration is incorrect, either the FSC does not reload, or the secret key is not listed, or the
fscadmin command gives the following error:
Error, server returned status code: 400, status message: TICKET_VALIDATION_FAIL_0
15. Delete the previous clear text key file after verifying the fscadmin command and FSC are
successfully using the keystore.
After confirming the encryption key has been successfully moved to the keystore file, manage it by:

© 2021 Siemens
File scanning process
• Storing a backup of your keystores and passwords in a safe location.
• Creating a new encryption key and deploying new keystores if you suspect the encryption key is
compromised.
Configuring file scanning during upload
File scanning process
You may allow suppliers to connect to existing File Management System (FMS) networks and to upload
files into FMS volumes. As suppliers connect to your network from other companies and networks, the
Teamcenter destination site loses control of the safety of uploaded files. Configuring FMS to scan files
for viruses as they are being uploaded, and to reject uploads that fail the check, protects your internal
system from potential viruses.
The following shows a basic topology for a virus scan configuration. (This is not a required configuration
but represents a common configuration that many sites may employ.)
You can configure a quarantine volume on an FMS server cache (FSC) server to invoke a third party virus
scanner on files being uploaded through it. This configuration allows uploaded files to be scanned
before the file is available for download. Siemens Digital Industries Software recommends that this be a
separate managed location away from FMS volumes.
When a file is routed through an FSC that has a quarantine volume defined, it is scanned for viruses.
Only uploads performed after you configure the scanner and the quarantine volume can be scanned for
viruses. Any file uploaded previously cannot be scanned by FMS.

© 2021 Siemens
1. A user starts the upload of a file using the Teamcenter rich client, Active Workspace, or the Data
Share Manager.
2. If the file is routed through an FSC with a quarantine volume, a virus scan is initiated. The file is
uploaded to the quarantine volume temporary storage location.
3. When the upload is complete, FMS runs the virus scan script file. If the script fails to operate
properly, a virus scan failure is reported.
4. The file is scanned according to the individual scanner and configuration. Results are processed by
the script file returned to the calling FSC.
5. If no virus is found, the file is forwarded to the destination FSC according to the routing. FMS
commits the file to the destination volume and informs the client that the upload was successful.
If a virus is found, FMS returns an error to the client and displays an error to the user. The upload
fails. Files that fail the scan are removed from the quarantine volume.
Scanner requirements
If you currently have a virus scanner in use in your environment, you must ensure it meets the following
requirements for use with File Management System (FMS). Otherwise, you must choose and install a
scanner that meets the requirements.
FMS connects to the scanner through a script or executable that you must supply. This approach lets you
use the scanner of your choice. When FMS attempts to scan a file, it calls the scanning script or
executable you've provided. The scanner software must meet the following requirements:
• Support for command line execution or API integration. Command line support allows the software to
be called directly from FMS or directly from a custom script. API integration allows you to supply a
custom executable to make the appropriate vendor calls.
• Support for unattended operation. The FMS virus scanning is done on the server without user
attention. If the scanner requires user interaction, FMS cannot complete the upload. Some tools have
a command line option to run without user interaction.
• Acceptable performance. A poorly performing scanner can have a significant impact on file upload
times.
• The ability to target specific files or directories. The scanner must be able to accept input specifying an
individual file or directory to scan. File and directory locations and names change with each call.
• Usable result output. If the FSC is calling the scanner from a script, the script is responsible for
converting the scanner output to a 0 or non-0 return value. Some scanners place the results in an
output file. In these cases, the calling script must parse that file to determine if the scan succeeded.
Other scanners may send the same result to the console.

© 2021 Siemens
File virus scanning impact on upload performance
• Support for multiple execution runs. A single FSC can handle multiple uploads in parallel, so the FSC
may be making parallel calls to the same scanner. If the scanner places its output in a single file that
cannot be configured, the scan result will not be associated with a specific file. If a scanner sends its
results to an output file only, you must be able to configure the name and location of the file with
each call.
File virus scanning impact on upload performance
Several factors can impact performance when scanning a file for viruses. Consider these factors carefully
to ensure your environment provides acceptable upload times.
Scanning an uploaded file causes a file to pass through at least one additional server, the quarantine
volume, before the file can be stored on the destination volume. This process can double the upload
time. The performance of your network and the scanning software is important in limiting this impact,
so test the performance of the scanning software prior to deployment.
If you define multiple quarantine volumes in your File Management System network, define the routing
carefully. If an uploaded file routes across multiple quarantine volumes, it is scanned multiple times
resulting in a significant decrease in upload performance.
FMS quarantine volume substitutions and attributes
The FMS (File Management System) can recognize the following parameters and make substitutions for
them to supply the correct values for a specific call to the virus scanner. Each time the scanner is called,
these values, if they exist in the command, are repopulated before being sent to the script.
• $SCAN_FILE
This is the full path to the file to scan.
Some third-party scanners accept an individual file as input. Each time a file is set to scan, it is within
the quarantinevolume root using this parameter's value.
• $SCAN_DIR
This is the full path of the directory to scan. Some scanners can scan a directory only. Use this
parameter in those cases. Each time a file is set to scan, it is placed in a temporary directory within
the quarantinevolume root using this parameter's value
• $SCAN_UNIQUE
This is a randomly generated UID that can be used when forming the scanner output file name. Some
scanners send their output to a temporary file that must be parsed by the scanning script. Use this
parameter to generate a unique output file name. This avoids file name collisions.
The quaratineVolume XML element has the following required and optional attributes:
• root (required)
Specifies a directory where the files are temporarily placed for scanning. The virus scanner and script
must have access to this location. The location cannot be automatically scanned by other virus
scanners.

© 2021 Siemens
• command (required)
Specifies a command line string that is used to run the scan script. This includes the script itself and
any input parameters.
Use the full path to the command. You must also supply either the file to scan or the directory
containing the file to scan. Use either $SCAN_FILE or $SCAN_DIR substitution to supply this value.
• timeout (optional)
Specifies the maximum amount of time in seconds that FMS waits for a return value from the virus
scanner. The default value is 20.
Configure the file virus scan
When configuring virus scanning, each assigned FSC (specified using assignedfsc elements in the
fmsmaster.xml configuration file) and each FMS bootstrap FSC (specified using the Fms_Bootstrap_Urls
preference) should have a quarantine volume. A common configuration is for assigned FSCs and FMS
bootstrap FSCs to be the same set of servers.
When configuring assigned FSCs in the fmsmaster.xml configuration file, assigned FSCs should be
placed in a different FSC Group (fscgroup element) than the protected area FSC servers. Doing so
prevents features such as direct FSC routing from allowing files to bypass the assigned FSC scanning.
1. Create a new File Management System (FMS) server cache (FSC) where the scanning is done or
configure an existing FSC. For better performance, you can install and configure the virus scanner
on the same host. The scanner software and quarantine volume must be accessible by the FSC.
2. (Optional) Configure the FSC as an entry FSC.
3. If you create a new entry FSC, update the FMSBootstrapUrls preference at supplier sites to include
the new entry FSC URL.
4. If you are not using an existing virus scanner, install the selected third-party virus scanner.
5. Add a quarantinevolume element to the FMS primary configuration file for the scan FSC. This
specifies the location of the temporary directory where the scanning is done. Exempt this location
from automatic scanning by any other virus scanner.
Note:
All FMS volumes should be exempted from automatic virus scans.
6. Ensure the virus scanner is installed and configured to be accessible to FMS.
7. Write a script or executable to call the scanner. The contents of the calling script or executable
depends on the scanner interface. The script or executable acts as an intermediary between FMS
and the virus scanner. It must handle the inputs and process the output to determine if the scan
was a success or not. The script or executable must:

© 2021 Siemens
Configure the file virus scan
• Remove any temporary files it creates.
• Return a 0 (zero) value if the file passes the scan or a non 0 value if it fails.
• (Optional) Remove the files or directory that it scans. This is not required.
The following example is a simple script for calling the freeware ClamAV virus scanner:
A simple example of a scanner script that

talks to the ClamAV freeware 3rd party scanner.
@echo off
@REM This is a batch file that will scan for viruses
IF "%1" ==
"" (EXIT /B 1)
IF "%2" ==
"" (EXIT /B 2)
"C:\Program
Files\ClamAV-x64\clamscan.exe" -r %1 >> %2 2>&1
findstr
/c:"Scanned files: 1" %2 >nul
IF NOT
"%ERRORLEVEL%" == "0" (
del %2 >nul
EXIT /B 3
)
findstr
/c:"Infected files: 0" %2 >nul
IF NOT
"%ERRORLEVEL%" == "0" (
del %2 >nul
EXIT /B 4
)
del %2 >nul
EXIT /B 0
ENDLOCAL
This example takes two input values: the directory to scan and the path to a temporary output file.
The third-party scanner is called directly and the output is directed to a temporary file. The
temporary file is scanned for keywords indicating a scan success. The temporary file is deleted, and
0 is returned.

© 2021 Siemens
8. Create the quarantine volume root directory.
Configuring native FSC client proxy in TcServer
The native implementation uses cURL and OpenSSL and requires a compatible trusted certificate file.
Note:
This trusted certificate file must be in privacy enhanced mail (PEM) format (which is not the same
format as the Java cacerts file).
Use one of the following methods to generate a cacerts.pem file that contains the required certificates.
• Download the trusted certificate file.

If your certificate authority (CA) signer is well known, the certificates may be available from the
Internet. Siemens Digital Industries Software recommends you contact your internal security team.
1. Download a current ca-bundle.crt file from the Internet, or get the file from your internal
security team. The file must be compatible with cURL and OpenSSL.
The file must contain the certificate chain that can validate the FSC certificate.
2. Name the file cacerts.pem and save it in the FSC_HOME directory.
3. Create or modify the FSC_HOME/fsc.clientagent.properties file with the

com.teamcenter.fms.curl.cacerts.file property with a value that is the absolute path and file
name to the cacerts.pem file. For example:
d:\path\to\tc\install\fsc\fsc.clientagent.properties
#
#
com.teamcenter.fms.curl.cacerts.file=d:\path\to\tc\install\fsc\cacerts.pem
• Generate a trusted certificate file based on the installed Java cacerts file.
If your certificate authority (CA) signer certificates are in the Java cacerts file, you can extract them
for cURL and OpenSSL.
1. Extract the trusted certificates in the Java cacerts file in the PEM format that cURL and OpenSSL
requires, for example (Windows):
rem cd to the dir the java cacerts file is in

cd /d %JAVA_HOME%\jre\lib\security
rem cleanup leftover files from this script, and any existing cacerts.pem as we are building
a new one
del /q cacerts.pem cacerts.list export.pem
rem get the aliases for all trusted certificates in the cacerts file
keytool -keystore cacerts -storepass changeit -list | find "trustedCertEntry" | sort >
cacerts.list
rem for each alias export the certificate and append to the cacerts.pem file

© 2021 Siemens
Configuring enhanced ticket authentication
for /f "delims=, tokens=1" %f in (cacerts.list) do keytool -export -rfc -alias %f -keystore

cacerts
-storepass changeit -file export.pem & echo %f >> cacerts.pem & type export.pem >>
cacerts.pem
rem cleanup leftover files from this script
del /q cacerts.list export.pem
rem cacerts.pem contains all the trusted certificates in pem format
2. Save the file in the FSC_HOME directory.

#
#
• Generate a trusted certificate file with only the certificates required by your CA.
If your CA used new certificates, you must also acquire the signer certificates from your CA. These
must be contained within the cacerts.pem file.
1. Acquire the signer certificates, in PEM format, from your CA.
2. Append the signer certificates to a cacerts.pem file.
3. Save the file in the FSC_HOME directory.

#
#
The client (native implementation in TcServer) is now able to communicate with the FSC.
Configuring enhanced ticket authentication
FMS permits file data access only when the requestor presents a valid security ticket. You can enhance
this security by configuring FMS to use Teamcenter Security Services (TCSS) to authenticate tickets only
when the requestor presenting the valid security ticket is the user who generated the ticket.
Enhanced ticket authentication designates an FSC server with TCSS installed as an edge server with
which TCSS clients interact. The FSC edge server authenticates each ticket, verifying that the requestor
presenting the valid security ticket is the user who generated the ticket, before passing it to a data
center FSC.

© 2021 Siemens
Non-interactive clients (for example, Vis Server and TcServer) not using TCSS are mapped to FCS servers
not configured with TCSS authentication. Active Workspace clients do not use TCSS, so they are also
mapped to FCS servers not using TCSS authentication.
Example of an enhanced ticket authentication configuration:
Configure enhanced ticket authentication as follows:
Verify TCSS configuration

Preform the following steps:
• Ensure TCSS and Security Services (SSO) are installed and configured.
• Ensure that you can log on to the rich client. Verify you logged on using SSO.
• Record the following values for later use. See Find Security Services settings for use in TCCS.
• SSO AppID
• SSO Identity Service URL
• Login Service URL

Configure TCSS on the edge FSC
Enable ticket authentication for all requests on the edge FSC by ensuring that the following lines are
included (uncommented) in the edge FMS server configuration file (fsc.xml). (Here SOOappID,
identity_service_url, and login_service_url are the values you recorded when verifying your TCSS
configuration.)
<fscdefaults>
...

© 2021 Siemens
Enabling and tuning WAN acceleration

<property name="FSC_TcSSAppId" value="SOOappID" overridable="true" />
<property name="FSC_TcSSIdentityServiceUrl" value="identity_service_url"
<property name="FSC_TcSSLoginServiceUrl" value="login_service_url"
</fscdefaults>
<fccdefaults>
...
<property name="FCC_TcSSAppId" value="SOOappID" overridable="false" />
<property name="FCC_TcSSLoginServiceUrl" value="login_service_url"
overridable="false" />
</fccdefaults>
Example:
<fscdefaults>
...
<property name="FSC_TcSSAppId" value="Teamcenter1" overridable="true" />
<property name="FSC_TcSSIdentityServiceUrl" value="identity_service_url"
<property name="FSC_TcSSLoginServiceUrl" value="login_service_url"
</fscdefaults>
<fccdefaults>
...
<property name="FCC_TcSSAppId" value="SOOappID" overridable="false" />
<property name="FCC_TcSSLoginServiceUrl" value="login_service_url"
overridable="false" />
</fccdefaults>
Configure the FMS primary

For each rich client and other interactive client assigned to use the edge FSC, configure the
clientmap element of the FMS primary configuration file (fmsmaster_fscid.xml) to use the edge FSC
as the assigned FSC. (See Subnet/mask attributes in a client map.)
Example:

<assignedfsc fscid="fsc_edge1" priority="0"/>
</clientmap>
<assignedfsc fscid="fsc_edge1" priority="0"/>
</clientmap>
Enabling and tuning WAN acceleration
Enable WAN acceleration across WAN assets to improve file transfers between FSCs and file download
performance to FMS clients. WAN acceleration splits larger files into smaller pieces, transfers file pieces

© 2021 Siemens
simultaneously, and reconstructs the files before passing the files to the client. WAN acceleration is not
enabled by default.
Enable WAN acceleration by setting the FSC and FCC transport modes as follows:
Configure FMS Server Cache Transport mode

Enable WAN acceleration between FSCs:
• In the FMS primary configuration file (fmsmaster_fscid.xml), ensure that the FSCs are defined in
separate fscgroup structures. For example:
<fscgroup id="myGroup>
<fsc id="fsc_SAMPLE_DB"...>...</fsc>
</fscgroup>
<fscgroup id="cacheGroup">
<fsc id="fsc_CACHE_DB".../>...
</fscgroup>
• In the FMS primary configuration file, update or add linkparameter elements with
transport="wan" to specify that WAN acceleration is used between the groups. For example:
<linkparameters fromgroup="myGroup" togroup="cacheGroup"

transport="wan">
<linkparameters fromgroup="cacheGroup" togroup="myGroup"
transport="wan">
• Optionally adjust the FSC_WANThreshold, FSC_WANChunkSize,

FSC_DoNotCompressExtensions, and Maxpipes WAN acceleration parameters for your site's
operation as described in FSC WAN acceleration tuning parameters.
• The FSC_MaximumWANDownloadSockets environment variable controls the number of sockets

used for WAN acceleration downloads. The default value of 255 allows for a maximum of 25
concurrent WAN downloads (10 sockets per download) to be running at one time. 255 is also the
default value of the FSC_MaximumThreads parameter specified in the FMS server configuration
file.
If you adjust the value of FSC_MaximumWANDownloadSockets to a value greater than the
value set for FSC_MaximumThreads, set FSC_MaximumThreads to the same value. If you set
FSC_MaximumWANDownloadSockets to a value greater than that of FSC_MaximumThreads,
FSC_MaximumWANDownloadSockets is automatically reduced to the same value as
FSC_MaximumThreads.
Configuring the FMS Client Cache Transport mode
Enable WAN acceleration between FSCs and FCCs:
• In the FMS client configuration file (FMS_HOME/fcc.xml), locate the parent FSC to which the FCC
connects and set transport="wan". For example

© 2021 Siemens
Configure Cloud Data Storage Service (DSS)
<parentfsc address="civ6s437:22470" priority="0" transport="wan"/>
Optionally adjust the FCC_WANThreshold, FCC_MaxWANSources, and FCC_WANChunkSize

WAN acceleration parameters for your site's operation as described in General FCC configuration
parameters.
• In the FMS primary configuration file (fmsmaster_fscid.xml), ensure that the parent FSC is
included in the client map settings and set transport="wan" for that FSC. For example:

<assignedfsc fscid="fsc_cache_DB" priority="0" transport="wan"/>
</clientmap>
• Optionally adjust the FSC_WANThreshold, FSC_WANChunkSize,

FSC_DoNotCompressExtensions, and Maxpipes WAN acceleration parameters for your site's
operation as described in FSC WAN acceleration tuning parameters.
Configure Cloud Data Storage Service (DSS)
In addition to standard network storage of volumes, File Management System supports S3 cloud
volumes through the Cloud Data Storage Service (DSS). DSS lets you create volumes that are stored on
Amazon S3 cloud-based servers. Configuration and use of S3 cloud storage is currently supported with
Siemens Managed Services accounts only.
Siemens Managed Services has partnered with industry leaders to deliver world-class cloud solutions.
These partners include Smartronix Inc. for system monitoring and administration of the delivery of
Amazon web services (AWS) for cloud infrastructure. The partnering of Smartronix and AWS with the
Siemens Professional Services and Cloud Services teams allows for the delivery of complete turnkey
cloud deployments tailored to customer business needs. These partners form a broad solution team
with Siemens Managed Services acting as your single point of contact for cloud-related solutions.
Configuring Cloud Data Storage Service during FMS installation
Chose to enable DSS when installing FMS as follows:
• When installing with Deployment Center, select the FSC component, check Enable Cloud Data
Storage Service (DSS).
• When installing using TEM, on the File System Cache Service (FSC) panel, click Advanced, open the
Cloud DSS tab, and check Enable Cloud Data Storage Service (DSS).
Supply the following details when using either TEM or Deployment Center:

© 2021 Siemens
Setting Description
Keystore Password A password you specify to protect the keystore file containing the Cloud
Data Storage Service credentials.
Account ID The ID of the Cloud Data Storage Service account that is to store
Teamcenter volumes.
User ID The user ID for the Cloud Data Storage Service account that stores
Teamcenter volumes.
Access Key ID The ID of the key used to access Teamcenter volumes stored in the Cloud
Data Storage Service account.
Secret Access Key The secret string of the key used to access Teamcenter volumes stored in
Cloud Data Storage Service account.
Optimizing FMS startup memory
When enabling cloud volumes, Siemens Digital Industries Software recommends you increase the FMS
and FCC startup memory values from their default values of 256MB to at least 1GB. To increase the
values, edit the values of FSC_MEM, TCCS_MEM, and TCCS_MEM_MAX in the file for your platform as
follows:
startfsc.bat (Windows)
set FSC_MEM=1024M
set TCCS_MEM=1024M
set FSC_MEM_MAX=1024M
startfsc.sh (Linux)
setenv FSC_MEM=1024M
setenv TCCS_MEM=1024M
setenv TCCS_MEM_MAX=1024M
Creating cloud volumes
A cloud volume named DefaultCloudVolume is created when Cloud Data Storage Service is installed. If
you want to use this cloud volume, use the Organization application to grant member access to the
volume and to otherwise manage the volume.

© 2021 Siemens
Manage DSS keys
You can also create new cloud volumes as described in Create a volume.
Manage DSS keys
Rotate (change) your DSS keys to limit exposure in case of a security compromise and to limit the
amount of information protected by any particular key. Use the following steps to rotate DSS keys.
1. Ensure cloud services are enabled and your environment is configured as specified in Manually
configure the Teamcenter environment. and your files are configured as specified in Log files
produced by Teamcenter.
2. Open a Teamcenter command shell:
• (Windows) Click Start and choose All Programs→Teamcenter x.x→configuration-name

Command Prompt.
• (Linux) Open a command shell, change to the TC_ROOT/tc_menu directory, and run the
configuration-name.sh script.
3. Use the following fscadmin command to rotate the DSS keys:
fscadmin -s FSC-URL ./external/keys/rotate/nvargs/storagetype="dss"
For example:
fscadmin -s http://localhost:4544 ./external/keys/rotate/nvargs/storagetype="dss"
Messages of the following form are returned:
DSS Keys rotated successfully and key store updated

ACCESS_KEY_ID=e83a4c2f98ff4290a098774dcc24258a
SECRET_ACCESS_KEY=9lCCIQ+wRF/evDKCFgKN8PU1T0+md1lpvAHxpn+Yesc=
4. Use the following fscadmin command to verify FMS access for your Teamcenter site:
fscadmin -s FSC-URL -k common-key-file ./status
For example:
fscadmin -s http://localhost:4544 -k FMS.key ./status
Resolving ticket expiration errors
Ticket expiration errors (such as TICKET_EXPIRED_0) are noted in the FSC log or can be displayed in
other parts of the system. These errors can be caused by time zone configuration issues or by poor clock
synchronization. This can hinder administrative FMS tasks, such as creating volumes, or, in severe cases,

© 2021 Siemens
cause file access issues. Resolve ticket expiration errors by verifying proper time zone configuration, and
then synchronize your local clock with local or public time servers.
If your company has local time servers, synchronize with them based on your company's policies. To
synchronize with public time servers:
• To synchronize your local clock on Windows, run the following operating system command:
net time /setsntp:pool.ntp.org
• To synchronize your local clock on Linux, run the following operating system command:
ntpdate -u pool.ntp.org
Configure FMS to work with multiple versions of Java
If you are running multiple versions of Teamcenter on your system and they are compatible only with
different versions of Java, you must configure your FMS client caches (FCCs) to use the Java run-time
environments (JREs) with which the caches were installed.
1. Open the FMS_HOME/starttccs.sh (Linux systems) file or the FMS_HOME\starttccs.bat (Windows

systems) file in a plain text editor.
2. Set the TCCS_JAVA environment variable to the JRE supplied with the Teamcenter version with
which the FCC was installed.
For information about versions of operating systems, third-party software, Teamcenter software, and
system hardware certified for your platform, see the Hardware and Software Certifications knowledge
base article on Support Center.
Configure FMS multiuser support
On Windows systems, the pipe connection to the FMS client cache (FCC) uses a single value by default,
allowing only one user to connect to the FCC per Windows workstation. If you want to enable multiple
users to start FCC client applications on the same machine at the same time, set the
FMS_WINDOWS_MULTIUSER environment variable to true.
A multiuser situation occurs, for example, when multiple users employ remote access applications such
as Citrix or Remote Desktop to access Teamcenter applications on a common Windows machine. FCC
separation is achieved because the environment variable setting causes the pipe names used for the
client-to-FCC communication to include the user ID, ensuring that each user connects with a unique pipe
to the appropriate FCC.
If the FMS_WINDOWS_MULTIUSER variable is set to true, user names should not end in numerals.
Names ending in numerals confuse the automated pipe name generation. For example, the pipe named
{RootPipeName}_User121 could be the first data pipe belonging to User12, or the 21st pipe belonging
to User1.

© 2021 Siemens
FMS considerations for running multiple Teamcenter environments
Use the following steps to configure FMS running on a Windows system to accept multiple users:
1. In the system environment (System Properties>Advanced>Environment Variables>System

Variables), set the FMS_WINDOWS_MULTIUSER environment variable to true.
To set a global environment variable, local administration privileges are required.
2. To propagate this setting to all users and applications, reboot the system.
Siemens Digital Industries Software customer support will assist in working through issues. Any issues
that are Siemens Digital Industries Software code related can be addressed as problem reports. Issues
arising from operating system or third party tools must be addressed with that vendor.
FMS considerations for running multiple Teamcenter environments
If for a testing or development purpose you have created multiple Teamcenter environments, either on a
single machine or multiple machines, such that there are multiple Teamcenter sites with the same site
ID that also have the same volume ID for each of their volumes, then the sites look the same to FMS
because they have the same site ID. This is different from regular Teamcenter deployments, which are
typically single instance installations on a given server infrastructure.
In this testing or development scenario, it is not necessary to move volumes to distinct volume IDs. You
can maintain the integrity of the data as long as you keep the sites apart.
To keep the sites apart, comply with the following:
• Do not use Multi-Site. There can be only one primary site. If you use Multi-Site in this scenario, then
there is a risk of replicating owned data.
• Do not share FSCs. There is a risk of checking in data to the wrong system.
Warning:
Production environments must not have duplicate site IDs.
Administering transient volumes
Introduction to administering transient volumes
Transient volumes are the mechanism used to transfer data either generated by or required by the
business logic server (TcServer). For example, transient volumes are used during PLM XML export. The
file is generated by the TcServer process and written to a temporary area, the transient volume. A ticket
for the file in the transient volume is sent to the client that uses the ticket to retrieve the file.
In a four-tier configuration, each business logic or enterprise tier server requires a transient volume. It is
best practice to have a local FSC on each server to service the local transient volume.

© 2021 Siemens
Client access to files within a transient volume is dependent on whether clients are running in two-tier
or four-tier. The tickets generated for client file access specify either two-tier, or four-tier depending on
how the client is connected to the TcServer.
• Two-tier transient volume file access

Clients in a two-tier environment can read and write to the same physical location as the TcServer
since they are on the same machine. In this case, the FCC process reads files directly from the
transient volume location.
File operations need no special fmsmaster_fscid.xml configuration because no FSCs are required to
transport the files, and therefore no fmsmaster_fscid.xml configuration is required.
• Four-tier transient volume file access

Clients in a four-tier environment do not have direct access to the transient volume location and must
use the FMS system to retrieve files. Therefore, four-tier transient file operations require transient
volumes to be configured in the fmsmaster_fscid.xml configuration file. Transient volumes are
declared under an FSC with direct access to the files, much like the TcServer process. The FSCs that
host transient volumes usually run on the same hosts, under the same user IDs, as the TcServer
process.
Note:
The four-tier FSC transient volume server must run with the same user credentials as the pool
server and TcServer processes that own the transient volume and all its files. The OS user that
FSC and TcServer run with requires read, create, write, and delete permissions in all directories
and subdirectories within the transient volume. No other users should have access to this
directory.
On the server side, two-tier or four-tier configuration makes no difference to how the TcServer process
assesses the transient volume.
Transient volume configuration components
In a two-tier environment the value used for the Transient_Volume_RootDir preference is always
overridden by a user-specific directory; the values set for any transient volume-related preferences or
environment variables are ignored.
Caution:
Do not define the directory path as a UNC path, for example, \\server\shared-transient-folder. Use
a direct path location. This requirement is because some ZIP archive utilities do not accept UNC
paths, resulting in failed exports to Microsoft Excel or Word.
If the TC_TMP_DIR environment variable is set, the value used for the Transient_Volume_RootDir
preference is:
• ${TC_TMP_DIR}/${USER}2TierTransientVolume on Linux

© 2021 Siemens
Configure transient volume elements in the primary configuration file
• TC_TMP_DIR%\%USERNAME%2TierTransientVolume on Windows
If the TC_TMP_DIR environment variable is not set, the value used for the Transient_Volume_RootDir
preference is:
• /tmp/${USER}2TierTransientVolume on Linux
• c:\temp\%USERNAME%2TierTransientVolume on Windows
In a four-tier environment, three elements control transient volumes:
• The site ID defines the database ID for the system.
• The Transient_Volume_RootDir preference is a multi-value variable used to provide Linux and

Windows path name of the transient volume on the server. When set as a preference, the values must
be valid for all machines of each platform type. When set as an environment variable (which overrides
any preference values) only a single platform path can be specified.
The preference is designed to accept multi-values to support multiple platforms. However, if you set
this preference with identical values, the following error message appears:
Duplicate transientvolume configuration elements were found for attribute id

with value attribute_value
If you are using only one platform, you can delete the other value to ensure you do not receive this
error message.
• The Transient_Volume_Installation_Location preference specifies the node name of the transient

volume. It is a location-based logical identifier and is generally set to the host name of the local
machine by the TC_DATA\tc_profilevars script.
The transient volume location is read/write/verify checked during TcServer startup. The location value
and any warning messages about the transient volumes are printed to the TcServer system log for
diagnostic purposes.
Configure transient volume elements in the primary configuration file
For four-tier client file access, transient volumes must be declared within the fmsmaster_fscid.xml
configuration file. They must be declared with the FSCs that host the transient volumes (these are the
FSCs capable of file input/output directly to the root path of the transient volume).
The declaration must include the transient volume ID as defined by the backup_xmlinfo utility, and the
path to the root of the transient volume. For example:
<fsc id="FSC_cinsun4_v10002a1" address="http://cinsun4:44021">

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

© 2021 Siemens
Any change to the fmsmaster_fscid.xml configuration file requires all FSCs to be configured as
configuration primaries to have their configuration files updated. Then the configuration must be
reloaded across the FMS network to propagate the changes to all FSCs.
To modify the transient volume ID or path in the primary configuration file:
1. Run the backup_xmlinfo utility and examine the backup.xml file created by the utility.
2. Edit the FMS primary configuration file(s) to reflect the new ID of the transient volume(s) and/or
the changed paths.
3. Either reload the configuration by stopping and restarting the FSCs that use this configuration
information, or reload the configuration using the fscadmin utility.
Reload the configuration across the entire FMS network by running the following command:
fscadmin -s http://fschost:fscport ./config/reload/all
Modify the transient volume ID for the current server context
Although a given TcServer only knows about a single logical transient volume, other parts of the system
(such as FMS) may need to work with more than one transient volume and therefore transient volumes
must be identifiable. A transient volume's identity is a unique value that is based on the site ID and
several of the transient volume preferences. This identity is called the transient volume ID.
The transient volume ID listed in the FMS primary configuration file is determined by a combination of
the site ID, the value of the Transient_Volume_RootDir preference, and the value of the
Transient_Volume_Installation_Location preference. Modifying any of these values changes the
transient volume ID, in which case you must manually modify the transient volume ID listed in the
primary configuration file.
Note:
The TC_DATA\tc_profilevars file sets the Transient_Volume_Installation_Location preference to
the computer/host name.
You can obtain a list of current volume definitions in the database by running the backup_xmlinfo
utility to generate the backup.xml file. The utility generates transient volume information for the
context in which the utility is being run (the current TcServer context). All other server pools or hosts
with transient volumes are not identified.
The procedure for setting the TcServer context differs, depending on whether you are on a Windows
and Linux platform.
• To set the TcServer context on Windows and run the utility:
1. Run the Teamcenter command prompt to open a command window by choosing

Start→Programs→Teamcenter version→configuration-name Command Prompt.

© 2021 Siemens
Determining the transient volume ID for a different server context
2. In the command prompt, type backup_xmlinfo -u=tc-admin-user -p=password -g=group where

tc-admin-user, password, and group are your site's administrative user ID, password and group
ID.
The backup.xml file is generated, listing the transient volumes.
• To set the TcServer context on Linux and run the utility:
1. Set the TC_DATA environment variable to your TC_DATA directory.
2. Set the TC_ROOT environment variable to your TC_ROOT directory.
3. Run source tc_profilevars.
4. Run backup_xmlinfo -u=tc-admin-user -p=password -g=group where tc-admin-user, password,

and group are your site's administrative user ID, password and group ID.
The backup.xml file is generated, listing the transient volumes. For example:
<?xml version="1.0" encoding="iso-8859-1"?>

<backupInfo>
<enterpriseId>468532367</enterpriseId>
<bootstrapInfo>
<fscUrl>http://cili6s08:7131</fscUrl>
</bootstrapInfo>
<volumeInfo>
<volumeName>public_vol</volumeName>
<volumeUid>1b604728a74d1bed3c8f</volumeUid>
<nodeName>cili6s08</nodeName>
<unixPath>/tc_volumes/tc200712</unixPath>
</volumeInfo>
<transientVolumeInfo>
<transVolId>875acf876dfccbc2dc76e9bf1e807d85</transVolId>
<unixPath>/tmp/transientvolume</unixPath>
</transientVolumeInfo>
<transientVolumeInfo>
<transVolId>8900c6b23daca8dcf231dbbf4331b703</transVolId>
<wntPath>c:\temp</wntPath>
</transientVolumeInfo>
</backupInfo>
Note:
The transient volume ID and path are platform dependent. Use the ID from either the unixPath or
the wntPath.
Define the transient volume within FSC elements in the fmsmaster_fscid.xml configuration file.
Determining the transient volume ID for a different server context
Although a given TcServer only knows about a single logical transient volume, other parts of the system
(such as FMS) may need to work with more than one transient volume and therefore transient volumes

© 2021 Siemens
must be identifiable. A transient volume's identity is a unique value that is based on the SiteID and
several of the transient volume preferences. This identity is called the transient volume ID.
The transient volume ID listed in the FMS primary configuration file is determined by a combination of
the site ID, the value of the Transient_Volume_RootDir preference, and the value of the
Transient_Volume_Installation_Location preference. Modifying any of these values changes the
transient volume ID, in which case you must manually modify the transient volume ID listed in the
primary configuration file.
You can obtain a list of current volume definitions in the database by running the backup_xmlinfo
utility to generate the backup.xml file. You must define which server context for which you are
generating transient volume information.
To generate transient volume information for other TcServers within the same system, set the
Transient_Volume_Installation_Location preference to the value used for the desired TcServer, then
complete the steps listed in Modify the transient volume ID for the current server context.
Note:
The Transient_Volume_RootDir preference allows the configuration of transient volume locations
for multiple platforms. Typically, one value represents the location of a transient volume on a
Linux system and the other a transient volume on a Windows system. Teamcenter distinguishes
the values based on the path name separator (/ for Linux, \ for Windows). If you use only one
platform, you can delete the other value. Multiple values can be specified but are not required.
If the values specified for the Transient_Volume_RootDir preference have identical values,
Teamcenter displays the following error message:
Duplicate transientvolume configuration elements were found for

attribute id with value attribute_value
Modifying transient volume ID components
Modifying either the site ID or the Transient_Volume_RootDir preference has far reaching impact,
affecting multiple transient volumes defined in the system.
Warning:
Siemens Digital Industries Software strongly discourages changing these values.
Changing the site ID invalidates all existing FMS configured transient volumes because the site ID
is used directly to generate transient volume IDs.
Changing the Transient_Volume_RootDir preference value invalidates all transient volumes on
the platform (Windows/Linux) that was modified because this preference defines the path to the
transient volumes for the specified platform.
To modify the Transient_Volume_RootDir preference:

© 2021 Siemens
Introduction to administering volumes
1. Change the value of the preference to the new path name of the transient volume on the
Transient_Volume_RootDir.
Caution:
Do not define the path as a UNC path, for example, \\server\shared-transient-folder. Use a
direct path location. This requirement is because some ZIP archive utilities do not accept UNC
paths, resulting in failed exports to Microsoft Excel or Word.
2. Generate the new transient volume IDs one server context at a time by completing the steps for
Determining the transient volume ID for a different server context.
3. Use the Organization application to reload the FMS configuration.
Administering volumes
Introduction to administering volumes
Use the Organization application to create new volumes and manage volume locations and properties.
After adding new volumes, use Organization to reload the File Management System (FMS) configuration
throughout the entire network, generate FMS reports, and display the FMS primary configuration file
You can also create, manage, review, purge, and move volumes using various Teamcenter utilities.
Default volumes
Default volumes specify the default final destination volume for Teamcenter files. Default volumes differ
from default local volumes in that default volumes are the first and final destination for Teamcenter
files. Default local volumes are temporary storage locations.
When users upload a new file, the default volume for the file is determined by the volume attribute of
either the user or the user's group. The system determines the volume by working through the following
values in order (the first value to have a valid volume is the destination volume):
• The default volume set by the user
• The default volume set by a group to which the user belongs
• The default volume set by a parent group of a group to which the user belongs
• Any volume to which the user has access
• Any volume to which a group the user belongs to has access

© 2021 Siemens
Create the volumes you want to use as default volumes in the Organization application. Creating
volumes in the Organization application adds the volumes to the List of Defined Volumes dialog box.
To view this list, select a user or a group and click the Default Volume button.
For performance reasons, you cannot set a cloud-based volume as a default volume.
After you create the volumes, the option to define a default volume is available while creating a new
user, modifying an existing user, creating a new group, and modifying an existing group.
You can also define a default volume for a user by choosing Edit→User Setting and selecting a default
volume from the Volume list.
Default local volumes
Introduction to default local volumes
Default local volumes are temporary local volumes that allow files to be stored locally before they are
automatically transferred to the final destination volume. This functionality improves end-user file
upload times from clients by uploading files to a temporary volume. Users can continue to work on their
files from the temporary location. The system moves the files to their final destination according to
administer-defined criteria. Files are accessible to FMS at all times. This behavior is also referred to as the
store and forward of files.
By default, store and forward functionality moves files from the local volume one at a time. If you prefer,
you can move files in batch by using the store_and_forward Dispatcher translator.
The purpose of temporary, local storage volumes is to provide upload capability to a volume that is local
to remote users. This is useful in situations when an FMS volume does not exist on the LAN with the
remote user. In these situations, the closer the initial volume is to the user uploading the file, the faster
the upload.
Note:
Default local volumes differ from default volumes in that default local volumes are temporary
volumes. Default volumes are the final destination for Teamcenter files.
When users upload a new file, the default local volume destination for the file is determined by the
volume attributes of either the user or the user's group. The system determines the initial upload
volume destination by working through the following values in order. The first value to have a valid
volume is the destination volume.
• The default local volume defined for the user
• The default local volume defined for the group under which the user is currently logged on
• The default local volume defined for the user’s default group

© 2021 Siemens
Enable default local volumes
• The default local volume defined for the parent group of:
• The default local volume defined for the group under which the user is currently logged on.
• The default local volume defined for the user’s default group, if the previous value is not set.
Note:
The TC_Store_and_Forward preference must be set to enable store and forward functionality. If
this preference is set, any of the users’ accessible volumes can be defined as the session local
volume using the Local Volume box on the User Settings dialog box in the rich client. The session
local volume setting overrides the default local volume setting.
If there are no default local volumes defined for the previous values, then store and forward
functionality is not used for the file. The normal upload volume location is used. The system determines
the volume destination by working through the following values in order. The first value to have a valid
volume is the destination volume.
• The default volume defined for the user
• The default volume defined for the group under which the user is currently logged on
• The default volume set for the parent group of the group under which the user is currently logged on
• Any volume to which the user has access
• Any volume to which a group the user belongs to has access
Enable default local volumes
automatically transferred to the final destination volume. This functionality improves end-user file
upload times from clients by uploading files to a temporary volume. This functionality is referred to as
store and forward functionality.
1. Set the TC_Store_and_Forward preference to true.

This preference can be used as either a site, user, or group preference. Users and administrators
can set the preference by choosing Edit→Options to open the Options dialog box. Use the Search
tab in this dialog box to locate the preference and ensure it is set to true. (The default value is
false.)
2. (Optional) Set the TC_Store_and_Forward_Transfer_Delay preference to how many minutes file

transfer between the initial volume and the destination volume is delayed.

© 2021 Siemens
Delaying the transfer to the final destination volume can improve performance if your site has a
high volume of revisions and the delay is long enough to allow a purge of file revisions before the
transfer to the final destination volume.
3. (Optional) Set the TC_allow_inherited_group_volume_access preference to allow subgroups to

inherit access to a Teamcenter volume from its parent group. If a group is explicitly granted volume
access, and this preference is set to a nonzero number, that group's subgroups (and the subgroup’s
children) are implicitly granted access to that volume.
Note:
Inherited access applies to all volumes including default local volumes, also known as store
and forward volumes.
4. Create the volumes you want to use as default local volumes in the Organization application.
Creating volumes in the Organization application adds the volumes to the List of Defined Volumes
dialog box. To view this list, select a user or a group and click the Default Volume button.
After you create the volumes, the option to define a default local volume is available while creating
a new user, modifying an existing user, creating a new group, and modifying an existing group.
You can also define a default local volume for a user by choosing Edit→User Setting and selecting
a default local volume from the Local Volume list.
Configuring default local volumes
The FMS Transfer Dispatcher Server module is used to transfer uploaded files in the default local volume
to the default destination volume. There are no location requirements for this module. It can be placed
on the corporate server, the server on which you deploy other Dispatcher Server modules, or by itself at
the remote site.
The module only acts as a trigger for the transfer, it does not actively participate in it. Therefore, there is
no requirement that it have a fast connection with the FCCs participating in the transfer. The only
requirement is that it is connected with its bootstrap FSC and with the Dispatcher Scheduler. This
connection allows placement at remote data centers.
A single module can handle multiple default local volumes. The number of modules required depends
on the expected store and forward usage, and your environment.
The Ticket_Expiration_Interval preference determines the length of time tickets are available for
Teamcenter functions such as reading a file or viewing a file. In the context of store and forward
functionality, this preference determines the amount of delay between the initial transfer of the file and
the cleanup of the file. For example, if you have cleanup tasks in your Dispatcher Server queue, this
value determines how long they remain in the queue. Store and forward functionality delays the
cleanup to ensure the file is available for any read ticket requests against the file's initial volume
location.

© 2021 Siemens
Move files in batch for default local volumes
Move files in batch for default local volumes
automatically transferred to the final destination volume. This functionality is also known as store and
forward.
By default, the store and forward functionality moves files from the local volume one at a time using the
fmstranslator Dispatcher translator. You can use the store_and_forward Dispatcher translator to
upload files in batch. This is useful in situations when an FMS volume does not exist on the LAN with the
remote user. In these situations, the closer the initial volume is to the user uploading the file, the faster
the upload.
Perform the following steps to configure moving files in batch for default local volumes:
1. Install and configure the translator by running Teamcenter Environment Manager (TEM). Choose
Enterprise Knowledge Foundation > Dispatcher Server.Then, in the Select Translators panel,
select the StoreAndForward translator.
If you have questions about setup, see the instructions in the \Module\Translators
\store_and_forward\Readme.txt file.
2. In the rich client, set the TC_Store_and_Forward preference to true.

To set the preference, choose Edit > Options to open the Options dialog box, and then use the
Search tab in the dialog box to locate the preference.
3. Set the FMS_SAF_Batch_Transfer_Enabled preference to true.

This switches the transfer mode from moving files one at a time (using the fmstranslator
translator) to moving files in batches (using the store_and_forward translator).
4. In the Organization application, choose Edit→User Setting to set the local volume for the user in
the User Settings dialog box.
5. Optionally, to view the files in local volumes to be moved to default volumes, run the
move_volume_files utility with the -listaf argument.
6. Run the store_and_forward translator in the Dispatcher Admin Client as a repeating job.

© 2021 Siemens
This translator in turn runs the move_volume_files utility with the -transferaf argument, which
queries the database for the user files in local volumes and transfers them to their respective
default volumes. It also automatically schedules a task to clean up the files from the local volumes.
You can also run the move_volume_files utility as a cron job or as a scheduled task using
process_move_file_volumes as a .sh or .bat script, respectively.
Note:
If you choose to use the Dispatcher Admin Client to schedule repeating jobs, ensure that the
module service is started by an OS user who is a member of the dba group. This is
mandatory because the -transferaf argument of the move_volume_files utility must have
DBA privileges with bypass authority to commit the database records belonging to different
users. However, if you use the cron job to schedule repeating jobs, you do not have this
restriction.
7. After the translator setup is complete, verify the translator installation:
a. Create datasets in the local volume using the rich client.
b. Import files into the datasets.
c. Verify the files are created under the local volume.
d. Schedule the repeating store_and_forward translation job using the Admin Client.
e. After the translation is complete, verify that the files are moved to the default volume.
Using store and forward after upgrading
After you upgrade from a pre-10.1 version of Teamcenter, and you subsequently use the batch store
and forward process to move files, you may discover that the process moves files back from the default
volume to the default local volume.
This problem occurs when you transition from the old store and forward method introduced in
Teamcenter 8.0 to the new batch store and forward method introduced in Teamcenter 10.1. Perform
the following steps to remedy the problem.
1. Ensure that all FMSTransfer dispatcher tasks are completed and that no new ones start up.

© 2021 Siemens
Using a default local volume with a single FSC
2. Ensure that the current value of the FMS_SAF_Batch_Transfer_Enabled preference is set to false.
3. Run the following command:
move_volume_files -u=admin-username -p=password -g=dba

-migrate_to_batch_saf
If the command completes successfully, the following message is displayed:
You can now switch over to using the batch Store and Forward
functionality.
4. After the move_volume_files utility is successfully executed, switch to the batch store and forward
process by setting the FMS_SAF_Batch_Transfer_Enabled preference to true.
Using a default local volume with a single FSC
The simplest configuration of store and forward functionality is to add a single default local volume to
an existing caching FMS server cache (FSC). This solution is appropriate when you have a small number
of users at the remote site.
The following graphic illustrates the addition of a default local volume to a remote caching FSC.
Add a default local volume to an existing caching FSC using the Organization application.

© 2021 Siemens
Using a default local volume with multiple FSCs
Remote sites with many users, or high-usage users, may have multiple caching FSCs sharing the load
across multiple clients. In such situations, a default local volume can be cross-mounted on the FSCs.
The following graphic illustrates the addition of a default local volume cross-mounted on two FSCs.
Use the filestoregroup element in the fmsmaster_fscid.xml file to add a default local volume, cross-
mounted on two FSCs. See the FSC_HOME\fmsmaster.xml.template file for an example of the
filestoregroup element.
Using a default local volume with side caching
After a file is transferred to the final destination volume, it is prepopulated into the exit cache on the
remote FSC group if side caching is enabled. Enable side caching by explicitly defining exit FSCs. Entry
FSCs and FSCs not configured in the FMS primary configuration file (fmsmaster_fscid.xml) as exit FSCs
do not perform side caching. Normal caching behavior applies in these circumstances.
Side caching is performed only for the highest priority exits defined in the primary configuration file. For
example, if three exits are defined, two set to priority 0 and one set to priority 1, only the two exits with
priority 0 are side cached.

© 2021 Siemens
Best practices for configuring default local volumes
The following graphic illustrates a caching configuration designed to support a large number of users. In
the example, one remote user uploads a file. Another remote user requests a download of the same file.
Without side caching configured, the file is only cached after the initial download. With side caching
enabled, after the file is transferred to the final destination volume, it is automatically side cached to the
defined exit FSCs in the remote FSC group. In this example, the remote user requesting the download
receives the file from Exit FSC 2.
Note:
The transfer to the final destination volume may not occur immediately. Until the transfer occurs,
remote users requesting download of the file receive it directly from the default local volume on
their LAN.
Best practices for configuring default local volumes
The default local volume (also referred to as the store and forward volume) is a real volume, storing
production data. The production data is transferred to the destination volume relatively soon
(depending on the load, and how you have configured the volume), but you must still consider upload
requirements. The volume must have the expected availability and reliability you require from a
production data volume. Siemens Digital Industries Software recommends RAID 5 or better.

© 2021 Siemens
It is best to ensure that once a file is uploaded to the destination volume, any remote requests for that
file are retrieved from the cache, not the destination volume. Keep in mind that once a file is transferred
to the destination volume, any download request for that file is delivered from the destination volume. If
the request comes from a remote user who has just uploaded the file, this represents a WAN hop,
producing the WAN penalty just avoided by using store and forward functionality.
Note:
Normal cache flushing and expiration rules apply to local default volume files.
Volume failover
Configuration failover versus volume failover
You can use File Management System (FMS) to manage different types of failover behavior.
Configuration failover features are configured for each client API, either in the Fms_Bootstrap_Urls
preference or the parentfsc list in the fcc.xml configuration file. (The fcc.xml file is located in the
FMS_HOME directory, for example, TC_ROOT\tccs.)
Volume failover features are configured with the priority= attributes of a number of elements in the
fmsmaster_fscid.xml file. (This file is located in the TC_ROOT\fsc directory.)
Once configuration failover delivers the assignedfsc list (and/or the directfscroutes list) to the FSC or
FCC client, the client uses this information to select the initial FSC for each data request, which is the
initial aspect of volume failover for Teamcenter data access.
Much of the volume failover implementation is in the intermediate FSC server routing logic, though the
client selection of the initial FSC server to receive each data request is also important.
Warning:
When configuring an FMS system for volume failover, you should also consider configuring for
configuration failover.
Volume failover is not particularly effective if clients cannot obtain an assignedfsc list because the
one and only configuration server FSC is offline. Larger deployments encompassing many remote
sites and several FSC servers may choose to set up a couple of FSC servers at each site exclusively
for use as configuration servers. Smaller deployments (using only a few FSC servers) should
consider configuring configuration failover similarly to volume failover.
Overview of configuration failover
FMS configuration is controlled through a primary configuration file (fmsmaster_fscid.xml) that is

hosted by an FSC referred to as the primary or configuration FSC. You can also configure more than one
primary or configuration FSC so that the additional FSCs act as failover servers.

© 2021 Siemens
Overview of volume failover
Configuration failover allows the client or the FMS network to fail over from one FSC configuration
server to another, based on the priority value of the FSC set in the fmsmaster configuration file. Similar
to other failovers in FMS configuration, the priority attribute determines the failover configuration with
0 being highest priority, followed by 1, 2 and so on.
Fail over priority is configured in the assignedfsc element in the clientmap element. For example

<assignedfsc fscid="fscPrimary1" priority="0" />
</clientmap>
Note that in this context, the configuration FSC does not need not be the same as the bootstrap FSC
specified using Fms_Bootstrap_Urls or similar mechanisms.
• If the bootstrap URL is indeed the same as the primary configuration FSC URL, to then achieve failover,
you must also specify all of the relevant Primary FSC URLs in the bootstrap.
• If the bootstrap URL is not the Primary FSC URL (for example, if it is a reverse proxy URL), the failover
will then work with the assignedfsc priority settings described here.
Overview of volume failover
Unlike configuration failover, volume failover is implemented in many forms and in many places
throughout FMS.
• Implemented within FSC clients

FSC clients use only the assignedfsc list in the fmsmaster_fscid.xml file to determine the initial FSC
destination of data requests from the client. This list is derived exclusively from the priority=
attributes of the elements in the client’s assignedfsc list.
• Implemented within FCC clients

FCC clients use a variety of information from the FSC configuration to determine the initial FSC
destination of a data request. These include, in order of precedence:
• If assignment mode="parentfsc" is specified in the fcc.xml file:
■ The parentfsc list in the fcc.xml file is treated as the actual assignedfsc list.
■ The assignedfsc list returned by the configuration server FSC is required but largely ignored.
■ The FCC_EnableDirectFSCRouting element is automatically set to false, regardless of any actual

settings in the fcc.xml or fmsmaster_fscid.xml files.
■ The directfscroutes list returned by the configuration server FSC is also ignored.

© 2021 Siemens
In this mode, the configuration failover settings are also used for volume failover at the FCC
client (by design). The assignment mode="parentfsc" setting only affects FCC selection of the
initial FSC server; it does not affect volume failover features at intermediate FSCs.
• If the FCC_TransientFileFSCSource parameter is set to ticketuri (the default setting), the URI in a
transient file ticket takes precedence. FMS tickets for resource types1 other than transientvolume
do not have a URI embedded in the ticket.
• If the FCC_EnableDirectFSCRouting parameter is set to true (the default setting), and the
resource element is served within the same fscgroup element as the client’s primary assignedfsc
element, the request is routed to the direct FSCs that serve it in order of the priority= attributes of
the direct FSC routes.
The priorities of direct FSC routes are determined by the priority= attributes of the resource and
filestoregroup elements of the fsc and loadbalancer elements in the fmsmaster_fscid.xml file
and delivered to the FCC with the assignedfsc list on FCC initialization.
• If the SiteID element (FMS-enterprise-ID) of the FMS ticket is listed in the site list of the fcc.xml
configuration file, the request is sent to the assignedfsc list specific to that client, obtained from
the parentfsc list specified in the corresponding site element of the fcc.xml file (using
configuration failover).
• If none of these situations apply, or all of the attempts fail in a manner indicating appropriate
failover, the request is sent to the assignedfsc list specific to that client, obtained from the default
parentfsc list (not in a site element) listed in the fcc.xml file. The priority order of the assignedfsc
list is determined by the priority= attributes of the assignedfsc elements of clientmap elements in
the fmsmaster_fscid.xml configuration file obtained from a default parentfsc.
• Implemented within intermediate FSCs

The bulk of the volume failover implementation is in the routing code of intermediate FSCs, which
route FMS requests to other FSC servers. Intermediate FSCs use priority= attributes on a number of
other elements in the fmsmaster_fscid.xml file to implement volume failover as a part of FMS
message routing. These elements include:
• The resource and filestoregroup elements of fsc and loadbalancer elements, which apply most
directly to the selection of target resource servers for FMS routing.
• The entryfsc elements of fscgroup elements, particularly when the entryfsc element refers
directly to volume servers.
• The exitfsc elements of fscgroup elements, particularly when the exitfsc element refers directly to
volume servers.
1 The list of resource elements includes volume, transientvolume, logvolume, and accesson.

© 2021 Siemens
Implement volume failover
• The fscimport elements of defaultfscimport elements, particularly when the fscimport elements
refer directly to volume servers in the fmsmaster_fscid.xml configuration file of the external
fmsenterprise element.
FMS uses client-proximity routing. Requests are routed by the first FSC to receive a request for a
resource that it can neither fulfill from cache nor serve directly from volume. This initial FSC routes
the request through the FMS network to another FSC that serves the requested resource.
Warning:
It is very important that all FSC servers within the same FMS system share identical
fmsmaster_fscid.xml file information. If an FSC server has an inaccurate configuration, it is
prone to routing errors, which can cause user transaction failure.
Implement volume failover
Implement volume failover by specifying backup volume servers using the priority= attributes of
resource and filestoregroup elements of the fsc and loadbalancer elements in the
fmsmaster_fscid.xml file.
The priority= attributes on a number of other elements in the fmsmaster_fscid.xml file affect the
failover characteristics of request routing, including:
• The assignedfsc elements of clientmap elements, particularly when the assignedfsc element refers
directly to volume servers.
• The resource and filestoregroup elements of fsc and loadbalancer elements, which apply most
directly to the selection of target resource servers for FMS routing.
• The entryfsc elements of fscgroup elements, particularly when the entryfsc element refers directly
to volume servers.
• The exitfsc elements of fscgroup elements, particularly when the exitfsc element refers directly to
volume servers.
• The fscimport elements of defaultfscimport elements, particularly when the fscimport elements
refer directly to volume servers in the fmsmaster_fscid.xml configuration file of the external
fmsenterprise element.
Configuring volume failover using multiple FSCs
You can provide volume failover by assigning multiple FSCs to serve the same storage resource. If the
primary FSC fails, the secondary FSC continues to serve files from the volume. Configure this behavior
by mounting the same volume on multiple FSCs, giving each FSC a different priority level. The volume is
always served by the available (alive) FSC with the lowest assigned priority.

© 2021 Siemens
In the following example, two FSCs mount the testvol volume. The primary FSC is fsc3. It is assigned
priority level 0. FSC fsc4 acts as a backup server. It is assigned priority level 1.
Look at the configuration for fscgroup g3, at the bottom of the code example. Both of the FSCs mount
the testvol volume, each with a different volume priority value. If fsc3 is alive it will serve testvol, fsc4
will only serve testvol if fsc3 is down.
<fmsworld>
<fmsenterprise id="fms.teamcenter.com">
<fscdefaults>
...
</fscdefaults>
<fscgroup id="g1">
<fsc id="fsc1" address="http://localhost:5551">
<volume id="myvol" root="data/myvol/>
</fsc>
<grouproute destination="g3">
<routethrough groups="g2" priority="0" />
</grouproute>
</fscgroup>
<fscgroup id="g2">
</fsc>
<assignedfsc fscid="fsc1" priority="0" />
</clientmap>
</fscgroup>
<fscgroup id="g3">
<volume id="testvol" root="//nfsserver1/datashare/testvol" priority="0"/>
</fsc>
<volume id="testvol" root="//nfsserver1/datashare/testvol" priority="1"/>
</fsc>
</fscgroup>
</fmsenterprise>
</fmsworld>
Configuring volume failover during file import
You can provide volume failover during file import by defining a failover volume for importing files. If
this behavior is configured, the system checks the target volume before import. If the target volume is
filled to a specified capacity, the file is directed to a specified failover volume.
Volume failover during file import proceeds as follows:
1. A user initiates a file import. The targeted volume is determined by the default volume specified for
the user’s group. If store and forward functionality is configured, the importing volume is the
specified default local volume.

© 2021 Siemens
Specifying alternate failover volumes
Note:
Default volumes and default local volumes are defined using the Organization application.
These settings are typically defined when the user account is created.
Generally, default volumes are defined at the group level, not the user level. Siemens Digital
Industries Software recommends that you do not define a default volume for each user; such
granular assignments are time-consuming to maintain. When the user’s default volume is not
specified, the group's default volume information is used.
2. The system searches for the cached value of the percent full of the targeted volume.
• If a cached value is found, the value’s age is checked. If it exceeds the time specified by the
TC_Volume_Status_Resync_Interval preference, a fresh value is requested by an FSC admin
call. A new percent full value is retrieved and cached.
The percent full values are cached to prevent excessive FSC requests. The
TC_Volume_Status_Resync_Interval preference specifies the minimum amount of time that
can pass before the percent-full value of a volume is retrieved from an FSC.
• If a cached value is not found, the value is requested by a FSC admin call. The percent-full value
is retrieved and cached.
3. The system compares the percent-full value with the percent full specified by the
TC_Volume_Failover_Trigger preference.
• If the trigger point is not met, the system imports the file to the original target volume.
• If the trigger point is met, the system imports the file to the failover volume defined by the
TC_Volume_Failover_Name preference.
The same behavior applies to default local volumes if store and forward functionality is configured.
Specifying alternate failover volumes
When a volume size is bigger than a certain threshold, you may decide to set the volume as read-only
and create a new volume with the same assigned users and groups. All subsequent file operations
should then use this new volume. There are conditions under which file write operations from the
Dispatcher Server fail because it cannot write back to the original volume.
To overcome this problem, the TC_Volume_Failover_Volume_Map preference allows specifying failover

(alternate) volumes for one or more volumes in the system. Use this when a volume is marked as read-
only or otherwise inaccessible for new write operations. Specifying the alternate volume ensures that
future writes are done to this alternate volume rather than the currently set volume. Each value set in
the preference should be of the form: source-volume:destination-volume. The mappings can be
cascaded, for example: VolA:VolB and VolB:VolC. This indicates that the system should use VolC when
VolA is the current volume.

© 2021 Siemens
The Teamcenter administrator typically follows these steps to enable this mechanism:
1. Create the new volume in Teamcenter.
2. Grant permissions for the required users and groups to access the new volume.
3. Set the values in the TC_Volume_Failover_Volume_Map preference in Teamcenter, for example,

original-volume:new-volume.
4. Set the original volume as read-only.
Note:
If permissions are not granted to a certain user to access the new volume, the system does not
error out. Instead, it defaults to the volume currently set for that user and group.
Volume data
Volume allocation rules
You can move files from one volume to another using allocation rules. Use the move_volume_files
utility with the -rulesfile argument to retrieve an XML file containing the volume allocation rules
template, edit the rules as desired, and then use the utility to move the volume files.
You can write volume allocation rules based on various dataset, item, item revision, and volume criteria.
Example:
Consider a site using both CAD and JT files. Because JT files are volatile and can be recovered from
the CAD file if lost, they are on a different backup schedule. The administrator decides to store all
JT files in a different volume than the CAD files.
Rules can be written in the XML file specifying different target volumes for the JT and CAD files.
Each time the utility is run, JT and CAD files not already stored in the respective target volume are
moved to the appropriate destination.
The utility can be run manually, as a cron job, or as a scheduled task.
The volume allocation rules accept the following criteria.

© 2021 Siemens
Volume allocation rules
User criteria Sample rules
ID <usercriteria name="id" value="tcdba" />
Group <usercriteria name="group" value="dba" />
Project <usercriteria name="project" value="FMS" />
Item criteria Sample rules
Item ID <itemcriteria name="id" value="ABC" />
Owning user <itemcriteria name="user" value="tcdba" />
Owning group <itemcriteria name="group" value="dba" />
Owning project <itemcriteria name="project" value="FMS" />
Attached dataset type <itemcriteria name="type" value="UGMaster" />
Item revision criteria Sample rules
Owning user <itemrevisioncriteria name="user" value="tcdba" />
Owning group <itemrevisioncriteria name="group" value="dba" />
Owning project <itemrevisioncriteria name="project" value="FMS" />
Attached dataset type <itemcriteria name="type" value="UGMaster" />

© 2021 Siemens
Dataset criteria Sample rules
Dataset type <datasetcriteria name="type" value="UGMaster" />
Owning user <datasetcriteria name="user" value="tcdba" />
Owning group <datasetcriteria name="group" value="dba" />
Owning project <datasetcriteria name="project" value="FMS" />
Volume ID <datasetcriteria name="volume" value="vol1" />
Created before <datasetcriteria name="createdbefore"

value="20-Oct-2020 12:12" />
Created after <datasetcriteria name="createdafter"

value="10-Oct-2020 16:24" />
Volume data criteria Sample rules
Volume free space <volumecriteria name="availablespace" value="50GB" />
Allocate volume data
1. Access the volume allocation rules XML template file by running the move_volume_files utility
with the -outrulesfile argument set to the desired name of the new XML template. For example,
the following command creates an XML template named VolumeSelectionRules.xml:
move_volume_files -u=tc-admin-user -p=password -g=group

-outrulesfile=VolumeSelectionRules.xml
The XML file is stored in the current directory.
2. Edit the volume allocation rules template to define volume allocation rules for your site.
3. Evaluate the rules and store the results by running the move_volume_files utility with the -
rulesfile argument set to the name of the XML file and the -f argument set to list. For example:

© 2021 Siemens
DTD file of volume allocation rules

-rulesfile=VolumeSelectionRules.xml -f=list
4. Evaluate the rules and move the specified files by running the move_volume_files utility with the -
rulesfile argument set to the name of the XML file and the -f argument set to move. For example:

-rulesfile=VolumeSelectionRules.xml -f=move
5. (Optional) Exclude specific volumes from all listing and transfer actions using the -excludedvollist
argument to process a file containing the list of volumes to be excluded. This argument is typically
used to list default local volumes (store and forward volumes) to ensure the files stored in these
temporary volume locations are not transferred.
Use either the full path to the file, or use the partial path/file name, in which case the utility
searches for the file name in the current directory.
Any number of volumes can be specified in this file. Each entry must be a valid volume name, listed
on its own row in the file.
You can run this utility as a cron job or as a scheduled task, using process_move_file_volumes as a .sh
or .bat script, respectively.
DTD file of volume allocation rules
Reference the volumereallocation.dtd file for the elements and references used in the volume
allocation rules XML file and their syntax. The DTD file is stored in the TC_DATA directory.


<!ELEMENT volumereallocation (reallocationrule+)>

<!ELEMENT reallocationrule (usercriteria*, itemcriteria*, itemrevisioncriteria*,
datasetcriteria*, volumecriteria*)>
<!ATTLIST reallocationrule id CDATA #REQUIRED>
<!ATTLIST reallocationrule destination CDATA #REQUIRED>
<!ELEMENT usercriteria EMPTY>
<!ATTLIST usercriteria name (id|group|project) #REQUIRED>
<!ATTLIST usercriteria value CDATA #IMPLIED>
<!ELEMENT itemcriteria EMPTY>
<!ATTLIST itemcriteria name (user|id|group|project|type) #REQUIRED>
<!ATTLIST itemcriteria value CDATA #IMPLIED>
<!ELEMENT itemrevisioncriteria EMPTY>
<!ATTLIST itemrevisioncriteria name (user|group|project|type) #REQUIRED>
<!ATTLIST itemrevisioncriteria value CDATA #IMPLIED>
<!ELEMENT datasetcriteria EMPTY>
<!ATTLIST datasetcriteria name (user|type|group|project|volume|createdbefore|
createdafter) #REQUIRED>
<!ATTLIST datasetcriteria value CDATA #IMPLIED>
<!ELEMENT volumecriteria EMPTY>
<!ATTLIST volumecriteria name (availablespace) #REQUIRED>
<!ATTLIST volumecriteria value CDATA #IMPLIED>

© 2021 Siemens
Sample volume allocation rules XML file
Retrieve the volume allocation rules XML template by running the move_volume_files utility with the -
outrulesfile argument set to the desired name of the new XML template.
The utility generates the XML template and stores it in the current directory. For example:

<!DOCTYPE volumereallocation SYSTEM "volumereallocation.dtd">
<volumereallocation>
<reallocationrule id="rule1" destination="volume1">
<usercriteria name="id" value="tcdba" />
<usercriteria name="group" value="dba" />
<usercriteria name="project" value="Aircraft" />
<volumecriteria name="availablespace" value="1GB" />
</reallocationrule>
<itemcriteria name="id" value="myitem" />
<itemcriteria name="project" value="Aircraft" />
<datasetcriteria name="type" value="UGMaster" />
</reallocationrule>
<usercriteria name="project" value="CarPart" />
<datasetcriteria name="type" value="DirectModel" />
</reallocationrule>
</volumereallocation>
Edit the rules template to define volume allocation rules for your site. For example:

<!DOCTYPE VolumeReallocationInfo SYSTEM "volumereallocation.dtd">
<volumereallocation>
<reallocationrule id="VM_0" destination="DV">
<usercriteria name="id" value="tcdba" />
<usercriteria name="group" eqvalue="dba" />
<usercriteria name="role" nevalue="Designer" />
<usercriteria name="project" value="11234556" />
<volumecriteria name="availablespace" value="10000000" />
</reallocationrule>
<reallocationrule id="VM_1" destination="vol1">
<itemcriteria name="id" value="ABC" />
<itemcriteria name="project" value="11234556" />
<datasetcriteria name="type" value="UGMaster" />
</reallocationrule>
<datasetcriteria name="type" value="JT" />
<usercriteria name="project" value="CarPart" />
</reallocationrule>
</volumereallocation>

© 2021 Siemens
Move volumes within an enterprise
Move volumes within an enterprise
You can move volumes across a WAN or LAN from one FSC to another FSC within a single enterprise
using the fscadmin utility.
For example, as shown in the following graphic, you can move Volume 1 from FSC A to FSC B. To do so,
you must remove the volume UID definition from FSC A and add it to FSC B. Because the volume UID is
not changed during the move, there is no impact to file access.
Read/write tickets may not be honored during the move operation. This has a significant impact on a
production system. To move a volume within an enterprise with minimum impact:
1. Use the backup_modes utility to put Teamcenter in read-only mode. For example:
backup_modes -m=rdonly -u=tc-admin-user -p=password -g=group
2. Use your operating system copy tools to copy the entire volume directory across a LAN or WAN
from its source location in FSC A to its destination location in FSC B.
3. Use the fscadmin utility (stored in the FSC_HOME directory) to retrieve the FMS primary
configuration of FSC A. Note the volume UID and the enterprise ID of FSC A. For example:
fscadmin -s http://FSCA-address:port ./config
4. Use the fscadmin utility to remove the volume UID from the FMS primary configuration file for FSC
A. For example.
fscadmin -s http://FSCA-address:port ./config/removevolume/nvargs/

volumeid=volume-UID;enterpriseid=site-ID;fmsconfigentryonly=1

© 2021 Siemens
5. Use the fscadmin utility to add the destination location and volume UID to the FMS primary
configuration file of FSC B using one of the following identifiers:
• Using FSC ID. For example, type the following all on one line:
fscadmin -s http://FSCB-address:port ./config/newaddvolume/nvargs/

root=destination-location;volumeid=volume-UID;
fscid=FSC-B;enterpriseid=site-ID
• Using the file store group. For example, type the following all on one line:

filestoregroupid=Group;enterpriseid=site-ID
• Using the load balancer ID. For example, type the following all on one line:

loadbalancerid=load-balancer;enterpriseid=site-ID
6. Using your operating system tools, delete the volume under FSC A.
7. Use the backup_modes utility to put Teamcenter in read-only mode. For example:
backup_modes -m=normal -u=tc-admin-user -p=password -g=group
8. In Teamcenter, using the Organization application, select the volume, modify the volume’s path
name, and click Modify.
In the Move Volume dialog box, at the prompt Do you want to move files?, select No. Select Yes
to change the volume location without moving the volume data.
Note:
Use the Organization application to move a volume from one location to another on the same
host.
Load balancing FMS
Configuration load balancing
FMS configuration is controlled through a primary configuration file (fmsmaster_fscid.xml) that is

hosted by an FSC referred to as the primary or configuration FSC. You can also configure more than one
primary or configuration FSC so that the additional FSCs load balance each other.
Configuration load balancing allows the client or the FMS network to use any one of the FSC
configuration servers in a rotating manner.

© 2021 Siemens
Introduction to load balancing FMS data
Similar to other load balancing configurations in FMS, the priority attribute determines the load
balancing configuration, such that all FSCs with the same priority value (such as 0) are considered
balanced.
Load balancing priority is configured in the assignedfsc element in the clientmap element. For example

</clientmap>
Note that in this context, the configuration FSC does not need not be the same as the bootstrap FSC
specified using Fms_Bootstrap_Urls or similar mechanisms.
• If the bootstrap URL is indeed the same as the primary configuration FSC URL, to then achieve load
balancing, you must also specify all of the relevant Primary FSC URLs in the bootstrap.
• If the bootstrap URL is not the Primary FSC URL (for example, if it is a reverse proxy URL), the load
balancing will then work with the assignedfsc priority settings described here.
Introduction to load balancing FMS data
You can load balance FMS data by distributing the network access load among same-priority elements.
Do this by setting selected XML elements to equal priority.
When elements of equal priority are encountered, FMS attempts to distribute the network access load
among the same-priority items. Lower-priority (numerically larger) elements are processed only after all
of the higher-priority (numerically smaller) elements are depleted without successful fulfillment of the
request.
You can assign same-priority values to the following elements:
Element Location
accesson Within the filestoregroup and fsc elements in the fmsmaster_fscid.xml file
assignedfsc Within the clientmap elements in the fmsmaster_fscid.xml file
defaultfsc Within the multisiteimport elements within the fmsenterprise elements in

the fmsmaster_fscid.xml file
entryfsc Within the fscgroup elements in the fmsmaster_fscid.xml file
exitfsc Within the fscgroup elements in the fmsmaster_fscid.xml file

© 2021 Siemens
Element Location
filestore Within the fsc elements in the fmsmaster_fscid.xml file
fscmaster The fsc.xml file
logvolume Within the filestoregroup and fsc elements in the fmsmaster_fscid.xml file
parentfsc The fcc.xml file.
transientvolume Within the filestoregroup and fsc elements in the fmsmaster_fscid.xml

file.
volume Within the filestoregroup and fsc elements in the fmsmaster_fscid.xml

file.
Note:
The routethrough elements within grouproute elements of the fmsmaster_fscid.xml file cannot
be load balanced.
This functionality is triggered entirely by the values of existing XML priority attributes. Load balancing
FMS elements requires no DSD or structural configuration changes. Load balancing is fully backward
compatible with existing and previous FMS configurations where unique priorities were rigidly enforced.
Existing configurations using unique priorities will experience no behavioral effect from the
implementation of the load balancing capabilities.
Examples of load balancing FMS data
The following examples illustrate how to load balance FMS data by assigning equal priorities to various
elements.
• Parent FSCs
The parentfsc element selects the FSC server(s) from which an FCC attempts to download its
configuration information. An FCC randomly selects from among elements of equal priority.
In the following example, the parentfsc setting results in an FCC first attempting to download its
configuration from either fsc1 or fsc2 approximately half of the time. When considered as an overall
effect among all clients, the requests for FCC configuration information are distributed approximately
equally between fsc1 and fsc2.
<parentfsc address="fsc1:4444" priority="0"/>
<parentfsc address="fsc2:4444" priority="0"/>
• Direct FSC routes

© 2021 Siemens
Introduction to using external hardware devices for load balancing
If the fscgroup element contains cross-mounted resources, you can load balance direct FSC routing.
An FCC randomly selects from among elements of equal priority.
Note:
This feature applies only when direct FSC routing is enabled on the FCC.
In the following example, if the primary configuration file contains the following elements, the FCC
directs requests for data on the volume vol1 approximately equally among FMS servers fsc1 and fsc2.
<filestoregroup id="fsgroup1">
<volume id="vol1" root="/data/vol1"/>
</filestoregroup>
<fsc id="fsc1" address=“http://fsc1:4444">

<filestore groupid="fsgroup1" priority="0"/>
</fsc>
<fsc id="fsc2" address=“http://fsc2:4444">

<filestore groupid="fsgroup1 priority="0""/>
</fsc>
• Entry FSCs
The entryfsc attribute within the fscgroup element of the fmsmaster_fscid.xml file defines which of
the FSCs in the FSC group are preferred for access from outside the FSC group. An FSC randomly
selects from among elements of equal priority.
In the following example, the presence of the following elements cause requests coming from other
FSC groups to be sent to router1 and router2 each approximately half of the time:
<entryfsc fscid="router1" priority="1"/>
<entryfsc fscid="router2" priority="1"/>
Using external hardware devices for load balancing
Introduction to using external hardware devices for load balancing
You can load balance FMS data using external hardware load balancers. These devices exist within the
network topology, but are not part of the FMS system. This load balancing method allows you to route
requests from multiple clients among a number of FSCs. You must configure the devices so that each
target server receives an equal load. Your goal is to minimize overall response time at the requesting
clients by routing requests to the most available server.
Configure FMS to recognize these third-party hardware devices using the loadbalancer XML element in
the fmsmaster_fscid.xml file. Identify which FSCs are within the scope of a load balancer using the
loadbalancerid attribute of the fsc element. Each loadbalancer XML element that contains one or

© 2021 Siemens
more resources (volume, logvolume, transientvolume, or accesson) or one or more filestore entries
must have at least one FSC in its scope.
FSCs within the scope of the specified load balancer serve all resources declared in the loadbalancer
element, and perform the routing behaviors (entryfsc, exitfsc, assignedfsc) attributed to the load
balancer. This prevents FSCs within the scope of a load balancer from forwarding requests back to the
load balancer.
To clients and FSCs not within the scope of the specified load balancer, the load balancer appears as a
single FSC which serves all of the balanced resources and exhibits the load balancer’s routing behaviors.
Direct FSC routing, intergroup routing, and intragroup routing all function on this basis. Thus clients
request the balanced resources only from the load balancer.
Note:
The loadbalancer XML element is similar to the fsc XML element. The significant difference is that
this element cannot be used as the ID of the FSC element in a local FSC configuration file. This is
because the loadbalancer XML element must always represent external hardware, never an
actual FSC.
This element can only be used in the primary configuration file (fmsmaster_fscid.xml). You can use the
loadbalancer ID as a value for any of the following attributes within the FSC group in which it is
declared:
entryfsc fscid
exitfsc fscid
assignedfsc fscid
fsc loadbalancerid
The loadbalancer element can contain any of the following child elements:
• connection
• fccdefaults
• fscdefaults
• filestore
• Any type of resource, such as volume, logvolume, transientvolume, accesson
Load balancers support health checking for their servers. Health checking is generally configured to use
a particular URL within the back-end servers.
Because FSC servers support few requests that do not require tickets, many default health checks return
HTTP 400 errors that load balancers may interpret to mean service is unavailable. To avoid these errors,

© 2021 Siemens
Local load balancing example
Siemens Digital Industries Software recommends using HTTP HEAD or GET requests for /Ping or /
favicon.ico resources. These requests return an HTTP 200 status and verify the FSC is alive.
For WebSEAL, this configuration is controlled using the ping-uri configuration element, documented in
the WebSEAL product documentation.
Local load balancing example
In the following example, three volumes are cross-mounted and served by two FSCs (FSC1 and FSC2),
which are serviced by an external load balancer. A third FSC services configuration information. Direct
FSC routing enables all of the clients to access volume data through the load balancer, which forwards
the requests to FSC1 and FSC2. These two FSCs share equal responsibility for providing volume data
access to the clients.
This implementation of local external load balancing is configured using the following XML code. Any
FSC containing a loadbalancerid element lies within the score of the specified load balancer. In this
example, FSC1 and FSC2 are within the scope of loadbal. These servers must reference data through
the load balancer. All servers within the scope of the same load balancer provide equivalent service in
regard to load balanced resources.
<fscgroup id="fscGroup1">

© 2021 Siemens

<filestoregroup id="vols">
</filestoregroup>
<loadbalancer id="loadbal" address="http://lb.ugs.com:4444">

<filestore groupid="vols" />
</loadbalancer>

<fsc id="fsc1" address=“http://fsc1.ugs.com:4444"

loadbalancerid="loadbal">

</fsc>
<fsc id="fsc2" address="http://fsc2.ugs.com:4444"

</fsc>

<fsc id="fscConfig" address="http://fscConfig.ugs.com:4444" />


<assignedfsc fscid="fscConfig" />
</clientmap>
</fscgroup>
Remote load balancing example
In the following example, three volumes are cross-mounted and served by two FSCs (FSC1 and FSC2)
which are serviced by an external load balancer. Clients are assigned to a remote FSC cache server,
which provides configuration information and caching at the remote site. As in the previous example,
direct FSC routing enables all of the clients to access volume data through the load balancer, which
forwards the requests to FSC1 and FSC2. These two FSCs share equal responsibility for providing volume
data access to the clients.
Additionally, an FSC concentrator can be used as a local cache concentrator and/or a router node for
requests to additional FSC groups.

© 2021 Siemens
Remote load balancing example
This implementation of remote external load balancing is configured using the following XML. Adding
the fscConcentrator element to an FSC group in the fmsmaster_fscid.xml file allows it to act as a
router and cache concentrator for data in this FSC group and/or other FSC groups. Defining the
loadbalancer id attribute assigns the load balancer preference for requests for data it serves (even
through it is a lower priority). Without this preferential treatment, all incoming requests are routed
through the FSC concentrator.
<fscgroup id="fscGroup1">

<filestoregroup id="vols">
</filestoregroup >
<loadbalancer id="loadbal" address="http://lb.ugs.com:4444">
<filestore groupid="vols" />
</loadbalancer>

© 2021 Siemens
</filestoregroup>

<fsc id="fsc1" address=“http://fsc1.ugs.com:4444"

</fsc>
<fsc id="fsc2" address="http://fsc2.ugs.com:4444"

</fsc>

<fsc id="fscConcentrator"
address="http://fscConcentrator.ugs.com:4444" />


<fscentry fscid="fscConcentrator" />

<fscentry fscid="loadbal" priority="1"/>
</fscgroup>
<fscgroup id="fscRemoteGroup">
<fsc id="fscRemote" address=“http://fscRemote.ugs.com:4444">
</fsc>

© 2021 Siemens
Introduction to client maps

<assignedfsc fscid="fscRemote" />
</clientmap>
</fscgroup>
FMS client maps
Introduction to client maps
The client map element in the primary configuration file (fmsmaster_fscid.xml) allows FCCs to access
the FMS network.
To log on to the FMS network, an FCC must locate its assigned FSC server. To do so, it sends a message
to its default FSC server. The default FSC sever retrieves the FCC IP address from the message protocol. It
performs an AND operation on the mask value and IP address, then compares the results with the
results of the same operation performed on the subnet/mask values of available servers. The FCC is
directed to the FSC server with the matching client map.
You can configure the client map element using either subnet/mask attributes, DNS-based attributes, or
a combination of both.
Subnet/mask attributes in a client map
A subnet is a range of logical addresses within the address space assigned to an organization. Within the
realm of FMS client map functionality, the subnet attribute is the base IP address.
The mask attribute masks a requesting FCC IP address, then compares the results with the subnet to
determine whether the requesting FCC address is assigned to a particular client map. The client map
contains a set of FSCs to be assigned to the FCC. This mapping technique works if your clients can group
their FCCs to numerically adjacent IP addresses, for example:

<assignedfsc fscid="fsc_engC" priority="0"/>
</clientmap>
When using the subnet/mask method, you can create a default client map by setting the mask attribute
value to 0.0.0.0. This creates a client map that matches all FCC addresses, for example:

</clientmap>

© 2021 Siemens
Warning:
This technique cannot be used in conjunction with DNS-based client map attributes. If you use a
mask value of 0.0.0.0 in conjunction with DNS-based client map attributes, the process fails.
CIDR attributes in a client map
You can use Classless Inter-Domain Routing (CIDR) notation to specify subnetted IPv4 or IPv6 addresses.
(A subnet is a range of logical addresses within the address space assigned to an organization.) Within
the realm of FMS client map functionality, the subnet attribute is the base IP address.
CIDR notation uses the following format:
IPv4-or-IPv6-address / prefix-length
The prefix length specifies how many leftmost bits of the address specify the prefix. This is an alternate
way of using the subnet and mask attributes in a clientmap element in the fmsmaster_fscid.xml file.
The prefix length masks a requesting FCC IP address and then compares the results with the prefix of the
IP address to determine whether the requesting FCC address is assigned to a particular client map. The
client map must contain a set of FSCs to be assigned to FSC clients.
Note:
The maximum prefix length is 32 for IPv4 addresses and 128 for IPv6 addresses.
• The following example illustrates a default client map using the CIDR method with an IPv4 address:
<clientmap cidr="216.068.063.000/24">
</clientmap>
• The following example illustrates a client map using the CIDR method with an IPv6 address:
<clientmap cidr="fe80::7a5c:6199:766a:812e/64">
</clientmap>
When using the CIDR method, you can create a default client map by setting the address and prefix
length to zeroes.
<clientmap cidr="0.0.0.0/0">
</clientmap>

© 2021 Siemens
Domain name client maps
<clientmap cidr="0::0/0">
</clientmap>
Warning:
This technique cannot be used in conjunction with DNS-based client map attributes. If you use a
prefix length value of 0 in conjunction with DNS-based client map attributes, DNS client attributes
are not considered.
Domain name client maps
Domain name client maps allow you to administer client map functionality based on domain name
servers. There are four DNS-based client map attributes. Only one of the attributes can be specified per
clientmap element in the fmsmaster_fscid.xml file.
Attribute Use
dnszone Assigns all the FCCs within the specified DNS zone to an FSC or set of
FSCs, for example:
<clientmap dnszone="engA.company.com">
<assignedfsc fscid="fsc_engA" priority="0"/>
</clientmap>
dnshostname Assigns a specific FCC to an FSC or set of FSCs, for example:
#clientmap dnshostname="wkst1.engA.company.com"$
#assignedfsc fscid="fsc_engB" priority="0"/$
#/clientmap$
default Defines the FSCs to be assigned when no other client map matches the
FCC address. This default client map applies to both subnet/mask and
domain name client map matches. If the default is not defined and the
client map match fails, then the FCC assignment fails, for example:
<clientmap default="true">
</clientmap>
dns_not_defined Use this attribute if you expect a reverse DNS lookup for an FCCs domain
name address cannot be performed. (For example, if it is an unregistered
address.) If this attribute is not defined and the reverse DNS lookup fails
then FCC assignment fails, for example:
<clientmap dns_not_defined="true">
</clientmap>

© 2021 Siemens
How the system processes client maps
Whenever an FCC requests its assigned FSCs from the FSC, the system performs the following actions in
the following order:
1. A subnet/mask IP match is attempted. If a match is found, its assigned FSCs are returned.
2. If there is no subnet/mask IP match and there are no domain name client maps defined:
• If the default IP client map was configured, its assigned FSCs are returned.
• If the default client map is not configured, a null is returned.
3. If there is no IP subnet/mask match, but there is at least one dnszone or dnshostname attribute
defined, a reverse DNS lookup of the FCC’s domain name address is performed.
• If the reverse DNS lookup fails and the dns_not_defined attribute is defined, its assigned FSCs
are returned.
If the reverse DNS lookup fails, but the dns_not_defined attribute is not defined, an error
message is logged and a null value is returned.
• If the reverse DNS lookup succeeds, the domain name client maps are searched for a match. If
one is found, its assigned FSCs are returned.
4. If no domain name client map match is found and the default attribute is defined, its assigned
FSCs are returned.
5. If no domain name client map is matched and no default attribute is defined, the query fails and a
null is returned.
Client map specificity
The subnet/mask client maps and the domain name client maps are applied in order of specificity.
Specificity is implemented by the following algorithms on the two separate lists.
Subnet/mask client maps are sorted based on the size of their mask values. Client maps with larger mask
values specify a bigger mask over the FCC IP address, so they are more specific. Client maps with larger
masks are searched first for a match.
In the following example, the "255.255.255.192" mask is more specific than the "255.255.255.000"
mask, so it is sorted first in the subnet/mask clientmap list.
subnet="192.168.000.128" mask="255.255.255.192"
subnet="192.168.000.000" mask="255.255.255.000"
Domain name client maps are sorted based on the length of the string in their dnszone or
dnshostname attributes. In the following example, the support.ugs.com dnszone is the most specific

© 2021 Siemens
Accessing multiple databases through a single FCC
so it is sorted first in the domain name client map list. The com dnszone is the least specific client map
and is sorted last.
dnszone="support.ugs.com"
dnszone="ugs.com"
dnszone="com"
You can access multiple databases through a single File Management System (FMS) client cache (FCC).
Teamcenter supports multiple installations on the same machine to access multiple site IDs (databases).
For example, consider a part supplier with multiple customers, requiring access to each customer’s PLM
data, where the customers are in direct competition with each other and each customer has a different
security key. The part supplier can modify the local FCC file or the primary configuration file at the
primary site to allow the FCC to determine from which FSCs to request additional site data.
Implement this functionality by configuring the FCC's local fcc.xml file or the primary configuration file
(fmsmaster_fscid.xml) at the primary site to provide the configuration data required so the FCC can
determine from which FSCs to request additional site data. The FCC receives this configuration data
upon startup when it loads data from the fcc.xml file and downloads configuration data from the
fmsmaster_fscid.xml file. Do this by modifying the fcc.xml file or fmsmaster_fscid.xml file to
configure your FCCs to route each FMS request to a different FSC (or set of FSCs) based on the site ID
contained in each request ticket. Each FCC continues to have one or more default FSC destination to
which it routes requests associated with unknown site IDs.
To implement this functionality:
• Each database must have a unique site ID.
• Each database may be assigned its own security key to prevent unauthorized access from other PLM
systems. Each competitor's PLM data should be controlled by a separate database.
• Configure either your fmsmaster_fscid.xml file or fcc.xml files to support multiple databases by
including valid configuration elements referencing at least one parent FSC that supports each of the
other databases to which the client may connect.
• The proper multisite FCC client configuration must be present in the FMS_HOME directory from
which the FCC is started. Siemens Digital Industries Software recommends that you use a single
FMS_HOME environment variable setting to point to the combined configuration.
• FSC servers for all databases must be online, properly configured, of the proper version, and
functional.
Following are configuration examples:
• fmsmaster_fscid.xml configuration example

© 2021 Siemens
Modify your fmsmaster_fscid.xml file to support multiple databases based on the following example.
The code defining multiple databases is in italic.

…
<fmsworld>
<fmsenterprise id="myenterprise">
…
<fccdefaults>

<site id="globalsite" overridable="true">
<parentfsc address="192.0.2.1:4220" priority="0"/>
</site>
</fccdefaults>
<fccdefaults>

<site id="groupsite" overridable="true">
</site>
</fccdefaults>
<fsc id="myfsc" address="127.0.0.1:4444">



<fccdefaults>

<site id="specialsite" overridable="true">
</site>
</fccdefaults>
<volume id="myvol" root="e:/FMSShare/FMSTestExplodedWar"/>
<volume id="testvol" root="d:/temp/testvol"/>
<transientvolume id="mytransvol" root="e:/FMSShare/Temp"/>

<transientvolume id="testtransvol" root="d:/temp/testtempvol"/>
</fsc>
…
</fscgroup>
</fmsenterprise>
</fmsworld>
• fcc.xml file configuration example

Modify your fcc.xml file to support multiple databases based on the following example. The code
defining multiple databases is in italic.

© 2021 Siemens

…
<fccconfig>
<fccdefaults>
<property name="FCC_CacheLocation" value="~/FMSCache"/>
<property name="FCC_MaxWriteCacheSize" value="10M"/>
<property name="FCC_MaxReadCacheSize" value="30M"/>
…

<site id="othersite" overridable="true">
<-- These parentfscs and assignment mode apply only to “othersite." -->
<assignment mode="clientmap"/>
</site>
</fccdefaults>

</fccconfig>
• fcc.xml file personal use configuration example

Modify your fcc.johndoe.xml file to allow the user (johndoe) to access a specific site (personalsite)
based on the following example. The fcc.johndoe.xml file should be owned by the user with the
name indicated in its file name (johndoe) and given owner-only access. The code defining the access
to the specific site is in italic.
Note:
The file name must include the user name, as indicated. Do not use this method in a fcc.xml file
shared by multiple users on the same machine, specifically, at sites using user-specific fcc.xml
files.
<fccconfig>
<fccdefaults>

<site id="personalsite" overridable="true">
</site>
</fccdefaults>
</fccconfig>

© 2021 Siemens
Compressing FMS files
Compress files for multisite transfer
You can compress File Management System (FMS) files before transferring them between FMS server
caches (FSCs), increasing performance and reducing network traffic. File compression is available for
FSC to FSC transfers across groups and across sites.
File compression is controlled with two fscdefault elements (FSC_DoNotCompressExtensions and

FSC_WANThreshold) and the compression attribute, available in the defaultfsc and linkparameters
elements.
To configure file compression for multisite transfer:
1. Specify the file extensions you do not want compressed by adding the extension names to the
FSC_DoNotCompressExtensions element, located within the fscdefault element in the
fmsmaster_fscid.xml file.
Enter values as a comma-separated list. FSCs do not send these file types as compressed files, nor
request compressed content for these file types.
The default value for this element is:
<property-name="FSC_DoNotCompressExtensions"
value="bz,bz2,cab,deb,docm,docx,ear,gif,gz,jar,jpeg,jpg,jt,lha,lzh,lzo,mp3,
mp4,mpg,rar,rpm,sit,taz,tgz,war,xlsm,xlsx,z,zip" overridable="true"/>
2. Specify the minimum file size threshold that must be reached before files are compressed by
setting the FSC_WANThreshold element located within the fscdefault element in the
fmsmaster_fscid.xml file. Files smaller than this value are not compressed. This value also
determines the threshold file size that must be reached before WAN acceleration is used. The
default setting is 256K.
This value also determines the threshold file size that must be reached before WAN acceleration is
used. The default setting is 32K.
3. For multisite transfer, add the compression attribute to the defaultfsc element and set it to gzip.
For example:
<defaultfsc fscaddress="http://localhost:5551" transport="wan" compression="gzip"

maxpipes="4" />
For group-to-group transfer, add the compression attribute to the linkparameters element for
each group and set each instance to gzip. For example:
<linkparameters fromgroup="g2" togroup="g4" transport="wan" compression="gzip"

maxpipes="4" />
maxpipes="4" />

© 2021 Siemens
File compression example
This configuration causes FSCs acting as servers to compress content for all clients that indicate they can
accept gzip compressed responses. It allows all FSCs acting as clients to request compressed content for
whole file transfers across sites and across groups.
File compression example
The following example illustrates how to compress FMS files for transfer across sites and across groups,
increasing performance, and reducing network traffic:
<fmsworld>
<multisiteimport siteid="s1">
<fscgroupimport localgroupid="g2">
maxpipes="4" />
</fscgroupimport>
<fscgroupimport localgroupid="g4">
maxpipes="4" />
</fscgroupimport>
</multisiteimport>
<fscdefaults>


<property name="FSC_ReadCacheLocation" value="$HOME/FSCCache|/scratch/$USER/
FSCCache" overridable="true" />
<property name="FSC_WriteCacheLocation" value="$HOME/FSCCache|/scratch/$USER/
FSCCache" overridable="true" />
<property name="FSC_LogFile" value="$HOME/$FSC_ID.log|/scratch/$USER/$FSC_ID.log"


<property name="FSC_LogLevel" value="WARN" overridable="true" />
<property name="FSC_TraceLevel" value="2" overridable="true" />


<property name="FSC_MaximumReadCacheFilePages" value="4096" overridable="true" />
<property name="FSC_MaximumReadCacheSegments" value="5000" overridable="true" />
<property name="FSC_ReadCacheHashBlockPages" value="2048" overridable="true" />
<property name="FSC_MaximumReadCacheExtentFiles" value="3" overridable="true" />
<property name="FSC_MaximumReadCacheExtentFileSizeMegabytes" value="64"


<property name="FSC_MaximumWriteCacheFilePages" value="4096" overridable="true" />
<property name="FSC_MaximumWriteCacheSegments" value="5000" overridable="true" />
<property name="FSC_WriteCacheHashBlockPages" value="2048" overridable="true" />
<property name="FSC_MaximumWriteCacheExtentFiles" value="3" overridable="true" />
<property name="FSC_MaximumWriteCacheExtentFileSizeMegabytes" value="64"
<property name="FSC_DoNotCompressExtensions"
value="bz,bz2,cab,deb,ear,gif,gz,jar,jpeg,jpg,lha,
lzh,lzo,mp3,mp4,mpg,rar,rpm,sit,taz,tgz,war,z" overridable="true"/>

© 2021 Siemens
</fscdefaults>
<fscgroup id="g2">
<fsc id="fsc2" address="http://localhost:5552"/>
<assignedfsc fscid="fsc2" />
</clientmap>
</fscgroup>
<fscgroup id="g4">
<volume id="testvol" root="$FMS_TESTFILE_DIR" />
<transientvolume id="transvol" root="$FMS_TESTFILE_DIR" />
<accesson id="myvolAearh---sy2a----bHA" root="$FMS_TESTFILE_DIR" username="mrd"

textfileencoding="UTF-8" lineterminationstyle="LF" />
<accesson id="testvolarh---sy2a----bHA" root="$FMS_TESTFILE_DIR" username="mrd"
textfileencoding="ISO-8859-1"
lineterminationstyle="CRLF" />
</fsc>
</fscgroup>

maxpipes="4" />
maxpipes="4" />
</fmsenterprise>
</fmsworld>
Transport methods for compressed files
The transport method that FMS uses to send compressed files is determined by how you configure the
transport and compression elements, file size, file extension, and network configuration.
Transport method Description
Standard LAN download Simple, single-stream download. Supports whole files and ranges.
Best for high bandwidth/low latency networks.
Compressed LAN Single compressed stream. Supports whole files only. Best for
download compressed data.
WAN download Multistream download. Supports whole files and ranges. Best for low
bandwidth/high latency networks. Relies on HTTP range functionality.
The following table lists the transport method used to transport files based the following factors:
compression parameter configuration, file type, and whether the file size is greater than the threshold
value set for the FCC_WANThreshold element.

© 2021 Siemens
Data Share Manager installation overview
Transport Compression File can be File size greater Transport method

value value compressed than threshold
Unset Unset N/A N/A Standard LAN download
lan Unset N/A N/A Standard LAN download
lan gzip Yes No Standard LAN download
lan gzip Yes Yes Compressed LAN download
lan gzip No N/A Standard LAN download
wan Unset N/A No Standard LAN download
wan Unset N/A Yes WAN download
wan gzip Yes No Standard LAN download
wan gzip Yes Yes Compressed LAN download
wan gzip No No Standard LAN download
wan gzip No Yes WAN download
Installing and configuring Data Share Manager
Data Share Manager installation overview
Teamcenter users can use Data Share Manager to asynchronously upload and download files, managing
the processes by pausing, resuming, or canceling them. Data Share Manager is supported on the rich
client, and is a separate program with its own user interface.
Data Share Manager can be installed on Windows, Linux, and Mac OS clients. It can be used to manage
file uploads and downloads for the rich client. Data Share Manager must be installed if you require
external site file virus scanning.
Note:
If a client has a previous version of Data Share Manager installed, uninstall the earlier version
before installing the new version of Data Share Manager.
Follow this process to install Data Share Manager:

© 2021 Siemens
1. Data Share Manager must be installed with a public key that grants access to the Teamcenter
database for end users to use Data Share Manager. Provide public keys using either of the following
methods:
• Provide separate key files to end users using the instructions in Exporting a public key for the
data share manager. (This is the only way to distribute keys on non-Windows platforms.)
• Bundle the key files with the Windows-based Data Share Manager stand-alone installer so the
keys are included when end users run the Windows stand-alone installer. Refer to Bundle
keys with the Windows stand-alone installer for the Data Share Manager for instructions on
bundling key files with the installer.
2. Set the Use_DataShare_Manager preference to true on the server. Doing so activates Data Share
Manager for file uploading and downloading.
Tip:
If users prefer to the synchronous import and export mechanism for file upload and
download instead of using Data Share Manager, they can set the Use_Datashare_Manager
preference to false with a User protection scope.
3. If the client has a previous version of Data Share Manager installed, uninstall the earlier version
before installing the new version of Data Share Manager.
Install Data Share Manager using the stand-alone installer for your platform.
Exporting a public key for the data share manager
Data Share Manager must be installed with a public key that grants access to the Teamcenter database.
If this key has not been installed, users will receive the an error message stating "The Task File "file-
name.plmd" required the key file "key-file-name.x509", which was missing".
By default, each Teamcenter database contains a private/public key pair that validates Data Share
Manager clients accessing the database. Export and install the public key as follows.
1. Export the public key using the install_datasharekeys utility:
install_datasharekeys -u=username -p=password -g=dba -f=exp_pubkey
This exports a *.pem file and a *.x509 key file.
2. Zip the resulting *.x509 key file into a keys.zip file. (The .pem file is not needed in the ZIP file.)
Ensure the *.x509 file is in a \keys directory in the keys.zip file so it can be properly read by
installers.
3. If users need access to multiple databases from their client, export a public key for each database
and add it to the keys.zip file.

© 2021 Siemens
Bundle keys with the Windows stand-alone installer for the Data Share Manager
4. Distribute the public keys to individuals who need to install the Data Share Manager in either of the
following ways:
• keys.zip file
Distribute the keys.zip file to users and tell them to point to this file when they install the Data
Share Manager using the stand-alone installer.
• Individual key files

Distribute the *.x509 key files directly to end users and tell them to place the files into their keys
directory after installation using the stand-alone installer. For example, on a Windows machine
that uses the stand-alone installation, end users copy the key files to the C:\Users\username
\Siemens\dsmgr\dm\keys directory.
Rather than provide a separate key file to end users, an administrator can bundle the key file with the
Windows-based Data Share Manager stand-alone installer. Then the keys are already included when end
users run the stand-alone installer.
1. The system administrator exports the public key from the database with the install_datasharekeys
utility by running the following from a Teamcenter command prompt:
install_datasharekeys -u=username -p=password -g=dba -f=exp_pubkey
The administrator zips the resulting *.x509 key file from the database into a keys.zip file. If users
need access to multiple databases from their client, the administrator must export a public key for
each database and add it to the keys.zip file.
Tip:
The *.x509 files must be included in the keys.zip file in a \keys directory so they can be
properly read by installers.
2. Copy the Data Share Manager stand-alone installer setup.exe file from the directory where it is
located in the Teamcenter installation source (additional_applications\dsm_install).
3. Place the setup.exe file and the keys.zip file into a temporary directory.
4. On a Windows system, run the iexpress command from a command prompt.
The IExpress wizard runs.

© 2021 Siemens
5. In the Welcome to IExpress 2.0 dialog box, select Create new Self Extraction Directive file and
click Next.
6. In the Package purpose dialog box, select Extract files and run an installation command and
click Next.
7. In the Package title dialog box, type a title for the installer (such as Datashare Manager
Installation) and click Next.
8. In the Confirmation prompt dialog box, select No prompt and click Next.
9. In the License agreement dialog box, select Do not display a license and click Next.
10. In the Packaged files dialog box, click Add button and select the setup.exe file and the keys.zip
file from the temporary directory location. Click Next.

© 2021 Siemens
11. In the Install Program to Launch dialog box, select setup.exe and click Next.
12. In the Show window dialog box, select Default and click Next.
13. In the Finished message dialog box, select No message and click Next.
14. In the Package Name and Options dialog box, click the Browse button and select a temporary
directory where to place the installer. Name the installer file with a temporary name such as
myinstaller.exe. This is to differentiate it from the original setup.exe file. Click Next.
15. In the Configure restart dialog box, select No restart and click Next.
16. In the Save Self Extraction Directive dialog box, click the Browse button and select a temporary
directory where to place the installer directive file. Click Next.
17. In the Create package dialog box, click Next.
The install package file is created.
18. When you look in the temporary directory where the output files were placed, you should see two
new files, for example, myinstaller.EXE and myinstaller.SED.
If the original setup.exe file is in this directory, rename it to something different, such as
setup_original.exe. Then rename the packaged installer file (for example, myinstaller.EXE) to
setup.exe. This new setup.exe file contains the keys.zip file.
19. Distribute the new setup.exe file to end users. When they run the file to install the Data Share
Manager, the bundled keys.zip file is unzipped into the \keys directory.

© 2021 Siemens
Install the Data Share Manager with the stand-alone installer
Use the stand-alone installer to install the Data Share Manager on individual client machines.
1. Ensure the Use_DataShare_Manager preference is set to true on the server or locally as described
in Data Share Manager installation overview.
2. If your client has a previous version of the Data Share Manager installed, uninstall the earlier
version before installing the new version of the Data Share Manager.
3. Browse to the additional_applications\dsm_install folder in the Teamcenter installation source.
4. Run the installation file for your platform.
• Windows: setup.exe
By default, Data Share Manager is installed to be available to only the user installing Data Share
Manager. To have Data Share Manager available for all users on the workstation, run setup.exe
with the /v option and specify an installation directory. For example:
setup.exe /v"INSTALLDIR=c:\apps\dsm_all_users"
• Linux: install.bin
• Mac OS: install.bin
5. Follow the prompts in the installation wizard to install the Data Share Manager.
• On Windows, if your administrator has provided you with a public key file (keys.zip), the wizard
will use this key file automatically if it is stored in the same directory as setup.exe. If the key file
is not found in the same directory as setup.exe, the wizard will prompt you to choose a security
key file. If you know the key file location, check Enter Security Key File, browse to the key file,
and select the file. Leave Enter Security Key File unchecked if you do not know the key file
location. The key file can be installed after Data Share Manager is installed.
On Linux and Mac OS systems, you have the option to choose either a Typical or a Custom setup
type. If your administrator has provided you with a public key file (keys.zip), the wizard will use
this key file automatically if it is stored in the same directory as install.bin when you select a
Typical install set.
• If your administrator has provided you with individual *.x509 public key files, choose the
Complete setup type. (If choosing the Custom setup type, leave Enter Security Key File
unchecked.)
Copy the *.x509 public key files into the keys directory after installing Data Share Manager. For
example, on a Windows workstation, copy the key files to the C:\Users\username\Siemens
\dsmgr\dm\keys directory.
6. Once the installation wizard finishes, log off and log on again to complete installation.
After logon, the Data Share Manager icon is displayed in the system tray.

© 2021 Siemens
Install the Data Share Manager with the stand-alone installer
Handling possible installation errors
If a previous version of Data Share Manager was installed, you may encounter an error stating the older
version of Data Share Manager cannot be uninstalled. This is a known issue with InstallAnywhere, the
underlying installation program. Use the following steps as a workaround:
1. Navigate to the following directory:

(Windows): ProgramFiles\Zero G Registry
(Linux)$HOME/
2. In that directory, locate the file .com.zerog.registry.xml. You may need to enable viewing hidden
files.
3. Create a backup copy of .com.zerog.registry.xml. The file may be required by other

InstallAnywhere-based installations, such as Teamcenter client communication system (TCCS).
4. In .com.zerog.registry.xml, use an ASCII editor to locate and remove the entries for Data Share
Manager and its components:
<product name="Data_Share_Manager" id="8ca639e8-1f16-11b2-8d72-974fa857b767"

upgrade_id="8ca639e8-1f16-11b2-8d72-974fa857b767" version="11.2.0.3"
copyright="2014" info_url="" support_url="" location="C:\Users\<userid>\
Siemens\dsmgr"
last_modified="2015-07-30 10:53:00">
<![CDATA[]]>
<vendor name="Siemens PLM Solutions"
id="54cad4f2-1f16-11b2-bbc2-974fa857b767"
home_page="" email=""/>
<feature short_name="Application" name="Application"
last_modified="2015-07-30 10:53:00">
<![CDATA[This installs the application feature.]]>
<component ref_id="54cad522-1f16-11b2-bbef-974fa857b767"
version="1.0.0.0"
location="C:\Users\<userid>\Siemens\dsmgr\
_Data_Share_Manager_installation\
Change Data_Share_Manager Installation.exe"/>
<component ref_id="54cad521-1f16-11b2-bbed-974fa857b767"
version="1.0.0.0"
location="C:\Users\<userid>\Siemens\dsmgr\dm\com\teamcenter\fms\dlmgr
\
ui\controls\dialogs.css"/>
</feature>
<feature short_name="Help" name="Help" last_modified="2015-07-30
10:53:00">
<![CDATA[This installs the help feature.]]>
<component ref_id="54cad522-1f16-11b2-bbef-974fa857b767"
version="1.0.0.0"
location="C:\Users\<userid>\Siemens\dsmgr

© 2021 Siemens
\_Data_Share_Manager_installation\
Change Data_Share_Manager Installation.exe"/>
<component ref_id="54cad521-1f16-11b2-bbed-974fa857b767"
version="1.0.0.0"
location="C:\Users\<userid>\Siemens\dsmgr\dm\com\teamcenter\fms\dlmgr
\
ui\controls\dialogs.css"/>
</feature>
</product>
<component id="54cad522-1f16-11b2-bbef-974fa857b767" version="1.0.0.0"

name="InstallAnywhere Uninstall Component"
location="C:\Users\<userid>\Siemens\dsmgr\_Data_Share_Manager_installation\
Change Data_Share_Manager Installation.exe" vendor="Siemens PLM
Solutions"/>
<component id="54cad521-1f16-11b2-bbed-974fa857b767" version="1.0.0.0"

name="Common" location="C:\Users\<userid>\Siemens\dsmgr\dm\com\teamcenter
\fms\dlmgr\ui\controls\dialogs.css" vendor="Siemens PLM Solutions"/>
5. Save .com.zerog.registry.xml.
6. Restart the installation file for your platform.
Uninstall Data Share Manager
Note:
You must first close Data Share Manager to stop the Java process before uninstalling. For example,
on a Windows system, right-click the Data Share Manager icon and choose Exit Data Share
Manager. On a Linux system, click the close button (X) in the upper-right corner of the Data Share
Manager user interface and click Yes in the confirmation dialog box.
The way you uninstall Data Share Manager depends on how it was originally installed.
• Teamcenter Environment Manager (TEM)
• Windows systems
1. Use the Windows Task Manager to terminate the dsm.exe process.
2. Remove the Data Share Manager item from the Windows Start menu.
3. Delete the TC_ROOT\dm directory.
• Linux systems

© 2021 Siemens
Import a Data Share Manager private key into an existing database
1. Use the kill -9 command to stop the dsm process.
2. Remove the DSM entries from $HOME/.mime types and $HOME/.mailcap.
3. Delete the TC_ROOT\dm directory.
• Stand-alone installer
Use this method for stand-alone installations.
1. Browse to the location where Data Share Manager is installed. For example, on a Windows
machine, browse to C:\Users\username\Siemens\dsmgr\ directory.
2. In the _Data_Share_Manager_installation directory, run the Change Data_Share_Manager

Installation file.
The uninstall dialog box is displayed.
3. Click Next.
Data Share Manager is uninstalled.
4. Log off and log back on to complete the uninstallation.
Configure Data Share Manager
Import a Data Share Manager private key into an existing database
There is only one active private key in the system that is used by Teamcenter. To import a private data
share key to an already installed database, use the install_datasharekeys utility. This utility is initially
called by the Teamcenter installation process to install the predefined private key.
To use the same key for more than one database (for example, after installing test environments),
perform the following steps:

© 2021 Siemens
1. Export the private key from a database that already uses it (for example, the database that
generated it):
install_datasharekeys -u=username p=password -f=exp_pvtkey
This generates the private_keypairID.pem file.
Caution:
Always keep the private key in a safe and secure place, inaccessible to unauthorized parties,
preferably away from the public key files.
2. Import (seed) the private key into each of the other already-installed databases:
install_datasharekeys -u=username -p=password -f=seed -f=private_keypairID.pem
private_keypairID.pem is the private key file exported from the database in step 1.
Caution:
Always keep the private key in a safe and secure place, inaccessible to unauthorized parties,
preferably away from the public key files.
3. Export the corresponding public key for distribution to the clients from any database that already
has the private key installed (after step 1 or 2):
install_datasharekeys -u=username -p=password -f=exp_pubkey
This generates the public_keypairID.pem and public_keypairID.x509 public key files. The
public_keypairID.x509 public key file can be freely distributed to Data Share Manager clients.
Enable SHA-256 digest algorithm for Datashare Manager
By default, the Datashare Manager uses the MD5 digest algorithm for validating file contents. If the
procedure Enable SHA-256 digest algorithm for the ticket digest has been performed on the Teamcenter
environment, you can configure the Datashare Manager to use the more secure SHA-256 digest
algorithm.
In the dm.properties file, set the following:
com.teamcenter.fms.digest.dlmgr.upload=SHA-256
Enable MD5 validation for Datashare Manager
By default, the Datashare Manager application and protocol use SHA-256 for validating file contents.
You can configure the Datashare Manager to use the less intensive MD5.

© 2021 Siemens
Configure PKI for the Data Share Manager
1. In the dm.properties file, set the following:
com.teamcenter.fms.digest.dlmgr.upload=MD5
Configure PKI for the Data Share Manager
You can configure public key infrastructure (PKI) authentication for Data Share Manager to authenticate
all uploads and downloads from Data Share Manager to FMS volumes. Authentication relies on two-way
encrypted communication between the client (Data Share Manager) and the server (FMS), and requires
the FMS system to be fronted by a reverse proxy configured to use two-way encrypted communications.
To enable PKI authentication for Data Share Manager, open the Data-Share-Manager-installed-location
\dm\dm.properties file and set the com.teamcenter.fms.servercache.ssl.enabled parameter to true.
Setting only this value to true without setting the keystore and truststore properties specifies that the
certificates should be read from the browser store. This is the recommended setting. (Setting the value
to false disables the authentication.) Setting the com.teamcenter.fms.servercache.ssl.enabled
parameter to false (or letting it default to false) may cause PKI-authenticated reverse proxy connections
to fail.
After PKI authentication is enabled, configure the following properties to use file-based keystore or
truststore:
• com.teamcenter.fms.servercache.ssl.keystore=keystore.jks
• com.teamcenter.fms.servercache.ssl.keystorepassword=password
• com.teamcenter.fms.servercache.ssl.keystoretype=jks|pkcs12
• com.teamcenter.fms.servercache.ssl.truststore=truststore.jks
• com.teamcenter.fms.servercache.ssl.truststorepassword=password
• com.teamcenter.fms.servercache.ssl.truststoretype=jks
To allow self-signed certificates from untrusted parties, set the value of the
com.teamcenter.fms.servercache.ssl.allowuntrusted parameter to true.
Warning:
Siemens Digital Industries Software does not recommend using self-signed (untrusted)
certificates. This configuration is provided only for test purposes and should only be used if you
are confident in the identity of the FMS (reverse proxy) URL and the integrity of your connection.

© 2021 Siemens
Routing FSCs between sites
You can define routes to a remote site based on the originating local fscgroup using WAN or LAN
transport modes. This allows you to express multisite routing configuration information without
exposing your entire network topology. Only the gateway FSCs in the remote site need to be known to
the local site. Use this method to define routes to a geographically close FSC in a remote site.
In the following example, routes between geographically close groups are expressed using a priority
scheme. (WAN routes can be used between geographically distant sites.)
Use the fscgroupimport XML element (in the fmsmaster_fscid.xml file) to define routes to a remote
site based on your local FSC group information. Within this XML element, use the defaultfsc attribute to
define the remote FSC address, ID, transport mode and priority for the route.

© 2021 Siemens
Accessing remote volumes using aliases (shared network)
In the following example code, fscgroupimport defines routes to FSCs in a remote site for FSCs coming
from a locally defined fscgroup.
<fmsworld>
<multisiteimport siteid="XYZ">
<defaultfscimport fscid="xfsc1" address="http://127.100.0.1:5101" priority="0"/>
<defaultfscimport fscid="yfsc1" address="http://127.100.0.1:5102" priority="1"/>
<fscgroupimport groupid="US_group_A">


<defaultfsc address="http://127.100.0.1:5101" priority="0"/>
<defaultfsc fscid="yfsc1" priority="1" transport="wan" maxpipes="4"/>
</fscgroupimport>
<fscgroupimport groupid="EU_group_B">
<defaultfsc fscid="yfsc1" priority="0"/>
<defaultfsc fscid="xfsc1" priority="1" transport="wan" maxpipes="4"/>
</fscgroupimport>
</multisiteimport>
<fmsenterprise id="ABC">
<fscgroup id="US_group_A">
<fsc id="afsc1" address="http://127.0.0.1:4101">
<volume id="avol1" root="/avol1"/>
</fsc>
</fsc>
</fscgroup>
<fscgroup id="EU_group_B">
<fsc id="bfsc1" address="http://127.0.0.1:4201">
<volume id="bvol1" root="/bvol1"/>
</fsc>
</fsc>
</fscgroup>
</fmsenterprise>
</fmsworld>
You can configure FSCs at your local site to access volumes managed by another site. In this case, the
FSC essentially becomes capable of managing volumes owned by the remote site. In this configuration,
FMS can take advantage of your local configuration, including your WAN transport capability.
In this shared network example, the fmsenterprise element (in the fmsmaster_fscid.xml file) is used to
map other sites to the local site. In this scenario, certain FSCs are shared and capable of managing
volumes owned by any defined site. Multiple sites and databases can be supported by a single FMS
configuration.

© 2021 Siemens

© 2021 Siemens
In the following example code, additional sites are added to the configuration using the fmsenterprise
element (DEF and XYZ):
<fmsworld>
<fmsenterprise id="ABC" >
<fmsenterprise id="DEF"/>
<fmsenterprise id="XYZ"/>
<fscgroup id="group1">
<fsc id="fsc11" address="http://fsc11:4544">
<volume id="volABD111" root="c:/volumes/volABD111"/>
<volume id="volXYZ111" root="c:/volumes/volXYZ111"/>
</fsc>
<volume id="volDEF121" root="c:/volumes/volDEF121"/>
</fsc>
</fscgroup>
</fsc>
</fsc>
</fscgroup>
<volume id="volABC312" root="c:/volumes/volABC312"/>
</fsc>
<volume id="volDEF321" root="c:/volumes/volDEF321"/>
</fsc>
</fscgroup>
<linkparameters fromgroup="group1" togroup="group2" transport="wan"

maxpipes="4"/>
maxpipes="4"/>
maxpipes="8"/>
maxpipes="8"/>
</fmsenterprise>
</fmsworld>

© 2021 Siemens
FMS monitoring
Introduction to File Management System monitoring
For File Management System (FMS) events, you can configure the following metrics to provide specified
levels of monitoring of specified events levels. Optionally, you can receive email notification when
specified metrics cross specified thresholds.
Configure FMS monitoring using either:
• FSC_HOME/monitoring/fscMonitorConfig.xml
• FMS monitoring administrative interface
Metric Description
All Routes Failed All routes to resources in the FMS topology are
inaccessible.
Expired Ticket The FSC Server encountered a expired ticket.
Generic Error The FSC server threw a general error.
Invalid Ticket The FSC server encountered a invalid ticket.
Memory Collection Threshold Exceeded The Java virtual machine has detected that the
memory usage of a memory pool is exceeding the
collection usage threshold.
Memory Usage Threshold Exceeded The Java virtual machine detects that the memory
usage of a memory pool is exceeding the usage
threshold.
No Route Error A client or FCC is connector to the wrong FSC server

process.
Periodic Checks The periodic FSC network, local volume,

performance, and configuration checks has detected
an issue.

© 2021 Siemens
Introduction to File Management System monitoring
Metric Description
Quarantined Dead Link A link between two resources in the FSC network
topology was quarantined.
Remote Admin Not Supported The Fms_BootStrap_Urls preference value is

incorrect.
For each metric the following information is collected:
• Date and time
• FSCID
• Message
• Log
Each alert notification contains:
• Date
• Message
• Possible causes
• Recommended actions
The MLD holder is used for the All Routes Failed metric and the alert notification trigger is a single
event occurrence. The countable MLD holder is used for all other metrics and the alert notification is
triggered when the number of events is greater than threshold values in a specified time period.
The FSC_Critical_Events Monitoring_Summary MBean consolidates the event metrics and their
corresponding values of the FSC process for display in one window of the Java EE administrative
interface. The FSC_Critical_Events_Monitoring_Configuration MBean contains the
Health_monitoring_mode attribute that you use to enable or disable the monitoring system. The
FSCHealthDiagnostics MBean performs periodic health checks and critical event reasoning.
Tip:
You should review all monitoring settings, ensuring the thresholds are set correctly for your site.

© 2021 Siemens
COLLECT. Collect the data and review to determine normal activity levels. Then set notification
Tip:
The contents of the email notifications are generated from the TC_ROOT/fsc/monitoring/
fscMonitorConfigInfo.xml file. (This is a companion file to the fscMonitorConfig.xml file.) For a
complete list of possible causes and recommended actions for server manager monitoring, see
this file.
Configure FMS monitoring with the fscMonitorConfig.xml file
This procedure describes how to configure FMS monitoring with a configuration file. You can also
configure FMS monitoring with an administrative interface.
1. Open the FSC_HOME/monitoring/fscMonitorConfig.xml file.
2. At the top of the file, set mode to one of the following:
• Normal
• Disable_Alerts
• Off
EmailResponder values.
• protocol
• hostAddress

© 2021 Siemens
Configure FMS monitoring with the fscMonitorConfig.xml file
Specify the server host from which the email notifications are sent. In a Multi-Site environment,
the host address identifies the location of the critical events.
• fromAddress
• toAddress
Specify the amount of time (in seconds ) to suppress email notification of critical events.
• emailFormat
which file, critical events are logged by setting the following LoggerResponder values.
• logFileName
• Collect
Collect metric data and display results in the MBean view (within the FMS administrative
interface) for this metric.
• Alert

© 2021 Siemens
values), and display results in the FMS administrative interfaces for this metric. Log file
messages and email notifications are only issued when monitoring mode is set to Alert.
• Off
the metric.
6. Save the file.

FMS monitoring is enabled for the metrics you configured.
Sample fscMonitorConfig.xml code
In the following example, the email notifications are sent to admin1@company.com.
<ApplicationConfig mode="Off" version="1.0" xmlns:xsi="http://www.w3.org/2001/

XMLSchema-instance"
xsi:noNamespaceSchemaLocation="healthMonitorV1.0.xsd">
<RespondersConfig>
</EmailResponder>
<logFileName value="FSCMonitoring.log" />
<suppressionPeriod value="60" />
</LoggerResponder>
</RespondersConfig>
- <MetricsConfig>
- <Metric name="Quarantined Dead Link" id="QuarantinedDeadLink" maxEntries="100"
mode="Collect"
metricType="integer" description="A link between two resources in FSC network topology was
quarantined.">
- <ThresholdWithPeriod>
<ThresholdValue name="NumberOfQuarantinedDeadLinks" value="2" description="If number of
timeouts
exceeds this limit, notify the administrator." />
<ThresholdPeriod name="TimePeriodInSec" value="6000" description="Periods for which
timeouts
will be monitored." />
- <Responders>
<ResponderRef id="EmailResponder1" />
<ResponderRef id="LoggerResponder1" />
</Responders>
</Metric>
- <Metric name="All Routes Failed" id="AllRoutesFailed" maxEntries="100" mode="Collect"
metricType="grave" description="All Routes to resources in FMS Network topology is down.
Something very bad has happened causing the FSC process to malfunction.">
- <Responders>

© 2021 Siemens
Sample fscMonitorConfig.xml code

</Responders>
</Metric>
- <Metric name="No Route Error" id="NoRouteError" maxEntries="100" mode="Collect"
metricType="integer" description="Client or FCC is connected to wrong FSC Server
process.">
<ThresholdValue name="NumberOfNoRouteError" value="2" description="If number of timeouts
exceeds
this limit, notify the administrator." />
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Remote Admin Not Supported" id="RemoteAdminNotSupported" maxEntries="100"
mode="Collect" metricType="integer" description="The Fms_BootStrap_Urls value is
incorrect.">
<ThresholdValue name="NumberOfRemoteAdminNotSupported" value="2" description="If number of
timeouts exceeds this limit, notify the administrator." />
timeouts will be monitored." />
- <Responders>
</Responders>
</Metric>
- <Metric name="Memory Collection Threshold Exceeded" id="MemoryCollection" maxEntries="100"
mode="Collect" metricType="integer" description="Java virtual machine detects that the
memory usage
of a memory pool is exceeding collection usage threshold.">
<ThresholdValue name="NumberOfMemoryCollection" value="1" description="If memory collection
exceeds this limit, notify the administrator." />
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Memory Usage Threshold Exceeded" id="MemoryUsage" maxEntries="100"
mode="Collect"
metricType="integer" description="Java virtual machine detects that the memory usage of a
memory
pool is exceeding usage threshold.">
<ThresholdValue name="NumberOfMemoryUsage" value="1" description="If memory collection
exceeds

© 2021 Siemens
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Generic Error" id="GenericError" maxEntries="100" mode="Collect"
description="A general error was thrown from FSC Server.">
<ThresholdValue name="NumberOfGenericError" value="10" description="If number of timeouts
exceeds
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Expired Ticket" id="ExpiredTicket" maxEntries="100" mode="Collect"
description="FSC Server encountered a expired ticket.">
<ThresholdValue name="NumberOfExpiredTicket" value="2" description="If number of timeouts
exceeds
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Invalid Ticket" id="InvalidTicket" maxEntries="100" mode="Collect"
metricType="integer" description="FSC Server encountered a invalid ticket.">
<ThresholdValue name="NumberOfInvalidTicket" value="1" description="If number of timeouts
exceeds
timeouts
- <Responders>
</Responders>
</Metric>
- <Metric name="Periodic Checks" id="PeriodicChecks" maxEntries="100" mode="Collect"
metricType="integer" description="Periodic FSC Server health checks has detected an
issue.">
<ThresholdValue name="NumberOfPeriodicChecks" value="2" description="If number of timeouts

© 2021 Siemens
Configure FMS monitoring with the administrative interface
exceeds
timeouts
- <Responders>
</Responders>
</Metric>
</MetricsConfig>
Configure FMS monitoring with the administrative interface
You can use a web browser interface to manage FMS operations. This procedure describes how to
configure FMS monitoring with the administrative interface.
You can also configure FMS monitoring with a configuration file.
Tip:
Because this functionality is provided through JMX Beans, any JMX client can access the FSC
monitoring data. Java provides free JMX clients such as JConsole and JVisualVVM that can be used
for this purpose.
1. Start the FMS monitoring administrative interface.

By default, the address is http://host-name:8999.

© 2021 Siemens
2. Under the FSC_Critical_Events heading, click

id=FSC_Critical_Events_Monitoring_Configurations.
This view lists the monitoring mode and all the metrics available for monitoring.
3. Set the Health_monitoring_mode value to one of the following:
• Normal
• Disable_Alerts
• Off
4. Click Apply and click Back to Agent View.
5. In the Agent View under the FSC_Critical_Events heading, click the id=EmailResponder1 value.
EmailResponder1 values.
All EmailResponder1 values in all child monitoring metrics must match the values set here.

© 2021 Siemens
Start the FMS monitoring administrative interface
• From_address
• Host_address
Specify the server host from which the email notifications are sent. In a Multi-Site environment,
the host address identifies the location of the critical events.
• To_address
addresses, separated by a semicolon ( ; ).
7. Click Apply.
8. Click Back to Agent View.
9. Under the FSC_Critical_Events heading, click id=LoggerResponder1.
which file, critical events are logged by setting the following LoggerResponder values.
All LoggerResponder values in all child monitoring metrics must match the LoggerResponder
values set here.
• Log_filename
Specify the amount of time (in minutes) to suppress logging of critical events to the log file.
11. Click Apply.
Start the FMS monitoring administrative interface
The web application collects a variety of metrics on FMS events that are relevant to performance and the
health of the FMS environment.
1. Ensure the web tier is installed.
2. Open the pref_export.xml.template file in the FSC_HOME directory.
3. Locate the RunHtmlAdapter key entry and ensure its value is set to true.
4. Add the following elements to the file following the RunHtmlAdapter setting:

© 2021 Siemens
<entry key="HtmlServerLogin" value="plmmonitor" />

<entry key="HtmlServerPassword" value="localhost" />
5. Save the modified file as pref_export.xml.
6. Open the startfsc file in the FSC_HOME directory.
7. Add the following to the VM parameters after the -Dcom.sun.management.jmxremote parameter

and save the file.
-Dcom.teamcenter.mld.runadapter=yes -Dcom.teamcenter.mld.jmx.
HtmlServerLogin=plmmonitor -Dcom.teamcenter.mld.jmx.HtmlServerPassword=localhost
-Dcom.teamcenter.mld.jmx.HtmlServerPort=8999
8. Restart the FSC and ensure there are no errors.
9. Open a web browser and type http://application-server-host:8999.
Note:
You can change the port number by changing the HtmlAdapterPort value in the
pref_export.xml file and the HtmlServerPort value in the VM parameters you added to the
startfsc file if necessary.
10. Log on using the default user name and password plmmonitor and localhost, respectively.
The web application metrics are displayed as in the following example:

© 2021 Siemens
Verify that files are not corrupted during transmission
11. Click any of the links for the listed metric MBean.
You can verify that files are not corrupted during transmission to, from, and within Teamcenter by
setting parameters in File Management System (FMS). This verification process computes message
digests (complex checksums) of files before and after transmission, which are then compared to verify
file integrity.
Content verification must be done in FMS between any two endpoints that transmit files. For example,
the system could verify a file’s content when uploading a file from a Teamcenter client to a Teamcenter
volume. Endpoints can include FMS clients like the rich client, Lifecycle Visualization, NX, and volume
server. There may even be more intermediate points like intermediate file cache servers.
To enable file content verification, you must set parameters in FMS configuration files such as the
fmsmaster_fscid.xml file and the fsc.properties file.
Tip:
The fmsmaster_fscid.xml file and fsc.properties file are located in the FSC_HOME directory (for
example, TC_ROOT\fsc). All the available parameters can be found in the corresponding template
files, for example, fmsmaster.xml.template.
To generate new file digests, run the generate_file_digests utility.
Following are file content verification properties used by FMS server cache (FSC). These properties are
set typically in the fmsmaster_fscid.xml file and possibly in the fsc.xml file for special cases. You can find
these properties listed in the fsc.xml.template file located in the FSC_HOME directory (for example,
TC_ROOT\fsc).
Valid
Name values Description
FSC_EnableUploadValidation true Enables upload data validation. Uses whatever
supported digest the client supplies.
false Disables upload data validation. Digests sent by
clients are ignored. This is the default value.
FSC_EnableDownloadValidation true Enables download data validation. Uses the digest
stored in the volume or cache.
false Disables download data validation. Any digest stored
in the volume or cache is ignored. This is the default
value.
FSC_TransferDigestAlgorithm None Disables transfer data validation. This is the default
value.

© 2021 Siemens
Valid
MD5 Requests MD5 digests on file transfers. Uses
whatever digest is returned from file origin.
SHA-1 Requests SHA-1 digests on file transfers. Uses
FSC_TransferRemoteMetadataFile true Enables transferring metadata files used in the
validation process. This is the default value.
false Disables transferring metadata files.
Following is an example of these properties used in an fmsmaster_fscid.xml file:
<fscdefaults>
…
<property name="FSC_EnableUploadValidation" value="true" overridable="true" />
<property name="FSC_EnableDownloadValidation" value="true" overridable="true" />
<property name="FSC_TransferDigestAlgorithm" value="MD5" overridable="true" />
<property name="FSC_TransferRemoteMetadataFile" value="true" overridable="true"/>
…
</fscdefaults>
Following are file content verification properties used by the FMS client cache (FCC). These properties
are set typically in the fmsmaster_fscid.xml file and possibly in the fcc.xml file for special cases. You can
find these properties listed in the fcc.xml.template file located in the FCC_HOME directory (for
example, TC_ROOT\fcc).
Name Valid values Description

FCC_UploadDigestAlgorithm None Disables upload data validation. This is the default
value.
MD5 Computes and sends MD5 digests on file uploads.
SHA-1 Computes and sends SHA-1 digests on file uploads.
SHA-256 Computes and sends SHA-256 digests on file uploads.
FCC_DownloadDigestAlgorithm None Disables download data validation. This is the default
value.
MD5 Requests MD5 digests on file downloads. (Uses
whatever supported digest the FSC supplies.)
SHA-1 Requests SHA-1 digests on file downloads. (Uses

© 2021 Siemens
Following is an example of these properties used in an fmsmaster_fscid.xml file:
<fccdefaults>
…
<property name="FCC_UploadDigestAlgorithm" value="MD5" overridable="true" />
<property name="FCC_DownloadDigestAlgorithm" value="MD5" overridable="true" />
…
</fccdefaults>
Following are file content verification properties used by FSCClientProxy, FSCJavaClientProxy and
FSCNativeClientProxy. You can set these properties in the fsc.properties file (for JNI FSCClientProxy),
the fsc.clientagent.properties file (for FSCNativeClientProxy or JNI FSCClientProxy), and in the
System.getProperties() call (for FSCJavaClientProxy). (For JNI FSCClientProxy, the
fsc.clientagent.properties file settings override those found in the fsc.properties file.)
Valid
com.teamcenter.fms.digest.upload None Disables upload data validation. This is the
default value.
MD5 Computes and sends MD5 digests on file
uploads.
SHA-1 Computes and sends SHA-1 digests on file
uploads.
uploads.
com.teamcenter.fms.digest.download None Disables download data validation. This is the
default value.
SHA-256 Requests SHA-256 digests on file downloads.
(Uses whatever supported digest the FSC
supplies.)
com.teamcenter.fms.digest.transfer None Disables transfer data validation. This is the
default value.
MD5 Requests MD5 digests on file transfers. Uses
Requests SHA-256 digests on file transfers. Uses

© 2021 Siemens
Following is an example of these properties used in an fsc.properties file:
com.teamcenter.fms.digest.upload=MD5
com.teamcenter.fms.digest.download=MD5
com.teamcenter.fms.digest.transfer=MD5
Following are file content verification properties used by FSCNetClientProxy and set in the
FSCNetClientProxynn.dll.config file. NET-version represents a .NET version number. This file resides in
the FSC_HOME\lib directory.
Name Valid values Description

com.teamcenter.fms.digest.upload None Disables upload data validation. This is the
default value.
MD5 Computes and sends MD5 digests on file
uploads.
uploads.
uploads.
com.teamcenter.fms.digest.download None Disables download data validation. This is the
default value.
SHA-256 Requests SHA-256 digests on file downloads.
(Uses whatever supported digest the FSC
supplies.)
Following is an example of these properties used in an appSettings file section of the configuration file:
<configuration>
<appSettings>
<add key="com.teamcenter.fms.digest.upload" value="MD5" />
<add key="com.teamcenter.fms.digest.download" value="MD5" />
</appSettings>
</configuration>
Enable SHA-256 digest algorithm for the ticket digest
By default, the Teamcenter and FMS systems use the MD5 digest algorithm for the ticket digest. You can
configure the Teamcenter system and FMS to use the more secure SHA-256 digest algorithm.

© 2021 Siemens
Enable MD5 encryption for the ticket digest
Sites that communicate with each other in a multisite federation must use the same digest algorithm,
one of MD5 or SHA-256.
1. Set the Teamcenter preference FMS_Use_SHA256_Tickets to true.
2. In the FMS primary xml file, after the fmsenterprise element, add a ticketdigest element and set
it to SHA-256. For example:

<ticketdigest value="SHA-256" />
3. In the $FSC_HOME/fscadmin.properties file, set
com.teamcenter.fms.fscadmin.default.ticketdigest=SHA-256
Enable MD5 encryption for the ticket digest
By default, the Teamcenter and FMS systems use the SHA-256 encryption algorithm for the ticket
digest. You can configure the Teamcenter system and FMS to use the less intensive MD5 algorithm. All
sites participating in one multisite federation must use the same algorithm, one of MD5 or SHA-256.
Sites that communicate with each other in one multisite federation cannot use different ticket digest
algorithms.
1. Set the Teamcenter preference FMS_Use_SHA256_Tickets to false.
2. In the FMS master xml file, after the fmsenterprise element, add a ticketdigest element and set it
to MD5. For example:

<ticketdigest value="MD5" />
3. In the $FSC_HOME/fscadmin.properties file, set
com.teamcenter.fms.fscadmin.default.ticketdigest=SHA-MD5
Enable use of FIPS 140-2 cryptography in FMS
You can use a cipher list on FSC servers to enforce FIPS manually. If all the ciphers in the list (and
therefore enabled for use by FSC) are FIPS-certified, the FSC is FIPS-compliant. For example, the
following configuration forces all FSCs in the scope of this setting to use the
TLS_RSA_WITH_AES_128_CBC_SHA cipher for their HTTPS connections:
<fscdefaults>
...
<property name="FSC_SSLEnabledCiphers" value="TLS_RSA_WITH_AES_128_CBC_SHA"

© 2021 Siemens
...
</fscdefaults>
To specify more than one cipher, separate each cipher name with a comma. This allows negotiation of
any of the listed ciphers for client connections. For example:
<fscdefaults>
<property name="FSC_SSLEnabledCiphers" value="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,
TLS_RSA_WITH_RC4_128_SHA" overridable="false"/>
</fscdefaults>
Caution:
It has not been determined whether any of the ciphers listed in the preceding examples are
actually FIPS compliant.
The list of ciphers available and supported by any given JRE are not determined by Siemens Digital
Industries Software. Refer to published Oracle documentation to determine which ciphers are available
in various JRE versions.
The list of FIPS-compliant ciphers is not determined by Siemens PLM or any of its software. You must
refer to published FIPS documentation to determine which of the supported ciphers are FIPS-compliant.
Improving FSC cache performance

You can improve Teamcenter file management performance by prepopulating your FSC caches with a
given set of files. This is useful if your site regularly has a large number of users all accessing the same
set of files simultaneously.
For example, if you have 50 designers all arriving at the same time in the morning, and they are all
simultaneously accessing the same large CAD assemblies, prepopulating your FSC caches with the
assembly files improves Teamcenter performance.
Prepopulate FSC caches using the plmxml_export and load_fsccache utilities.
1. Extract the file information for cache prepopulation by running the plmxml_export utility, using
the justDatasetsOut transfer mode to create a PLM XML file containing all external file references
associated with the top-level item selected. For example:
plmxml_export -u=tc-admin-user -p=password -g=group -item=item-id -export_bom=yes

-transfermode=justDatasetsOut -xml_file=tickets.xml
2. Run the load_fsccache utility to target the fsc_ids within the PLM XML file and prepopulate the
cache. For example:
load_fsccache -u=tc-admin-user -p=password -g=group -f=load

© 2021 Siemens
About the sample FMS configurations
-plmxml=tickets.xml -fsctargets=FSC-ID
Sample FMS configurations
About the sample FMS configurations
The sample Teamcenter rich client FMS configurations are fairly simple FMS deployments illustrating a
single FMS capability and addressing basic FMS configuration solutions.
These sample configurations do not represent full configuration files. Rather, the configuration files
include the key FMS configuration file statements and structures that are being illustrated, while leaving
out default FSC and FCC property values to reduce the size of the file and to focus on the subject.
Sample LAN configurations
Single FSC configuration
A Teamcenter Environment Manager installation of Teamcenter provides a single FSC that mounts a
single volume, a typical use for small deployments. Adding two additional volumes creates the basic
two-tier Teamcenter FMS configuration shown in the following figure.

© 2021 Siemens
• FSC roles
The single FSC in this diagram fulfills the volume server and configuration server roles. The FSC does
not provide file caching, as it has direct access to all the volumes. It also does not provide transient
volumes as this function is performed by the FCC in two-tier mode.
• FCC roles
The FCC provides file caching (as always in both two-tier and four-tier configurations). It also provides
a transient volume so that clients need not be aware of two-tier or four-tier operation.
All clients are configured to retrieve the initial bootstrap configuration information from FSC1, which
assigns all clients to FSC1 for file access.
• FMS primary configuration file (FSC_HOME/fmsmaster_fsc-ID.xml)

This file is served by FSC1. See the FSC_HOME/fmsmaster.xml.template file for all available
elements. Key points of this file include:

© 2021 Siemens
Single FSC configuration
• fmsenterprise element
This statement contains a definition of FSC defaults, FCC defaults, FSC1 and its assigned volumes.
This statement also includes an ID attribute which must match the unique identifier for the
database.
• fscdefaults element
Specifies where the FSC read and write cache files are stored. These defaults are used by any
additional FSCs installed in the future.
• fccdefaults element
Specifies the default location of the user's cache.
• fscGroup element
Defines the FSC group. All FSCs must belong to one, and only one, FSC group.
• fsc element
Defines the FSC identifier and configures the FSC. In the following example, the address of FSC1 is
146.122.40.99:4444. Dot notation is used in this example for simplicity. DNS names may also be
used, such as csun17.ugs.com:4444.
• volume element
Several volumes are defined for FSC1. Each volume must have an entry under FSC1. The volume
statements also specify the root directory for each volume. The volumes can be either local disk
volumes, or mounted volumes on the network. While paths specified for the volume typically
match the traditional Teamcenter path for the volume for a small deployment, FSCs can be installed
on any box as needed and file paths may depend on mount points provided on that box. Thus the
path need not match the traditional Teamcenter volume path.
You can use the backup_xmlinfo utility to generate the volume IDs.
• clientmap element
Specifies that all clients on 146 prefixed network addresses are assigned to FSC1.
A sample of the primary configuration file for this configuration is:
<!DOCTYPE fscconfig SYSTEM "fmsmasterconfig.dtd">
<fmsworld>
<fscdefaults>
<property name="FSC_ReadCacheLocation"
value="$HOME/FscCache|/tmp/FscCache"
<property name=“FSC_WriteCacheLocation"
</fscdefaults>
<fccdefaults>
<property name="FCC_CacheLocation"
value="$HOME/FCCCache|/tmp/$USER/FCCCache"

© 2021 Siemens
</fccdefaults>
<fscGroup id="fscGroup1">
<fsc id="fsc1" address=“http://146.122.40.99:4444">
<volume id="vol1" root="//csun17/vol1"/>
</fsc>

<assignedfsc fscid="fsc1"/>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>
• FSC configuration file (FSC_HOME/fsc.xml)

This file is small in this example, containing the minimum required statements for an fsc.xml file, and
does not define or override any FSC or FCC defaults. See the FSC_HOME/fsc.xml.template file for all
available elements. Key points of this file in this configuration are:
• fscmaster element
Specifies that the FSC reads the file directly from disk out of the FSC launch (working) directory.
Note that the file name may be specified in the launch command as the fms.config property.
• fsc element
Specifies the FSC ID for this installed FSC. This FSC ID is used to refer to the FSC definition provided
in the FMS primary configuration file. For example:
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
• FCC configuration file (FMS_HOME/fcc.xml)

This file is small in this example, containing only the bootstrap address for the FSC configuration
server which allows the FCC configuration to be downloaded. See the FMS_HOME/fcc.xml.template
file for all available elements. Key points of this file in this configuration are:
• parentfsc element
This statement identifies which parent FSC to use for the initial configuration download.
• FCC cache location

All windows clients contain an FCC cache located as specified by the FCC_CacheLocation XML
attribute. All users with cache size parameters are based on the default coded values since there
were no default settings in the FMS primary or FSC configuration files.

© 2021 Siemens
FCC direct connect configuration
• Assigned FSC
The assigned FSC is FSC1, as specified in the FMS primary configuration file.
A sample of the FCC configuration file for this configuration is:
<fccconfig>
<parentfsc address=“http://146.122.40.99:4444" priority="0"/>
</fccconfig>
This configuration provides a standard multiple FSC configuration for small or medium deployments.
This configuration contains a single FSC group, with an FSC deployed for each volume. Clients download
files directly from the appropriate volume server. This configuration may handle approximately three
times the file transfer volume of a single FSC deployment, since there are now three (essentially)
independent FSC servers.

© 2021 Siemens
• Primary configuration file (FSC_HOME/fmsmaster_fscid.xml)

This file is configured similar to the previous example for the single FSC configuration. See the
FSC_HOME/fmsmaster.xml.template file for all available elements. Key points of this file in this
configuration are:
• Multiple FSCs
This configuration contains three FSCs deployed on different boxes, each containing a single
volume.
• Direct user access

By default, a multiple FSC deployment enables all clients to directly download files from any FSC in
the group that contains the clients assigned FSC.
• assignedfsc element
All users have an assigned FSC even though direct routing is enabled. In this configuration, the
assigned FSC is only used to determine the group and the list of FSCs to which the client may
directly connect. More complex deployments described in later sections describe additional roles
for the assigned FSC.

© 2021 Siemens
• Separation of configuration and data paths

All FCCs and FSCs bootstrap the configuration file from FSC1, but users access files via all three FSC
volume servers.
<fmsworld>
<fscdefaults>
<property name=“FSC_WriteCacheLocation"
</fscdefaults>
<fccdefaults>
</fccdefaults>
<fsc id="fsc1" address=“http://csun17.ugs.com:4444">
<volume id="vol1"
root="/data/vol1"/>
</fsc>
<volume id="vol2"
root="/data/vol2"/>
</fsc>
<volume id="vol3"
root="/data/vol3"/>
</fsc>

<assignedfsc fscid="fsc1"/>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>
• FSC configuration files (FSC_HOME/fsc.xml)

In this example, each FSC has a separate fsc.xml file. See the FSC_HOME/fsc.xml.template file for all
available elements. Key points of this file in this configuration are:
• Multiple FSC configuration files

Each FSC has a separate configuration file.
• fmsmaster element

© 2021 Siemens
Specifies that FSC1 is the primary configuration server in the FSC1config file. The FSC2 and FSC3
configuration files download the primary configuration file from FSC1.
A sample FSC configuration file for this configuration is:
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fscmaster serves="false" address=“http://csun17.ugs.com:4444" />
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>

This example of the FCC configuration file is similar to previous examples:
<fccconfig>
<parentfsc address=“csun17.ugs.com:4444" priority="0"/>
</fccconfig>
FSC cached configuration
This configuration provides a high-speed cache server for improved client performance. When users
upload new files to the volume, the files are cached in the FSC cache but streamed to the volume. This
results in two copies of the file, but should not affect performance. Downloaded files are also cached.

© 2021 Siemens
Typically, the end result is that the FSC cache server holds a small percentage of the most commonly
accessed files, and the number of file accesses to the volume servers is substantially reduced. A benefit
of this configuration is that clients may continue to download commonly accessed files with brief
outages of the volume server network by downloading files from the FSC cache.

This file is configured similar to the example for the FCC direct connect configuration. See the
FSC_HOME/fmsmaster.xml.template file for all available elements. Key points of this file in this
configuration are:
• FSC cache
This configuration contains an FSC cache. The FSC cache acts as both a cache server and a
configuration server. It does not provide volume or transient volume server functions.
• FCC_EnableDirectFSCRouting element

© 2021 Siemens
Set this configuration parameter to false to disable direct routing. This causes all FCC data access to
be provided by the FCC's assigned FSC. If this parameter is not set, the client FSCs directly access
the FSC volume servers.
• FSC cache sizing

The FSC uses the default read/write partial cache configuration and sizes.
<fmsworld>
<fscdefaults>
<property name="FSC_WriteCacheLocation"
</fscdefaults>
<fccdefaults>
<property name="FCC_EnableDirectFSCRouting"
Value="false"
Overridable="false" />
</fccdefaults>
<fsc id="fscCache" address=“http://csun16.ugs.com:4444" />
</fsc>
</fsc>
</fsc>

<assignedfsc fscid="fscCache"/>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>

This FSC configuration file is similar to the FSC direct connect configuration file. Each FSC has a
separate fsc.xml file. See the FSC_HOME/fsc.xml.template file for all available elements. In this
configuration, additional key points of the FSC configuration file are:

© 2021 Siemens
• Separation of configuration and data paths

All clients and all FSCs bootstrap the configuration from csun16.ugs.com:4444.
• FSC cache
This configuration includes an FSC cache. This configuration also requires a FSC configuration file.
A sample of the FSC configuration file for this configuration is:
FSCCACHE
<fscconfig>
<fsc id=" fscCache"/>
</fscconfig>
FSC1
<fscconfig>
<fscmaster serves="true" />
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>


© 2021 Siemens
<fccconfig>
<parentfsc address=“http:// csun16.ugs.com:4444" priority="0"/>
</fccconfig>
Remote user WAN configurations
FSC cached remote office configuration
This configuration provides a shared cache at the remote office so users have shared local LAN access to
recently downloaded or uploaded files.

This file is configured similar to the example for the FSC cached configuration. See the FSC_HOME/
fmsmaster.xml.template file for all available elements. Key points of this file in this configuration
are:
• FSC remote group

This configuration contains a second FSC remote group, which contains the FSC remote cache. This
is required because FSCs within an FSC group must be on a local LAN, not configured over a WAN.

© 2021 Siemens
FSC cached remote office configuration
• Assigned FSC
Clients are assigned to the FSC remote cache server. This provides a local shared cache for the
remote user group. Direct routing is not required for the FSC remote cache, since there are no
volumes in the FSC remote group.
• entryfsc parameter
This parameter ensures that all incoming requests to FSC Group 1 are sent to the FSC cache server.
If the entry FSC is not specified, requests are sent directly to the FSC volume servers.
• FCC_EnableDirectFSCRouting parameter
By default, this parameter is set to true. In this configuration, the value has no effect, as there are
no volumes in the FSC remote group.
• Link parameters
WAN acceleration is enabled from the remote office to the central office using the linkparameters
fromgroup statement.
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
</fccdefaults>
<fscGroup id="fscRemoteGroup">
<fsc id="fscRemoteCache"
address=“http://rsun10.ugs.com:4444" />
<assignedfsc fscid="fscRemoteCache"/>
</clientmap>
</fscGroup>
</fsc>
</fsc>

© 2021 Siemens
</fsc>
<entryfsc fscid="fscache" priority="0"/>
</fscGroup>
<linkparameters fromgroup="fscRemoteGroup"
togroup="fscGroup1"
transport="wan" />
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration has the same key points as the FSC cached
configuration.
FSCREMOTECACHE
<fscconfig>
<fsc id="fscRemoteCache "/>
</fscconfig>
FSCCACHE
<fscconfig>
<fsc id="fscCache"/>
</fscconfig>
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>

© 2021 Siemens
Remote FSC without caching configuration
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>

<fccconfig>
<parentfsc address=“http://rsun10.ugs.com:4444" priority="0"/>
</fccconfig>
This configuration services WAN users, but users must download their own file copies; there is no shared
cache at the remote site.

© 2021 Siemens

fmsmaster.xml.template file for all available elements. The key point of this configuration's
configuration file is:
• FSC remote group

This configuration does not contain a remote cache. Therefore, a file may be downloaded multiple
times as each user separately downloads files without the benefit of a shared cache.
<fmsworld>
<fscdefaults>

© 2021 Siemens
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
</fsc>
</fsc>
</fsc>
<assignedfsc fscid="fscCache" transport="wan"/>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration has the same key points as the FSC cached remote
office configuration.
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>

© 2021 Siemens
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache
<fscconfig>
<fsc id="fscCache"/>
</fscconfig>

<fccconfig>
<parentfsc address=“http://csun17.ugs.com:4444" priority="0"/>
</fccconfig>
Exit FSC cache configuration
This configuration illustrates a shared cache at a remote site with volumes. Users have shared local LAN
access to recently accessed files from other FSC groups.
• FSC servers route outbound requests to an exit FSC, which routes the requests to FSCs outside the
group.
• The exit FSC routes the requests either to the outside group’s entry FSC (if configured) or to an FSC
that serves the requested resource. Outbound requests are requests for data on a resource outside
the group. Outbound requests typically originate within the group, but this is not always the case.
• The exit FSC is primarily a cache server. Its purpose is to populate and serve data originating outside
the group from its cache whenever possible. The data in its cache is high value. By serving the data
from its cache, a WAN trip is prevented.

© 2021 Siemens
• Maintain the high value of the data in the exit FSC cache by setting the FSC_CachePolicy element to
CacheIfNotInLocalFSCGroup. This prevents the exit FSC from caching group data.

fmsmaster.xml.template file for all available elements. Key points of this file in this configuration
are:
• ExitFSC element
This configuration includes an exit FSC that caches data from outside groups. It also includes a
second FSC remote group that contains local volumes.
• FCC_EnableDirectFSCRouting element
The FCC_EnableDirectFSCRouting element is set to true. FCCs in each FSC group route requests
for locally served volumes directly to the FSCs serving the volume. Therefore, local requests from
rich clients are not routed through the AssignedFSC or ExitFSC elements.
• AssignedFSC element
The AssignedFSC element for each group is ExitFSC. Therefore rich clients route requests for data
served outside the group to the exit FSC first.

© 2021 Siemens
• FSC_Cache Policy element

The FSC_CachePolicy element is set to CacheIfNotInLocalFSCGroup in FSCGroup1 and
FSCGroup2, preventing the FSC caches within the groups from storing data served within the local
FSC group.
• Link parameters
WAN acceleration is enabled from the remote office to the central office using the linkparameters
fromgroup element.
An example of the primary configuration file for this configuration is:

<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
value="true"
</fccdefaults>
<fscdefaults>
<property name="FSC_CachePolicy"
value="CacheIfNotInLocalFSCGroup"
</fscdefaults>
<fsc id="fscRemoteExit"
address="http://rlnx03.ugs.com:4444" />
<fsc id="fsc4" address="http://rsun44.ugs.com:4444">
</fsc>
</fsc>
</fsc>
<assignedfsc fscid="fscRemoteExit"/>
</clientmap>
<ExitFSC fscid="fscRemoteExit" priority = "0"/>
</fscGroup>
<fscdefaults>
<property name="FSC_CachePolicy"
value="CacheIfNotInLocalFSCGroup"

© 2021 Siemens
</fscdefaults>
<fsc id="fscExit"
address="http://csun16.ugs.com:4444" />
<fsc id="fsc1" address="http://csun17.ugs.com:4444">
</fsc>
</fsc>
</fsc>
<entryfsc fscid="fscExit" priority="0"/>
<assignedfsc fscid="fscExit"/>
</clientmap>
<ExitFSC fscid="fscExit" priority = "0"/>
</fscGroup>
togroup="fscGroup1"
transport="wan" />
<linkparameters fromgroup="fscGroup1"
togroup="fscRemoteGroup"
transport="wan" />
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration has the same key points as the FSC cached
configuration.
FSCREMOTECACHE
<fscconfig>
<fscmaster serves="false" address="http://csun17.ugs.com:4444" />
<fsc id="fscRemoteExit"/>
</fscconfig>
FSCEXIT
<fscconfig>
<fsc id="fscExit"/>
</fscconfig>
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>

© 2021 Siemens

<fsc id="fsc2"/>
</fscconfig>
…
FSC6
<fscconfig>
<fsc id="fsc6"/>
</fscconfig>


<fccconfig>
<parentfsc address="rlnx03.ugs.com:4444" priority="0"/>
</fccconfig>
FSCGROUP1
<fccconfig>
<parentfsc address="http://csun16.ugs.com:4444" priority="0"/>
</fccconfig>
FSC primary server load balancing
This configuration illustrates how to configure multiple primary FSC servers for load balancing.

© 2021 Siemens
FSC primary server load balancing

This file is configured similar to the previous examples. See the FSC_HOME/fmsmaster.xml.template
file for all available elements. The key points of this configuration's configuration file are:
• filestoregroup element
The filestoregroup element defines a volume (or group of volumes) to be load balanced across
several FSCs.
• filestore element
The filestore element in an FSC definition, within an fscgroup, identifies the filestore group to
serve. The priority attribute defines its load balancing priority.
<fmsworld>
<fscdefaults>

© 2021 Siemens
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
<volume id="data" root="/nfs/data"/>
</filestoregroup>
<fsc id="volserver1" address="http://fsc1:4444">
</fsc>
<fsc id=" volserver2" address="http://fsc2:4444">
</fsc>
<transientvolume id="transientdata"
root="/PLM/volumes/transientdata"/>
</fsc>
<assignedfsc fscid="volserver1" />
</clientmap>
<assignedfsc fscid="fscCache1" />
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>
FCC LAN client failover configuration
This configuration provides a hot local LAN failover configuration.

© 2021 Siemens
FCC LAN client failover configuration

file for all available elements. The key point of this configuration's configuration file is:
• User assigned groups

Half of the users are assigned to FSC Cache 1 as the primary FSC, half are assigned to FSC Cache 2.
If either FSC cache machine fails, the FCCs fail over to the other FSC.
• Hot failover
Both of the FSC cache machines are caching files. Therefore, if one FSC cache machine fails, the
other takes up the additional traffic. There is potential performance degradation.
• Full system failure

If both cache machines fail, no file access is available for clients. The volume servers can be
designated as failover machines to cover the unlikely event of a three-box failure scenario.

<fmsworld>
<fscdefaults>

© 2021 Siemens
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
<fsc id="fscCache1" address=“http://csun15.ugs.com:4444" />
</fsc>
</fsc>
</fsc>
<clientmap subnet="146.122.40.1"
mask="255.255.255.0">
<assignedfsc fscid="fscCache1" priority="0" />
</clientmap>
mask="255.255.255.0">
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration has the following key points:
• Redundant configuration servers

FSC1 and FSC2 are designated as configuration servers. The other FSC servers specify FSC1 and
FSC2 as the primary and failover configuration server, respectively.
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>

© 2021 Siemens
FSC clientmap DNS suffix configuration
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fscmaster serves="false" address=“http://csun17.ugs.com:4444" priority="0" />
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
<fsc id="fscCache1"/>
</fscconfig>
FscCache2
<fscconfig>
</fscconfig>

This example of the FCC configuration file is similar to previous examples. The key point is:
• Configuration failover
Two different FSCs are identified as configuration servers. This insures that the FCC can initialize by
downloading the configuration file in case one FSC cache machine has failed or is taken down for
maintenance.

<fccconfig>
</fccconfig>
This configuration illustrates how to use DNS names to map an FCC to the parent FSCs.

© 2021 Siemens
• Primary configuration file (FSC_HOME/fmsmaster_fsc-ID.xml)

• dnszone client map attribute

The dnszone attribute can be used instead of the subnet and mask attributes to map FSCs.
• dnshostname client map attribute

The dnshostname attribute can be used instead of the subnet and mask attributes to map a
specific host to FSCs.
• default client map attribute

The default attribute can be used to define default FSCs whenever subnet/mask, dnszone, or
dnshostname client maps fail to map an FCC. This default attribute replaces the legacy
mask="0.0.0.0" technique previously used for subnet/mask maps.
• dns_not_defined client map attribute

The dns_not_defined attribute can be used to define an FSC map whenever a requesting FCC’s IP
address cannot be converted to a DNS name.

<fmsworld>

© 2021 Siemens
<fscdefaults>
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
</fsc>
</fsc>
</fsc>
<clientmap dnszone="yoyodyne.com">
</clientmap>
<clientmap dnszone="eng.yoyodyne.com">
</clientmap>
<clientmap dnszone="mfg.yoyodyne.com">
</clientmap>
<clientmap dnshostname="supervisor.mfg.yoyodyne.com">
</clientmap>
<clientmap default="true">
</clientmap>
<clientmap dns_not_defined="true">
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration has the following key points:

© 2021 Siemens
• Redundant configuration servers

FSC1 and FSC2 are designated as configuration servers. The other FSC servers specify FSC1 and
FSC2 as the primary and failover configuration server, respectively.
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
</fscconfig>
FscCache2
<fscconfig>
</fscconfig>
FCC external load balancing configuration
This configuration illustrates how to load balance FMS data.

© 2021 Siemens
FCC external load balancing configuration

• assignedfsc priority attribute

Within the primary configuration file, priority attributes may have priority levels of the same value.
When this condition is found, the FCC returns these parallel priorities upon initialization. The FCC
then load balances its requests to these parallel FSCs.
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>

© 2021 Siemens
Value="false"
</fccdefaults>
</fsc>
</fsc>
</fsc>
</clientmap>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>

This FCC configuration file for this configuration has the following key point:
• parentfsc priority attribute

If two or more parentfscs are assigned the same priority level, then when the FCC is initialized it
randomly selects one of these parallel parentfscs and requests its configuration data. This feature
is useful when a large number of FCCs use the same FSCs as configuration servers. If all the FCCs
initialize at the same time (for example, after a building power failure) then the FCCs can be
distributed across a number FSCs if the priorities are set to 0.
<fccconfig>
</fccconfig>

© 2021 Siemens
FSC volume load balancing of FMS data configuration
FSC volume load balancing of FMS data configuration
This configuration illustrates how to load balance FMS data by distributing the network access load
among same-priority elements.

• filestoregroup element
The filestoregroup element defines a volume (or group of volumes) to be load balanced across
several FSCs.
• filestore element
The filestore element in an FSC definition, within an fscgroup, identifies the filestore group to
serve. The priority attribute defines its load balancing priority.

© 2021 Siemens
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
<volume id="data" root="/nfs/data"/>
</filestoregroup>
<fsc id="volserver1" address="http://fsc1:4444">
</fsc>
</fsc>
<transientvolume id="transientdata"
root="/PLM/volumes/transientdata"/>
</fsc>
<assignedfsc fscid="volserver1" />
</clientmap>
<assignedfsc fscid="fscCache1" />
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>
FSC volume failover configuration
This configuration illustrates how to configure an FSC volume failover.

© 2021 Siemens
FSC volume failover configuration

file for all available elements. The key point of this configuration is:
• volume priority attribute

Assigning a priority to a volume assigned to an FSC defines what priority the FSC serves the
volume. Notice in the configuration below that each of the three volumes are assigned to two of
the three serving FSCs, one at priority="0" and one at priority="1". The priority 0 FSC normally
serves the volume but if one of the FSCs is down, the FSC with the priority 1 serves the offline
volume.
<fmsworld>
<fscdefaults>

© 2021 Siemens
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
<volume id="vol1" root="/data/vol1"/ priority="0">
</fsc>
</fsc>
</fsc>
</clientmap>
</clientmap>
</fscGroup>
</fmsenterprise>
</fmsworld>
FSC remote cache failover configuration
This configuration provides a hot remote cache configuration, and a idle central cache configuration.

© 2021 Siemens
• Primary configuration file (FSC_HOME/fmsmaster_fsc-ID.xml)


• Hot remote failover

Both of the FSC remote cache machines are caching files. Therefore, if one fails, the other machine
takes up the additional traffic. There is potential performance degradation.
• More remote FSC caches

Additional FSC remote cache machines can be added to divide users over more machines.
Additional machines decrease performance degradation of a single FSC machine failure.
• Cold failover

© 2021 Siemens
All requests from the FSC remote group go through the FSC Cache 1 machine. The FSC Cache 2
machine is idle until there is a failure, in which case the FSC remote cache machines fail to FSC
Cache 2. FSC Cache 2 can be assigned local LAN access to utilize this spare capacity.
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
Value="false"
</fccdefaults>
<fsc id="fscRemoteCache1"
mask="255.255.255.0">
</clientmap>
mask="255.255.255.0">
</clientmap>
</fscGroup>
</fsc>
</fsc>
</fsc>
<entryfsc fscid="fscache1" priority="0" />
</fscGroup>
togroup="fscGroup1"

© 2021 Siemens
transport="wan">
</fmsenterprise>
</fmsworld>

This FSC configuration file for this configuration is as follows:
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
</fscconfig>
FscCache2

© 2021 Siemens
<fscconfig>
</fscconfig>
FSCRemoteCache1
<fscconfig>
<fsc id="fscRemoteCache1"/>
</fscconfig>
FSCRemoteCache2
<fscconfig>
</fscconfig>

This example of the FCC configuration file is similar to previous examples.
<fccconfig>
</fccconfig>
Alternate FSC remote cache failover configuration
This configuration provides a failover configuration with a local cache at the remote location, but this
configuration results in files being loaded over the WAN multiple times if the remote location cache fails.

© 2021 Siemens


All users are assigned to the shared FSC remote Cache 1
• FCC failover
When the FSC remote Cache 1 machine fails, all remote users' FCCs failover to FSC Cache1. If that
machine also fails, all remote users fail over to FSC Cache 2. As a result, FSC Cache 2 is normally an
idle machine.

© 2021 Siemens
• FCC configuration failover

FCCs receive configuration download data from the FSC remote Cache 1 machine. If this machine is
down, the FCCs receive the configuration download data from the FSC Cache 1 machine. If this
machine is also down, the FCCs receive the configuration download data from the FSC Cache 2
machine.
• entryfsc parameter
This parameter specifies the routing during normal operations when file requests flow through the
FSC Remote Group during normal operations. If the remote cache fails, these statements have no
effect. When the remote cache fails, users are assigned FSC Cache 1 or FSC Cache 2, according to
the client masks.
• FCC_EnableDirectFSCRouting parameter
This parameter does not need to be set; there is only one FSC in the FSC Remote group, which is
the primary group for all users. This parameter applies only to the primary assigned group, it does
not apply to secondary groups if the remote cache server fails. Thus, this parameter setting has no
impact on this configuration.
• WAN settings
During normal operations, traffic between the groups is based on the link parameters which specify
WAN acceleration. During failover operations the assigned FSCs in the masks specify that the FCC
should use WAN acceleration for access to the FSC Group 1 cache servers.
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
</fccdefaults>
mask="255.255.255.0">
<assignedfsc fscid="fscRemoteCache1"
priority="0" />
<assignedfsc fscid="fscCache1"
transport="wan"
priority="1" />
transport="wan"

© 2021 Siemens
priority="2" />
</clientmap>
mask="255.255.255.0">
<assignedfsc fscid="fscRemoteCache1"
priority="0" />
transport="wan"
priority="1" />
transport="wan"
priority="2" />
</clientmap>
</fscGroup>
</fsc>
</fsc>
</fsc>
</fscGroup>
togroup="fscGroup1"
transport="wan" />
</fmsenterprise>
</fmsworld>

FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>

© 2021 Siemens
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
</fscconfig>
FscCache2
<fscconfig>
</fscconfig>
FSCRemoteCache1
<fscconfig>
</fscconfig>


© 2021 Siemens
FSC remote multiple-level cache failover configuration
<fccconfig>
</fccconfig>
This configuration provides failover for either a single point of failure, or failover if both of the FSC
Remote Group 3 cache machines fail.

© 2021 Siemens



© 2021 Siemens


• Cold failover
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
</fccdefaults>
<fscGroup id="fscRemoteGroup1">
<fsc id="fscCache2"
mask="255.255.255.0">
<assignedfsc fscid="fscRemoteCache1" priority="0" />
</clientmap>
mask="255.255.255.0">
</clientmap>
<grouproute destination="fscGroup1">
<routethrough groups="fscRemoteGroup3"
priority="0" />
<routethrough groups=""
priority="1" />
</grouproute>
</fscGroup>

© 2021 Siemens
<fsc id="fscCache2"
mask="255.255.255.0">
<assignedfsc fscid= fscRemoteCache4" priority="1" />
</clientmap>
mask="255.255.255.0">
</clientmap>
priority="0" />
<routethrough groups=""
priority="1" />
</grouproute>
</fscGroup>
</fscGroup>
</fsc>
</fsc>
</fsc>
</fscGroup>
<linkparameters fromgroup="fscRemoteGroup1"
togroup=" fscGroup1"
transport="wan">
transport="wan">
transport="wan">
</fmsenterprise>
</fmsworld>

FSC1

© 2021 Siemens
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
</fscconfig>
FscCache2
<fscconfig>
</fscconfig>
FSCRemoteCache1

© 2021 Siemens
<fscconfig>
<fscmaster serves="false" address=“http://rsun5.ugs.com:4444" priority="0" />
</fscconfig>
FSCRemoteCache2
<fscconfig>
</fscconfig>
FSCRemoteCache3
<fscconfig>
</fscconfig>
FSCRemoteCache4
<fscconfig>
</fscconfig>
FSCRemoteCache5
<fscconfig>
</fscconfig>
FSCRemoteCache6

© 2021 Siemens
FSC remote multiple-level hot cache failover configuration
<fscconfig>
</fscconfig>

This example of the FCC configuration file is similar to previous examples. The following is the
configuration file for FSC Remote Group 1:
<fccconfig>
</fccconfig>
Configuration file for remote group 2 clients
<fccconfig>
</fccconfig>
This configuration provides active remote cache servers at all remote groups and idle cache servers at
the central site.

© 2021 Siemens



© 2021 Siemens


• Cold failover
<fmsworld>
<fscdefaults>
</fscdefaults>
<fccdefaults>
</fccdefaults>
<fsc id="fscCache2"
mask="255.255.255.0">
</clientmap>
mask="255.255.255.0">
</clientmap>
priority="0" />
priority="1" />
</grouproute>
</fscGroup>

© 2021 Siemens
<fsc id="fscCache2"
mask="255.255.255.0">
<assignedfsc fscid= fscRemoteCache4" priority="1" />
</clientmap>
mask="255.255.255.0">
</clientmap>
priority="0" />
priority="1" />
</grouproute>
</fscGroup>
</fscGroup>
</fscGroup>
</fsc>
</fsc>
</fsc>
</fscGroup>
togroup="fscGroup"
transport="wan">
togroup="fscGroup"
transport="wan">
</fmsenterprise>
</fmsworld>


© 2021 Siemens
FSC1
<fscconfig>
<fsc id="fsc1"/>
</fscconfig>
FSC2
<fscconfig>
<fscmaster serves="false" />
<fsc id="fsc2"/>
</fscconfig>
FSC3
<fscconfig>
<fsc id="fsc3"/>
</fscconfig>
FscCache1
<fscconfig>
</fscconfig>
FscCache2
<fscconfig>
</fscconfig>
FSCRemoteCache1

© 2021 Siemens
<fscconfig>
</fscconfig>
FSCRemoteCache2
<fscconfig>
</fscconfig>
FSCRemoteCache3
<fscconfig>
</fscconfig>
FSCRemoteCache4
<fscconfig>
</fscconfig>
FSCRemoteCache5
<fscconfig>
</fscconfig>
FSCRemoteCache6

© 2021 Siemens
FSC group import multisite routing configuration
<fscconfig>
</fscconfig>

<fccconfig>
</fccconfig>
FSC group import multisite routing configuration
This configuration illustrates how to import an FSC group from a remote FMS site over a LAN or WAN
network.

© 2021 Siemens

Use the localfscgroup element to express routes between two sites. With this element, you can
express multisite routing configuration without exposing the entire network topology of the remote
site. Only the gateway FSCs in the remote site need be known by the local site.
• fscgroupimport element
The fscgroupimport element defines routes to FSCs in a remote site. This element allows you to
define routes to a remote site based on the originating local fscgroup. The fscgroupimport
contains defaultfsc elements, which define the remote FSC address or ID, transport mode and
priority for the route. Using fscgroupimport elements, a site can express multisite routing

© 2021 Siemens
FMS shared network configuration
configurations without exposing their entire network topology. Only the gateway FSCs in the
remote site need be known by the local site.
• defaultfsc element
The fscgroupimport elements contains defaultfsc elements, which can define the remote FSC
address or ID, transport mode and priority for the route. Using this element, a site can define a
route to a geographically close FSC in the remote site which makes sense for the local site's group.
• wan transport attribute

The wan attribute allows you to direct remote traffic via the WAN transport mode. Use this
attribute to configure WAN routes between geographically distant sites.
<fmsworld>
<multisiteimport siteid="XYZ">
<defaultfscimport fscid="xfsc1" fscaddress="http://127.100.0.1:5101"
priority="0" />
<defaultfscimport fscid="yfsc1" fscaddress="http://127.100.0.1:5102"
priority="1" />
<fscgroupimport groupid="US_group_A">
<defaultfsc address=http://127.100.0.1:5101 priority="0"/>
<defaultfsc fscid="yfsc1" priority="1" transport="wan"
maxpipes="4"/>
</fscgroupimport>
<fscgroupimport groupid="EU_group_B">
<defaultfsc fscid="yfsc1" priority="0"/>
<defaultfsc fscid="xfsc1" priority="1" transport="wan"
maxpipes="4"/>
</fscgroupimport>
</multisiteimport>
<fscgroup id="US_group_A">
</fsc>
</fsc>
</fscgroup>
<fscgroup id="EU_group_B">
</fsc>
</fsc>
</fscgroup>
</fmsenterprise>
</fmsworld>
This configuration illustrates how to map other sites onto a local site using a shared network
configuration (also known as alias access configuration). In this situation, certain FSCs are shared and
capable of managing volumes owned by any defined site. The added benefit of this configuration is that
multiple sites/databases can be supported by a single FMS configuration.

© 2021 Siemens
• All groups are shared.
• All FSCs are shared.
• All linkparameters, entryfsc, exitfsc, and so on are shared.
• Volumes belong to just one enterprise.
The following diagram demonstrates how to map sites onto a local site using a shared network
configuration.

© 2021 Siemens

© 2021 Siemens
Additional sites can be defined using the fmsenterprise element, which uses the same configuration
defined by the local enterprise.
file for all available elements. The key point of this configuration file is:
• fmsenterprise element
Define additional sites using the fmsenterprise element, which uses the same configuration
defined by the local enterprise. This arrangement allows for an FSC to manage volumes owned by
either site. Whatever routing is defined in the local site is shared between the sites. (These multisite
enterprise elements have the DEF and XYX attributes in the following configuration file. The
advantage of this configuration is that a single FMS configuration can be defined to manage
multiple sites (databases). This assumes that the common FSC can be physically shared between
the sites.
<fmsworld>
<fmsenterprise id="DEF"/> 
<fmsenterprise id="XYZ"/>
<volume id="volABC111" enterpriseid="ABC" root="c:/volumes/volABC111"/>
<volume id="volXYZ111" enterpriseid="XYZ" root="c:/volumes/volXYZ111"/>
</fsc>
<volume id="volDEF121" enterpriseid="DEF" root="c:/volumes/volDEF121"/>
</fsc>
</fscgroup>
</fsc>
</fsc>
</fscgroup>
</fsc>
<accesson id="volDEF321" enterpriseid="DEF" root="c:/volumes/volDEF321"/>
</fsc>
</fscgroup>
<linkparameters fromgroup="group1" togroup="group2" transport="wan" maxpipes="4"/>
</fmsenterprise>
</fmsworld>

© 2021 Siemens
6. Volume Management application
Getting started with Volume Management
Introduction to Volume Management
Use the Volume Management application to monitor volume usage and improve Teamcenter
performance by moving infrequently used data from primary storage space to either destination
volumes or to third-party storage systems. All data continues to appear online to users, whether the data
is stored online, near-line, or offline.
The Volume Management perspective consists of two views.
Volume Management view
Displays by default when you open the Volume Management perspective. If you close this view to
better display the Volume Monitor view, you can open it again by choosing Window→Show
View→Volume Management.
Use the Volume Monitor view to monitor volume usage and balance volume resources by reassigning
default volumes for specific users or groups. After migration policies are created, you can use the
Volume Management view to:
• Preview the impact of migration policies.
• Use the FMS server cache (FSC) process to migrate volume files from a source volume to a destination
volume.
• Export pending migration file sets to third-party hierarchical storage management (HSM) systems to
migrate/purge files from the online primary tier to near-line secondary tiers or offline tertiary tiers.
• Generate data migration reports.
Volume Monitor view
To open the Volume Monitor view, from the Volume Management perspective choose
Window→Show View→Volume Monitor.
Use the Volume Management view to create migration policies by applying migration options and
metadata query options to a specific policy.

© 2021 Siemens
Tip:
Use volume management (VM) migration policies to migrate and consolidate Teamcenter volume
files and to migrate infrequently used Teamcenter files off of source volumes and on to
destination volumes.
Use hierarchical storage management (HSM) migration policies to move lower priority files to
third-party storage systems. Files stored on secondary and tertiary tiers can be read without
moving them to the highest level.
Before you begin
Prerequisites • You need Teamcenter administrator privileges to use the Volume

Management application.
• If you intend to use hierarchical storage management (HSM), you need a

third-party HSM tool.
Enable Volume Volume Management does not need to be enabled before you use it.
Management
If you have trouble accessing Volume Management, see your system
administrator. It may be a licensing issue.
Note:
You can log on to Teamcenter only once. If you try to log on to more
than one workstation at a time, you see an error message.
Configure Volume Volume Management does not need to be configured.

Management
However, you can modify the following Volume Monitor preferences to
change the levels at which volumes reach warning and critical states:
• TC_VOLUME_MONITOR_WARNING_LEVEL
• TC_VOLUME_MONITOR_CRITICAL_LEVEL
Start Volume
Click Volume Management in the navigation pane.
Management

© 2021 Siemens
Volume Management view interface
Volume Management interface
Volume Management view
Volume Management view interface
1 Volume The Definition tab displays options for defining volume management (VM)
Management migration policies and hierarchical storage management (HSM) migration
tabs policies. Use this tab to define various migration policies by applying
migration options and metadata query options to a specific policy.
The Migration tab displays preview and migration options for specific
migration policies. Use this tab to preview the impact of a migration policy,
and to implement migration policies.

© 2021 Siemens
The Report tab displays migration report options. Use this tab to create pie
charts and textual reports. Reports can be printed or saved to a file.
2 Policies tree Displays migration policies that you have created. Migration policies define
what data will be migrated. You can create VM migration policies and HSM
migration policies.
3 Policy Type Use the Definition tab to select the type of policy you want to manage: VM
and Policy or HSM. You can also set the policy status.
Status
4 Volume Selection of the policy type (VM or HSM) determines which migration
Migration options appear.
Options
5 Additional Selection of the policy type (VM or HSM) also determine which additional
Migration migration options appear.
Options
6 Metadata Use the MetaData Query Options functionality to further filter which files
Query Options are migrated. Select a workspace object type from the Saved Queries list
to limit migration to files of the selected object type. You can further filter
which files are migrated, refining the saved query using the workspace
object fields (name, Item ID, and so on).
Pending migration requests buttons
Use the buttons in the Migration tab to work with pending migration file sets. These buttons are
displayed to the right of the Pending Migration Requests pane after a migration is initiated.
Button Name Description
Move up Moves up the selected pending file set.
Move down Moves down the selected pending file set.
Delete Deletes the selected pending file set.
Open Opens the selected pending file set.
Export Exports the pending file set in either XML or text format.

© 2021 Siemens
Report buttons in the Volume Management view
Migrate Migrates the selected files and deletes the pending file set.
Clear Clears the Pending Migration Requests box.
Report buttons in the Volume Management view
Use the buttons in the Report tab to select which report type to generate.
PieChart Generates a report of how much data is migrated

through a volume management (VM) migration policy.
This graphical report illustrates the storage space saved
by migrating the selected data, relative to the capacity of
the source volume. You can save the report as a JPEG or
PNG file.
Report Generates a report of how much data is migrated

through a VM migration policy. This text-based report
provides an itemized list of the migrated files, the total
number of migrated files, and the total size (in bytes) of
the migrated data.
Save Saves the report. Displays at the center-right of the

Report tab.
Print Prints the report. Displays at the center-right of the

Report tab.
Clear Clears the report. Displays at the center-right of the

Report tab.

© 2021 Siemens
Volume Monitor view
Volume Monitor view interface
1 Filestore tree Displays all filestores defined in your FMS configuration that contain
configured volumes.
Add volumes to a filestore using the filestore element in the FMS master
configuration file (FSC_HOME/fmsmaster_fscid.xml).
Note:
Only configured volumes display. If, for example, you have a load
balancer defined in your FMS configuration with no volume
definitions, the load balancer does not display in the filestore tree.
2 Volume table Displays the status, percentage full, and free space available for all volumes
defined for the selected filestores.

© 2021 Siemens
Filestore tree buttons
3 Usage table Displays user and group usage information (number of files, and total
space used) for the volume selected in the volume table.
Note:
Determining the total space used by users and groups requires
calculating the size of every file on the volume. This can be a time-
consuming operation if numerous files exist on the volume, taking
hours to complete. By default, this calculation is disabled.
To display the total space used by users and groups, select the Enable
Total Space Retrieval check box. You are prompted to confirm that
you want to continue with this operation. Click OK to display the total
space calculations for all users and groups on the selected volume.
4 User/group Displays user information for the user or group selected in the usage table.
information
pane
Filestore tree buttons
Use the buttons in the filestore tree pane to work with the contents of the filestore tree and to retrieve
volume information.
Clear Clears the filter box in the lower-left corner of the volume
tree and restores tree contents back to an unfiltered state.
Refresh with Refreshes the filestore tree.

current items
Retrieve volume Retrieves volume information for the filestores selected in

information the filestore tree and displays the information in the
volume table.
Volume table buttons
Use the buttons in the volume table pane to work with the volume table and to retrieve usage
information.

© 2021 Siemens
Clear Clears the filter box in the lower-left corner of the volume
tree and restores tree contents back to an unfiltered state.
Refresh with Refreshes the volume table, based on the data most
current items recently retrieved from the filestore tree.
Retrieve user Retrieves user and group usage information for the volume
information selected in the volume table and displays the information
in the usage table.
Configuring Volume Management
Setting Volume Management preferences
Use the following preferences to modify behavior of the Volume Management application.
• Use the HSM_integration_enabled preference to enable the Volume Management application to

work with third-party hierarchical storage management (HSM) software.
• Use the HSM_read_thru_supported preference to declare whether read access to secondary and
tertiary volumes is supported. If your HSM system or hardware platform does not support read access
from secondary and tertiary volumes, the migrated files are moved to a higher tier to be read. Using
HSM_read_thru_supported requires that the HSM_integration_enabled preference be set to true.
For example, the IBM Tivoli HSM product does not provide read-through capability, and the EMC
DiskXtender HSM product only provides read-through capability on Windows. In such situations, use
reverse migration to return files to the primary tier.
• Use the HSM_primary_tier_hosts preference to define the host names on which the primary tier
volumes are managed by third-party HSM software.
HSM migration is applied to the volume files residing on hosts defined by this preference. The
hsm_capacity_alert utility estimates the capacities of the volumes and uses the values defined in this
preference to send email alerts when the primary tier capacity exceeds alert levels. Volumes residing
on hosts not defined by this preference are ignored for HSM migration and the hsm_capacity_alert
utility.
• Use the HSM_secondary_tier_capacity preference to send an email alert when the capacity of the
second tier volume reaches capacity. Set this preference to the estimated capacity level of the second
tier volume. Compute this estimate by totaling all storage capacities of all disks mounted on the
secondary tier.
• Use the TC_VOLUME_MONITOR_WARNING_LEVEL preference to specify when a volume reaches

warning level. By default, this preference is set to 80. When a volume becomes 80 percent full, it

© 2021 Siemens
Running Volume Management command line utilities
reaches warning level and displays in the volume table of the Volume Monitor tab with a yellow
background.
• Use the TC_VOLUME_MONITOR_CRITICAL_LEVEL preference to specify when a volume reaches

critical level. By default, this preference is set to 90. When a volume becomes 90 percent full, it
reaches critical level and displays in the volume table of the Volume Monitor tab with a red
background.
Running Volume Management command line utilities
Use the following Volume Management command line utilities in conjunction with the Volume
Management application.
• The hsm_capacity_alert utility determines when the capacity of specified volume tiers exceed
specified alert levels. When alert capacity is reached, the utility sends an email alert to the system
administrator.
Note:
You can run this utility overnight by wrapping it as a .bat file and using Windows Scheduler
(Windows) or wrapping it as a shell script and running a cron job (Linux).
• The hsm_report utility evaluates the specified hierarchical storage management (HSM) migration
policies and generates the specified reports.
Note:
For better performance, generate migration reports using this utility rather than the PieChart
and Report buttons in the Volume Management application. You can run this utility overnight
using a Windows at command or running a Linux cron job.
• The install_vminfo_acl utility creates access control list (ACL) rules for migration of the existing
Teamcenter volume files. The Volume Management application introduces changes to the Access
Manager (AM) rule tree. This utility verifies whether the AM rule tree contains the required rules
(HSM_Info and VM_Info). If not, the rules are added to inherit the access privileges of the named ACL
POM Open Access in par with the ImanFile object and saves the changes.
This utility runs automatically at installation. Typically, there is no need for administrators to run the
utility again. In cases where an administrator has overwritten the rule tree with custom rules, this
utility can be run to ensure the required rules are added to the rule tree.
• The mark_for_migrate utility determines whether there are any volume files pending for migration,
and if so, marks the files for migration.

© 2021 Siemens
Note:
For better performance, mark files for migration using this utility rather than the Mark for
Migration button in the Volume Management application. You can run this utility overnight
• The unmigrate_from_hsm utility is used for reverse migration of existing Teamcenter volume files.
This utility removes the hsm_info object associated with file objects from a specified volume, or from
all volumes. Use this utility to resolve error situations that occurred while migrating files to HSM, or to
remove a volume from the purview of HSM.
Running this utility only removes the HSM functionality associated with the specified files. All physical
volume files must still be returned to the primary tier if they were migrated to a secondary or tertiary
tier.
Note:
Siemens Digital Industries Software recommends that you execute this utility on a specific
volume when no other users are accessing Teamcenter, especially during maintenance or
upgrades.
• The vm_report utility evaluates the specified volume management (VM) migration policies and
generates the specified reports.
Note:
For better performance, generate migration reports using this utility rather than the PieChart
and Report buttons in the Volume Management application. You can run this utility overnight
Basic concepts about Volume Management
Why use Volume Management?
Primary disk space is expensive. Volume Management allows you to monitor volume usage and migrate
infrequently used data to secondary and tertiary storage media. You can define various migration
policies for specific types of data, and the system migrates the data based on the policies you define.
You can define both volume management (VM) migration policies and hierarchical storage
management (HSM) migration policies.
VM migration policies specify data to be migrated from a source volume to a destination volume. These
migration policies let you specify that data is migrated by saved queries, by watermark levels, or by
migrating all data from the source volume.
HSM migration policies direct data to be migrated between storage tiers. Data can be migrated from a
primary to a secondary tier, from a primary to a tertiary tier, or from a secondary to a tertiary tier. These

© 2021 Siemens
Monitoring volumes
migration policies let you choose whether to purge the original data after migration, or to purge when
specified watermark levels are reached.
Monitoring volumes
It is important to know how much free space is available on each volume at your site, to avoid import
errors and emergency fixes. Use the Volume Monitor tab to monitor free space and proactively manage
volume usage for all volumes at your site.
The volume table lists the status, percentage full, and free space for any volume at your site. When free
space is low, use the usage table to track space usage by group or by individual users. Balance volume
resources by reassigning default volumes for specific users or groups.
Volume Management migration overview
Migration moves infrequently used Teamcenter files from primary storage space to either third-party
storage systems or to destination volumes. All data continues to appear online to users, whether the
data is stored online, near-line, or offline.
Reverse migration is available only for hierarchical storage management (HSM) migration policies. This
functionality returns files to the primary tier based on the number of times it has been accessed on the
secondary or tertiary tier.
Migration policies in the Volume Management application
Migration policies are displayed in the Policies tree in the left pane of the application. They define the
data to be migrated. You can create volume management (VM) migration policies and hierarchical
storage management (HSM) migration policies. Create migration policies in the Definition pane by
defining the migration options and metadata query options to be applied to a given migration policy.
Migration options differ depending on the type of migration policy being defined. Options for VM
migration policies focus on source and destination volumes. Options for HSM migration policies center
around purging methods and third-party storage locations.
Use the saved query options to further define the data to be migrated. Both HSM and VM migration
policy options allow you to specify criteria using standard Teamcenter saved queries. You can define the
queries using standard saved queries for items, item revisions, or datasets.
Following are the types of migration policies:
• VM migration policies
Use VM migration policies to migrate and consolidate Teamcenter volume files.
Migration options for this method focus on selecting a source and destination volume. You can then
either select certain types of data to be migrated, choose to migrate data when specified volume
watermark levels are reached, or choose to migrate all files.
These migration policies do not necessarily require a third-party HSM system. You can use VM
migration policies to emulate HSM functionality without the use of third-party storage systems by

© 2021 Siemens
migrating infrequently used Teamcenter files off of source volumes and on to destination volumes.
The pending file sets defined by VM migration policies are migrated using File Management System
(FMS).
Alternatively, VM migration policies can be used to loosely couple your third-party migration tool with
Teamcenter. Pending migration file sets (VM_Migration files) are exported to a valid operating
system directory, either in text or XML format. The third-party migration tool reads the exported file
to perform the migration.
• HSM migration policies

Use HSM migration policies to move lower priority files to third-party storage systems. Files stored on
secondary and tertiary tiers can be read-accessed without moving them to the highest level. HSM
migration requires third- party HSM tool integration and configuration with Teamcenter.
Note:
Read-access from secondary and tertiary tiers is not supported by certain third-party storage
systems or certain hardware platforms. For example, the IBM Tivoli HSM product does not
provide read-through capability, and the EMC DiskXtender HSM product only provides read-
through capability on Windows. In such situations, you must set the
HSM_read_thru_supported preference to false and use reverse migration to return files to the
primary tier for read access.
Migration options for this method include selecting purge options and third-party storage locations.
Define the type of data to be migrated by selecting additional migration options (such as re-filed files
and checked out objects). Further define data to be migrated by applying saved queries.
This method requires that your site implements third-party HSM systems. The HSM migration policies
provide the following types of storage strategies:
• Online primary tier storage

Data is stored on third-party HSM software compatible disk media such as simple Windows or Linux
SAN attached disks. This is the primary, direct, volume storage location.
• Near-line secondary tier storage

Data is stored on third-party HSM software compatible disk media that can be either simple
Windows or Linux SAN attached disks or complex network access storage (NAS) systems from HP,
EMC Celerra or NetApp NearStore.
• Offline tertiary tier

Data is stored on third-party HSM software compatible devices such as EMC Centera, WORM drives,
Juke Box, and tape drives.
HSM pending file sets can be migrated by loosely coupling third-party HSM storage systems with
Teamcenter. Pending migration file sets (HSM_Migration files) are exported to a valid operating
system directory, either in text or XML format. The HSM storage systems read the exported file to
perform the migration.
Alternatively, you can tightly couple third-party HSM storage systems with Teamcenter. Pending
migration file sets are routed through API (user exit) calls to the HSM storage systems. This method

© 2021 Siemens
Basic tasks for Volume Management
allows you to replace the base user exit extension with a custom extension using Business Modeler
IDE.
• Active and inactive migration policies

Active migration policies are displayed under the Policies tree in full color. Only active migration
policies can be selected for evaluation and migration. Migration policies are made active at the time
they are defined.
Inactive policies are grayed out in the Policies tree. Make a migration policy inactive to prevent
future evaluations and migrations.
Basic tasks for Volume Management
Following are some of the basic tasks you perform with Volume Management:
• Reallocating volume usage

Volume usage is not always distributed evenly between users on a given volume. A few users (or
groups) may use many times more volume space than others. When volume usage is significantly
unequal, and volume free space is becoming limited, you can balance volume usage by reallocating
heavy users or groups to a different volume with more free space.
• Defining volume management (VM) migration policies

Migration policies define the data to be migrated. VM migration policies specify data to be migrated
from a source volume to a destination volume. These migration policies let you specify that data is
migrated by saved queries, by watermark levels, or by migrating all data from the source volume.
• Defining hierarchical storage management (HSM) migration policies

Migration policies define the data to be migrated. Hierarchical storage management (HSM) migration
policies direct data to be migrated between storage tiers. Data can be migrated from a primary to a
secondary tier, from a primary to a tertiary tier, or from a secondary to a tertiary tier. These migration
policies let you choose whether to purge the original data after migration or to purge when specified
watermark levels are reached.
• Data migration
After defining the data to be migrated, you can migrate the data to the specified location. Migrating
data involves previewing the migration results, marking the files for migrate, and then migrating the
data.
• Generating reports
After migrating data, you can generate migration reports to determine how much data was migrated
between volumes or tiers, and to see which migration policies migrated the data. You can refine
reports by date, by policy, or you can generate a report covering all current migration policies. Reports
can be printed or saved to a file.

© 2021 Siemens
Monitoring volumes
Introduction to monitoring volumes
It is important to know how much free space is available on each volume at your site, to avoid import
errors and emergency fixes. Use the Volume Monitor tab to monitor free space and proactively manage
volume usage for all volumes at your site.
Choose Window→Show View→Volume Monitor from the Volume Management perspective to open
the Volume Monitor view. The filestore tree displays in the left side of the view.
The filestore tree lists all filestores with volumes defined on them. The filestores in the tree are loaded
from the bootstrap FSC, which is defined by the Fms_BootStrap_Urls preference. Filestores are grouped
in the tree by FSC, load balancers, and filestore groups.
Selecting one or more filestores from the tree and clicking the Retrieve volume information button
at the bottom of the file store tree pane populates the volume table.
Selecting a volume from the volume table and clicking Retrieve user information populates the
usage table with user and group data.
To retrieve volume usage information, select a group or user from the usage table. This populates the
boxes to the right of the volume table with usage information.

© 2021 Siemens
Retrieving volume information
Retrieving volume information
Selecting one or more filestores from the tree and clicking Retrieve volume information populates
the volume table with the following information for each volume associated with the selected filestores.
Data Description
Volume Name Specifies the name of the volume.
Volume ID Specifies the volume ID.

© 2021 Siemens
Data Description
Parent ID Specifies the filestore ID of the parent filestore. If the volume is hosted
on multiple filestores, all parents display in a comma-separated list.
Severity Lists the possible severity levels: Low, Warning, Critical.

The severity level determines the row color:
• Low is clear.
• Warning is yellow.
• Critical is red.
If an FSC volume is offline, it is listed as Critical.

Set severity levels with the TC_VOLUME_MONITOR_WARNING_LEVEL
and TC_VOLUME_MONITOR_CRITICAL_LEVEL preferences.
State Indicates the state as Online or Offline.
% Full Specifies the percentage of space consumed on the disk hosting the
volume.
File Management System (FMS) does not maintain quotas at a volume
level, thus two volumes hosted on the same disk display the same
value.
Total Size Specifies the total amount of space, both used space and free space,
available on the disk hosting the volume.
Free Space Specifies the total amount of free space available on the disk hosting
the volume.
Retrieving user information for a volume
Selecting a volume from the volume table and clicking Retrieve user information populates the
usage table.
Select the Users option to display the following user statistics for the selected volume.

© 2021 Siemens
Retrieving user information for a volume
Data Description
User ID Lists the names of each user owning data on the selected volume.
# of files Specifies the total number of files owned by the corresponding user.
Total space Specifies the total space used by all the files owned by the
corresponding user.
Select the Groups option to display the following group statistics for the selected volume.
Data Description
Group Name Lists the names of each group owning data on the selected volume.
# of files Specifies the total number of files owned by the corresponding group.
This number includes all files owned by all users in that group and
subgroups.
Total space Specifies the total space used by all the files owned by the
corresponding group.

© 2021 Siemens
Note:
Determining the total space used by users and groups requires calculating the size of every file on
the volume. This can be a time-consuming operation if numerous files exist on the volume, taking
hours to complete. By default, this calculation is disabled.
To display the total space used by users and groups, select the Enable Total Space Retrieval check
box. You are prompted to confirm that you want to continue with this operation. Click OK to
display the total space calculations for all users and groups on the selected volume.
Retrieving volume usage information
Selecting a user from the usage table populates the boxes to the right of the table with the following
usage information.
Data Description
Person Name Specifies the full name of the selected user.
User ID Specifies the user ID used for Teamcenter logon.
OS Name Specifies the selected user's operating system name.
Default Group Specifies the default group assigned to the selected user.
When a user belongs to more than one group, one of them is
designated as the default group. The user's default group is used at
logon unless the user specifies another group.

© 2021 Siemens
Retrieving volume usage information
Data Description
Default Volume Specifies the default volume assigned to the selected user.
Typically, default volumes are assigned per group, rather than per user.
Siemens Digital Industries Software recommends that you do not define
a default volume for each user, as it is time-consuming to change
volumes for every user individually. (When a default volume is not
specified when creating a user in the Organization application, the
group's default volume information is used.)
If volume usage is significantly unequal between users and volume free
space is becoming limited, you can balance volume usage by
reallocating users consuming large amounts of volume space to a
different default volume.
Default Local Volume Specifies the default local volume assigned to the selected user.
This temporary local volume allows the file to be stored locally before it
is automatically transferred to the final destination in the background.
Once the file is stored in the default local volume, the user can continue
working without having to wait for the upload to take place.
If volume usage is significantly unequal between users and volume free
space is becoming limited, you can balance volume usage by
reallocating users consuming large amounts of volume space to a
different default local volume.
Selecting a group from the usage table populates the boxes to the right of the table with the following
group information.
Data Description
Group Name Specifies the name of the selected group.
Description Provides a description of the group, entered by the system administrator

when creating the selected group.
To Parent Specifies the parent group of the selected group.
Default Volume Specifies the default volume assigned to the selected group.
Typically, default volumes are assigned per group, rather than per user.
(When a default volume is not specified when creating a user, the
group's default volume information is used.)

© 2021 Siemens
Data Description
Warning:
If you create a group without assigning a default volume, group
members cannot save datasets.
If volume usage is significantly unequal between groups and volume

free space is becoming limited, you can balance volume usage by
reallocating groups consuming large amounts of volume space to a
different default volume.
Default Local Volume Specifies the default local volume assigned to the selected group.
This temporary local volume allows the file to be stored locally before it
is automatically transferred to the final destination in the background.
Once the file is stored in the default local volume, the user can continue
working without having to wait for the upload to take place.
If volume usage is significantly unequal between groups and volume
free space is becoming limited, you can balance volume usage by
reallocating groups consuming large amounts of volume space to a
different default local volume.
How to monitor volumes
1. Select one or more filestores from the filestore tree. If necessary, locate a filestore in the tree using
one of the following methods:
• Select FSCs, Load Balancers and/or Filestore Groups to select all filestores within the selected
grouping. Selecting all three groupings effectively selects all volumes defined in your FMS
configuration.
• Filter the entries in the filestore tree by entering a filestore name in the search box. As you type
in the box the tree refreshes, listing only filestores with names containing the characters typed
in the search box.
• If you recently added a filestore to your site, click Refresh with current items to update the
cached filestore information read from the bootstrap FSC.

© 2021 Siemens
How to monitor volumes
2. Click Retrieve volume information .

The volume table is populated with the following data for the selected filestores.
3. Monitor the selected filestore by reviewing the data in the volume table using one of the following
methods:
• Filter the entries in the table entering a volume name in the search box. As you type in the box
the tree refreshes, listing only volumes with names containing the characters typed in the search
box.
• If you have recently modified filestores at your site, click Refresh with current items to
update the cached filestore information read from the bootstrap FSC.
4. Select the volume in the volume table for which you want to retrieve usage information.
5. Click Retrieve user information in the volume table.

The usage table is populated with data for the selected volume. By default, user data is populated.
Select the Groups option to display group data in the usage table.
6. Monitor usage information for the selected volume by reviewing either user or group data in the
usage table.
7. Monitor user information for a specific user by selecting a user from the usage table.
If necessary, filter the entries in the usage table by entering all or part of a user name in the search
box. As you type in the box the table refreshes, listing only users with names containing the
characters typed in the search box.

© 2021 Siemens
The boxes to the right of the usage table are populated with volume information for the selected
user.
8. Monitor group information for a specific group by selecting a group from the usage table.
If necessary, filter the entries in the usage table by entering all or part of a group name in the
search box. As you type in the box the table refreshes, listing only groups with names containing
the characters typed in the search box.
The boxes to the right of the usage table are populated with group information for the selected
group.
9. If volume usage is significantly unequal between users or groups, and if volume free space is
limited, balance volume usage by reallocating users or groups consuming large amounts of volume
space to a different default volume, and/or a different default local volume.
Reallocate volume resources
1. (Optional) Display the total space used by users or groups by selecting the Enable Total Space
Retrieval check box.
When you click Retrieve user information , you are prompted to confirm that you want to
continue with this operation. Click OK to display the total space calculations for all users and
groups on the selected volume.
Note:
Determining the total space used by users and groups requires calculating the size of every
file on the volume. This can be a time-consuming operation if numerous files exist on the
volume, taking hours to complete. By default, this calculation is disabled.

© 2021 Siemens
Reallocate volume resources
2. Balance default volume usage by reallocating users or groups consuming large amounts of volume
space to a different default volume by selecting the user or group whose default volume you want
to change.
Note:
Default volumes specify the default final destination volume for Teamcenter files. Default
volumes differ from default local volumes in that default volumes are the first and final
destination for Teamcenter files. (Default local volumes are temporary storage locations.)
The boxes to the right of the usage table are populated with user/group information for the
selected user or group.
3. Select a different default volume from the Default Volume list. Generally, this is a volume with
more free space than the original default volume.
4. Click Modify to send the change to the database.

Alternatively, click Reset to reset the value to what is set in the database.
5. Balance default local volume usage by reallocating users or groups consuming large amounts of
volume space to a different default local volume by selecting the user or group whose default local
volume you want to change.
Note:
Default local volumes are temporary local volumes that allow files to be stored locally
before they are automatically transferred to the final destination volume. This functionality
improves end-user file upload times from clients by uploading files to a temporary volume.
Users can continue to work on their files from the temporary location. The system moves the
files to their final destination according to administer-defined criteria. Files are accessible to
FMS at all times. This behavior is also referred to as the store and forward of files.
The boxes to the right of the usage table are populated with volume information for the selected
user or group.
6. Select a different default local volume from the Default Local Volume list. Generally, this is a
volume with more free space than the original default local volume.
7. Click Modify to send the change to the database.

Alternatively, click Reset to reset the value to what is set in the database.

© 2021 Siemens
Defining migration policies
Migration policy options
Migration policies define the data to be migrated. You can create either volume management (VM)
migration policies or hierarchical storage management (HSM) migration policies. Either type of
migration policy allows you to select various migration options. Depending on the options chosen, you
can further refine the data to be migrated by filtering using standard saved queries for commonly used
workspace objects, such as items, item revisions, and datasets.
When defining volume management policies you must select a source and destination volume. The
following table defines the different migration types and migration options available.
Volume Description Metadata query options

policy
migration
options
Filter and Refines a migration policy by checked- Further refines a migration policy by
MetaData out objects, in-process objects and/or defining attributes of the following
remote objects. It further refines a saved queries: item, item revision,
migration policy by file size and date dataset.
access. You can also choose to retain a
copy of migrated files. This is the most

© 2021 Siemens
Migration policy options
Volume Description Metadata query options

policy
migration
options
granular method of creating a VM

migration policy.
Water Mark Specifies the high and low watermark No saved queries attributes can be
Levels levels of the source volume. When the used with this method.
high watermark level is reached, the
data is migrated from the source
volume to the destination volume.
Migration stops when the low
watermark is reached. You can further
refine the data to be migrated by file
size.
Moving All Migrates all valid files from the source No saved queries attributes can be
Contents volume to the destination volume. used with this method.
When defining HSM management policies, you must select a purge option and a migration tier option.
The following table lists all available options.

© 2021 Siemens
HSM policy migration Definition

options
Purge After Migrate Purges files immediately after migration.
Purge Watermark Purges files after the specified high watermark has been reached. Purge
continues until the low watermark is reached.
Primary-Secondary Migrates files from the primary source tier to the secondary destination
migration tier tier.
Secondary-Tertiary Migrates files from the secondary destination tier to the tertiary
migration tier destination tier.
Primary-Tertiary Migrates files from the primary source tier to the tertiary destination
migration tier tier.
Re-Filed Files Includes refiled files in the migration evaluation.
Checked Out Objects Includes the files of checked-out objects in the migration evaluation.
In Process Objects Includes the files of in-process objects in the migration evaluation.
Remote Objects Includes the files of remote objects in the migration evaluation.
Files Accessed Before Considers files accessed before the specified date in the migration
evaluation.
Files Accessed After Considers files accessed after the specified date in the migration
evaluation.
File Size Range Includes files of the specified size range in the migration evaluation.
Reverse Migrate File Used with reverse migration. Any file in the secondary or tertiary tier
Accessed that is accessed more than the selected number of times ( 1 or 2) is
selected for reverse migration.
Define a VM policy by filters and metadata
This method creates migration policies using logic filters and standard saved queries. It is the most
granular method for defining volume management (VM) migration policies. It is the default method.

© 2021 Siemens
Define a VM policy by filters and metadata
1. Open the Volume Management view.
2. Type a name for the migration policy in the Policy Name box.
If you create both VM and hierarchical storage management (HSM) migration policies at your site,
implementing a naming convention that differentiates between the two types simplifies managing
your policies from the Policies tree after the policies are created.
3. Type a description of the migration policy in the Policy Description box.
4. Click the Definition tab.
5. In the Policy Type section in the upper-right corner of the pane, click Volume Policy.
6. In the Policy Status section in the upper-right corner of the pane, click Active.
7. In the Volume Migration Options section, click Filter and MetaData.

The remaining migration options become specific to this migration method.
8. Select a source volume from the Source Volume list. Select the volume from which you want to
migrate the data.
Note:
The list displays all defined volumes for the Teamcenter database. If you do not see a volume
you created during this session, close and reopen the Volume Management application.
9. Select a destination volume from the Destination Volume list. Select the volume to which you
want the data migrated.
10. (Optional) In the Additional Migration Options section, select Checked Out Objects to include
the files of all checked-out objects in the migration.
11. (Optional) Select In Process Objects to include the files of all in-process objects in the migration.
12. (Optional) Select Remote Objects to include the files of all remote objects in the migration.
13. (Optional) Select Retain Copy of Migrated File to retain a copy of the migrated file in the source
volume. Previously issued FMS read tickets on the volume files are honored. When these tickets
have expired, you must remove the copy of the migrated file by running the review_volumes
utility.
14. (Optional) Select a date from the Files Accessed Before calendar to limit migration to files
accessed before the specified date.
15. (Optional) Select a date from the Files Accessed After calendar to limit migration to files accessed
after the specified date.

© 2021 Siemens
16. (Optional) Type a minimum and maximum number in the File Size Range From and To boxes and
select the size measurement type (bytes, KB or MB) from the list to limit migration to files within
the specified size range.
17. (Optional) In the MetaData Query Options section, select a workspace object type from the Saved
Queries list to limit migration to files of this object type.
18. If you select an object type in the previous step, type information into any of the boxes to further
define the saved query.
19. After you finish defining the data to be migrated, click Create at the bottom of the pane to create
the migration policy.
The migration policy appears under the Policies tree.
After one or more migration policies have been defined, you can preview the results of the migration,
then migrate the data.
Define a VM policy by watermark levels
This method creates a volume management (VM) migration policy that directs the system to migrate or
purge files when the specified watermark level (capacity) is reached within the source volume. The only
migration options that you can specify using this method are the source and destination volumes, and
the watermark levels of the source volume. You cannot define any additional migration options or query
options.
7. In the Volume Migration Options section, click Water Mark Levels.

migrate the data.

© 2021 Siemens
Define a VM policy by moving all files
Note:
10. Select a watermark percentage from the High Water Mark list. When the capacity of the source
volume reaches this percentage of capacity, migration begins.
11. Select a watermark percentage from the Low Water Mark list. When the capacity of the source
volume drops to this percentage level, migration ends.
After one or more migration policies are defined, you can preview the results of the migration, then
migrate the data.
Define a VM policy by moving all files
This method creates a volume management (VM) policy that migrates all files from the source volume
to the destination volume. The only migration options that can be specified using this method are the
source and destination volumes. No additional migration options or query options can be defined. This
is the least refined of the VM migration policies.
7. In the Volume Migration Options section, click Moving All Contents.


© 2021 Siemens
migrate the data.
Note:
10. (Optional) Select Retain Copy of Migrated File to retain a copy of the migrated file in the source
volume. Previously issued FMS read tickets on the volume files are honored. When these tickets
have expired, you must remove the copy of the migrated file by running the review_volumes
utility.
migrate the data.
Define an HSM policy to purge after migration
In this method, third-party hierarchical storage management (HSM) systems purge migrated data from
the source tier immediately after migration.
All HSM migration policies migrate specified lower priority files to third-party storage systems. Files
stored on secondary and tertiary tiers can still be read-accessed without returning them to the source
volume.
Note:
HSM migration policies require a third-party HSM system.
If you create both VM and HSM migration policies at your site, implementing a naming convention
that differentiates between the two types simplifies managing your policies from the Policies tree
after the policies are created.

© 2021 Siemens
Define an HSM policy to purge after migration
5. In the Policy Type section in the upper-right corner of the pane, click HSM Policy.
7. In the Purge Options section, click Purge After Migrate.
8. From the Migration Tier section, specify the migration path for the selected data. Click either
Primary-Secondary, Secondary-Tertiary, or Primary-Tertiary.
For example, Primary-Secondary migrates data from the primary tier to the secondary tier.
9. (Optional) In the Additional Migration Options section, select Re-Filed Files to refile the latest
version of data to the same tier from which it originated.
10. (Optional) Select Checked Out Objects to include the files of all checked-out objects in the
migration.
15. (Optional) Type a minimum and maximum number in the File Size Range From and To boxes and
select the size measurement type (bytes, KB or MB) from the list to limit migration to files within
the specified size range.
16. (Optional) Select 1 or 2 from the Reverse Migrate File Accessed More Than list. Any file in the
secondary or tertiary tier accessed more than the selected number of times is selected for reverse
migration.
18. If you selected an object type in the previous step, type information into any of the boxes to further
migrate the data.

© 2021 Siemens
Define an HSM policy to purge at watermark levels
In this method, third-party hierarchical storage management (HSM) systems purge migrated files from
the source tier only after the source tier capacity reaches a specified watermark level.
All HSM migration policies migrate specified lower priority files to third-party storage systems. Files
stored on secondary and tertiary tiers can still be read-accessed without returning them to the source
volume.
Note:
HSM migration policies require a third-party HSM system.
5. In the Policy Type section in the upper-right corner of the pane, click HSM Policy.
7. In the Purge Options section, click Purge Water Mark.
8. Select a watermark percentage from the High Water Mark list. When the capacity of the source
tier reaches this percentage of capacity, migration begins.
9. Select a watermark percentage from the Low Water Mark list. When the capacity of the source tier
drops to this percentage level, migration ends.
10. From the Migration Tier section, specify the migration path for the selected data. Click either
For example, Primary-Secondary migrates data from the primary volume to the secondary
volume.
11. (Optional) In the Additional Migration Options section, select Re-Filed Files to refile the latest
version of data to the same tier from which it originated.
12. (Optional) Select Checked Out Objects to include the files of all checked-out objects in the
migration.

© 2021 Siemens
Define a Volume Management policy based on an existing policy
17. (Optional) Select 1 or 2 from the Reverse Migrate File Accessed More Than list. Any file in the
secondary or tertiary tier accessed more than the selected number of times is selected for reverse
migration.
19. If you selected an object type in the previous step, type information into any of the boxes to further
After one or more migration policies have been defined, you can preview the results of the migration,
then migrate the data.
Define a Volume Management policy based on an existing policy
You can define a new volume management (VM) or hierarchical storage management (HSM) migration
policy based on an existing policy. Use this method when you want to create a migration policy similar
to an existing one.
2. Select an existing migration policy from the Policies tree.

The selected migration policy settings appear.
4. Type a new name for the migration policy in the Policy Name box.
5. Type a new description of the migration policy in the Policy Description box.

© 2021 Siemens
6. Modify the remaining settings as desired.
7. After you finish defining the data to be migrated, click Modify at the bottom of the pane to create
migrate the data.
Deactivate a migration policy in Volume Management
Make a migration policy inactive to prevent future evaluations and migrations. Inactive policies are
grayed out in the Policies tree.
2. Select an existing migration policy from the Policies tree.

The selected migration policy's settings appear.
4. In the Policy Status section, click Inactive.
Migrating volume data
Introduction to migrating volume data
After defining the data to be migrated, you can migrate the data to the specified location. Migrating
data involves previewing the migration results, marking the files for migration, and then migrating the
data.
Previewing migration results allows you to sort your volume files based on specified migration policies
and review the list of files to be migrated. Use the preview functionality to run what if scenarios to
assess the impact of a specific migration policy before implementing the migration. For example, if you
change the last access date of a migration policy from 90 days to 200 days, you can easily determine
how much more data will be moved between tiers or volumes by running a preview. You can print the
result or save the results to a file.
When you are satisfied with the migration results, you can mark the files for migration and migrate the
files.

© 2021 Siemens
Introduction to migrating volume data
Note:
For better performance, mark files for migration using the mark_for_migrate utility rather than
the Mark for Migration button in the Volume Management application. You can run this utility
overnight using a Windows at command or running a Linux cron job.
Migration methods differ depending on whether you are migrating data from a volume management
(VM) migration policy or a hierarchical storage management (HSM) migration policy.
VM migration policies can be migrated using one of the following methods:
• FMS-based migration uses the FSC process to migrate files from the source volume to the destination
volume. This method does not required a third-party migration tool and works without additional
configuration.
• Basic migration loosely couples your third-party migration tool with Teamcenter. Pending migration
file sets (VM_Migration files) are exported to a valid operating system directory, either in text or XML
format. The third-party migration tool reads the exported file to perform the migration.
Note:
Before using this method, your third-party migration tool must be configured to work with
Teamcenter.
Tip:
Before migrating VM migration policies, use the review_volumes utility to delete unreferenced
files.
HSM migration policies can be migrated using one of the following methods:
• Basic migration loosely couples third-party HSM storage systems with Teamcenter. Pending migration
file sets (HSM_Migration files) are exported to a valid operating system directory, either in text or
XML format. The HSM storage systems read the exported file to perform the migration.
Tip:
Before migrating VM migration policies, use the review_volumes utility to delete unreferenced
files.
• API-based migration tightly couples third-party HSM storage systems with Teamcenter. Pending
migration file sets are routed through API (user exit) calls to the HSM storage systems. This method
allows you to replace the base user exit extension with a custom extension using the Business
Modeler IDE. Use the HSM_migrate_files_msg operation (under HSM_Policy business objects) in the
Business Modeler IDE.

© 2021 Siemens
Preview migration results
Use the Preview functionality to evaluate how much data is migrated between volumes (for VM
policies) or migration tiers (HSM policies) for a selected migration policy. The migration information
appears in a pie chart illustrating the storage space saved by migrating the selected data (relative to the
capacity of the source volume) or in a text-based report detailing the number and size of migrated files.
Note:
Siemens Digital Industries Software recommends that you preview migration information before
actually migrating the data.
2. From the Policies tree, select a policy, either a volume management (VM) policy or a hierarchical
storage management (HSM) policy.
3. Click the Migration tab.

The policy name and description appear at the top of the Migration pane.
If you select a VM policy, the Migration Volumes section displays the source and destination
volume for the select migration policy. If you select an HSM policy, this section displays the tier
from which the data is being migrated and the tier to which it is being migrated.
4. In the Function Options section, click Preview.
5. Run the preview.
• At the bottom of the pane, click PieChart .

A pie chart appears in the Preview Report section.
• At the bottom of the pane, click Evaluate .

A text-based report appears in the Preview Report section.
6. (Optional) To the right of the Preview Report section, click Save to save the preview to a file, or
Print to print the preview.
Migrate VM policy data using FMS-based migration
Use the Migration functionality to migrate VM migration policy data from a source volume to a
destination volume using FMS-based migration. Teamcenter's FMS APIs for migration perform the file
migration and commit migration-related changes to the database.
2. From the Policies tree, select a volume management (VM) policy.

© 2021 Siemens
Migrate VM policy data using basic migration

The policy name and description display at the top of the Migration pane. Verify that the selected
policy is a VM migration policy.
The Migration Volumes section displays the source and destination volume for the select
migration policy.
4. In the Function Options section, click Migration.
5. At the bottom of the pane, click Mark For Migration.

Any files defined by the selected migration policy that meet the migration criteria are added to a
pending migration request and displayed in the Pending Migration Requests section.
6. Manage the pending migration requests in the list using any of the buttons to the right of the
Pending Migration Requests section.
7. Select the pending file request to be migrated and click the Migrate button to the right of the
The Migration dialog box appears.
8. Select Use FMS APIs for Migration and click OK. A progress indicator displays the migration
progress as the FMS APIs perform the file migration and the changes are committed to the
database.
Note:
If an error occurs, the current file is rolled back; files from the migration set that already
migrated without error are stored to the database. If you rectify the error and reselect the
same pending file set for migration, the second iteration of the migration begins from the
current file.
9. When the migration completes, a Migration successful message appears. Click OK.
Migrate VM policy data using basic migration
Use the Migration functionality to migrate volume management (VM) migration policy data from a
source volume to a destination volume using basic migration. This method requires third-party
migration tools.
Note:
Before using this migration method, you must export the pending file sets to the operating system
directory upon which your third-party migration tool is running. The migration tool reads the
exported file and performs the actual migration. The following steps ensure the migration
information is committed to the database. The pending file sets can be exported in either XML or
text format.

© 2021 Siemens
2. From the Policies tree, select a VM policy.

The policy name and description appear at the top of the Migration pane. Verify that the selected
The Migration Volumes section displays the source and destination volume for the select
migration policy.

7. Select the pending file request to be migrated and click the Export button to the right of the
The pending file sets are exported in either XML or text format to the operating system directory
upon which your third-party migration tool is running. The migration tool reads the exported file
and performs the actual migration.
Caution:
Ensure this step actually takes place before proceeding.
9. Select Use 3rd Party Tool for Migration and click OK.
10. Click Yes when the following message appears to confirm you have exported the pending file set
to the operating system for third-party tool migration:
Has the selected pending file set been exported for

third party tool migration?
A progress indicator appears as Teamcenter commits the file migration information to the
database.
11. After the migration completes, a Migration successful message appears. Click OK.

© 2021 Siemens
Migrate HSM policy data using basic migration
Migrate HSM policy data using basic migration
Use the Migration functionality to migrate hierarchical storage management (HSM) migration policy
data from a primary tier to a secondary or tertiary tier using basic migration.
Note:
Before using this migration method, you must export the pending file sets to the operating system
directory upon which your third-party migration tool is running. The migration tool reads the
exported file and performs the actual migration. The following steps ensure the migration
information is committed to the database. The pending file sets can be exported in either XML or
text format.
2. From the Policies tree, select an HSM policy.

The policy name and description appear at the top of the Migration pane. Verify that the selected
policy is an HSM migration policy.
The Migration Volumes section displays the tier from which the data is being migrated, and the
tier to which it is being migrated.

7. Select the pending file request to be migrated and click the Export button to the right of the
The pending file sets are exported in either XML or text format to the operating system directory
upon which your third-party migration tool is running. The migration tool reads the exported file
and performs the actual migration.
Caution:
Ensure this step actually takes place before proceeding.

© 2021 Siemens
9. Select Use Loosely Coupled (Basic) HSM Migration and click OK.
10. Click Yes when the following message appears to confirm you have exported the pending file set
to the operating system for third-party HSM tool migration:
Has the selected pending file set been exported for

third party HSM tool migration?
A progress indicator appears as Teamcenter commits the file migration information to the
database.
Migrate HSM policy data using API-based migration
Use the Migration functionality to migrate hierarchical storage management (HSM) migration policy
data from a primary tier to a secondary or tertiary tier using API-based migration. This method tightly
couples third-party HSM storage systems with Teamcenter. Pending migration file sets are routed
through API (user exit) calls to your HSM storage system. The API calls perform the actual migration and
commit the changes to the database.
Note:
HSM API-based migration requires tight integration with your third-party HSM system.

The policy name and description display at the top of the Migration pane. Verify that the selected
The Migration Volumes section displays the tier from which the data is being migrated, and the
tier to which it is being migrated.


© 2021 Siemens
Volume Management migrated file set format
8. Select Use Tightly Coupled (API Based) HSM Migration and click OK.
9. Click Yes when the following message appears to indicate you are using a third-party HSM storage
system:
Has the 3rd party file migration tool been integrated

and configured with Teamcenter?
The selected data is migrated. A progress indicator displays the migration progress as the APIs
perform the file migration and the changes are committed to the database.
Note:
If an error occurs, the current file is rolled back; files from the migration set which have
already migrated without error are stored to the database. If you rectify the error and re-
select the same pending file set for migration, the second iteration of the migration begins
from the current file.
Pending migrated file sets can be exported to any valid operating system directory in either XML or text
format. Your third-party HSM application reads these files to perform the migration. The following code
is an example of an XML DTD format for exporting pending migration sets.
The DTD is common to both VM and HSM migration policies.

<!ELEMENT policyInfo (enterpriseId, pendingFileSet+ )>
<!ELEMENT enterpriseId (#PCDATA)>
<!ELEMENT pendingFileSet (purgeInfo,tierInfo? )>
<!ELEMENT purgeInfo (purgeImmediately,purgeWaterMark?)>
<!ELEMENT purgeImmediately (#PCDATA)>
<!ELEMENT purgeWaterMark (lowWaterMark, highWaterMark)>
<!ELEMENT lowWaterMark (#PCDATA)>
<!ELEMENT highWaterMark (#PCDATA)>

© 2021 Siemens
<!ELEMENT tierInfo (migrateFromTier?, migrateToTier?, volumeInfo

+ )>
<!ELEMENT migrateFromTier (#PCDATA)>
<!ELEMENT migrateToTier (#PCDATA)>
<!ELEMENT volumeInfo (volumeName, nodeName, filePath+)>
<!ELEMENT volumeName (#PCDATA)>
<!ELEMENT nodeName (#PCDATA)>
<!ELEMENT filePath (#PCDATA )>
The following code is an example of a VM migration instruction in XML format:
<?xml version="1.0" encoding="ISO-8859-1"?>
<policyInfo>
<enterpriseId>-2035849880</enterpriseId>
<PendingFileSet>
<pendingObjUid>yTZFeW53opnVGC</pendingObjUid>
<purgeInfo>
<purgeImmediately>TRUE</purgeImmediately>
</purgeInfo>
<migrateFromSource>
<volumeInfo>
<volumeName>volume</volumeName>
<volumeNode>SVI6W181</volumeNode>
<filePath>d:\apps\Siemens\volume
\dba_51e2c745\mds_def_tex_j34034w4zk6p6.txt</filePath>
\dba_51e2c745\070000_unk_fho00tw4zk6r3.xlsm</filePath>
\dba_51e2c745\070000_unk_lxx00tw4zk6r1.xlsm</filePath>
\dba_51e2c745\070000_unk_1io00tw4zk6qz.xlsm</filePath>
\dba_51e2c745\070000_unk_j1p00tw4zk6qx.xlsm</filePath>
</volumeInfo>
</migrateFromSource>
<migrateToDestination>
<volumeInfo>
<volumeName>volume2</volumeName>
<filePath>d:\apps\Siemens\volume2\dba_51e9a92a
\mds_def_tex_j34034w4zk6p6.txt</filePath>
\070000_unk_fho00tw4zk6r3.xlsm</filePath>
\070000_unk_lxx00tw4zk6r1.xlsm</filePath>
\070000_unk_1io00tw4zk6qz.xlsm</filePath>

© 2021 Siemens
\070000_unk_j1p00tw4zk6qx.xlsm</filePath>
</volumeInfo>
</migrateToDestination>
</PendingFileSet>
</policyInfo>
The following code is an example of a VM migration instruction in text file format:
# Note: Lines starting with hash(#) provide HSM migration data. If this file
# is used with IBM TSM HSM migration utility, it logs error code 8 on lines
# starting with #.The user can ignore those errors or alternatively edit this
# file to remove lines starting with #, after comprehending the information.
# enterpriseId = -2035849880
# BEGIN:
# purgeImmediately = TRUE
# migrateFromSourceVolume = volume
# nodeName = SVI6W181
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_j1p00tw4zk6qx.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_1io00tw4zk6qz.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_lxx00tw4zk6r1.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_fho00tw4zk6r3.xlsm
d:\apps\Siemens\volume\dba_51e2c745\mds_def_tex_j34034w4zk6p6.txt
# migrateToDestinationVolume = volume2
d:\apps\Siemens\volume2\dba_51e9a92a\070000_unk_j1p00tw4zk6qx.xlsm
d:\apps\Siemens\volume2\dba_51e9a92a\070000_unk_1io00tw4zk6qz.xlsm
d:\apps\Siemens\volume2\dba_51e9a92a\070000_unk_lxx00tw4zk6r1.xlsm
d:\apps\Siemens\volume2\dba_51e9a92a\070000_unk_fho00tw4zk6r3.xlsm
d:\apps\Siemens\volume2\dba_51e9a92a\mds_def_tex_j34034w4zk6p6.txt
# END:
The following code is an example of an HSM migration instruction in XML format:
<?xml version="1.0" encoding="ISO-8859-1"?>
<policyInfo>
<enterpriseId>-2035849880</enterpriseId>
<PendingFileSet>
<pendingObjUid>AuaFfEDvopnVGC</pendingObjUid>
<purgeInfo>
<purgeImmediately>TRUE</purgeImmediately>
</purgeInfo>
<tierInfo>
<migrateFromTier>Secondary</migrateFromTier>
<migrateToTier>Tertiary</migrateToTier>
<volumeInfo>
<volumeName>volume</volumeName>
\dba_51e2c745\mds_def_tex_j34034w4zk6p6.txt</filePath>
\dba_51e2c745\070000_unk_fho00tw4zk6r3.xlsm</filePath>
\dba_51e2c745\070000_unk_lxx00tw4zk6r1.xlsm</filePath>

© 2021 Siemens
\dba_51e2c745\070000_unk_1io00tw4zk6qz.xlsm</filePath>
\dba_51e2c745\070000_unk_j1p00tw4zk6qx.xlsm</filePath>
</volumeInfo>
</tierInfo>
</PendingFileSet>
</policyInfo>
The following code is an example of an HSM migration instruction in text file format:
# Note: Lines starting with hash(#) provide HSM migration data. If this file
# is used with IBM TSM HSM migration utility, it logs error code 8 on lines
# starting with #.The user can ignore those errors or alternatively edit this
# file to remove lines starting with #, after comprehending the information.
# enterpriseId = -2035849880
# BEGIN:
# purgeImmediately = TRUE
# migrateFromTier = Secondary
# migrateToTier = Tertiary
# volumeName = volume
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_j1p00tw4zk6qx.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_1io00tw4zk6qz.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_lxx00tw4zk6r1.xlsm
d:\apps\Siemens\volume\dba_51e2c745\070000_unk_fho00tw4zk6r3.xlsm
d:\apps\Siemens\volume\dba_51e2c745\mds_def_tex_j34034w4zk6p6.txt
# END:
Volume Management migration reports
Introduction to generating volume migration reports
After migrating data, you can generate migration reports to determine how much data migrated
between volumes or tiers and to see which migration policies migrated the data. You can refine reports
by date, by policy, or generate a report covering all current migration policies. Reports can be printed or
saved to a file.
Reports can be generated using one of the following methods:
• Text-based reports provide an itemized list of the migrated files, the total number of migrated files,
and the total size (in bytes) of the migrated data.
• Pie chart reports illustrate the percentage of files that were migrated for each migration policy. These
reports can be saved as JPEGs or PNGs.

© 2021 Siemens
Generate a VM policy report
Note:
For better performance, generate migration reports using either the vm_report utility or the
hsm_report utility rather than the PieChart and Report buttons in the Volume Management
application. You can run them overnight using a Windows at command or running a Linux cron
job.
Generate a VM policy report
Use this report to determine how much data is migrated through a volume management (VM) migration
policy. The text report provides an itemized list of the migrated files, the total number of migrated files,
and the total size (in bytes) of the migrated data. The pie chart report graphically illustrates the storage
space saved by migrating the selected data, relative to the capacity of the source volume. You can save
the pie chart report as a JPEG or PNG file.
2. From the Policies tree, select a VM policy.
3. Click the Report tab.

The policy name and description appear at the top of the Report pane. Verify that the selected
4. In the Volume Migration Options section, select the source volume and destination volume for
which you want to generate the report.
5. (Optional) In the Migration Dates section, select the beginning and end dates for which you want
to generate the report.
6. Alternative to the two previous steps, select Load Previously Generated Report to load the last
report created.
7. Run the report.
• Click Report at the bottom of the pane to generate the text-based report.
• Click PieChart at the bottom of the pane to generate the graphic report.
The report appears in the Report section.
8. Manage the report using any of the buttons to the right of the Report section.

© 2021 Siemens
Generate an HSM policy report
Use this report to determine how much data is migrated through a hierarchical storage management
(HSM) migration policy. The text report provides an itemized list of the migrated files, the total number
of migrated files, and the total size (in bytes) of the migrated data. The pie chart report graphically
illustrates the storage space saved by migrating the selected data, relative to the capacity of the source
volume. You can save the pie chart report as a JPEG or PNG file.

The policy name and description appear at the top of the Report pane. Verify that the selected
4. From the Migration Tier section, specify the migration path for the selected policy. Click either
For example, Primary-Secondary reports the migrated data from the primary tier to the secondary
tier by the selected policy.
to generate the report.
report created.
7. Run the report.
• Click Report at the bottom of the pane to generate the text-based report.
Click PieChart at the bottom of the pane to generate the graphic report.
The report appears in the Report section.
Generate a report on all policies
Use this report to determine how much data is migrated using all currently defined policies, either
volume management (VM) policies or hierarchical storage management (HSM) policies. The report
format can be either text-based or in a pie chart.
2. From the Policies tree, select a policy, either a VM policy or an HSM policy.

© 2021 Siemens
Generate a report on all policies
If you select a VM policy, a report is run on all defined VM policies. If you select an HSM policy, a
report is run on all HSM policies.
4. Select All Policies to generate a report on all defined policies.
5. Refine the report.
• If you select a VM policy, in the Volume Migration Options section, select the source volume
and destination volume for which you want to generate the report.
• If you select an HSM policy, in the Migration Tier section, specify the migration path for the
selected data. Click either Primary-Secondary, Secondary-Tertiary, or Primary-Tertiary.
For example, Primary-Secondary migrates data from the primary volume to the secondary
volume.
to generate a report.
report created.
8. Click PieChart at the bottom of the pane to illustrate the percentage of files that were migrated
for each migration policy in the Report section.
9. Click Report at the bottom of the pane to generate the total number and size of all files that are
migrated by each policy in the Report section.

© 2021 Siemens

© 2021 Siemens
7. Administering Teamcenter client
communication system (TCCS)
Introduction to Teamcenter client communication system (TCCS)
As an enterprise class application, Teamcenter works within company infrastructure and security
policies. Teamcenter accommodates company infrastructure such as forward proxies, reverse proxies,
commercial single sign-on (SSO) integrations, and secure sockets layer (SSL), among others. Teamcenter
client communication system (TCCS) is a centralized tool to configure these points of contact between a
company’s infrastructure and Teamcenter.
TCCS includes the following features for supported clients:
• Forward proxy support

A forward proxy server takes requests from an internal network and forwards them to the Internet.
TCCS provides centralized forward proxy support to supported Teamcenter clients configured to use
TCCS for SOA/web tier requests. TCCS also provides forward proxy credentials sharing and reuse across
supported Teamcenter client applications. The FCC also uses TCCS forward proxy support.
• Reverse proxy support

A reverse proxy server takes requests from the Internet and forwards them to servers in an internal
network.
TCCS provides centralized reverse proxy support (for supported proxies) to supported Teamcenter
clients configured to use TCCS for SOA/web tier requests. Reverse proxy challenges and cookie storage
is managed by Security Services (SSO). Therefore, reverse proxy for WebSEAL is only supported in
environments for which SSO is enabled. The FCC also uses TCCS reverse proxy support.
• Centralized network configuration

Provides centralized configuration for defining web tier, SSO URLs, and forward proxy configurations.
Supported Teamcenter clients refer to a common configuration defined in TCCS. The ability to specify
specific environments to be used with a given TCCS connection is provided.

© 2021 Siemens
7. Administering Teamcenter client communication system (TCCS)
Teamcenter client communication system (TCCS) provides transport-level support to manage

communication between the following Teamcenter clients and the web tier or the FMS server cache
(FSC):
Business Modeler IDE

Client for Office
Lifecycle Visualization
NX
Rich client
Solid Edge
TcPMM
TCCS is a container application that contains the following Teamcenter applications:
• Teamcenter server proxy (TSP)

TSP manages HTTP communications for Teamcenter server (TcServer) requests. It accepts client
requests over secured pipes using a proprietary protocol and submits the requests over HTTP to the
web tier endpoint. TSP uses the TcProxyClient component and forward proxy configuration to
support forward and reverse proxy servers.
Use the tspstat utility to administer and obtain run-time statistics from TSP.
• Teamcenter model event manager (TcMEM)

TcMEM manages event synchronization across service-oriented architecture (SOA) clients sharing the
same Teamcenter server instance.
Use the tcmemstat utility to administer and obtain run-time statistics from TcMEM.
• FMS client cache (FCC)

The FCC provides a private user-level cache, just as web browsers provide a read file cache. It also
provides a high-performance cache for both downloaded and uploaded files. The FCC provides proxy
interfaces to client programs and connectivity to the server caches and volumes.
The FCC accepts client requests over secure pipe connections and submits them to the appropriate
FMS server cache (FSC) process. It uses the TcProxyClient component and forward proxy
configuration to support forward and reverse proxy servers.
Use the fccstat utility to administer and obtain run-time statistics from the FCC.
Note:
TCCS and all its container applications run simultaneously. Starting, stopping, or reconfiguring
TCCS (or any of its applications) propagates the same action to all.
TCCS installation is included in a Teamcenter client installation.
Clients using TCCS can use client-certificate authentication through secure sockets layer (SSL) settings.

© 2021 Siemens
Tools to configure TCCS
Tools to configure TCCS

You can configure Teamcenter client communication system (TCCS) using tools such as Teamcenter
Environment Manager (TEM), the TCCS installer, and the Client for Office installer. The TCCS
configuration options in these tools are similar. The remainder of the topics in Administering
Teamcenter client communication system (TCCS) show how to use Teamcenter Environment Manager
(TEM) to configure TCCS.
Teamcenter Environment Manager (TEM)

In TEM, configuration panels for TCCS appear during installation of 4-tier rich client and the 2 and 4-
tier rich client, especially if you choose Advanced options. Once TCCS has been installed, in the
Feature Maintenance panel of TEM, you can use the options in the Client Communication System
section to configure TCCS.
TCCS stand-alone installer
To install TCCS for a client other than the rich client, such as NX or Lifecycle Visualization, that needs
to communicate with a Teamcenter server, from the installation source files run the
additional_applications\tccs_install\tccinst.exe file.
Client for Office installer
To configure TCCS as part of installing Teamcenter Client for Microsoft Office, from the installation
source files run the additional_applications\OfficeClient\setup.exe file.
Configure TCCS for rich client (two-tier and four-tier)

When the Teamcenter Rich Client (2-tier and 4-tier) feature is installed, you must set up server
pointers in TCCS for both the two-tier client and the four-tier client.
1. In the Feature Maintenance panel of Teamcenter Environment Manager (TEM), under

Teamcenter Rich Client (2-tier and 4-tier) select Modify settings and click Next until you reach
the Environment Settings for Client Communication System panel.
The environments entered in this panel are displayed in the list of available environments when a
client is launched. Use this panel to set up pointers to both the two-tier client and the four-tier
client.
2. In the Environment Settings for Client Communication System panel, type values in the
following table cells:
Name Specifies the name of the TCCS environment. Assign the TCCS name precisely to
indicate a two-tier or four-tier environment.
URI/TC_DATA Specifies the four-tier URI to the TCCS environment or two-tier TC_DATA location.
TEM validates this field whether it is a valid URI or TC_DATA location.
Tag Specifies a pattern to apply when filtering the list of available TCCS environments.
SSO App ID Specifies the ID of the Security Services application you use with TCCS.

© 2021 Siemens
SSO Login Specifies the URL to the Security Services Login Service application you use with
URL TCCS.
TcServer Specifies the TcServer character encoding set that the two-tier rich client uses to
Character access the database by canonical name, for instance, Cp1252. This entry is only
Encoding needed for two-tier environments. This field is empty for four-tier environments.
Canonical
Name (2-
tier)
Single Specifies whether the connection is to a single server machine (true) or multiple
Server servers in a distributed environment (false).
3. To set up additional TCCS features such as forward and reverse proxy, SSL, and Kerberos
authentication, click Advanced.
A tabbed panel opens in which you can set up the features.
When you have finished setting up the features, click OK to close the advanced features panel.
4. Click Next until you reach the Confirmation panel and then click Start.
The environment information is saved. If the configuration is shared, the files are saved to the
AllUsersProfile\Siemens\cfg\tccs\Teamcenter\envs directory. If the configuration is private, the
files are saved to the UserProfile\Siemens\cfg\tccs\Teamcenter\envs directory.
When you log on to the client, the environments are displayed in a list when a client is launched.
Create shared or private TCCS configurations

A TCCS configuration contains information about how TCCS connects to the server. A TCCS configuration
can be either shared or private. If both private and shared configurations exist for a user, the private
configuration takes precedence.
A shared configuration is used by all system accounts. Location of the files depends on the operating
system:
For this operating system Shared TCCS files are located here
Windows 10 AllUsersProfile\Siemens\cfg
Linux etc/Siemens/cfg
A private configuration is used by a single user. On Windows systems, the files are located in UserProfile
\Siemens\cfg.
Perform the following steps to create shared or private TCCS configurations using Teamcenter
Environment Manager (TEM).

© 2021 Siemens
Configure TCCS for forward proxy
Note:
This procedure describes how to create shared or private configurations using TEM. Depending on
your environment, you can also configure TCCS using other tools such as the TCCS installer, the
Client for Office installer, and web tier context parameters. TCCS configuration options in these
tools are similar.
1. In TEM, navigate to the Feature Maintenance panel, and under Client Communication System,
select Use Configurations and Environments.
2. In the Client Communication System Switch panel, to authorize the system to use the
configuration, select Use Configurations and Environments and click Next.
To set up the configuration without enabling it in the system, leave the check box empty.
Tip:
If you have trouble launching Teamcenter after creating TCCS configurations, try clearing the
Use Configurations and Environments check box. It could be that an incorrect setting in a
configuration is the source of the problem.
3. In the Configuration Selection for Client Communication System panel, if you are a TCCS
administrator and you want this configuration to be used by multiple users, select Shared. By
default, the shared configuration is used by the system for all users connecting using TCCS.
If this configuration is for your use only, select Private.
A TCCS administrator can create both shared and private configurations. A non-TCCS administrator
can only create a private configuration. If both private and shared configurations exist for a user
(designated as existing in the configuration panel in TEM), the private configuration takes
precedence.
4. Click Next and continue to set up the configuration (for example, for forward proxy, environments,
and so on). Click Next until you reach the Confirmation panel and then click Start.
The configuration information is saved.
Configure TCCS for forward proxy

If Teamcenter client applications must use a forward proxy to access Teamcenter services such as the
web tier and the FMS server cache (FSC), then install Teamcenter client communication system (TCCS)
on the client machine and perform the following steps in Teamcenter Environment Manager (TEM) to
configure TCCS to point to the forward proxy server:
Note:
This procedure describes how to configure TCCS for forward proxy using TEM only. You can also
configure TCCS using other tools depending on your environment, such as the TCCS installer, the

© 2021 Siemens
Client for Office installer, and web tier context parameters. The TCCS configuration options in
most of these tools are similar.
Companies frequently use forward proxies to control access of clients to the Internet and to cache
responses to optimize Internet access. Users in these companies typically set their web browsers to use
the proxy server when accessing the Internet. When a Teamcenter client is deployed in such an
environment, it must adapt to the requirements of the forward proxy server including submission of the
request to a proxy address (in addition to the address for the Teamcenter service) and authentication to
the proxy server.
Many companies configure proxy access centrally for all browsers using a mechanism called proxy
autoconfiguration (PAC). Their web browsers are then set to download the autoconfiguration at startup.
Teamcenter clients leverage this existing central configuration to fit in automatically to your deployment
environment.
In TEM, navigate to the Forward Proxy Settings view, which is an advanced view of Client
Communication System settings. You reach the view as part of initial installation of the rich client, or as
modification of the Client Communication System feature configuration.
The settings in the Forward Proxy Settings view are similar to the settings found in web browsers for
configuring proxies. Select the appropriate setting for your environment, adding values as needed.
For this situation Do this
Your company does not use Select Do not use forward proxy
forward proxy.
Users in your company are required Select Use web browser settings.
to use their web browser settings to
Selecting this option automatically retrieves the proxy settings
point to the proxy server.
from the client’s web browser.
Your company uses a Web Proxy Select Detect settings from network.
Auto-Discovery Protocol (WPAD) to
With WPAD, clients automatically locate a URL of a configuration
file using the Dynamic Host Configuration Protocol (DHCP) or the
Domain Name System (DNS).
Your company uses a proxy Select Retrieve settings from URL.

autoconfiguration (PAC) file to
In the Proxy URL box, type the address where the PAC file is
located.
Your company does not use Select Configure settings manually.

automatic methods to point to the
proxy server.
In this situation Do this
The same proxy server Select All Protocols Host.

is used for all forward Type the host name or IP address of
the server in the Host box, and type

© 2021 Siemens
Configure TCCS for reverse proxy form-based authentication
For this situation Do this
and reverse proxy the server port number in the Port

requests. box.
You have separate Select HTTP Protocols.

proxy servers
Select HTTP Host and HTTPS Port and
dedicated to HTTP and
type the host and port information in
HTTPS requests.
the provided boxes.
In the Exceptions box, type a list of host names or IP addresses

that are not proxied. Separate hosts by semicolons. For example,
localhost; my_tc; 182 exempts http://localhost:8017/tc,
https://my_tc:14327/tc, and http://182.0.0.27:8080/tc.
The forward proxy information is saved in the fwdproxy_cfg.properties file.
To test forward proxy settings, you can launch the rich client and select a single sign-on (SSO)
environment for which forward proxy is set. A forward proxy challenge dialog box is displayed.
Configure TCCS for reverse proxy form-based authentication

If Teamcenter client applications must connect to the Teamcenter web tier via a reverse proxy server
that requires form-based authentication, and if the reverse proxy server is other than WebSEAL, then
you must either configure TCCS with advanced reverse proxy criteria to recognize the form-based
challenge, or disable reverse proxy criteria checking. Failure to do this may lead to errors about invalid
SOA responses.
Note:
This procedure describes how to use TEM to configure TCCS reverse proxy settings. Depending on
your environment, you can configure TCCS using other tools such as the TCCS installer, the
Client for Office installer, and web tier context parameters. The TCCS configuration options in
these tools are similar.
1. In TEM, navigate to the Reverse Proxy Settings view, which is an advanced view of Client
Communication System settings.

© 2021 Siemens
You reach the view as part of initial installation of the rich client, or as modification of the Client
Communication System feature configuration.
2. Depending on your situation, either configure TCCS with criteria to recognize the form-based
challenge, or disable reverse proxy criteria checking.
• Your reverse proxy performs Select the Skip reverse proxy criteria check check box.
form-based authentication
If checking is disabled, then TCCS treats all reverse proxy
using SiteMinder or another
text/html packages with HTTP status of 200 as form-based
server type that does not send
challenges that pass criteria checking.
specific header information in
the type 200 form-based
challenge.
• You are troubleshooting

communication errors, your
reverse proxy requires form-
based authentication, and you
suspect invalid criteria settings.
Your reverse proxy is not At your discretion, delete any existing criteria and form
configured for form-based actions. Criteria are not needed.
authentication challenges, thus
Ensure that the Skip reverse proxy criteria check check
there is no occasion for TCCS to
box is not selected.
perform checking.
Your reverse proxy server performs Ensure that the Skip reverse proxy criteria check check
form-based authentication using box is not selected.
WebSEAL, or using another server
Add appropriate criteria for identifying the challenge.
type that does send specific
header information in the type The Reverse Proxy Settings view includes two groups:
200 form-based challenge.
Private Reverse Proxy Settings
Lists the reverse proxy criteria currently defined. Each
row is a criteria XML element defined in the specified
format. By default, the table is blank and no criteria are
defined. A criterion string is of the following form:
Header_Name1, Header_Value1, Header_Name2,

Header_Value2,…:Form_Action
Criteria Details
Lists the details of a criterion selected in the Private
Reverse Proxy Settings group. Each criterion must
contain at least one header name/header value pair or
at least a single form action. To satisfy a criterion, a
reverse proxy form-based challenge package must

© 2021 Siemens
Configure multiple TCCS environments
match every criteria element listed within a given

criterion.
a. Next to the Private Reverse Proxy Settings group,

click Add.
b. Next to the Criteria Details group, use the Add and

Remove buttons to add or remove HTTP header names
and values for the selected criterion.
c. In the Form Action box, specify a form action.
d. Click Apply.
The criterion is added to the criteria table.
Note:
If you have reached the Reverse Proxy Settings view
in TEM, and you do deploy the advanced TCCS
configuration, TEM saves the configuration to the
reverseproxy_cfg.xml file, which overrides the
default WebSEAL configuration. To ensure that TCCS
correctly performs checking if you use WebSEAL, add
the following criterion:
Header Header Form action

name value
server webseal /pkmslogin.form
When you are through configuring criteria, click Next until you reach the Confirmation panel and
click Start.
The reverse proxy information is saved in the reverseproxy_config.xml file.

A single TCCS configuration can contain multiple environments, providing support for multiple versions
or server databases. For example, you may want to install some TCCS environments with Security
Services (SSO), some environments without SSO, some environments on one server, and other
environments on another server.

© 2021 Siemens
If multiple environments are configured, all environments are displayed at rich client logon, allowing the
user to select which TCCS environment to use.
Each environment contains one or both of the following service types:
• sso
The sso service endpoint corresponds to the SSO logon URL. id corresponds to SSO AppID.
• tcserver
The tcserver service endpoint is the URL of the web tier deployment.
Perform the following steps to create multiple environments using Teamcenter Environment Manager
(TEM).
1. In the Feature Maintenance panel of TEM, under Client Communication System select Modify
Configurations and click Next until you reach the Environment Settings for Client
Communication System panel.
The environments entered in this panel are displayed in the list of available environments when a
client is launched.
2. To add a TCCS environment, in the Environment Settings for Client Communication System
panel, click Add.
a. For each environment, type a value in the Name and URI boxes.
Note:
If your network uses IPv6 (128-bit) addresses, use the hostname in URIs and do not use
the literal addresses, so the domain name system (DNS) can determine which IP address
should be used.
b. (Optional) Use the Tag box to tag the environment. When installing a rich client, you can
optionally provide a Client Tag Filter value to filter the list of environments displayed in the
rich client to those environments that match the filter.

© 2021 Siemens
Example:
You create 10 environments, three on Server1 with SSO, three on Server1 without
SSO, and four on Server2.
Tag the environments SSO, no SSO, and Server2, respectively.
Tip:
You must have already created these tags. To create a tag, see the Client Tag Filter
panel described later in this procedure.
c. If you want to add a single sign-on environment, type the values for the single sign-on server
in the SSO App ID and SSO Login URL boxes.
For example, in the SSO App ID box, type the value of the SSO_APPLICATION_ID context
parameter from the web tier installation. In the SSO Login URL box, type the value of the
SSO_LOGIN_SERVICE_URL context parameter.
Tip:
You must have already set up the single sign-on server.
3. Click Next until you reach the Client Tag Filter panel.
The Client Tag Filter value specifies a pattern to apply when clients filter TCCS environments. To
specify multiple filter tags, separate the entries with a pipe (|).
Example:
To display only the environments containing the SSO tag, type SSO in the box.
To display the environments containing the SSO and Server2 tags, type SSO|Server2 in the
box.
When installing a rich client, you can optionally provide a Client Tag Filter value to filter the list of
environments displayed in the rich client to those environments that match the filter. (In a four-tier
environment, the Client Tag Filter context parameter sets the tag.) Environments that do not fit
the pattern are not available to the rich client. For example, if the rich client Client Tag Filter value
is 9.*, all TCCS environments with Tag values beginning with 9. are available to the rich client.
Environments with Tag values beginning with 10 are not available.
The environment information is saved. If the configuration is shared, the files are saved to the
AllUsersProfile\Siemens\cfg\tccs\Teamcenter\envs directory. If the configuration is private, the
files are saved to the UserProfile\Siemens\cfg\tccs\Teamcenter\envs directory.

© 2021 Siemens
Configure TCCS for Kerberos

Kerberos, a network authentication protocol originally developed at MIT, provides authentication for
client/server applications by using secret-key cryptography. With the Kerberos protocol, a client proves
its identity to a server (and vice versa) across an insecure network connection. Kerberos allows a user to
be authenticated without sending the user’s password over the network. Instead, encrypted tickets
derived from the password and secret key information are sent over the network.
After you install Kerberos, perform the following steps to set up an environment in TCCS so that users
can log on to Teamcenter using Kerberos authentication:
In TEM, navigate to the Kerberos Authentication Settings view, which is an advanced view of Client
1. Select the Support Kerberos authentication check box.
2. Select the Kerberos configuration file:
• Select Use default settings if you want to use the default Kerberos configuration file on the
host.
On Windows hosts, the default file is C:\Windows\krb5.ini. For Linux, the default file is etc/
krb5.conf.
• Select Use this Krb5 file you want to use a custom Kerberos configuration file. If you select this
option, enter the path to the file.
The following is an example of a Kerberos configuration file (krb5.ini):
[libdefaults]
default_realm = TCSS2.NET
default_tkt_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = aes128-cts rc4-hmac des3-cbc-sha1 des-cbc-md5 des-cbc-crc
[realms]
TCSS2.NET = {
kdc = myhost1.TCSS2.net
}
TCSSO.NET = {
kdc = myhost2.TCSSO.net
}
TCTCSS.NET = {
kdc = myhost3.TCTCSS.net
}
TCTCSS-CHILD.TCTCSS.NET = {
kdc = myhost4.net.acmecorp.com
}
[domain_realm]
.TCSS2.net = TCSS2.NET
.TCTCSS.net = TCTCSS.NET

© 2021 Siemens
Configure TCCS for Kerberos
.TCTCSS-child.TCTCSS.net = TCTCSS-CHILD.TCTCSS.NET
.TCSSO.net=TCSSO.NET
[capaths]
TCTCSS.NET = {
TCSSO.NET = .
}
3. To always prompt for a Kerberos user name, select the Always prompt for User ID check box. If
you want to enable zero sign-on functionality on Windows hosts, clear this check box.
Zero sign-on allows Windows users to launch a Teamcenter client without being prompted to log
on to Teamcenter. Zero sign-on functionality requires that you configure Security Services in
applet-free mode.
4. Click the Back button until you reach the Environment Settings for Client Communication
System panel.
5. In the Environment Settings for Client Communication System panel, enter the Kerberos
environment. (For applet-free mode, ensure that /tccs is appended at the end of the value in the
SSO Login URL box.)
The Kerberos environment information is saved.
When users log on, they select an environment from the list of configured environments.
When prompted for a user name, user must correctly enter the user name for the environment. For
Kerberos authentication, the domain must be in all uppercase letters. (For example,
username@DOMAIN).

© 2021 Siemens
Configure TCCS for SSL

Secure sockets layer (SSL) is a framework to provide an encrypted connection between the client and
the server.
Following are some SSL terms and their meanings:
Cacerts A file that holds certificates issued by trusted certificate authorities (CAs).
Certificate A verification tool that consists of a public encryption key with identity information and
an expiration date. Clients and servers trust certain certificate authorities (CAs) that
issue SSL certificates.
Keys An encryption key pair that consists of a private key and a corresponding public key.
Data encrypted by one can only be decrypted by other.
Keystore A file used for storing private keys and certificates and their corresponding public keys.
Truststore A file used for storing certificates from other parties or from trusted certificate
authorities. A cacerts file is a truststore.
If you have set up your enterprise to use SSL, perform the following steps to configure TCCS to use SSL:
In TEM, navigate to the Secure Socket Layer (SSL) Settings view, which is an advanced view of Client
1. In the Secure Socket Layer (SSL) Settings panel, select one of the following:
• Use Internet Explorer Certificate Store (Recommended)

Uses certificates stored in Microsoft Internet Explorer. This option is available only on Windows
hosts.
• Disable SSL
Turns off SSL.
• Configure Certificate Store Manually

Allows you to certificate store you want to use.
a. Select Use trust store (supported type is JKS) to use an established repository file of
trusted certificates, such as Java KeyStore. Click the ellipse button in the File box to point to
the file. This populates the truststore element in the tccs.xml file. (When this is
unspecified, Java uses the standard Java Development Kit (JDK) CA keystore in the jre/lib/
security/cacerts folder.)
b. Select Accept untrusted certificates to allow self-signed certificates from untrusted

parties. This sets the allowuntrustedcertificates element in the tccs.xml file to true.
Select this option if you do not want to provide warnings for untrusted certificates.

© 2021 Siemens
Modify four-tier server connection settings
c. Select Use Key Store to use a keystore file that holds private keys and certificates and their
corresponding public keys. Click the ellipse button in the File box to point to the keystore
file. This populates the keystore element in the tccs.xml file. Click the arrow in the Type
box to select JKS or PKCS12 as the keystore file format.
2. Click Next until you arrive at the Confirmation panel and then click Start.
The SSL settings are saved.
3. Verify the following SSL settings in the tccs.xml file:
This setting Specifies this
keystore The path to a key store file containing a user’s private keys.
keystorepassw The password for the key store file.

ord
truststore The path to a trust store file that hold trusted certificates. When this is
unspecified, Java uses a standard JDK file cacerts.
truststorepass The password for the trust store.

word
allowuntruste Allows self-signed certificates from untrusted parties.

dcertificates
Modify four-tier server connection settings

You can change the list of web servers available for connection from the four-tier rich client.
1. In the Feature Maintenance panel of TEM, under Client Communication System, select Modify
4-tier server settings and click Next.
2. In the 4-tier server configurations panel, in the 4-tier Servers list, edit the list.
TEM applies the four-tier server settings.
Modify FCC parent settings

You can specify the FMS server caches (FSCs) used by the FMS client cache (FCC). The FCC can have
multiple parent FSCs to use in case of failover. FSCs are used in the priority you specify.

© 2021 Siemens
1. In the Feature Maintenance panel of TEM, under Client Communication Setting, select Modify
FCC Parent settings and click Next.
The FCC Parents panel is displayed.
2. From the FSC assignment mode list, select the method to assign FSCs:
• clientmap
Routes FCC data requests to the assignedfsc elements specified within the clientmap section of
the fmsmaster_fscid.xml configuration file.
• parentfsc
Routes FCC data requests to the list of parentfsc elements specified in the fcc.xml configuration
file.
Use this setting when the default client mapping setting is not efficient.
3. In the FCC Parents table, add the FSC parents and set their priority. This table specifies from which
FSCs to download the FMS configuration information. FSCs are used in the priority you specify. You
may specify multiple parent FSCs to provide failover.
The values entered are placed into the parentfsc node of the FMS_HOME/fcc.xml file.
The FCC parent settings are saved.
5. Verify the settings in the TC_ROOT\tccs\fcc.xml file:

<parentfsc address="http://SVI6W181:4544/" priority="0" />
<parentfsc address="http://AHIU351:4544/" priority="1" />
<parentfsc address="http://LLB3W067:4544/" priority="2" />
Find Security Services settings for use in TCCS

Teamcenter Security Services works in conjunction with Teamcenter client communication system
(TCCS). When you configure TCCS, you must point to settings for Security Services.
For example, in the Environment Settings for Client Communication System panel, you must type
Security Services settings in the SSO App ID and the SSO Login URL boxes.
The settings that are used with TCCS are configured when Security Services is first installed.

© 2021 Siemens
Orientation to TCCS configuration files
To review the settings, in the Web Application Manager, open the context parameters panel.
Corresponding value in the Environment

This context parameter value in the Web Settings for Client Communication System
Application Manager panel
SSO_APPLICATION_ID SSO App ID
SSO_LOGIN_SERVICE_URL SSO Login URL
TCCS configuration files
Orientation to TCCS configuration files
After you install TCCS, you can configure TCCS using the following configuration files:
tccs.xml
Configures TCCS settings. This file includes a list of applications configured with TCCS and HTTP
configuration values.
fwdproxy_cfg.properties
Configures forward proxy settings.
reverseproxy_config.xml
Configures reverse proxy settings.
TCCS configuration files location
When TCCS starts, it looks for TCCS configuration files in the location concatenated as a combination of
parent and child folders. The folder locations can be set by the following environment variables.
TCCS_CONFIG_HOME
Sets the path to the TCCS configurations home directory (the parent folder).

© 2021 Siemens
OS Default TCCS_CONFIG_HOME value
Windows For a private installation: %USERPROFILE%\Siemens\cfg\tccs

For a shared installation: %ALLUSERSPROFILE%\Siemens\cfg\tccs
Linux For a private installation: $HOME/Siemens/cfg/tccs

For a shared installation: /etc/Siemens/cfg/tccs
TCCS_CONFIG
Sets the name of the TCCS configuration directory containing the TCCS environment configuration
files (the child folder).
If TCCS_CONFIG is undefined, the default child folder value is Teamcenter.
When TCCS is upgraded or installed as part of a client, configuration files are always placed in the
default location, even if TCCS_CONFIG_HOME or TCCS_CONFG is set to other than the default value. In
that case, adjust either the environment variable values or the file locations so that TCCS finds the
correct files.
tccs.xml file
The tccs.xml file defines TCCS configuration settings.
The tccs.xml file contains the following sections:
• List of applications configured with TCCS

This section contains the list of hosted TCCS components and the startup information for each
component.
• Max idle time in minutes for TCCS before it shuts down

The maxidletime attribute indicates the maximum time (in minutes) the application is idle before
shutting itself down. The default idle time is 240 minutes.
• Default HTTP Configuration

The default HTTP configuration settings work for most Teamcenter environments. Components with
the initialize attribute set to true are initialized during TCCS startup. These components apply to all
the TCCS container applications using TcProxyClient transports, such as the FCC and the Teamcenter
server proxy.
Note:
Alternative settings of the same components in the tcserverproxy.xml file take precedence for
Teamcenter server proxy behavior.
• allowchunking

© 2021 Siemens
tccs.xml file
Allows the HTTP message body to be transmitted to the client as chunks that are stamped with the
size of the chunks.
The default value for the attribute is false. This value must be false for WebSEAL proxy servers
when you are using an IIS web server because the IIS web server does not support chunking. This
value must be false when using a Squid proxy server because the Squid proxy server does not fully
support HTTP version 1.1, which is the version that supports chunking.
• allowuntrustedcertificates
Allows TCCS to accept server certificates that are not signed by a trusted certificate authority.
• connectiontimeout
Sets the time period that a connection remains idle before it is closed.
• httpversion
Indicates the HTTP protocol version. The default is version 1.1.
Note:
HTTP version 1.1 supports chunking; version 1.0 does not.
• keystore
Sets the path to the Java keystore containing the user’s own certificate and private key used for
two-way SSL. The value is set into the Java system’s javax.net.ssl.keyStore property.
• keystorepassword
Specifies the password for the Java keystore. The value is set into the Java system’s
javax.net.ssl.keyStorePassword property.
• maxconnectionsperhost
Sets the maximum number of connections to the proxy server from a single host. The default value
is 8.
• maxretriesreverseproxy
Set the maximum number of times an HTTP request is attempted when receiving an authentication
challenge from a reverse proxy server.
• sslEnabled
Sets whether secure sockets layer (SSL) is enabled. This attribute is optional and appears only when
the installer selects one of the following on the Secure Socket Layer (SSL) Settings panel in
Teamcenter Environment Manager (TEM):
■ Disable SSL
■ Accept untrusted certificates

© 2021 Siemens
■ Configure keystore
Note:
The application assumes that SSL is enabled regardless of the sslEnabled tag in the XML file
when the value of the allowuntrustedcertificates setting is false, the keystore and truststore
paths are not specified, and SSL is not disabled.
• sockettimeout
Sets the maximum amount of time (in milliseconds) the HttpClient component (the TCCS HTTP
transport library) waits for data when executing the method. A value of zero specifies an infinite
time-out.
• stalechecking
Enables the HttpClient component (the TCCS HTTP transport library) to determine if the active
connection is stale before executing a request.
Typically, stale checking is disabled to improve performance.
• totalmaxconnections
Sets the maximum number of connections to the proxy server from all hosts.
• truststore
Specifies the path to the Java keystore containing the certificate authority (CA) certificates trusted
by the user. The value is set into the Java system’s javax.net.ssl.trustStore property. If not
specified, the Java default trust store is used.
• truststorepassword
Specifies the password for the Java trust store. The value is set into the Java system’s
javax.net.ssl.trustStorePassword property.
• usesinglecookieheader
When submitting multiple HTTP cookies to a server, allows TCCS to place all cookies in a single
cookie header rather than using multiple cookie headers. Set to true to allow submitting a single
cookie header. This is useful when working with HTTP servers that cannot process multiple cookie
headers correctly.
• Default Kerberos configuration

If Kerberos authentication is configured, the following components are listed.
• kerberosconfig
Set enable to true to configure support for Kerberos authentication in TCCS. The default value is
false.
• alwayspromptforusername
Determines whether TCCS prompts users for their user name with Kerberos authentication. Set to
true for users to be prompted for their user name, preventing zero sign-on functionality. Set to

© 2021 Siemens
fwdproxy_cfg.properties file
false for the user name to be automatically obtained from the operating system logon, enabling
zero signon functionality.
The default value is false. This attribute is only valid when kerberosconfig enable is set to true.
• krb5path value
Specifies the path to the Krb5 file used with Kerberos authentication. This must be the absolute
path to the Krb5 file including the file name. If no value is provided, the Krb5 file is located in the
default location as specified in the Sun Java documentation.
fwdproxy_cfg.properties file
The fwdproxy_cfg.properties file contains forward proxy-related configuration properties used by TCCS
for server requests. All these values are set in the Teamcenter Environment Manager (TEM) Forward
Proxy Settings panel.
To view the panel in TEM, in the Feature Maintenance Panel under Client Communication System,
select Modify Configurations and click Next until you reach the Forward Proxy Settings panel.
Note:
If your network uses IPv6 (128-bit) addresses, use the hostname in URIs and do not use the literal
addresses, so the domain name system (DNS) can determine which IP address should be used.
The file contains the following properties:
• tcproxy.connection.type
Determines the type of connection for forward proxy servers. The default value is direct, indicating
there is no forward proxy server. Other valid values for this property are:
• browser
Uses the web browser proxy settings.
If you have more than one browser installed, your designated default browser is used.
• network
Detects the proxy settings from the network the client is on.
• url
Retrieves the proxy autoconfiguration (PAC) file from the URL set in the tcproxy.connection.url
property.
• manual
Uses the proxy settings set in the manual configuration properties. These are the properties
prefixed with tcproxy.connection.manual in this file. The manual configuration properties are
ignored if the tcproxy.connection.type attribute is not set to manual.

© 2021 Siemens
• tcproxy.connection.url
Sets the URL the TCCS application uses to retrieve the PAC file. This property must have a value if the
tcproxy.connection.type attribute is set to url.
• tcproxy.connection.manual.all.host
Sets the host name or IP address for the proxy server for all protocols.
If you set a value for this property, the following protocol host and port properties are ignored:
• tcproxy.connection.manual.all.port
Sets the port number for the proxy server for all protocols.
• tcproxy.connection.manual.http.host
Sets the host name or IP address for the proxy server for the HTTP protocol. If using manual
configuration properties and a value for this property is not provided, HTTP requests attempt to
connect directly to the server host.
• tcproxy.connection.manual.http.port
Sets the port number for the proxy server for the HTTP protocol.
• tcproxy.connection.manual.https.host
Sets the host name or IP address for proxy server for the HTTPS protocol. If using manual
configuration properties and a value for this property is not provided, HTTPS requests attempt to
connect directly to the server host.
• tcproxy.connection.manual.https.port
Sets the port number for the proxy server for the HTTPS protocol.
• tcproxy.connection.manual.socks.host
Sets the host name or IP address for proxy server for the SOCKS protocol. If using manual
configuration properties and a value for this property is not provided, the SOCKS protocol requests
attempt to connect directly to the server host.
• tcproxy.connection.manual.socks.port
Sets the port number for the proxy server for the SOCKS protocol.
• tcproxy.connection.manual.exceptions
Contains a semicolon-delimited list of hosts where direct connections can be attempted.
• tcproxy.advanced.address_caching
Indicates whether resolved proxy addresses are cached based on their host and port. Valid values
are on and off (case-sensitive)
• tcproxy.advanced.retry_delay
Specifies the number of minutes to wait before retrying a connection to a proxy server that failed a
client connection. Valid values are any positive integer.

© 2021 Siemens
reverseproxy_config.xml file
reverseproxy_config.xml file
The reverseproxy_config.xml file contains a list of criteria used for detecting a form challenge from a
reverse proxy server.
A criteria element requires one or more header elements and can contain zero or one form element.
Default criteria elements are provided for WebSEAL and SiteMinder. You can edit these or add additional
criteria elements, for example:
<criteria active="true">
<header name="server" value="Webseal"/>
<header name="challengeType" value="Form"/>
<form action="pkmsloginform"/>
</criteria>
The criteria list of values can be set in the Teamcenter Environment Manager (TEM) Reverse Proxy
Settings panel. To view the panel in TEM, in the Feature Maintenance Panel under Client
Communication System, select Modify Configurations and click Next until you reach the Reverse
Proxy Settings panel.
TCCS and container applications
Administering the TCCS container
The TCCS container reads TCCS configuration files on startup and launches the container applications
enabled in the configuration.
Enable each container application to run within TCCS by setting its initialize parameter to true in the
tccs.xml file, for example:
Consider the following behavior when working with the TCCS container:
• TcProxyClient component
The container initializes the TcProxyClient component that is the forward and reverse proxy support
library for TCCS.
• Idle shutdown
TCCS checks each application to determine if it is idle, shutting down when all applications are idle for
a configured amount of time. By default, this is set to 240 minutes. If set to zero, TCCS does not
automatically shut down. It continues to run until manually shut down.

© 2021 Siemens
• Fatal application errors

Each application shuts down the TCCS container if it encounters an unrecoverable fatal error.
• Restart
You must restart TCCS after making changes in TCCS configurations, such as forward proxy, server
end points, and HTTP parameters.
Note:
• TCCS lock file

The inappropriate shutdown of TCCS can cause the lock file to become stuck.
If the lock file has become stuck, remove the TCCS lock file. It is stored in the %USERPROFILE% \.user-
name_lock_host-name directory (Windows) or HOME /.user-name_lock_host-name directory (Linux).
The file name is TCCS_CONFIG.lck. By default, the TCCS_CONFIG environment variable is set to
Teamcenter.
For example:
C:\Users\smith\.smith_lock_host123\Teamcenter.lck
Administering the Teamcenter server proxy
The Teamcenter server proxy manages HTTP communications for Teamcenter server (TcServer)
requests. It accepts client requests over secured pipes using a proprietary protocol and submits the
requests over HTTP to the web tier endpoint.
Use the tcserverproxy.xml file to set HTTP configuration elements related to Teamcenter server proxy
behavior. (The file is located in the USERPROFILE\Siemens\cfg\tccs\TCCS_CONFIG directory.) These
settings override any corresponding tccs.xml file settings applied to Teamcenter server proxy behavior.
(Settings in the tcserverproxy.xml file do not affect corresponding tccs.xml file settings as applied to
FCC behavior.)
Use the tspstat utility to administer and obtain run-time statistics from the TcServerProxy component.
Note:
The tcserverproxy.xml file contains HTTP configuration elements related to the TcServerProxy
component. These settings override any corresponding tccs.xml file settings.
It contains the following configuration elements:
• maxconnectionsperhost

© 2021 Siemens
Administering the FCC for TCCS
Sets the maximum number of connections through each proxy server to a single host. The default
value is 8.
• totalmaxconnections
Sets the maximum number of connections through each proxy server to all hosts. The default value is
10.
• connectiontimeout
Sets the time period that a connection remains idle before it is closed. The default value is 30000.
• sockettimeout
Sets the maximum amount of time (in milliseconds) the HttpClient component (the TCCS HTTP
transport library) waits for data when executing the method. The default value is 0, which specifies
an infinite time-out.
• stalechecking
Enables the HttpClient component (the TCCS HTTP transport library) to perform determine if the
active connection is stale before executing a request. The default value is false.
Typically, stale checking is disabled to improve performance.
• maxretriesreverseproxy
Sets the maximum number of times an HTTP request is attempted when receiving an authentication
challenge from a reverse proxy server. The default value is 5.
• idleconntimeoutms
Sets the time period (in milliseconds) that a connection remains idle before it is closed. The default
value is 30000.
• idleconnintervalms
Sets the time period (in milliseconds) for the interval between closing each idle server connection.
The default value is 10000.
• httpversion
Indicates the HTTP protocol version. The default value is version 1.1.
Note:
HTTP version 1.1 supports chunking, version 1.0 does not.
Administering the FCC for TCCS
The FMS client cache (FCC) provides a private user-level cache, just as web browsers provide a read file
cache. The FCC also provides a high-performance cache for both downloaded and uploaded files. The
FCC provides proxy interfaces to client programs and connectivity to the server caches and volumes.
• Use the fcc.xml file to manage FCC behavior, such as connection time-outs and the maximum
number of retries.

© 2021 Siemens
• Use the fccstat utility to administer and obtain run-time statistics from the FCC.
Consider the following behaviors when working with the FCC as it runs with TCCS:
• Setting the initialize parameter of the FMSClientCache element to true in the tccs.xml file enables
FCC functionality when TCCS starts. This is the default value.
• The only tccs.xml file the FCC accesses is the one stored in the TCCS configuration directory. Any
other tccs.xml files are ignored.
• HTTP configuration parameters in the tccs.xml file are also applied to the FCC connections to an FMS
server cache (FSC).
Note:
Note:
Native FCC does not run in the TCCS container.
Administering TcMEM
The Teamcenter model event manager (TcMEM) manages event synchronization across SOA clients
sharing the same Teamcenter server instance.
Use the tcmemstat utility to administer and obtain run-time statistics from TcMEM.
Note:
Administering proxy support for clients not integrated with TCCS

Not all Siemens Digital Industries Software clients are integrated with TCCS, including:
• Teamcenter Systems Engineering
Consider the following when administering proxy support for clients not integrated with TCCS:
• Forward proxy support

A non-integrated client does not leverage the TCCS ability to send requests using a forward proxy
server. Unless the client has its own support for forward proxy, the client must connect directly to any

© 2021 Siemens
TCCS logging
Teamcenter services it requires. A client with its own forward proxy support does not leverage the
TCCS proxy configuration and must be separately configured.
Note:
Browser-based clients do not integrate with TCCS but do leverage the browser’s capabilities and
configuration.
• Reverse proxy support

A non-integrated client does not leverage the TCCS ability to recognize authentication challenges
from a reverse proxy server such as WebSEAL.
If the Teamcenter web tier is protected by an authenticating reverse proxy server, the client must
have its own support for recognizing and responding to authentication challenges. There is limited
support for this recognition and response in some clients, including those based exclusively on the
Teamcenter SOA client framework.
If only Security Services is protected by an authenticating reverse proxy server, a client does not
directly receive authentication challenges from the reverse proxy. The challenges come only to the
browser and applet used for TcSS authentication and session management. The browser and applet
are capable of responding to these challenges.
TCCS logging
You can examine TCCS log files to troubleshoot problems. TCCS log files are stored in:
• Windows systems:
%USERPROFILE% \user-name\Siemens\ogs\tccs\TCCS\process\
tccs_os-user-name_%TCCS_CONFIG_host-name.log
• Linux systems:
$HOME/user-name/Siemens/logs/tccs/TCCS/process/
tccs_os-user-name_$TCCS_CONFIG_host-name.log
Users can change the log file location by setting the LOG_VOLUME_LOCATION environment variable to
a different location.
There are two logging configuration files, stored in the same location as the TCCS startup script.
• log.properties
When TCCS starts, it looks for this file’s location in the classpath. The location is specified by the
LogVolumeLocation parameter, which points to the logs value, which specifies the relative path to
the TCCS startup script.
TCCS log files are output to the TCCS/process subdirectory within the logs directory. Users can change
the location that TCCS log files are stored by setting the LOG_VOLUME_LOCATION environment
variable. In which case, the TCCS log files are written to LOG_VOLUME_LOCATION/TCCS/process.
The log.properties file contains the LogConfigLocation parameter, which specifies the name of the
logger definition file, stored in the same directory as the log.properties file. By default, this is the
log4j.xml file.

© 2021 Siemens
• log4j.xml
This file contains an Appenders section and an MLD Loggers section. The appenders are referenced by
the logger definitions. Users can add additional loggers to the file. The following must be specified for
each logger entry:
• logger name
Specifies the name of the MLD logger.
• level value
Specifies the level of logging performed by the specified logger. See the following table for default
logging levels.
By default, all logging levels are set to warn.
• appender-ref
Specifies the appender to reference.
For example:
Logging level name Description
fatal Logs only fatal errors. Fatal errors typically result in application
shutdown.
error Logs all errors.
warn Logs all warnings and errors.
info Includes debugging logs along with all warnings and errors.
debug Includes debug log levels and debugging logs, along with all
warnings and errors.
Users can define their own custom log4j configuration. This allows them to supply their own
configuration without affecting other users sharing the same TCCS deployment environment. In this
case, the LOG_CONFIG_LOCATION environment variable must be set to specify the location of the
custom log4j file.

© 2021 Siemens
8. Configuring external management of
passwords
Enabling external password management for Teamcenter
Administrators can install Security Services to enable user password management by an external identity
service provider, rather than by Teamcenter. All other user administration tasks remain within
Teamcenter.
Security Services is optional. To enable external password management, the Security Services services
must be installed and an external identity service provider must be configured.
Configuring Teamcenter clients for Security Services

After Security Services is installed and the external identity service provider configured, configure
Security Services for Teamcenter by manually entering the Security Services environment variables in
the tc_profilevars properties file and the rich client properties in the site_specific.properties file.
To enable Security Services for Teamcenter clients other than the rich client, such as command line
utilities and ODBC Driver, set the TC_SSO_SERVICE environment variable. When this environment
variable is set, user authentication is performed by the external identity service provider (the user must
enter the password defined in the external identity service provider); otherwise, the logon is unchanged.
To enable Security Services for the rich client, set the TC_SSO_SERVICE and TC_SSO_LOGIN_URL
environment variables. For administrative purposes, the administrator can choose not to set the
TC_SSO_LOGIN_URL environment variable.
In the rich client and ITK, the ability to set or change a password in the Teamcenter database is disabled
when the TC_SSO_SERVICE environment variable is set. The Change Password command remains
available from the Actions menu. In the Organization application, the password text box and blank
password check box are disabled.
The following table lists the logon scenarios for users logging on to the Teamcenter rich client before
logging on to any other Teamcenter product.
Environment variables set Logon scenario

No Security Services environment Security Services is not enabled. User authentication is performed
variables are set. by Teamcenter:
• The rich client displays its standard logon dialog box; users
enter the user IDs and passwords defined in Teamcenter.

© 2021 Siemens
8. Configuring external management of passwords

• To access other Teamcenter products, the rich client user must
log on again.
TC_SSO_SERVICE is set in the Security Services is enabled for the rich client and server. User
tc_profilevars properties file. authentication is performed by external identity service provider:
TC_SSO_LOGIN_URL is set in the
client_specific.properties file (two- • Security Services displays a browser logon page and starts a
tier installation). For a four-tier Security Services user session. Users enter user IDs defined in
installation, it is in the the Teamcenter database, but passwords are defined in the
site_specific.properties file. external identity service provider.
If applet-free mode is configured, the sign-on process is
performed without a Web browser and session applet. This
mode requires HTTP 401-based authentication.
If zero sign-on is configured using Kerberos authentication, no
Teamcenter logon challenges appear. Zero sign-on in applet
free mode requires HTTP 401-negotiate authentication.
For information about configuring Kerberos authentication, see
Security Services Configuration.
For information about the results of different logon
configurations, see Teamcenter Basics.
• The logon uses default values for Teamcenter group and

database. Users can change the group default using the User
Settings dialog box; the default database can be changed
using the HTTP_SERVER_n.URI property in the rich client
site_specific.properties file.
• Users can access other Teamcenter products that implement

Security Services without logging on again during a Security
Services user session.
TC_SSO_SERVICE is set in the Security Services is enabled for the rich client server only. User
tc_profilevars properties file. authentication is performed by the external identity service
provider:
• Security Services does not start a user Security Services

session; the rich client displays its standard logon dialog box,
but users enter passwords defined in the external identity
service provider.
• To access other Teamcenter products, user must log on again.

A Security Services session is essential for logging on to other
products using authentication by the external identity service
provider.
This configuration is for the following special uses:

© 2021 Siemens
Configuring load balancer timeouts

• Administrators can start multiple sessions as different user IDs
to act on behalf of several users.
• Users can log on using a group or database other than the

default values.
When one external identity provider serves multiple Teamcenter sites, and each site authorizes a
different set of users, the administrator must set the TC_SSO_APP_ID environment variable to identify
the site. This site ID must match a site ID registered with the Security Services service. This environment
variable is optional; when used, it must be set in both the tc_profilevars file for the server and the
site_specific.properties file for the rich client.
When Security Services is installed and enabled, the rich client user logon defaults to the Teamcenter
database, behaving as if users had entered user IDs and passwords in its standard logon dialog box but
left the database blank. The default database is the database defined by the HTTP_SERVER_n.URI
property (for four-tier rich client configurations) in the client_specific.properties file. This property is
set using Teamcenter Environment Manager: the HTTP-based protocol enables SOAP-based HTTP
communication and is implemented for a four-tier configuration. To specify a different default database
for Security Services logons, you must manually modify the appropriate property in the rich client
site_specific.properties file.
Configuring load balancer timeouts

If you use a third-party load balancer, ensure its timeout setting values are equal to or greater than the
timeout settings for Teamcenter as entered in the Web Application Manager Session Timeout box. This
indicates how many minutes of inactivity are permitted before the web server terminates the session on
the web server. From the Modify Web Application dialog box, click Modify Web Application
Information. The Web Application Manager displays the Modify Web Application Information dialog
box for the Session Timeout box.
The Teamcenter web tier and Teamcenter Security Services Login Service maintain client session
information. When deployed behind a load balancer, it is important that all requests from a given client
are routed to the same back-end web tier or Login Service instance. Ensure that you set the load
balancer's session timeout interval to a value equal to or greater than the Teamcenter session timeout
values. Also, load balancers typically have a stickiness or affinity setting, and this must be set as well in
the load balancer configuration for these Teamcenter web applications. Otherwise, the load balancer
timeout eclipses the Teamcenter timeout and can lead to apparently random and unexpected behavior
as the load balancer switches between active web application instances.

© 2021 Siemens
8. Configuring external management of passwords

© 2021 Siemens
9. Configuring Teamcenter mail and
instant messaging
Configuring Teamcenter mail
Administrators can configure Teamcenter mail to:
• Specify the mail gateway server, port, and character set used to send mail.
• Allow e-mail addresses to exceed 32 characters in length.
• Notify users of important schedule dates, milestones, and task completion.
• Enable and disable the capability to send operating system e-mail from within Teamcenter.
• Specify the interval at which Teamcenter checks for new mail.
• Work with external e-mail for subscription notices.
Change email server authentication settings
Email server authentication settings are initially configured using Teamcenter Environment Manager
manager.
1. Run Teamcenter Environment Manager from your Teamcenter home directory.
2. Select Configuration Manager and choose to perform maintenance on your existing Teamcenter
Foundation configuration.
3. On the Foundation Settings panel, choose the Email server settings tab and specify a new
password and change related security settings.
Configure external e-mail for subscription and workflow notification
To use external (operating system) e-mail for subscription and workflow notification, you must:
• Set mail gateway preferences:
• TC_subscription=ON to enable display and use of the Tools→Subscribe menu command.
• Mail_server_name=a_valid_SMTP_mail_server
• Mail_OSMail_activated=true to enable operating system email from Teamcenter.

© 2021 Siemens
9. Configuring Teamcenter mail and instant messaging
To view notification e-mail sending records, set TC_audit_manager=ON,

TC_audit_manager_version=3, and SCM_notification_history=true.
• For the person objects associated to users to be notified, ensure the E_Mail address fields are set
correctly in the Organization application.
• Start the subscriptionmgrd subscription monitor process daemon.
Configuring Teamcenter to use email servers requiring

authentication
You can use TEM to configure Teamcenter to access an email server that requires authentication.
The following preferences get set based on the values supplied in TEM, and can be updated if your email
server requirements change.
Mail_server_authentication_activated
Set to true to connect to a server requiring authentication.
Mail_server_authentication_id
The e-mail ID or the user ID to use for e-mail authentication.
Mail_server_authentication_passwd_location
The full path and file name of the encrypted password to use for e-mail authentication.
Mail_server_connection_security
The type of secure connection to establish when connecting to the mail server.
None (The default value.) No security connection protocol is used when connecting with
the mail server.
SSL/TLS Establish an SSL/TLS connection when connecting to the mail server.
STARTTLS Establish an initial insecure connection and later convert to a TLS connection with
the mail server.
Mail_server_ssl_protocol
The protocol and version to use when connecting with the mail server.
TLSv1 (The default value.) Transport Layer Security version 1.

TLSv1_1 Transport Layer Security version 1.1.
TLSv1_2 Transport Layer Security version 1.2.
SSLv2 Secure Sockets Layer version 2.
SSLv23 Secure Sockets Layer version 2.3.

© 2021 Siemens
Configuring instant messaging
SSLv3 Secure Sockets Layer version 3.
Configuring instant messaging

Note:
Teamcenter rich client instant messaging with Microsoft Office Communicator should continue to
work. However, Siemens Digital Industries Software no longer has an environment in which to
validate the instant messaging functionality.
Teamcenter users can view the current status of the owning and last modified users, and, from within a
Teamcenter application, can initiate communication using Microsoft Office Communicator.
This capability:
• Is supported only on Windows systems with Microsoft Office Communicator.
• Lets you access all available Microsoft Office Communicator features.
• Is available in Teamcenter and is enabled and controlled by preference settings.
• The OCS_use_presence_display preference specifies whether the functionality is integrated with

Teamcenter.
• The OCS_use_email_property preference specifies whether to use the e-mail ID from the e-mail ID
field of the user Person object.
• The OCS_company_email_domain preference value specifies a domain name if the

OCS_use_email_property preference value is false.
• For the rich client, integration is implemented in:
• My Teamcenter Summary view
• My Teamcenter Viewer view
• Workflow perform-signoffs panes
• Systems Engineering
• Structure Manager
• Schedule Manager

© 2021 Siemens
9. Configuring Teamcenter mail and instant messaging
Note:
Microsoft Office Communicator must be installed and running on your computer to use the
Teamcenter integration with Microsoft Office Communicator.
• If you try to use this feature when Microsoft Office Communicator is not installed and running
on your computer, Teamcenter displays the symbol color corresponding to the Microsoft Office
Communicator Presence Unknown status.
• If you try to use the Teamcenter integration with Microsoft Office Communicator to contact a
user for whom the system cannot find an e-mail ID, the system displays a message listing
possible reasons for the inability to continue the communication.

© 2021 Siemens
10. Configuring Teamcenter email polling
What is Teamcenter email polling?
Teamcenter email polling is functionality that checks an email account for unread messages that match
criteria specified in a polling rule. For messages that meet the polling criteria, Teamcenter performs a
specified type of response.
You can use email polling to bring email content from third parties into Teamcenter. You can also extend
email polling to perform additional actions on email messages and attachments.
Actions performed during an email polling cycle include the following:
1. The business user defines an email polling rule and then starts or schedules email polling.
2. Teamcenter logs in to the user's e-mail account and checks the Inbox folder for unread messages.
3. Teamcenter tests unread messages for matches to criteria (subject and token files) specified in the
business user's rules.
4. If an unread message matches the specified criteria, then Teamcenter performs actions according
to the response type specified in the rule. The default response type performs the following
actions:
• Downloads the message body and attachments to a specified folder on the Teamcenter server.
• Moves the message to a specified archive folder in the mail system.
• Starts a review workflow of the downloaded message in Teamcenter.
An administrator or developer can create a subtype of the basic email-polling business object and
define additional actions for a response. For example, attachments could be scanned for viruses.
5. From the review workflow task, the business user reviews the message and attachment files and
chooses whether to approve or reject the message and attachments.
Teamcenter does this with the file

For this decision (default action)
Approve No further action.
Reject Purges the downloaded file.
Email polling can be started or scheduled either of these ways:

© 2021 Siemens
• By the business user from within the rich client, if standard Teamcenter dispatcher services have been
configured. Multiple rules can be scheduled to run.
• By an administrator at the command line or in a chron job using the email_polling utility.
Configure email polling types

System administrators or customizers configure email polling types and can customize the actions
performed by a type. The types are referenced by email polling rules.
Prerequisites
• Teamcenter is installed and configured to work correctly.
• BMIDE is installed and is working property.
• The system administrator or customizer performing the configuration:
• has sufficient privileges (dba) to create and install templates or make changes to the Teamcenter
database.
• has write access to all Teamcenter installation folders.
• If scheduled polling using Teamcenter Dispatcher is to be used, when installing or updating

Dispatcher, in the Select Translators panel, Email Polling→Email Polling is selected.
Configuration steps
1. In BMIDE, for the e-mail polling type that you want to configure:
a. Create or open a template project.
b. In the classic LOV list Fnd0EmailResponseTypes, create a list value to identify the polling
type that you want to define.
Only the value parameter of the list value is used for polling; its description and condition
parameters are not used.
c. If in your application you want to persist more data than just e-mail body text and
attachments, or to impart additional behavior, then create a subtype of the object
Fnd0EmailResponseRecord.
Add your custom actions to your new object subtype.
d. Save and deploy the template.
2. In the rich client:

© 2021 Siemens
Create an email polling rule
a. Log on using an account with dba privileges.
b. Choose Edit→Options.
c. Find the preference Email_polling_download_dir, and set the preference value to the
desired location for downloaded attachments in the server's file system. This location is used
by all email polling types.
The specified location must exist in the server's file system; the polling functionality does not
create the folder.
d. For each value that you added to the classic LOV list Fnd0EmailResponseTypes, do the
following:
A. Create a new preference named <LOV value>_Response_Record_Object.
B. Set the preference value to Fnd0EmailResponseRecord or, if you created a subtype of

the object Fnd0EmailResponseRecord and you want to associate the LOV value with
that object subtype, set the preference value to the name of the object subtype.
Create an email polling rule

Business users create email polling rules to configure checks for incoming email messages and
attachments, and to specify the polling type to apply to qualified messages. Multiple rules can use the
same polling type.
1. In My Teamcenter, choose File→New→Other→Email Polling Rule.

© 2021 Siemens
2. In the Email Polling Rule dialog box, enter the following information.
Field Description
Description A brief description of the email polling rule and its usage.
Name A name for the email polling rule.
Polling Archive The destination user email folder for archived email messages. The folder
folder must exist. The polling functionality does not create the folder.
Polling Inbox The email user folder containing the messages to test.
folder

© 2021 Siemens
Configure user email account settings
Field Description
Polling Subject The words at the beginning of the email message subject that qualify it for
action by the rule.
Polling Token The names of files provided to responders for required attachment to
File Names response emails.
Required attachments may include digitally signed request-identification-
documents or pre-encrypted binary files. Token files are a means of
enhancing security.
Leave blank if token files are not used.
Response Type The type of email response to which this rule applies. This is a value
contained in the application template classic LOV (list of values)
Fnd0EmailResponseTypes as configured by the system administrator/
customizer.
Rule ID The ID for the newly created rule.

The ID is used to identify the rule when starting email polling.
3. Click Finish.
Configure user email account settings

To enable Teamcenter polling functionality to communicate with an email server, user email account
information must be specified before starting or scheduling email polling.
1. In My Teamcenter, choose Tools→Email Polling→Configure Email Polling.

© 2021 Siemens
2. In the Configure Email Polling dialog box, enter the following information:
Field Description
Address of the email The address of the email server for your email account.
server being polled
Example:
mycasa001.net.acme.com
Polling user email ID Your email account address.
Example:
john.smith@acme.com
Polling user password The password for your email account.
Server port number The email server port number for messages sent to your account
(incoming).
Example:
993
SMTP port number The email server port number for uploading messages that you
want to send from your account (outgoing).
Example:
465
SMTP server address The host name of the SMTP (Simple Mail Transfer Protocol) server
for outgoing mail.
Example:
smtp.acme.com
Polling protocol for the The protocol for connecting with the email server, either POP3 or
server IMAP.
3. Click OK.

© 2021 Siemens
Configure Dispatcher for email polling
Configure Dispatcher for email polling

Note:
Dispatcher settings for email polling may have been set by Teamcenter Environment Manager
(TEM). In that case, confirm the following configuration.
1. To activate the EmailPollingService service, set the isactive attribute to true in the DISP_ROOT
\Module\conf\translator.xml file.
<EmailPollingService provider="SIEMENS" service="emailpolling" isactive="true">
Note:
DISP_ROOT is the dispatcher root directory provided in Teamcenter Environment Manager
(TEM).
2. In the DISP_ROOT\Module\Translators\emailpolling\emailpolling.bat file, set the following

variables to your installation locations:
• TC_ROOT
• TC_DATA
• JRE_HOME
3. In the TC_DATA\EmailPolling.conf file, remove the comments before these settings:
• EmailPolling_JAVA_XMS=16m
• EmailPolling_JAVA_XMX=128m
4. Run the genregxml.bat utility.
• Open a Teamcenter command prompt and type the following command:
TC_ROOT\portal\registry\genregxml.bat
5. For each Teamcenter user who performs email polling actions, set the E-Mail Address property.
a. Using an account with dba privileges, log on to the rich client and open the Organization
application.
b. Expand the Persons node and select the person who performs email polling actions.
c. Set the E-Mail Address property.

© 2021 Siemens
Start or schedule email polling

Prerequisites
• User email account information is configured
• Dispatcher is configured for email polling
Procedure
1. In My Teamcenter, choose Tools>Email Polling>Start Email Polling.
2. In the Start Email Polling dialog box, enter the following information:
Field Description
Start now! Select one of these choices.

Schedule
• Start now! runs a single on-demand poll.
• Schedule enables scheduling periodic polling.
Start Time The date and time to start scheduled polling.
End Time The date and time to end scheduled polling.
Interval The interval of time to repeat the poll.
Rules ID The ID of the email polling rule to use.
3. Click OK.

© 2021 Siemens
Teamcenter email polling preferences
You can administer scheduled polling requests using the Dispatcher request administration console.
Teamcenter email polling preferences

For basic email polling functionality, you do not need to change default values for the following
preferences.
EMLPOLLING_default_polling_config_id
Defines the identifier for email polling configuration to be used in the email polling operation.
Default value: def_polling_config_id
Fnd0EMLPollingRevFrm.JAVARENDERING
Defines the Java class to render the property panel of a form with type Review Email Polling
Revision Form.
Default value:
com.teamcenter.rac.emailpolling.commands.rendering.EmailPollingRevisionForm
Fnd0_review_email_attachments_workflow
Defines the create workflow for email polling functionality.
Default value: Review Mail Attachments

© 2021 Siemens

© 2021 Siemens
11. Configuring Teamcenter notes and
parametric requirements
Configuring standard notes and custom notes
Standard note or parametric requirement objects are used to provide information about parts and
documents that is based on the established practices of a design program. The following aspects of
standard note and parametric requirement behavior can be configured by a Teamcenter administrator:
• Creation privileges
Users must fill a role specified in the Ads0CreateStandardNoteAuthority list of values to be able to
create a standard note or parametric requirement.
• Delimiter between parameters in note text
• Ability to attach multiple revisions of a standard note or parametric requirement to an item or item
revision
Configure standard note creation authority

By default, standard notes and parametric requirements can be created by any user. You can specify the
roles that are allowed to create notes and requirements and then specify access privileges based on
these roles.
To specify the roles that are allowed to create standard notes and parametric requirements, add the roles
to the Ads0CreateStandardNoteAuthority list of values. You can then grant access privileges based on
those roles.
Set the delimiter that separates parameters in standard note text

A standard note or parametric requirement contains:
• Text
• A parameter and applicable values, using the following syntax:
text [parameter name: parametric value1 delimiter parametric value2 delimiter .....
parametric value n]
The default delimiter separating the parameters in the note is a comma (,). To change the delimiter
separating the parameters in the note, set the Fnd0ParamReqDelimiter global constant.

© 2021 Siemens
11. Configuring Teamcenter notes and parametric requirements
Enable attachment of multiple revisions of a parametric

requirement
Standard notes and parametric requirements can be attached to an item or item revision. By default,
only one revision of a standard note or parametric can be attached to an item or item revision. You
cannot attach multiple revisions of the same note or requirement to a single item or item revision.
However, you can enable multiple revisions of the same standard note or parametric requirement to be
attached to an item or item revision by setting the AllowMultipleRevisionsofStdNotes global constant.
Configure the behavior of custom notes

Custom notes provide unique information about an individual part or document, and they can be
attached to an item or item revision. The following behavior can be configured for custom notes:
• By default, a custom note item can be attached to a single item or multiple revisions of the same item.
A custom note item cannot be attached to multiple items or to revisions of multiple items.
To enable a custom note item to be attached to multiple items or revisions of multiple items, set the
Fnd0AttachCustomNoteToMultiItems business constant to true.
• By default, multiple revisions of a custom note cannot be attached to an item or item revision.
To enable multiple revisions of a custom note to be attached to an item or item revision, set the
Fnd0AllowMultipleRevofCustomNote global constant to true.

© 2021 Siemens
12. Teamcenter licenses
Licensing overview: seats, features, and bundles
Managing how users access your company data is an important factor in information security. Users
may be employees within your company, or they may be outside suppliers or contractors. Users gain
authorized access to Teamcenter functionality through named user licensing.
With named user licensing, each user has appropriate access to the system from any Teamcenter client,
and purchase of licenses and keys can be minimized.
When Teamcenter is installed, a Default Local License Server (DLLS) is defined. This DLLS is used as the
default license server for the site, which in turn becomes the default license server for a user. If multiple
license servers exist, an administrator can assign a different license server.
When a user logs on through any Teamcenter interface, such as rich client and Active Workspace, NX
and Solid Edge integrations, SOAs, and mobile applications, Teamcenter requests checkout of a seat
license from the license server assigned to the user. As the user performs actions beyond foundation
functionality, such as actions that are part of Change Manager and Requirements Manager features,
Teamcenter requests checkout of corresponding feature keys from the license server.
A named user on a site can be assigned only one license server at a time. A license server can serve
licenses to more than one site.
Seat level
A seat license enables access to the system and foundation (base) Teamcenter functionality. By default,
users are assigned an Author license seat level. An administrator can assign the user a different seat
level, such as Consumer. Typically, license files include three license seat level options plus an internal
seat type for administration:
Seat level Primary focus

Author Create and edit data.
Consumer Query, view, print, and use basic viewer capabilities.
Create/Edit item Yes No

Create/Edit BOM Yes No
Create/Edit change Yes No 1
1 Consumer can create a Problem Report (PR) or Issue Report.

© 2021 Siemens
Seat level Primary focus
Create/Edit dataset Yes Yes

Create/Edit folder Yes Yes
Initiate workflow Yes No 2
Review/Approve workflow Yes Yes 3
Occasional Create and edit data as at the Author level, but only for a limited time per month. This
author level is intended to support two use cases:
• Access is required several days per month, but for short periods.
• Access is infrequently required, with long periods.
Limited time is defined as the combination of the following:
• Maximum of twenty hours per month.
• Maximum of five unique calendar days when logged on for over an hour each day.
Teamcenter counts a minimum of 1 hour use per logon, and a maximum of 7.5 hours
per day.
Admin A special system administration level assigned to the infodba and dcproxy user
definitions provided for every site. The infodba and dcproxy users cannot be switched to
another seat level, nor can other users be assigned the Admin seat license level.
The infodba user should only be used for installation and upgrade, and dcproxy should
be used only for the Dispatcher. The infodba and dcproxy users should not be used to
perform any actions as regular Teamcenter users.
Day-to-day administration activities (including scheduled cron jobs such as running the
data_sync utility) should be performed by a named user who is a member of an
administrator group. Members of an administrator group may have similar privileges and
authorizations as infodba, but have greater accountability because their activities are
logged with their identity.
Feature keys
Feature keys are licenses for optional Teamcenter modules, and are required to use certain Teamcenter
solutions, such as Change Manager and Requirements Manager. Checkout of a key gives a user access
to the module from all interfaces to Teamcenter.
2 Consumer can initiate a workflow on PRs and Issues.

3 Consumer cannot approve a workflow if approval would make updates to an object other than PR, ECR, or ECN.

© 2021 Siemens
How license use is calculated
License bundles
Companies can purchase license bundles as well as licenses for individual seats and features.
Teamcenter license bundles typically include seat-level licenses for base (foundation) Teamcenter
functionality and keys for a group of features. Bundles are created such that upon logon a user
consumes a seat license and the entire group of features in the bundle, and users not assigned the
bundle cannot independently leverage the features in the bundle. If the license server assigned to the
user includes a license bundle in the license file, an administrator can assign the user a license bundle.
Support for license bundles includes:
• Assigning license bundles to users using the rich client.
• Assigning license bundles to users using the make_user utility.
• Enforcing a user's seat license level based on the base seat license available in the assigned bundle.
• Ensuring that only as many active users are assigned a bundle as there are licenses for that bundle.
• Allowing check out of feature keys that are not part of the assigned bundle, but are available
separately in the license file.
• Recording use of feature keys and license bundle in the FlexLM license logs.
How license use is calculated

When a user logs on, Teamcenter requests checkout of a seat license from the assigned license server.
As the user performs actions beyond foundation functionality, such as actions that are part of Change
Manager and Requirements Manager features, Teamcenter requests checkout of corresponding
feature keys from the license server.
Tip:
The Siemens Digital Industries Software Common Licensing Server is described in the
SPLMLicensing_user_guide.pdf (Siemens PLM Licensing User Guide), available for download
from Support Center.
With this system, each user has appropriate access to the system from any Teamcenter client, and
purchase of licenses and keys can be minimized.

© 2021 Siemens
The license-used count for each seat license level comprises the sum of the following:
• All users defined as active at the level.
• Plus those users who logged on during the current calendar month with that level, but are now either
set to inactive or are assigned a different seat level.
An inactive user who never logs on during a calendar month is not added to the used count.

© 2021 Siemens
Federated license servers
Example:
A customer purchases 10 Author and 100 Consumer licenses. The customer adds 10 active Author
users and 100 active Consumer users to Teamcenter. When a user logs on to Teamcenter, the
system checks out that license from the license server. If all of the active Teamcenter users log on,
then the customer has exactly the correct amount of licenses and all users have access.
When on January 1 user X, an Author level user, logs on, one Teamcenter Author license is
checked out to user X for the remainder of the calendar month. On January 5, the administrator
sets one of the 100 active Consumer users who has never logged on to inactive, and then changes
user X to a Consumer level license. On January 10, user X logs on, and one Consumer license is
checked out to user X for the remainder of the calendar month.
In this case, user X consumes both an Author license and a Consumer license until February 1.
Because all 10 Author licenses and all 100 Consumer licenses are assigned to active users or
checked out, the administrator cannot add another active Author user until February 1.
Example:
Chris, an Occasional author, logs on for 45 minutes a day each of seven days early in a month.
7 logons x 1 hour minimum = 7 hours
On two days later in the month, Chris logs on multiple times throughout the entire day,
accumulating the daily maximum for each day.
2 days x 7.5 hours = 15 hours
At this point, Chris has accumulated 22 hours use, more than the maximum 20 hours, but still less
than the maximum of five unique calendar days at over an hour per day. Chris can continue to log
on until both the maximum hours and maximum days are reached.
If a user who is assigned to the Occasional author seat level regularly exceeds the time limit, then the
user should be reassigned to the Author license seat level.
Federated license servers

A single Teamcenter site can potentially be accessed by multiple users from inside and outside a
company. Conversely, a user may need to access multiple sites. Rather than requiring that a user with
the same exact name and user ID consume site-specific seat and feature licenses when logging in to
different sites, or that all users of a site draw from the same license server, multiple license servers with
varying license files can be defined for a site. This capability is referred to as federated license servers.
Administrators can define license servers for a site and assign them to users using either the site_util
utility or the Organization perspective in the rich client.
The following scenarios are some examples in which multiple license servers are used to appropriately
provide access.

© 2021 Siemens
Different business units want control over their own licenses

Having separate license files and servers can provide business units better control over licenses, and
can help avoid cross charging within a company.
Multisite environment
A user may generally work in SiteA, but might need to approve a Global workflow in SiteB. The user
can be added to SiteB and point to the original license server to get authorized access.
Test, Development, and Production environments
Similarly to multisite environments, a user can be added to multiple environments and point to and
use the single license from the original license server.
Adding new licenses
Say that company ABC has seat and feature licenses for a current set of users. The company wants
to add seats and different feature licenses for process planning purposes to a new set of 50 users. In
this case, the company can add the new 50 users and assign a new license server that has the
required features without having to combine all the licenses into one file.
Global and regional licenses

License files can be purchased and generated for either global or regional use. Typically, an uplift charge
is incurred for a global license.
Global licensing can facilitate Teamcenter administration and access for users who travel outside the
region where the license server exists.
Purchasing both types of license files can make sense when a company has a sizable group of users who
do not travel outside a region as well as users who do travel outside a region.
General principles of global vs. regional licenses
• A soldto ID cannot have both global and regional licenses. If both license types are required, then they
must have separate soldto IDs.
• A license server can serve only one type of licenses, either global licenses or regional licenses.
• A global license can provide access to users physically located outside the region of the global license
server as well as users located within the region of the license server.
• A Teamcenter user may only point to 1 license server. All Teamcenter licenses and add-on modules
the user needs must exist on that 1 license server.

© 2021 Siemens
Example:
A user who requires the use of an Author seat, and Change and Classification features, must
point to a license server that contains all three licenses.
• If regional license users travel outside their home license server region, then they cannot access their
home region license. They must use a global license or a regional license served by a license server in
the region where they are physically located.
Global vs. regional licenses Q & A
When licensing Teamcenter, does the location of the Database Server matter?
No, only the location of the license server and the physical location of the users.
When licensing Teamcenter, does the location of the Application (Enterprise) Server matter?
No, only the location of the license server and the physical location of the users.
In a cloud deployment, does every license need to be global?
No.
Can a company have both a regional and a global license server if they only have one Teamcenter
database server and Application server?
Yes, as long as they are separate servers.
Can a company run a Multi-Site deployment in 2 regions with 2 regional licenses?
Yes.
If a small company located in 1 region was to deploy to the cloud, where would their license
server need to be? Could they use regional licenses or do they require global?
Their license server could be either on-premise or in the cloud. They could use a regional license
since they have no users outside of the 1 region.
Example Scenario 1 - Single region Teamcenter deployment
Enterprise server, Database server and License server(s) exist in the same region as the User. Multiple
organizations (such as Manufacturing and Engineering) in a company can have separate license servers/
soldtos.
A single regional license is all that is required as long as the users remain in the region.

© 2021 Siemens
Example Scenario 2 - 2 region Teamcenter deployment
Teamcenter Application Server and Database server are in the US with clients in both US and Asia.
Three licensing options are possible:
• 1 global license – All licenses require the global uplift
• 2 regional licenses (1 in the US and 1 in Asia) – No global uplift
• 1 regional license server to serve the US and 1 global license server to serve outside of the US –
Global uplift paid on licenses on the global license only.

© 2021 Siemens
Example Scenario 3 - 3 Region Deployment
3 region Teamcenter deployment using Multi-Site in 2 regions – Teamcenter application servers in the
US and Europe. Database in the US shared with Europe via Multi-Site. All users accessing the US Site are
in the US. Europe site used by clients in Europe and Asia.
Three licensing options are possible:
• 1 global license – All licenses require the global uplift
• 3 regional license servers (1 in each of the US, Europe, and Asia) – No global uplift
• Combination of 1 or 2 regional license servers to serve the local region(s) and 1 global license server
to serve outside of the region(s) – global uplift paid on licenses on the global license only.
Example Scenario 4 - Cloud deployment
Teamcenter deployed to the Cloud – Teamcenter Enterprise Server and Database server are in the Cloud
with clients in US, Europe and Asia
Licensing options Q & A
Does it matter in what country the cloud service provider is located?

No.
Can a Cloud Deployment use global and/or regional licenses?
Can use either or a combination of the two.
Can each site have its own regional license server serving regional licenses?
Yes.
In a hybrid Multi-Site environment, on-premise in 1 region and in the cloud in another region, how
would the environment be licensed?
Can be a combination of regional and global as needed.

© 2021 Siemens
Teamcenter licensing preferences

To configure Teamcenter license management, you can set the following preferences.
To do this Set this preference
Adjust the threshold at which a warning message appears license_warning_level

if, when you create or modify a user, the number of
The default preference value is 5.
available base Teamcenter licenses equals or falls below
the threshold.
Specify identifiers of administrative users who receive LicenseUsage_admin_notifier_list

Teamcenter notifications when an occasional author
exceeds the allotted usage and/or grace period limits
specified for the occasional author license level.
Specify remaining duration (in days) of allotted usage LicenseUsage_days_warning_level

when occasional logged-on users start receiving
notification of approaching their allotted usage days.
Specify remaining duration (in hours) of allotted usage LicenseUsage_hours_warning_level

when occasional logged-on users start receiving
notification of approaching their allotted usage hours.
Specify logins remaining in the month when LicenseUsage_module_usage_warn

administrators start receiving warning messages that ing_level
feature key usage is approaching the allowed limit.
Control inclusion of the actual user ID in generated license LicenseUsage_show_userId_in_rep

usage reports. ort

© 2021 Siemens
Configure failover license servers
To do this Set this preference
Specify the email ID of the Siemens Digital Industries Siemens_PL_email_id

Software licensing account team that receives
notifications when any module usage limit exceeds its
allowed usage.
Allow use of any account with DBA role to cause the License_allow_dba_to_change
SPLM_LICENSE_SERVER environment variable/Default
Local License Server (DLLS) comparison and update to
occur.
Configure failover license servers

To define a reference to a trio of license servers that are set up in Redundant Server Configuration, use
the following procedure in the Teamcenter rich client Organization perspective.
1. Define references to the failover license servers (the second and third servers listed in the
Redundant Server Configuration enabled license file).
Each reference consists of Host, Port, and Protocol information.
2. Define a reference to the primary license server (the first server listed in the license file).
In addition to the Host, Port, and Protocol information, add the references for the failover license
servers to the Failover License Server(s) list.
3. When the Redundant Server Configuration is intended to be the default license server for the site,
the best practice is to do the following:
• In the License Servers category, set the Default Local License Server definition to the first
server listed in the license file.
• In the Site object definition, set the license server to the Default Local License Server
reference.
Managing Teamcenter licenses
Create a license server reference
A license server is a process dedicated to serving software licenses and tracking license usage. Multiple
license servers can be used to serve licenses. A reference to a license server is needed when specifying a
default license server for a site, configuring failover license servers, or assigning a specific license server
to a user.

© 2021 Siemens
1. Log on to the rich client as an administrator and open the Organization perspective.
2. Select License Servers, enter the required information, and click Create.
The Failover License Servers list is needed only when defining the primary license server for a
Redundant Server Configuration (federated servers). For details, see Configure failover license
servers.
Change the Teamcenter default license server
The Default Local License Server (DLLS) is a special license server reference that is created during
installation of Teamcenter. It is used as the default for the site, and thereby the default for all users. An
administrator can change the value of the DLLS in either of two ways:
• In the rich client Organization perspective, select Default Local License Server and change the DLLS
value. This approach is the most direct and obviously intentional.
• On the Teamcenter corporate server (enterprise server), do the following steps. This approach may be
more convenient when multiple enterprise servers are deployed, or when changed or corrupted
license server values do not allow logging in to the rich client.
1. Set the SPLM_LICENSE_SERVER environment variable so that the first port and server name
value in the file is the desired value for the DLLS.

© 2021 Siemens
Set a default license server for a site
Note:
In the case that the SPLM_LICENSE_SERVER environment variable lists multiple license
servers (where each server is separated by a semicolon), Teamcenter only reads the first
license server value.
2. Log on as a user with Teamcenter administration privileges.
When an administrator logs on, Teamcenter compares the value of the value of the
SPLM_LICENSE_SERVER environment variable to the value of the DLLS. If the two values differ,
then Teamcenter updates the DLLS with the value of the SPLM_LICENSE_SERVER.
Note:
If the License_allow_dba_to_change preference is set to True, then logging on using any
account with DBA role causes the SPLM_LICENSE_SERVER environment variable/DLLS
comparison and update to occur.
Set a default license server for a site
During Teamcenter installation, a Default Local License Server (DLLS) is defined. That DLLS is the default
license server for users logging on to the site. An administrator can specify a different license server as
the default for the site either indirectly or directly:
• indirectly by changing the Teamcenter default license server, which affects all sites in the
Teamcenter environment that point to the DLLS.
• directly for a single site by ensuring that a license server reference for the intended license server
exists in the site.
You can use either of two methods to assign a license server reference to the site:
• Use the site_util utility with the -license_server argument.
• Use the Organization application.
1. As an administrator, log on to the rich client and open the Organization application.
2. Select the site and in the License Server box, assign a license server to a site.

© 2021 Siemens
Assign Teamcenter licenses to users
A Teamcenter administrator can assign a Teamcenter seat license, license server, and license bundle to
users using either the rich client or a command line utility.
For this approach Do this
Teamcenter rich client 1. Log on to the rich client as an administrator and open the
Organization perspective.
2. Open the Users pane.
3. The default license level is Author. To assign a different seat

license level, do one of the following:
• Select a Licensing Level.
• (For license bundles that include a seat license) From the

License Bundle list, select a license bundle.
Note:
When you create or modify a user, Teamcenter compares
the number of purchased licenses with the license-used
count. If all licenses at the requested seat level are

© 2021 Siemens
Assign Teamcenter licenses to users
currently used, then you cannot create or modify a user at

that seat licensing level.
4. (As needed) To override the site's default license server

assignment for this user, select a value from the License Server
list.
Each user can be assigned to only one license server. If multiple
license server references have been defined in Teamcenter,
then administrators can assign a user to a specific license
server. Assignment to a single license server does not preclude
assignment to the first server in a Redundant Server
Configuration, which allows for failover in case a license server
fails.
Note:
This single-server license attachment differs from versions
prior to Teamcenter 11.2, where a user could query
multiple license servers with distinct license files (Multiple
Server Configuration).
Overriding the site default license server assignment might be

necessary when, for example, both regional and global license
servers exist, when different groups use different licenses
(federated servers), or when load balancing among license
servers is necessary.
5. (As needed) To assign a license bundle, select a value from the

License Bundle list.
make_user utility Use the make_user utility with the -licenselevel, -licenseserver, or -
licensebundle arguments to set the respective values for a user.

© 2021 Siemens
To update more than one user's licensing information, use the

utility's batch mode processing capability.
Releasing checked out licenses
When attempting to release checked-out licenses, consider the following use cases:
• Use case 1:
Acme Corporation has X number of licenses. It purchases an additional number (Y) of licenses, which
requires a new license file.
1. Shut down the license server, let the license server read the new license file, and restart the
license server with the new license file.
2. Stop the pool manager.

By doing this, the cache carrying the licensing information gets reset.
3. Restart the pool manager, which allows Teamcenter to access the newly purchased licenses.
Note:
The licenses-used count within Teamcenter is not cleared. However, the additional newly
purchased licenses are immediately available for use.
• Use case 2:
Acme Corporation has X number of licenses and all licenses have already been checked out this
month.
Acme Corporation wants a different set of users to consume the same licenses and wants to release
the checked-out licenses.
This cannot happen because Teamcenter counts the licenses as used until the end of the calendar
month. The licenses used count resides in the database and cannot be reset. The stability of the
licenses used count is critical for auditing purposes and for tracking license usage.
Monitor seat license level violations
When a user logs on to Teamcenter, the seat license consumed is at one of two seat level types: author
or consumer.
The pairing of a given operation (action) performed on a given business object (type) is categorized as
either author level or consumer level.

© 2021 Siemens
License usage information logged in Teamcenter
When a user logged on with a consumer level license performs an author level operation on a given
operation/business object pair, Teamcenter counts a license violation. When the user exits the session,
the violations are recorded in a log file on the server.
The log file is saved in the consumer_violations directory within the Teamcenter log location and
named with the pattern user-id_license_violation.log.
By default, the Teamcenter log location is the value present in the TEMP environment variable. If a
TC_LOG_DIR environment variable has been set on the server, then the consumer_violations directory
is created within that location.
Use the consumer_license_violation_report utility to summarize license violation data from individual
user log files. Users assigned a consumer level license who regularly perform author level operations
should be reassigned an author level seat license.
After generating a license violation report, an administrator may choose to delete user-specific license
violation log files. However, reports generated after these files have been deleted do not contain the
historical license violation data of the users.
Example:
At the end of a two-week period, an administrator generates a summary report of license
violations, and then deletes all user-specific license violation log files. In the following two weeks,
new user-specific license violation log files are generated. At the end of the week four, the
administrator generates a new summary report. The original summary report contains the
violations for weeks one and two, and the new summary report contains only the violations for
weeks three and four.
Reporting license usage
License usage information logged in Teamcenter
The following license usage details are logged in the Teamcenter database.
• Users logged in, seats used, and features used per calendar month.
• For Occasional author level users:
• Hours of use per month.
■ Logs a minimum of 1 hour per logon. If a named user logs on for only 1 minute, usage is logged
for 1 hour
■ Logs a maximum of 7.5 hours per day. If a named user is logged on continuously, usage is
logged for only 7.5 hours.

© 2021 Siemens
• Simultaneous logons by the same user, such as when a single user is logged on to both the rich
client and the Teamcenter Client for Microsoft Office.
The system counts the usage from the first logon time for that named user until the last logoff
time. Time spent logged on to multiple clients simultaneously is counted once, not multiple times.
• Days of use per month.
• Number of logons per month.
• Any use violations.
You can Generate a license usage report of license use information logged within Teamcenter.
License bundle logging
The following are examples of license logs when license bundles are used.
• When a user with assigned bundle (Bundle2) logs in, the base license feature key is checked out:
09:59:36 (ugslmd) OUT: "Bundle2" gopinats@TcServer 09:59:36 (ugslmd) OUT:
"Bundle2_teamcenter_author" gopinats@TcServer
• When user creates a Requirement item, the requirements_user feature key is checked out:
10:42:11 (ugslmd) OUT: "Bundle2_requirements_user" gopinats@TcServer
• When user queries for a schedule object, the prog_exec_access feature key is checked out:
11:21:34 (ugslmd) OUT: "Bundle2_prog_exec_access" gopinats@TcServer
• When the user logs out, all the checked out feature keys along with the bundle are released:
11:30:34 (ugslmd) IN: "Bundle2_prog_exec_access" gopinats@TcServer
11:30:34 (ugslmd) IN: "Bundle2_requirements_user" gopinats@TcServer
11:30:34 (ugslmd) IN: "Bundle2_teamcenter_author" gopinats@TcServer
11:30:34 (ugslmd) IN: "Bundle2" gopinats@TcServer
Generate Teamcenter license reports
As an administrator, you must make sure that an appropriate number of software seat and module
(feature) licenses are available and that you comply with the terms of your license agreement. For the
purpose of examining usage, you can generate reports of license and module usage information logged
in the Teamcenter database.
Note:
Specifics of your purchased license levels, their detailed descriptions, and their quantities are
contained in your master license agreement. Your site's license file determines which license level
options appear in the rich client Organization view.

© 2021 Siemens
Report seat licenses in use on a server
1. In the rich client, open the My Teamcenter perspective and choose Tools→Reports→Report
Builder Reports.
The Report Generation Wizard appears.
2. Select one of the following reports.

License Provides a summary of each named user’s use per month of seat licenses.
Usage
Report To assist you in ensuring that seat license levels are appropriately assigned to
users in compliance with your license, Teamcenter provides the utility
consumer_license_violation_report. The utility forms a consolidated report of
users who repeatedly perform author-level operations (actions) while logged on
with a consumer-level seat.
Module Provides a summary of use per month of optional module licenses (for example,
Usage change author, requirements access, and so on).
Report
License If geography access has been configured for Teamcenter, reports the locations
Login Report from which a user logs on.
3. Click Next.
4. At the Fill in Criteria page, specify criteria for the limiting the report.
For a License Usage Report or License Login Report, you must specify at least one criterion. For
example, to get a report of all recorded usage violations, in Usage Violation type True.
Tip:
For License Usage Report criteria that require keyed entry, hover over the criterion box to
see a description of valid input parameters.
5. Click Finish.
The report is generated and displayed in comma-separated format. The output can be saved as
a .csv file and opened in a spreadsheet application such as Microsoft Excel.
Report seat licenses in use on a server
To determine how many seat-level licenses are in use on a license server, run the license_usage utility.
You can compare the resulting usage information to the purchased number of licenses to help
determine whether a license should be available for creating a new user.

© 2021 Siemens
License usage report
Example license usage report displayed in a table
The columns of a license usage report output from Teamcenter match the columns from a FlexNet
analysis log output, except that the pseudo IDs are encrypted more securely, and the feature keys used
are grouped together on one line. This grouping minimizes the database table space required, and is
appropriate because any seat or feature used is allotted to the named user for the month.
Column header Description
user id The Teamcenter user ID.
Note:
The LicenseUsage_show_userId_in_report preference
controls whether or not to output the actual user ID; the
preference default value is true. When the preference
LicenseUsage_show_userId_in_report is set to false,
generating license usage reports from the Teamcenter
database provides a secure method of hiding user identity in
the output reports.
pseudo id A unique ID generated to enable anonymous reporting of user data.

The pseudo user ID is always output.
seat level The highest seat level used in the month by the user.

© 2021 Siemens
License usage report
license bundle The license bundle from which a seat license was obtained.
license server The license server that served the license.
feature keys Feature keys that were allotted to the user.
month The month being reported.
used hours The number of hours the Teamcenter occasional author used
Teamcenter in a given month.
usage days The number of days the Teamcenter occasional author used
Teamcenter in a given month.
number of logins The number of times the Teamcenter occasional author logged on in
a given month.
usage violation Displays the value Y for Teamcenter occasional authors when there
are logon denials.
Tip:
The user can specify this value in query criteria to fetch the
data for all the violation records.
usage violation reason Lists the reason for the usage violation of the license by the
Teamcenter occasional author.
Tracked for Teamcenter occasional authors only.
max day usage Displays the value Y if the maximum hours of usage (7.5) is being
recorded in any day in that month for the user.
max value reason Lists the reasons for the Maximum Day Usage value being recorded
as Y, such as no logoff in a day.

© 2021 Siemens
not released lic count The number of times a license is not released at the end of the day in
a month. This is incremented when there is no logoff for a particular
session on the same day the user logged on.
grace days The number of grace days used by the user.

grace hours The number of grace hours used by the user.

grace logins The number of times an occasional author who exceeded license
limits (hours and unique days) was allowed to log on.
number denials The number of times an occasional author who exceeded license
limits attempted to log on but was denied access.
home site The home site of the user.
Module usage report
The module usage report provides a summary of usage per month of optional module licenses (for
example, change author, requirements access, and so on).
Module use reporting may occasionally show that the number of licenses or keys used exceeds the
number of licenses purchased. This is typical where the number of purchased licenses is intentionally
minimized. Siemens Digital Industries Software allows for a small over-use. Administrators are notified
about the over-use so that they can work with their Siemens PLM account representatives to identify the
total number of licenses and keys required and take appropriate steps to comply with the licensing
agreement.
When entering parameter values to generate a module usage report, you can:
• Enter the month as either a number or text (3-character abbreviations or alphabetic month values).
For example, to indicate March, you can enter 3, Mar, or March.
• Enter the year values.

For example, to run the module usage report for all months from January 2017 through December
2018, enter 2017 in From Year and 2018 in End Year.

© 2021 Siemens
License login (location) report
• Leave the month fields blank and just enter the year value.
For example, to run the module usage report for 2018, enter 2018 in From Year and 2018 in End
Year.
The Module Usage report saved to a .csv file and viewed in Excel resembles the following:
Example module usage report
Note:
The module Usages numbers are accurate for all reported months. However, the Purchased
numbers are not stored in the Teamcenter database; all months for Purchased licenses show the
numbers pulled from the current license file at the time the report is generated. Therefore in the
following situations the purchased numbers in the report are not historically accurate:
• License modules have been added to or deleted from the server's license file between usage
and running of the report.
• The number of module licenses in the server's license file has increased or decreased.
• A module has expired in the server's license file between usage and running of the report.
License login (location) report
When geography access has been configured for Teamcenter, you can run a license login report to
analyze the locations from which a user logs on. The report displays one line per user per login region
and includes the following columns of information:

© 2021 Siemens
user id The Teamcenter user ID.
month The month reported.
user declared geography The user-reported region or country from which the logon occurred.
ip address The IP address from which the logon occurred
login count The total number of times that the user logged on from a region or
country.
last login time The most recent time that the user logged on.
license status message Messages regarding user and site geography.
License login report saved to local file system and opened in a spreadsheet.

© 2021 Siemens
13. Configuring access to administrative
applications and utilities
Using Authorization to control access to applications and utilities
The Authorization application enables you to control access to Teamcenter administrative applications
and utilities based on users' group membership or their role in a group.
For example, you can:
• Grant all members of the DBA Lite group access to the Organization application, regardless of their
role within the group.
• Grant users who occupy the importer role in the DBA Lite group access to the PLM XML/TC XML
Export Import Administration application.
The Authorization application works in conjunction with other Teamcenter applications to control access
to product features and data, as follows:
• Access to product features is controlled using the Command Suppression application Command
Suppression application.
• Access to operations on objects, such as delete, copy, and change ownership, is controlled by
configuring rules in Access Manager.

© 2021 Siemens
13. Configuring access to administrative applications and utilities
Authorization interface
1 Quick Links Click either the Applications link or Utilities link to set
access level.
2 Organization tree Displays the groups and roles in your organization. From
the Organization tree, you can choose a group or for a
selected role.
3 Applications with Read Only For the selected group or role in group, the Applications
Access with Read Only Access list contains the administrative
utilities or applications that are shown in the interface with
read only access to the functionality.
4 Applications with Full Access For the selected group or role in group, the Applications
with Full Access list contains the administrative utilities or
applications that are shown in the interface with full access
to the functionality.
How Authorization works with group hierarchies

Groups within the organization tree can be configured into one or more hierarchies. Each group has
exactly one parent group (unless it is at the root of the hierarchy, when it has no parent group), and
each group can have one or more child groups (subgroups).
Authorization rules are inherited within the group hierarchy, as follows:
• Rules defined for a parent group are inherited by all subgroups of the parent group.

© 2021 Siemens
Default authorization rules and Authorization
• Rules defined at the subgroup level apply only to that subgroup.
Note:
In the event that two subgroups of different parentage share the same name, rules defined for
one parent group are not inherited by the same-name subgroup of the other parent group. For
example, if both the Manufacturing group and the Design group have a Validation subgroup,
authorization rules defined for the Manufacturing group apply only to the Validation subgroup
that is directly related to the Manufacturing group. Likewise, authorization rules defined for the
Design group apply only to the Validation subgroup that is directly related to the Design group.
Default authorization rules and Authorization

System-level authorization rules are those rules delivered as part of your standard Teamcenter
installation that govern access to administrative applications and utilities. By default, Teamcenter
supplies two groups for administrative purposes, the Project Administration group and the dba group.
Project Administration group members only have access to the Project application, which allows them
to create, delete, modify, and add users to or remove users from projects. dba group members are
granted access to all Teamcenter administrative applications and utilities.
Often, administrative tasks are assigned at a functional level corresponding to your business practices.
For example, responsibility for administering user data such as personal and organization information
may be assigned to one group, while a different group may be responsible for designing workflow
processes. In such cases, dba group privileges are more broad and powerful than is necessary or
desirable. Authorization enables you to create authorization rules to model access to administrative
tools to your business processes.
Where can I limit access using Authorization?

The following applications are supported for access configuration using Authorization:
Access Manager Organization
ADA License PLM XML/TC XML Export Import Administration
Audit Manager Project
Authorization Setup Wizard
Business Modeler IDE Subscription Administration
Classification Admin Workflow Designer
You can configure access to these applications by group or by role in group.

© 2021 Siemens
You can also set the TC_authorization_mode preference to specify whether to evaluate all the group
memberships of users and their role in those groups when authorizing access to an application or to
evaluate their current group logon and role in that group.
Example:
To access the Organization application, a user must have dba privileges (be a member of dba with
the role of DBA). If the user is a member of both the dba and the Engineering groups and logs on
under the Engineering group, the user may or may not have access to the Organization application
depending on how TC_authorization_mode is set:
• If set to on (evaluate all group memberships and the roles in the groups), the user has
administration privileges based on membership in the dba group, even though the user is not
currently logged on under that group. The user can access the Organization application.
• If set to off (evaluate only the current logon group and the role in that group), the user does not
have administration privileges through the Engineering group. Therefore, the user cannot
access the Organization application.
The following utilities are supported for access configuration using Authorization:
data_share dsa_util purge_invalid_subscriptions
data_sync export_recovery update_project_data
database_verify fscadmin
You can configure access to these utilities by group or by role in group.
Create Authorization rules for applications and utilities

1. Click the Applications link in the Quick Links section of the navigation pane.
2. Expand the Organization tree and click the group or role to whom you want to grant or deny
application access.
3. Select the application from the Applications with Read Only Access list to grant access to the
group or role in group. Click the right-arrow button to move the application to the Applications
with Full Access list.
Tip:
If the Applications with Read Only Access list is empty, click any group or role symbol in the
Organization tree to refresh the list.
4. Click Save.

© 2021 Siemens
Configure access to utilities by group or by role in group
Configure access to utilities by group or by role in group

1. Click the Utilities link in the Quick Links section of the navigation pane.
2. In the Authorization application pane, expand the Organization tree and click the group or role
to whom you want to grant or deny utility access.
3. Select the utility from the Applications with Read Only Access list to grant access to the group or
role in group. Click the right-arrow button to move the utility to the Applications with Full Access
list.
Tip:
If the Applications with Read Only Access list is empty, click any group or role symbol in the
Organization tree to refresh the list.
4. Click Save.
Sharing authorization rules with other Teamcenter sites
Importing and exporting Authorization rules
Authorization rules can be exported to an operating system directory as an XML file that can then be
imported at another Teamcenter site, allowing you to synchronize authorization rules between sites that
share data.
Export authorization rules
1. In the Authorization application pane, click the exportRule button.
2. In the exportRule dialog box, navigate to the directory location where you want to save the rule
file.
3. Type a name for the file in the File name box.
Note:
The file is output in XML format; therefore, the file name must end in .xml.
4. Click the exportRule button.

The authorization rule file is saved in the operating system directory that you specified in step 2.

© 2021 Siemens
Import authorization rules
1. In the Authorization application pane, click the importRule button.
2. In the importRule dialog box, navigate to the directory containing the authorization rule file that
you want to import.
Note:
Rule files are XML files.
3. Select the authorization rule file.
4. Click the importRule button.

The authorization rule file is imported in to Teamcenter.

© 2021 Siemens
14. Backing up and recovering a
Teamcenter environment
Backing up a Teamcenter environment
Caution:
Failure to back up all environment components runs the risk of data loss in the event of the need
to restore the environment.
Backup software requirements
Third-party software is used to back up and restore files in volumes. Ensure the user running the third-
party backup software user is the same as the volume owner.
When to back up
In addition to the normal backup of information for purposes of disaster recovery, back up the
Teamcenter environment before performing any of the following actions:
• Installing or updating Teamcenter software
• Changing the machine environment, such as updating operating system software or 3rd party
software
• Changing the data model, especially by deploying a new or modified template
• Other tasks that modify a particular directory in the installation
Example:
The addition of another FSC modifies the TC_ROOT\fsc directory. In such cases, that directory
and any other related dependencies (database, volumes, and so on) should also be backed up.
Components of a Teamcenter environment backup
• For each configured database:
• Oracle or Microsoft SQL Server database
• TC_DATA directory and its contents
• Teamcenter volume directories

© 2021 Siemens
14. Backing up and recovering a Teamcenter environment
• On each workstation where Teamcenter is installed:
• TC_ROOT\install
• TC_ROOT\bmide and any custom Business Modeler IDE project folders stored in a location other
than TC_ROOT\bmide
• Depending on the environment, additional components should be backed up. For example:
• Dispatcher root directory (if updating the dispatcher configuration)
• TC_ROOT\fsc (if updating the FSC configuration)
Tip:
In the case of Teamcenter environment components installed in virtual machines, taking a
snapshot of the affected virtual machines is also a viable means of backup.
Overview of the integrated backup and recovery process

The integrated backup and recovery feature facilitates online backup by third-party backup systems,
allowing Teamcenter to operate continually. This feature focuses on the area of backing up metadata
and files, and recovering that data in different restoration scenarios. To accomplish this, the integrated
backup feature places Teamcenter in different operation modes using the backup_modes utility.
To set the backup mode, use the -m (mode) argument in the backup_modes utility with the following
options: rdonly, normal, and blobby. Use the current option to show the current mode in effect.
The integrated backup system operates in three modes: read-only, blobby volume, and normal. These
are the different modes prompted in the rich client.
Mode Description
Read-only mode Places Teamcenter into read-only state. This state holds writing files to the
volume during backup.
Blobby volume Places Teamcenter in blobby (temporary) volume mode. Teamcenter can be
mode switched into this mode after the third-party backup software takes a snapshot of
the data, thus allowing continuous availability.
Normal mode Places Teamcenter back in normal mode from read-only or blobby volume mode.

© 2021 Siemens
Overview of the integrated backup and recovery process
The following steps describe the process flow of a third-party integrated backup:
1. The third-party backup software requests that Teamcenter freeze all operations on its file system
volumes.
Note:
The method of the request depends on how the third-party backup software is integrated
with Teamcenter. In a loosely coupled integration, the request can be a reminder or email to
the system administrator to begin the backup process. A tightly integrated system can trigger
the read-only mode using the backup_modes command line utility.
2. Teamcenter starts database and file system volume synchronization by ensuring there are no open
writes to volumes. (The system pauses until all open writes are completed, and suspends future
writes by putting file system volumes in read-only mode.)
3. Teamcenter returns an OK message after a successful math and metadata synchronization.
4. The third-party backup software puts the database in hot backup mode and creates a snapshot of
the file system.
5. Third-party storage management systems start the backup of database and file system volumes.
Optionally, during the backup, the third-party software can request that Teamcenter operate in
blobby volume mode. The blobby volume (a temporary file system area) serves as an alternate
volume location for file writes during the hot backup, allowing for continuous availability. The
blobby mode can be triggered using the backup_modes command line utility.

© 2021 Siemens
6. The third-party backup software completes the backup operation of database and file system
volumes.
7. The third-party backup software requests that Teamcenter resume normal mode. The contents
under bobby volumes are moved back to the original volume location.
Normal mode can be triggered using the backup_modes command line utility.
8. Teamcenter resumes normal mode.
Oracle Recovery Manager (RMAN)
Introduction to the Oracle Recovery Manager (RMAN)
Siemens Digital Industries Software recommends the Oracle Recovery Manager (RMAN) product be used
with the Teamcenter integrated backup application. RMAN is an Oracle utility that backs up, restores,
and recovers database files. This is a feature of the Oracle database server and does not require separate
installation. Recovery Manager uses database server sessions to perform backup and recovery
operations. It stores metadata about its operations in the control file of the target database, and
optionally, in a recovery catalog schema in an Oracle database. You can invoke RMAN as a command line
executable from the operating system prompt or use some RMAN features through the Enterprise
Manager interface.
The features of RMAN are available using the Oracle Backup Manager interface. This is a command line
interface, similar to SQL*DBA. It provides a powerful operating-system- independent scripting language
and works in interactive or batch mode. The RMAN environment consists of the utilities and databases
that play roles in a backup and recovery strategy. A typical RMAN setup utilizes the following
components:
• RMAN executable
• Target database
• Recovery catalog database
• Media management software
Of these components, only the RMAN executable and target database are required. RMAN automatically
stores its metadata in the target database control file, so the recovery catalog database is optional.
Siemens Digital Industries Software recommends maintaining a recovery catalog. If you create a catalog
on a separate machine and the production machine fails completely, you have all the restore and
recovery information you need in the catalog.
When configuring backup and recovery, you must specify all of the following items to ensure a complete
recovery:
• The database (such as Oracle and MS SQL).

© 2021 Siemens
Benefits of RMAN
• All database volumes.
• The TC_DATA directory.
• The TC_ROOT\install directory, which stores configuration data.
• The TC_ROOT\bmide directory (if the Business Modeler IDE is installed). This directory can contain
database templates and custom templates under project folders.
• All local Business Modeler IDE project folders, including project folders within source control
management (SCM) systems.
You can hot backup the database and volumes. You must cold backup the remaining items.
Benefits of RMAN
The following table lists a comparison between the Oracle Recovery Manager (RMAN) and user-
managed methods.
Recovery Manager User-managed method
Uses a media management API so that RMAN Does not have support of a published API.
works seamlessly with third-party media
management software. More than 20 vendors
support the API.
When backing up online files, RMAN rereads Requires placing online tablespaces in backup
fractured data blocks to get a consistent read. mode before backing them up and then taking
You do not need to place online tablespaces in the tablespaces out of this mode after the
backup mode when performing backups. backup is complete. Serious database
performance and manageability problems can
occur if you neglect to take tablespaces out of
backup mode after an online backup is
complete.
Performs incremental backups, which back up Backs up all blocks, not just the changed blocks.
only those data blocks that changed after a Does not allow you to recover a
previous backup. You can recover the database NOARCHIVELOG database.
using incremental backups, which means that
you can recover a NOARCHIVELOG database.
However, you can only take incremental
backups of a NOARCHIVELOG database after a
consistent shutdown.

© 2021 Siemens
Computes checksums for each block during a Does not provide error checking.
backup and checks for corrupt blocks when
backing up or restoring. Many of the integrity
checks that are normally performed when
executing SQL are also performed when backing
up or restoring.
Omits never-used blocks from datafile backups Includes all data blocks, regardless of whether
so that only data blocks that have been written they contain data.
to are included in a backup.
Stores RMAN scripts in the recovery catalog. Requires storage and maintenance of operating
system-based scripts.
Allows you to easily create a duplicate of the Requires you to follow a complicated procedure
production database for testing purposes or when creating a test or standby database.
easily create or back up a standby database.
Performs checks to determine whether backups Requires you to locate and test backups
on disk or in the media catalog are still available. manually.
Performs automatic parallelization of backup Requires you to parallelize manually by

and restore operations. determining which files you need to back up
and then issuing operating system commands
in parallel.
Tests whether files can be backed up or restored Requires you to actually restore backup files
without actually performing the backup or before you can perform a trial recovery of the
restore. backups.
Performs archived log failover automatically. If Cannot failover to an alternative archived log if
RMAN discovers a corrupt or missing log during the backup encounters a problem.
a backup, it considers all logs and log copies
listed in the repository as alternative candidates
for the backup.
Uses the repository to report on crucial Does not include any reporting functionality.
information, including:
• Database schema at a specified time.
• Files requiring backup.

© 2021 Siemens
Features of RMAN
• Files that have not been backed up in a

specified number of days.
• Backups that can be deleted because they are

redundant or cannot be used for recovery.
• Current RMAN persistent settings
Features of RMAN
Feature Description
Incremental backups Up to four levels; level 0 and levels 1 and 4.
Corrupt block detection During backup:
• v$backup_corruption, v$copy_corruption
• Also reported in the databases alert log and trace files.
Restore
Easy management Distributing database backups, resources, and recoveries across

clustered nodes in an Oracle parallel server.
Performance • Automatic parallelization of backup, restore, and recovery.
• Multiplexing prevents flooding any one file with reads and writes
while keeping a tape drive streaming.
• Backups can be restricted to limit reads per file, per second to

avoid interfering with OLTP work.
• No generation of extra redo during open database backups.
• Easy backup of archived redo logs.
Limit file size • Limits number of open files.
• Size of backup piece.

© 2021 Siemens
Feature Description
Recovery catalog Automates restore and recovery operations.
Selective backups Backs up an entire database, selected tablespaces, or selected

datafiles.
ARCHIVELOG mode considerations
Running an Oracle database in ARCHIVELOG mode is necessary in 24x7 environments. If the archive log
destination runs out of space, the database enters into freeze mode until free space is available in the
destination directory. The immediate reaction is to delete some of the archive log files. Deleting archive
redo logs creates holes in the archived log sequence. This can cause database recovery to fail. Use the
following procedures to avoid inadvertently deleting archived logs.
Note:
Oracle documentation should be consulted for exact details of this operation. These procedures
are offered as solutions to be considered, and may not be best for all environments.
• Redirect the archive log destination

Maintain two archive log destinations: primary and secondary. Once the primary log is filled to 85 or
90%, a switchover to secondary destination can be performed and vice versa. After switch over, the
archived logs in the primary destination can be backed up and subsequently purged from the disk.
• Move archive logs to a temporary directory

Once the archive logs are moved to a temporary directory, Oracle will begin functioning again.
Backup the archives logs in the archive log destination directory, and temporary directory, and
subsequently purge them to release space.
• Selectively delete oldest archived logs

This is the last resort. List the logs based on time stamp, and selectively delete the oldest archived
logs that have already been backed up. (Ensure you back it up before manual delete.) The best
practice is to perform Oracle database backups at regular intervals, which can be used to ensure
complete recovery while using minimal space.
Restoring purged files
Single file recovery (SFR)
Single file recovery (SFR) allows users to easily search for and restore purged versions of files from the
backup medium. This feature also helps restore the files from the backup if accidentally deleted by a
user. The scope of SFR is limited to restoring files from your backup medium.

© 2021 Siemens
Single file recovery object model
In Teamcenter, files revised beyond the set revision limit (the default is 3) are eclipsed. These eclipsed
files are stored in the volume and are no longer referenced by the dataset once the revision limit is
reached. A typical day-to-day backup preserves the revision limit versions of the file in the Teamcenter
backup volumes. These files cannot be referenced in Teamcenter but are stored on backup media.
Because the files are no longer associated in Teamcenter, it is tedious to manually bring the file back
into Teamcenter. Rather than performing this task manually, Siemens Digital Industries Software
recommends using SFR to recover a single file.
SFR uses File Management System (FMS) to search for and restore files within the time limits specified
by the TC_sfr_recovery_interval and TC_sfr_process_life_time preferences. The third-party backup
software recovers the purged versions of files from the Teamcenter volume. If the file is found, it is
imported into Teamcenter as a new dataset and placed in the user's Newstuff folder. If the file is not
found under the Teamcenter volume location, even after the maximum time duration specified by the
TC_sfr_process_life_time preference, a message appears user stating that the file cannot be recovered.
Single file recovery object model
SFR contains several classes and tables. These tables are installed as a part of the Teamcenter integrated
backup application. SFR also derives attributes from various Teamcenter classes. These attribute values
are copied and therefore do not impact in the base classes from where they were derived.
The following graphic shows the single file recovery object model.

© 2021 Siemens
Single file recovery in Teamcenter rich client
SingleFileRecovery instances are created using the sfr_instances utility. The instances are generally
created just before the routine backup by third-party backup systems. The backup label used in
generation of these instances is subsequently used by third party backup systems to identify their
backup sets with this label. On recovery command issued by Teamcenter, the user exit API contacts the
3rd party backup systems based on this backup label and restores the file to a common area.
The user exit API must be integrated with a third-party backup system to make this operational. The
background process sfr_bg eventually retrieves the dataset containing the Teamcenter files to the users’
Newstuff folder. The number of sfr_instances quickly grows in the database. Depending on the
retention policy backup data of your site, the old instances should be deleted using the sfr_instances
utility. The user exit API is:
extern USER_EXITS_API int SFR_recover_files_to_location(

const char * dstClient, /**<(I) Volume host(node) name */
const char * destination, /**<(I) The common area where files need to be
recovered */
int no_of_files, /**<(I) Number of files to be recovered */
char * bkup_lab, /**<(I) Backup Label associated with recovered files */

© 2021 Siemens
Single file recovery query
char ** volPath /**<(I) Absolute Volume paths of recovered files */

);
Single file recovery query
The SingleFileRecovery query, located in the My Teamcenter search pane, is used to locate single files
for recovery.
Once you run the query, the system displays the following message:
A Reference of File in the Database OR a Copy of file from Backup will be

recovered in the Newstuff folder.
The recovery process starts in the background, to compensate for the lead time in recovering the file
from the backup medium. Specify the time intervals of this functionality using the following
preferences:
• TC_sfr_recovery_interval
Specifies, in seconds, how often the system checks for recovered files after a user-initiated single file
recovery action is activated.
• TC_sfr_process_life_time
Specifies, in minutes, how long the system continues to check for recovered files after a user-initiated
single file recovery action is activated.
Alternative hot backup and recovery procedures
Back up and restore SQL Server database files
If you do not use third-party storage management systems, Siemens Digital Industries Software
recommends that you use the SQL Servers Enterprise Manager or T-SQL backup/restore scripts to
perform the hot backup and recovery operations on the database.
MS SQL Server supports online (hot) backups from Enterprise Manager that can back up, restore, and
recover database files. This is a feature of the MS SQL Database Server and does not require separate
installation.
1. Open the SQL Enterprise Manager by clicking Start→All Programs→Microsoft SQL

Server→Enterprise Manager.
2. Expand the SQL Server Group to view all existing servers.
3. Expand the required SQL Server.
4. Expand Databases to list the available databases.

© 2021 Siemens
5. Right-click the required database and select All Tasks→Backup Database…/Restore Database….
6. Click Backup Database to start the database backup process.

The SQL Server Backup dialog box is displayed.
7. On the General tabbed page, choose a type of backup from the Backup options.
After you create a complete database backup (using the Database-complete option), you must
also create a Transaction log backup. To do this, open the SQL Server Backup dialog box and
select the Transaction log backup option.
8. Select the destination (tape or disk) for the backup.

A backup device is a location that stores backup files. A backup file can hold multiple backups.
If this is the first backup of your database, create a backup device by performing the following
steps:
a. Click Add.
The Backup Destination dialog box is displayed.
b. Type a name for the backup in the Name box.

The database name with a .bak extension is used as the default name for the backup.
c. Click File Name (backup device).
d. Define the appropriate path for the file.
e. Click OK.
The SQL Server Backup dialog box is displayed again.
f. Select the device or file you created from the Destination list.
9. Select the appropriate overwrite option for your backup. You can use this option to add multiple
backups to file or device or to overwrite previous backups with the most current backup.
Warning:
Selecting the Schedule box automates the database backup process. Siemens Digital
Industries Software does not recommend using this option, because it only backs up the
database. It does not automate the backup of volumes.
10. Click OK.

The SQL Server Backup dialog box is displayed.
11. Click the Options tab.
12. Select the options that are appropriate for your organization.
13. Click OK.

© 2021 Siemens
Back up and restore Teamcenter volumes
A message is displayed indicating successful completion of the backup operation.
Back up and restore Teamcenter volumes
1. Use backup_modes utility to Set Teamcenter to read-only or blobby volume mode.
2. Copy the volumes from the source location to the destination device/location.
3. After completing the backup, return Teamcenter to normal mode.
Backup with SQL Server Virtual Device Interface (VDI)
Microsoft's Virtual Device Interface (VDI) is integral to all third-party SQL Server backup solutions,
whether hardware or software. The VDI provides third-party vendors access to a collection of high-
performance backup-and-restore mechanisms. By writing to the VDI, developers can substitute a virtual
device for a server's local disk file or tape.
VDIs enable third-party software to control SQL Server backup and restore, which allows vendors to
create a seamless interface between their own high-performance technologies and the SQL Server.
Third-party applications can use the VDI interface to perform snapshot as well as standard SQL Server
backup and restore.
However, VDI under the SQL Server 7.0 does not permit true third-party integration. It supports only
standard SQL Server backup and restore. SQL Server, through its support for snapshot backups, treats
the third-party solutions as true backups.
In this case, the backup of volumes and databases must be performed in the traditional manner.
The ability to back up and restore data in a reliable and timely manner requires the SQL Server VDI
(Virtual Backup Device API). Most third-party independent software vendors use the VDI application
programming interface to integrate SQL Server into their products. The advantages and disadvantages
of VDI are as follows:
Advantages
• This API is engineered to provide maximum reliability and performance to support the full range of
SQL Server backup and restore functionality.
• This API is used by most third-party vendors to perform backup/recovery operations. The VDI provides
parallel high-speed data transfer between the SQL Server and the snapshot provider with minimal
overhead.
Disadvantages
• Only utilities that interact with the SQL Server through the VDI can issue the backup and restore
command snapshot option. Users cannot issue the snapshot option directly.

© 2021 Siemens
• SQL Server supports only the backups and restorations saved in the snapshot format. It does not
support differential and transaction log backups saved as snapshots.
• Backup/restore of the SQL Server database is possible using the SQL Server Enterprise Manager or VDI.
However, an integrated solution to back up both the SQL database and volumes is not possible using
these approaches. Backup/recovery of Teamcenter volumes must be performed using the traditional
copy and paste method.
• VDI combined with the third-party integrations can effectively back up and restore Teamcenter
metadata and files that require minimal downtime and require SQL Server 2000/2005 to be in hot
backup mode. This combination enables you to achieve greater flexibility by ensuring 24 X 7
availability.

© 2021 Siemens
15. Import, Export, and Report
Administration Data
What is administration data?
Administration data is data within the Teamcenter site database that defines:
• The behavior of the site.
• Who has access to information in the database.
Administration data in the following categories is maintained using a client such as the rich client or
Active Workspace. This data is not contained in Business Modeler IDE projects, nor in solution templates:
Access Manager Preferences Saved queries Subscriptions

Logical Objects Project Stylesheets Workflow
Organization Revision Rules
You can use administration data reporting capabilities to generate interactive reports of these
categories of administration data, which you can use to analyze and troubleshoot a site, and to compare
differences in data between environments.
You can use administration data export and administration data import to copy and paste
administration data across Teamcenter environments.

© 2021 Siemens
15. Import, Export, and Report Administration Data
To safeguard functionality and data integrity in a production environment, separate environments are
often created for purposes of development, training, patch testing, and troubleshooting. The ability to
report and analyze administration data, and the ability to export and import administration data across
environments, helps in maintaining these environments.
Administration data reporting capabilities have analogous data model element reporting capabilities
accessible from within the Business Modeler IDE.
Videos: Managing Administration Data
Manage administration data across environments
Teamcenter tools for managing your environment's administration data make it easy to perform tasks
with administrative data.

© 2021 Siemens
Copy and compare administration data across environments
Copy and compare administration data across environments
Teamcenter includes tools to help administrators manage your environment's administration data. The
categories of data that are critical to your Teamcenter environment are supported.
Compare administration data before an upgrade
Steps involved in generating a comparison report:

© 2021 Siemens
Tools for managing administration data

You can invoke tools for managing administration data from the command line and, to a lesser extent, in
the Teamcenter Environment Manager (TEM).
Tool function Command Line tool TEM tool

Export administration data from the admin_data_export Manage
current site into an export package file. Administration Data
panel export options.
Import administration data from an admin_data_import Manage
administration data export package into the Administration Data
current Teamcenter site. panel import options.
Generate an interactive report of generate_admin_data_report None.
administration data contained in a site or
in an administration data export package
file.
Generate an interactive report of generate_admin_data_ None.
differences between the administration compare_report
data in an administration data export
package file and either the current site or
another package file.

© 2021 Siemens
Example tasks and processes for managing site behavior
Example tasks and processes for managing site behavior

The following task examples illustrate how you can use interactive administration data reports along
with administration data export/import utilities to manage your Teamcenter sites.
Task General process

Analyze how a site is Generate an interactive report of administration data at the site and
configured and troubleshoot review the report in any web browser.
configuration issues.
Ensure that one site is Export all administration data from one site and import it to another.
configured the same as
This capability is useful when you must ensure certain administration
another.
data at one site exists at another site, such as a test site and a training
site or during site consolidation.
Spread workload for a Set up several isolated sites for work group teams to work on particular
project, such as adding or parts of a development project. A team can make changes in its site
modifying multiple and then export the changed (partial) administration data. You can
workflows, among teams. then consolidate the changes by importing the administration data
from the multiple partial export packages into one site, such as a
sandbox site for final testing.

© 2021 Siemens
Task General process
Determine the cause of Generate a report that compares the administration data from a
differences in site behavior source site with the administration data in a target site. Then analyze
and troubleshoot the report of differences in administration data to determine the cause
configuration issues. of differences in site behavior.
You can also use the report to provide information to an administrator
at a different site.
Determine when a particular Review a site's administration data import history report to track
change was introduced to a impacts of importing administration data over time. This report is
site. automatically updated upon each successful administration data
import to the site.
Reconcile differences in administration data between Teamcenter

sites
You may need to determine why two sites behave differently, or may want to ensure that the
administration data is the same at both sites to allow consolidation of data. Use the following process to
reconcile administration data between two sites.
1. Export the administration data from both sites.
2. Generate an administration data comparison report.
The report shows the areas that differ between the sites for each type of administration data.

© 2021 Siemens
Why would I export administration data?
3. View the comparison report and analyze the differences.
4. After you determine the administration data that requires modification at a target site, import the
data from the source administration data package. Set the appropriate merge options during the
import to ensure you get the only the desired data modification.
Caution:
When you export and import administration data between sites, it is important that the schemas
for the administration data and any related objects involved in the transfer are the same at both
sites.
Example:
Given a situation where:
• A custom business object type exists in the schema at an exporting (source) site, but not at the
importing (target) site.
• A revision rule included in the administration data export refers to an instance of the custom
business object.
Then:
• The administration data import succeeds, but errors occur during activities involving the
revision rule due to the nonexistent custom business object.
Exporting administration data
Why would I export administration data?
Export administration data from a site into an administration data export package, which you can use
when you want to:
• Configure a target site the same as the source site.
• Export administration data from a test site, so you can import it to a production site.

© 2021 Siemens
• Collect information on a site, so you can compare it to another site.
• Export partial administration data from multiple developers into a source code management (SCM)
system for compilation into a comprehensive set of administration data.
You can use either the admin_data_export command line utility or the Teamcenter Environment
Manager (TEM) to export administration data into an administration data package. Procedures in the
TEM vary for partial export and full export.
Note:
It is important to be aware of the considerations for partial export of administration data.
Export administration data using the admin_data_export utility
Note:
It is important to be aware of the considerations for partial export of administration data.
Export administration data using the admin_data_export utility
At a Teamcenter command prompt, run the admin_data_export utility.
Tip:
When the export completes, you may want to use the generate_admin_data_report utility to
generate a report of the site administration data contained in the package.
Export full administration data using TEM
Export full administration data using TEM
You can select the categories of data to export by using the Full export option in Teamcenter
Environment Manager (TEM).
1. Start TEM.

© 2021 Siemens
Export partial administration data using TEM
a. In the Maintenance panel, select Configuration Manager and click Next.
b. In the Configuration Maintenance panel, select Perform maintenance on an existing

2. Select the configuration for the site where you want to export the administration data file and click
Next.
3. In the Feature Maintenance panel, under Teamcenter Foundation, select the Manage
Administration Data option and click Next.
4. In the Manage Administration Data panel, select the Full export option and click Next.
5. In the Full Administration Data Export panel, select the administration data package and the
categories to export and click Next.
a. Click the ... button to the right of the Administration Data Package box to browse to the
location where you want to place the administration data package.
b. Select the administration data categories to export and click Next.
6. In the Teamcenter Administrative User panel, enter the logon information for the Teamcenter
administrative user account and click Next.
7. In the Confirmation panel, review the choices and click Start.
On successful export, TEM packages the exported administration data to the specified packaging
directory. The export package contains the administration data in TC XML files that are used later for
importing into another Teamcenter environment.
Tip:
Note:
It is important to be aware of Considerations for partial export of administration data.

© 2021 Siemens
You can export specific administration data components using the Partial export option in TEM. You
select the specific instances of administration data by category, class, and specific attribute/value
criteria.
However, each administrative data type supports only specific elements in partial export, but not all. For
example, Access Manager supports only Named ACL and Privilege elements to be exported partially,
but not rule trees.
1. Start TEM.

2. Select the configuration for the site where you want to export the administration data file and click
Next.
3. In the Feature Maintenance panel, select the Manage Administration Data option under
Teamcenter Foundation and click Next.
4. In the Manage Administration Data panel, select the Partial export option and click Next.
5. Use the Partial Administration Data Export panel to specify the administration data to export.
a. Click the ... button to the right of the Administration Data Package box to browse to the
location where you want to place the administration data package.
b. Click the arrow in the Category Name box to select the administration data category to
export.
c. Click the arrow in the Export box to select the administration data class to export.
d. Refine the administration data that is exported by using rows in the table.
A. Type the Attribute and Value pair.
Depending on what you select from the Export list, the system may supply an entry for
the Attribute.
B. Click the Add button to the right of the table to add rows for additional attribute/value
pairs and select the Boolean Operator to define how the attributes are added.

© 2021 Siemens
To delete an attribute/value pair, select a row from the table and click the Remove
button.
C. Click Next.
administrative user account.
7. In the Confirmation panel, review the choices and select Start.
On successful export, TEM packages the exported administration data to the specified packaging
directory. The export package contains the administration data in TC XML files used later for importing
into another Teamcenter environment.
Tip:
Examples of partial export attributes and values using TEM
Following are some example attributes and values for partial administration data export using
Teamcenter Environment Manager. Depending on your selection from the Export list, the system may
supply an entry for Attribute. These are examples only. The attributes and values listed here may not
match what you have in your system.
Category name Export Attribute (example) Value (example)

Access Manager Named ACL ACL_Name System
Privilege Privilege_Name READ
Organization Discipline discipline_name *
Group name Engineering
License Server fnd0name *
Person user_name *
Role role_name Designer
Site name *
Volume user_name *
Discipline volume_name volume
Preferences Preferences by Category Category Name (supplied) Change Management
Preferences by Group Group Name (supplied) Engineering
Preferences by Preference Preference Name (supplied) HiddenPerspectives
Name

© 2021 Siemens
Category name Export Attribute (example) Value (example)

Preferences by Role Role Name (supplied) Designer
Preferences by User User Name (supplied) user0001
Project Project project_id *
Revision Rules Revision Rule object_name *
Saved Queries Saved Query query_name *
Stylesheets Stylesheets by Preference Name (supplied) *SUMMARYRENDERING
Name
Stylesheets by Stylesheet Name (supplied) Item*
Name
Subscriptions Subscription subscriber *
Workflow Named ACL ACL_Name Vault
Privilege Privilege_Name PROMOTE
Workflow Templates by Name (supplied) Quick Release
Name
Considerations for partial export of administration data
General considerations
• To export only part of an administration data category, you must specify input criteria that identify
the data you want to export. Prepare your criteria before beginning the export.
• By default, partial exports do not include referenced user information. To understand some
implications of not including referenced user information, read and understand the description for the
-session_options argument option opt_traverse_ref in admin_data_export before performing the
administration data transfer.
• With any partial export, the Access Manager privileges are always exported in order to maintain the
data integrity.
• Partial export of an Organization tree is supported bottom-up and not top-down. For example, if you
have the following tree and you are exporting the group1 group partially, the complete tree may not
be exported. But if you export the user1 user partially, the complete tree is exported.
group1
- role1
- user1

© 2021 Siemens
Considerations for partial export of administration data
Input criteria for a partial export: class name{attribute=value}
To export partial administration data, you must specify input criteria that identify the data you want to
export. The specification includes:
• Administration data class name.
Note:
If you are specifying a partial export using TEM, the class name is understood by the system
when you select an option from the Export list.
• The real name (not the display name) for an attribute of the named class.
Note:
If you are specifying a partial export using TEM, depending on your selection from the Export
list, the system may supply the attribute name, in which case the display name is shown.
• The value of the named attribute.
What are the classes associated with administration data?
Not all categories of administration data are associated with classes, but many are. The following table
lists associated classes for commonly partially-exported categories of administration data.
Administration data type Associated class

Access Manager AM_ACL
Organization
Discipline Discipline
Group Group
License Server Fnd0LicenseServer0
Person Person
Role Role
Site POM_site_config
User User
Volume ImanVolume
Project TC_Project
Revision Rules RevisionRule

© 2021 Siemens
Administration data type Associated class

Saved Queries SavedQueryCriteria
Subscriptions ImanSubscription
How can I find the real names of attributes?
Following are some tools you can use to look up the real names of attributes:
• Query Builder
Allows you to build queries on classes and their attributes.
For example, following is a query on the Access Manager class (ACM_ACL) showing its attributes:
• Business Modeler IDE

Displays the Teamcenter classes and their attributes in the Classes view of the Advanced perspective.
You can also see the corresponding business objects and their properties in the Business Objects
view.
Following is a display of the Access Manager class (ACM_ACL) in the Classes view:
• taxonomy utility
Lists the classes in the Teamcenter system and their attributes. To output the list to a file, run the
following from a Teamcenter command prompt:
taxonomy -f=classes_and_attributes.txt
Following is an excerpt of the output for the Access Manager class (ACM_ACL):

© 2021 Siemens
Why would I import administration data?
[ 1]<-->[AM_ACL] app [AM]
Class is NOT exportable.
POM class definition for: AM_ACL

application name: AM
Number of super classes: 1
Super class : POM_object
Number of Attributes: 5
Attribute 1 Name : ACE_Ids

Type : POM_untyped_reference
...
Attribute 2 Name : ACE_Ids_togo
Type : POM_untyped_reference
...
Attribute 3 Name : ACL_Flag
Type : POM_string
...
Attribute 4 Name : ACL_Name
Type : POM_string
...
Attribute 5 Name : acl_loaded
Type : POM_logical
...
Number of indexes : 0
Class size in bytes: 171
How can I find attribute values?
Generate an administration data document report. Review the report to see all the administration
data attributes and their values.
Note:
The report shows attribute display names, but not attribute real names.
Importing administration data
Why would I import administration data?
Import administration data previously exported from a source site into a target site when you want to:
• Configure the target site the same as the source site.
• Move administration data configured on a test environment into a production environment.
When importing administration data, you can use merge options to control whether the source or target
takes precedence.

© 2021 Siemens
Before actually importing data, you can perform a dry run import, and then review the dry run report to
analyze the potential impact and resolve any conflicts.
You can perform the dry run import, and perform the actual import, using either the
admin_data_import utility or using Teamcenter Environment Manager (TEM).
Perform a dry run import of administration data using TEM
Using an administration data package file that is the output of exporting administration data from a
source site, you can perform a dry run import to a target site to see the impact before actually importing
data. You can perform the dry run import using the admin_data_import utility or using TEM.
Perform the dry run data import using Teamcenter Environment Manager
1. Start TEM.

2. Select the configuration for the site where you want to import the administration data file and click
Next.
4. In the Manage Administration Data panel, select the Dry run import option and click Next.
5. In the Dry Run Import Administration Data panel, click the ... button in the Administration Data
Package box and select the administration data package. Click Next.
6. In the Import Merge Options panel, select the merge option for each category and click Next.
8. In the Confirmation panel, review the choices and click Start.
9. In the Install panel, monitor the Overall Progress or select Show Details to see the install status.
View the Administration Data Import (dry run) report
To view a dry run report, after the run completes, browse to the following location:
TC_ROOT\logs\admin_data_import_history\Import_date-and-time\index.html

© 2021 Siemens
Perform a dry run import of administration data using the admin_data_import utility
The following image shows the summary page of an example partial administration data import dry run
report. In an actual report, you can click links to navigate through the report.
Perform a dry run import of administration data using the

admin_data_import utility
source site, you can perform a dry run import to a target site to see the impact before actually importing
data. You can perform the dry run import using the admin_data_import utility or using TEM.
Perform the dry run data import using the admin_data_import utility
At a Teamcenter command prompt, run the admin_data_import command line utility with the -dryrun
argument.
Note:
Use the -mergeOption argument to specify the merge options to set for each data type.
View the Administration Data Import (dry run) report
To view the dry run report, after the run completes, browse to the following location:
report. In an actual report, you can click links to navigate through the report.

© 2021 Siemens
Import administration data using TEM
source site, you can import administration data to a target site. You can perform the import using the
admin_data_import utility or using TEM.
The type of administration data that you can import is determined by what the import package contains.
If multiple categories of data are in the file, you can select the categories that you want to import.
1. Start Teamcenter Environment Manager (TEM).

2. Select the configuration for the site where you want to import the administration data file and click
Next.
4. In the Manage Administration Data panel, select the Import option and click Next.
5. In the Import Administration Data panel, click the ... button to the right of the Administration
Data Package box to select the administration data package to import. Click Next.
6. In the Import Merge Options panel, select the merge option for each category and click Next.

© 2021 Siemens
Import administration data using the admin_data_import utility
8. In the Confirmation panel, review the choices and select Start.
9. In the Install panel, monitor the Overall Progress or select Show Details to watch the install
status.
10. After the import, access the results from the following location:
Note:
If your imported administrative package contains volume objects, you must postprocess the
imported volume objects for them to work properly.
Following is an example import report.
Import administration data using the admin_data_import utility
source site, you can import administration data to a target site. You can perform the import using the
admin_data_import utility or using TEM.
The type of administration data that you can import is determined by what the import package contains.
You can specify the administration data categories that you want to import.

© 2021 Siemens
Note:
If the administration data contains volume objects, you must postprocess the imported volume
objects for them to work properly.
1. To see the potential impact before actually importing data, perform a dry run import using either
using the admin_data_import utility or using TEM. Review the dry run import report and resolve
any conflicts.
2. At a Teamcenter command prompt, run the admin_data_import command line utility.
Use the -mergeOption argument to specify the merge options for each data type.
3. After the import, access the results from the following location:
Note:
If your imported administrative package contains volume objects, you must postprocess the
imported volume objects for them to work properly.
Following is an example import report.
Postprocess imported volume objects
If your imported administrative package contains volume objects, the volume's host and FMS
configuration must be updated with the importing site data.

© 2021 Siemens
Administration data import merge options
1. Extract the VolumeAttributeUpdateInput.xml file from the export package.
2. Open the file and update the host name and host path with the importing site's host name and
path.
3. Run the tc_attribute_bulk_update utility with the updated VolumeAttributeUpdateInput.xml file

as the -inputfile argument value, for example:
tc_attribute_bulk_update -u=admin -p=password -g=dba

-inputfile=VolumeAttributeUpdateInput.xml -import
4. Run the update_fms_configuration utility to update the FSC configuration, for example:
update_fms_configuration -u=admin -p=password -g=dba

-volumes=volume-names-in-comma-separated-list -fsc_id=fsc-id
Administration data import merge options
When you import administration data, for each category of administration data you must specify how to
handle data conflicts between the target (importing) site administration data and the source (exporting)
site data in the input package.
Following are the available merge options:
Override With Source

Overrides target objects with source objects. If an object exists in both environments, the attributes
on the object are taken from the source environment and updated on the object in the target
environment during the import. If an object in the source environment does not exist in the target
environment, it is imported to the target environment.
To avoid unexpected behavior that could result from mixing the rule tree contents, this is the only
option available for Access Manager administration data.
Keep Target
Keeps the target site’s administration data for all conflicts. If an object exists in both environments,
the object in the target environment is kept as-is. If an object in the source environment does not
exist in the target environment, it is imported to the target environment.
Choose Latest
Chooses objects that were last saved (based on the Last Saved Date property value). If an object
exists in both environments and the one in the source environment was saved last, the attributes on
the object in the source environment are used to update the attributes of the object in the target
environment during the import. If the object in the target environment was saved last, the attributes
on the object in the source environment are not imported. If an object in the source environment
does not exist in the target environment, it is imported to the target environment.
Choose Source for Unresolvable Conflicts

© 2021 Siemens
Chooses objects from the source environment if they were edited in the source environment and
not in the target environment since the last import. If an object exists in both environments, the
attributes on the object in the source environment are used to update the attributes on the object in
the target environment during the import. If an object was edited only in the target environment
and not the source environment since the last import, the object is left as-is at the time of import. If
an object in the source environment does not exist in the target environment, it is imported to the
target environment.
This option is not available for workflow administration data.

Choose Target for Unresolvable Conflicts
Chooses objects from the target environment if they were edited in the target environment and not
in the source environment since the last import. If an object was edited only in the target
environment and not the source environment since the last import, the object is left as-is at the time
of import. If an object in the source environment does not exist in the target environment, it is
imported to the target environment.
This option is not available for workflow administration data.
How you set import merge options depends on which method you use to perform the import, either
with the admin_data_import utility or with the Teamcenter Environment Manager (TEM):
• admin_data_import utility
Use the -MergeOptions argument to specify the merge option to use with each administration data
category.
• Import Merge Options panel in TEM

When you perform a dry run import or a regular import of administration data, the Import Merge
Options panel is displayed. Select the merge option you want to use with each data category.
Tip:
The default values on this panel are the actions that Siemens Digital Industries Software
recommends you use in most cases to avoid unintentional changes.
Style sheet import behavior
By default, each style sheet has two preferences set. For example, the summary style sheet has the
following:
type-name.SUMMARYRENDERING=dataset-name
dataset-name.SUMMARY_REGISTEREDTO=type-name
If no preferences or only one preference is defined on a style sheet, then the style sheet is not in use.
During import, when the target database is missing one or both preferences for a style sheet, the import
is processed as if both preferences are defined in the target database.

© 2021 Siemens
Style sheet import behavior
The following tables show details of the import actions taken for the two preferences depending on
whether the preferences exist. The last column shows the target action when you select the import
option Choose Source or Choose Source For Unresolved Conflicts.
Preference import actions for Item dataset cases

Source preferences Target preferences Action Target preferences after Target action
import with source
option1
Item. SUMMARYRENDERING First time import, dataset Added at Item. SUMMARYRENDERING Add at target
does not exist. source site. site using import
ItemSummary. ItemSummary. package data.
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO
Dataset does not exist Item. SUMMARYRENDERING Added at target No change. None.
site.
ItemSummary.
SUMMARY_REGISTEREDTO
Item. SUMMARYRENDERING Item. SUMMARYRENDERING First time Item. SUMMARYRENDERING Update using
created at source package.
ItemSummary. ItemSummary. source. ItemSummary.
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO
First time
created at
target not by
importing.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Change XML Item. SUMMARYRENDERING Update.
file content at
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Change XML Item. SUMMARYRENDERING Update using
file content at source package.
Change XML
file content at
target.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Change XML Item. SUMMARYRENDERING Add using
file content at source package.
Delete at
target.
Item. SUMMARYRENDERING Delete at None.
source.
ItemSummary.
Item. SUMMARYRENDERING Delete at None.
target.
ItemSummary.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Delete at Item. SUMMARYRENDERING None.
source.
ItemSummary. ItemSummary. ItemSummary.
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO Delete at SUMMARY_REGISTEREDTO
target.
1 When you select either the Choose Source option or Choose Source for Unresolved Conflicts option.

© 2021 Siemens
Source preferences Target preferences Action Target preferences after Target action
import with source
option2
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Delete at Depends on SyncDelete SyncDelete
source. option.
ItemSummary. ItemSummary. ON: Delete
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO Change at
target. OFF: Keep
target.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Delete at Depends on SyncDelete SyncDelete
source. option.
ItemSummary. ItemSummary. ON: Delete
OFF: Keep
target.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Added at Item. SUMMARYRENDERING Add using
source from source 2.
ItemSummary. ItemSummary. source 2. ItemSummary.
Imported at
target from
source 1.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Change at -override_
target. with_ source
ItemSummary. ItemSummary. option, update
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO using source
package.
-choose_
source_ for_
unresolved_
conflicts option,
keep target.
Item. SUMMARYRENDERING Item. SUMMARYRENDERING Delete at Item. SUMMARYRENDERING Add using
target. source package.
ItemSummary. ItemSummary. ItemSummary.
Preference import actions for Item Revision and Document Revision datasets cases
Source preferences Target preferences Action Target preferences after Target action with a
import source option3
ItemRevision. ItemRevision. Add at ItemRevision. Add at target site
SUMMARYRENDERING SUMMARYRENDERING source. SUMMARYRENDERING using import package
data.
ItemRevisionSummary. ItemRevisionSummary. Add at ItemRevisionSummary.
SUMMARY_REGISTEREDTO SUMMARY_REGISTEREDTO target. SUMMARY_REGISTEREDTO DocumentRevision
has it own stylesheet.
DocumentRevision. (DocumentRevision inherits DocumentRevision.
SUMMARYRENDERING ItemRevision’s summary SUMMARYRENDERING
style sheet.)
DocumentRevisionSummary. DocumentRevisionSummary.
2 When you select either the Choose Source option or Choose Source for Unresolved Conflicts option.
3 Choose Source option or Choose Source for Unresolved Conflicts option.

© 2021 Siemens
Modifying an administration data package
Modifying an administration data package
Normally, you do not need to alter the content of the administration data TC XML file. However, after
you export an administration data file, you can carefully modify the TC XML content of the file to provide
changes for specific sites or groups of sites.
Note:
Because mistakes in the TC XML file can cause corruption and possibly data loss during import,
import of a modified file requires an authorization key. After passing the Manage Administration
Data self-paced course available from Learning Advantage, you can file a support case on Support
Center to obtain a key. The course provides the information necessary to avoid potential problems
when editing the TC XML content of an administration data file.
Following are rules for editing an administration data TC XML file:
• Ensure the uniqueness of elemId attributes across the TC XML file.
• Ensure the value of Boolean type attributes are Y (true) or N (false).
• Ensure the value of reference type attributes are formatted as:
#<elemId-of-the-GSIdentity-of-the-referenced-object>
• Ensure the value of date type attributes are in GMT format:
year-month-dayThour:minute:SecondZ
For example, for 09 September 2014 at 4:21:04 AM (GMT), 2014-09-23T04:21:04Z.
• Ensure the timestamp value is present.
• Ensure L10N attributes are list of values formatted as:
locale:M/S:M/A/P/R/I:sequence:[aA-zZ]^32:translation
A locale in the format of en_US: M/S is a master or secondary language.

M/A/P/R/I is the translation status.
The sequence number is 4 digits for multiple value attributes.
There are 32 characters reserved.
The rest is the translation, for example:
de_DE:S:A:0000::Proxy-Link,
en_US:S:A:0000::Proxy Link,
es_ES:S:A:0000::Enlace proxy,
fr_FR:S:A:0000::Lien proxy,

© 2021 Siemens
it_IT:S:A:0000::Collegamento proxy,
pt_BR:S:A:0000::Link de proxy
• When editing the attributes that are part of the candidate key, the GSIdentity label of the object, and
the label of the objects that reference the object, must be updated accordingly.
• Ensure all required attributes for the administration object have values.
• For out-of-the-box administration objects, a user's home, mailbox_folder, and newstuff_folder

attributes must not be added. Also, a dataset rev_chain_anchor attribute must not be added. This is
true even though these are required attributes.
• After editing the file, validate the complete file content against LLTCXML.xsd file (low-level TC XML
schema) located in the TC_DATA directory to ensure the XML is valid.
Import a modified administration data package
Because mistakes in the TC XML file can cause corruption and possibly data loss during import, import of
a modified file requires an authorization key. You can obtain the key from Support Center after passing
the Manage Administration Data self-paced course available from Learning Advantage. The course
provides the information necessary to avoid potential problems when editing the TC XML content of an
administration data file.
1. In your Teamcenter environment, set the BULK_LOADER_AUTH_KEY environment variable to the

value of the authorization key.
This enables the bulk load capabilities that are used to import the modified package. If you do not
set this variable to a valid value, TEM returns an error message when you attempt to import the
modified package.
2. When importing the modified package in Teamcenter Environment Manager (TEM), navigate to the
Manage Administration Data page and select the Ignore package validation check box.
This enables bulk load functionality that bypasses certain validation checks.
Reporting administration data
What administration data reports are available?
Documentation, Comparison, Import (dry run), and Import (history) administration data reports show
detailed Teamcenter administration data for the data categories that are specified when the report is
generated. If an object is referenced by other objects, reports include a where-used table that indicates
the categories and objects that have references to the object. You can use any web browser to view and
interactively navigate through the reports.

© 2021 Siemens
Administration Data Documentation report
Administration data report types
Documentation
Reports administration data for the current Teamcenter environment or for an administration data
export package.
For use in effectively administering your environment, generate a documentation report of your
environment administration data.
Example Teamcenter [version] Administration Data Documentation reports of a default installation

of Teamcenter foundation are available on Siemens PLM Support Center under the Programming
and Customization category. These example reports provide a reference without having to first
install Teamcenter. However, they do not contain an accurate representation of your individual
environment.
Comparison
Reports differences between administration data in two Teamcenter environments.
Import (dry run)
Reports changes in administration data that will occur due to importing an administration data
package to the current Teamcenter environment. Use a dry run import report to assess the effects of
importing administration data without changing the existing data.
Import (history)
Reports the administration data that was impacted by an import to the current Teamcenter
environment at a particular point in time. A separate report is generated for each import. The report
file contains the site name and a timestamp. You can use these reports to determine exactly what
and when changes occurred that may be affecting behavior in the environment.
Administration Data Documentation report
You can use interactive Administration Data Documentation reports to:
• Troubleshoot issues with configuration.

• Periodically review a production environment to ensure it complies with business objectives.
• Capture a snapshot of the configuration at a point in time for archiving or audit reviews.
• Train administrators.
Generate an Administration Data Report
Use the generate_admin_data_report utility to generate a report of site administration data.
• You can run the report for the current site or for an exported administration data package.
• You can report all Administration Data categories or only selected categories.

© 2021 Siemens
View an Administration Data Report
To view a generated report, browse to the output location and open the index.html file.
The following image shows the summary page of an example report. In an actual report, you can click
links to navigate through the report to find summaries and details of administration data.
Administration Data Comparison report
You can use Administration Data Comparison reports to:
• Troubleshoot differences in business logic behavior by reviewing configuration differences between

two environments.
• Determine whether a new environment is configured the same as a reference environment.
• Prepare for site consolidation by comparing environments to see what is common and what is
different.
• Identify differences between a customer environment and an out-of-the-box Teamcenter
environment.
• Compare a baseline export of an environment to a later export of the same environment.
Generate an Administration Data Comparison report
To make the comparison, the utility requires an administration data export package from one
environment as a source, and either the local environment or another administration data export
package as a target. The report highlights differences between the source data and the target data.

© 2021 Siemens
Administration Data Comparison report
If an object is referenced by other objects, the report includes a where-used table that indicates the
categories and objects that have references to a selected object in both source and target environments.
The report summary page shows all the administration data types included in the comparison and the
number of differences for each element present within the category. The report includes a glossary of
administration data categories and the elements available in each of the categories.
Use the generate_admin_data_compare_report utility to generate a report comparing a source

environment administration data export package file to either:
• The current environment

• Another administration data export package file.
View an Administration Data Comparison report
To view a generated report, browse to the output location and open the index.html file.
The following image shows the summary page of an example comparison report. Differences are
highlighted in yellow. In a real report, you can click links to navigate through the report to find
summaries and details of administration data.

© 2021 Siemens
Example:
As you navigate to details of the report, you can easily identify even very small differences.
Permission difference in Access Manager.
Label difference in a Style Sheet.

© 2021 Siemens
Administration Data Import (dry run) report
Administration Data Import (dry run) report
You can perform a dry run import to a target site in order to generate a report of the potential impact
before performing the actual import.
Generate an Administration Data Import (dry run) report
Perform a dry run import using either
• The admin_data_import utility with the -dryrun argument
• Or the Dry run import option in Teamcenter Environment Manager (TEM).
View an Administration Data Import (dry run) report
To view a dry run report, after the run completes, browse to the following location:
report. In a real report, you can click links to navigate through the report to find summaries and details
of administration data.
Administration Data Import (history) report
You can use the interactive Administration Data Import (history) report for a site to:
• Track impacts of importing administration data.
• Determine when a particular change was introduced to a site.

© 2021 Siemens
Generate an Administration Data Import (history) report
An Administration Data Import (history) report is automatically generated after each successful import
of administration data. Imports can be performed using the admin_data_import command line utility
or Teamcenter Environment Manager (TEM).
View an Administration Data Import (history) report
To view an Administration Data Import (history) report, browse to:
TC_ROOT\logs\admin_data_import_history\index.html
The following image shows the summary page for an import report selected from the three available
historic reports. For this import, the only imported administration data category was Organization.
Impacts are highlighted in blue. In a real report, you can click links to navigate through the report to find
summaries and details of administration data.

© 2021 Siemens
16. Cryptography and FIPS compliance in
Teamcenter server
Teamcenter can be configured to use FIPS (Federal Information Processing Standard) standards by using
the FIPS-certified Teamcenter Cryptographic Module (TCM). When using the TCM, Teamcenter uses the
FIPS PUB 140-2 standard to perform all cryptographic functions. The TCM provides FIPS-140-2 validated
encryption, hashing, digital signatures, and random number generation.
All Teamcenter cryptographic functions are handled with the OpenSSL-based TcCrypto library.
Teamcenter Cryptographic Module (TCM)
The TCM is a software library providing an API for use by applications that require cryptographic security.
The TCM is classified by FIPS 140-2 as a software module, multichip standalone module embodiment.
The Siemens Digital Industries Software Teamcenter Cryptographic Module FIPS 140-2 security Policy
(Certificate #2624) is available at https://csrc.nist.gov.
The TCM is a cryptographic engine library that is used only in conjunction with additional software.
Aside from the use of the NIST-defined elliptic curves as trusted third party domain parameters, all other
FIPS 186-3 assurances are outside the scope of the TCM, and are the responsibility of the calling process.
The TCM software version for this validation is provided in the Siemens Digital Industries Software
Teamcenter Cryptographic Module FIPS 140-2 security Policy (Certificate #2624) available at https://
csrc.nist.gov.
The TCM has the following characteristics:
• The physical cryptographic boundary is the general purpose computer on which the TCM is installed.
• The logical cryptographic boundary of the TCM is the TcCryptoFips object module. It is designed to be
a shared library.
• The TcCryptoFips library communicates only with the calling TcCrypto library, which is responsible
for invoking the TCM services in FIPS mode.
• The TCM requires the following initialization sequence.
• Upon load, the TcCryptoFips library runs the integrity test followed by the self tests.
• When a calling application requests the module to be in FIPS mode, the TCM invokes
FIPS_mode_set() implemented in the TcCryptoFips library. Doing so verifies the user password
and reruns the algorithms test, returning a 1 for success or 0 for failure.
If FIPS_mode_set() fails, all subsequent cryptographic services in the FIPS module fail. The module
can later be initialized in domestic mode and an application can test whether FIPS mode has been
successfully enabled.

© 2021 Siemens
16. Cryptography and FIPS compliance in Teamcenter server
See section 9.5 in Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation
Program available at https://csrc.nist.gov for further information on initialization sequences.
Configure Teamcenter to use FIPS standards
Configure Teamcenter to use FIPS standards by setting the TCCRYPTO_FORCE_FIPS_MODE environment

variable to a value of true.
You can also define and set TCCRYPTO_FORCE_FIPS_MODE in the file tc_profilevars.bat (Windows) or
tc_profilevars.sh (Linux).

© 2021 Siemens
17. Encryption key management
Teamcenter Key Manager
Teamcenter Key Manager is an optionally-installed feature that enables you to manage, edit, and share
encryption keys and policies in a centralized secure manner for a distributed Teamcenter site.
Teamcenter Key Manager consists of a central key manager server which delegates key storage and
cryptography to the public key cryptography standard PKCS #11 hardware or software plugin of your
choice. Default Network Security Services (NSS) is delivered with Teamcenter Key Manager. Customized
Network Security Services (NSS) and hardware security modules (HSM) are also supported.
Trusted Teamcenter satellites communicate with the key manager server using two-way SSL to share
keys and perform cryptography for features and applications such as Teamcenter two-tier rich clients
and Dispatcher. With Teamcenter Key Manager, you can define component-specific policies governing
the algorithms used for key generation and the key encryption and decryption life times.
The key manager server, where all policies and keys are stored, resides on single host, accessed over
secure HTTPS on a dedicated configurable port with two-way transport layer security. A key manager
satellite resides on each enterprise tier host, and accesses the key manager server over HTTPS.
An optional secondary key manager server maintains synchronization with the primary key manager
server, and automatically acts as a failover server for satellites if the primary key manager server
becomes unavailable. The secondary server resides on a separate host than the primary server.
For sites using Teamcenter Key Manager, if key manager servers or the satellites are not running, users
will not be able to log into Teamcenter.
Installing Teamcenter Key Manager

If your site is using Teamcenter Key Manager for cryptographic services, use the following installation
approaches:
When installing Teamcenter using TEM

Teamcenter Key Manager and the local key manager satellite must be installed and running before
Teamcenter can be installed. Teamcenter Key Manager and key manager satellites are installed
using Deployment Center as described in the following steps.
Once Teamcenter Key Manager is installed, install Teamcenter using Teamcenter Environment
Manager (TEM). On the TEM Key Manager Configuration panel, check Enable Key Manager and
specify the location of the key manager satellite.
When installing Teamcenter using Deployment Center
Teamcenter Key Manager and the local key manager satellite can be installed before or after
Teamcenter foundation is installed using Deployment Center.

© 2021 Siemens
A key manager satellite must be installed on every machine that will be using Teamcenter Key Manager.
SSL certificates must also be established on each machine involved in the Teamcenter Key Manager
system.
Note:
Once a site is using Teamcenter Key Manager for cryptographic services, it cannot be reconfigured
to use an alternate cryptographic system without reinstalling Teamcenter.
Install the key manager server and satellites
Teamcenter Key Manager is installed and deployed using Deployment Center. See the Teamcenter
Compatibility Matrix to verify the version of Deployment Center required to install and deploy
Teamcenter Key Manager.
The following steps are specific to installing and deploying Key Manager using Deployment Center. For
detailed information on using Deployment Center, see the most recent Deployment Center help
collection available on Support Center.
1. Download the Teamcenter Foundation software kit from Support Center and place it in the
Deployment Center software repository.
2. Log onto Deployment Center and click the Software Repositories tile to view the Teamcenter
Foundation software kit, verifying its availability in the software repository.
3. Click the Environments tile to display the environments scanned by Deployment Center. Select or
add an environment in which to install Teamcenter Key Manager.
4. Click the Deploy Software tab. In the Software task, add the Teamcenter Foundation software kit
to the Selected Software list.
5. In the Options task, select the options for your environment. Selecting Single Box allows you to
install the key manager server and satellite on one machine. Selecting Distributed allows you to
install the key manager server on one machine and satellites on one or more other machines.
6. In the Applications task, click to edit the selected applications. The list of available applications
is displayed.
7. Under Available Applications, check Key Manager.
8. Remove the check from Teamcenter Foundation if any of these conditions apply:
• You will be installing Teamcenter using TEM.
• Teamcenter has already been installed using Deployment Center.

© 2021 Siemens
Installing Teamcenter Key Manager
• You will install Teamcenter later using Deployment Center.
Click Update Selected Applications.
9. In the Components task, one key manager server and one key manager satellite component is
listed.
• If you have additional machines requiring satellites and selected Distributed in the Options task,
click to add a satellite for each additional machine. Satellites are required for each machine
requiring cryptographic services, such as machines with two-tier rich clients and Dispatcher.
• If you plan to deploy a secondary key manager server, add a secondary server to the list.
• If you are installing Teamcenter and have the Server Manager component checked, ensure that
a Key Manager satellite is installed on the server manager machine.
10. Bring each component to a 100% complete status by supplying any remaining required settings for
each. With a component selected, move your cursor over fields in the right pane for tips on
entering setting values for that component and the machine on which it will be deployed. Values
will all be verified during deployment of the component. Be aware of the following items:
• When setting a value for PKCS#11 Configuration Type, Default Network Security Services
(NSS) is delivered with Teamcenter Key Manager. Selecting Customized Network Security
Services (NSS) or Hardware Security Module (HSM) requires that those security systems are
already installed at your site. Primary and secondary key manager servers must use the same
PKCS#11 configuration type.
• The Default Network Security Services (NSS) PIN can contain numbers, letters, and special
characters.
• Record PINs, passwords, and other values for later reference.
11. In the Deploy task, generate the installation scripts. Review the Deploy Instructions information
related to the generated installation scripts.
12. Follow the steps in Run the deployment scripts in the Deployment Center help collection to run the
deployment scripts for the primary server and satellites.
• Do not run the deployment script for a secondary key manager server until the primary key
manager server and satellites are deployed and running. Deploying a secondary server requires
that the primary server has already been deployed. See Installing a secondary Teamcenter Key
Manager server for more details.
• If you selected Distributed in the Options task and are deploying multiple satellites, deploy the
Teamcenter Key Manager server before deploying satellites. Attempting to deploy satellites
before deploying the server will fail.

© 2021 Siemens
If you selected Single Box in the Options task, the Teamcenter Key Manager server will
automatically deploy before the satellite.
• Record the key manager and satellite installation directories for use during Teamcenter
installations on each machine requiring Teamcenter Key Manager.
13. If you are deploying Teamcenter Key Manager on Linux as a user without root privileges, log on as
a user with root privileges and run the following scripts from the Teamcenter Key Manager
installation directory ($INSTALL_DIR) for each server and satellite deployment:
Teamcenter Key Manager server:

$INSTALL_DIR/KeyManagerServer/root_post_tasks_key_manager_server<id>.ksh
$INSTALL_DIR/KeyManagerServer/root_post_tasks_key_manager_ca_server<id>.ksh
$INSTALL_DIR/KeyManagerServer/root_post_tasks_key_manager_admin<id>.ksh
Teamcenter Key Manager satellites:
$INSTALL_DIR/KeyManagerSatellite/root_post_tasks_key_manager_satellite<id>.ksh
14. Teamcenter Key Manager servers and satellites run as services on Windows, and are started
automatically. Ensure the services were successfully started as part of the deployments. If they are
not running, start them using the steps in Starting and stopping Teamcenter Key Manager
services.
On Linux, Teamcenter Key Manager servers and satellites run as daemons that may need to be
started manually if Java is not installed on the local machine. Ensure the following daemons are
started. If necessary, start them as described in Starting and stopping Teamcenter Key Manager
daemons.
• rc.key.manager.ca.server.<your_env_name>
• rc.key.manager.admin<your_env_name>
• rc.key.manager.satellite.<your_env_name>
• rc.key.manager.server.<your_env_name>
Establish SSL certificates
To provide keys and perform cryptography for programs running in the distributed Teamcenter
environment, Teamcenter Key Manager is itself a separate distributed client-server system in which the
client and the server trust each other using a PKI infrastructure.
As part of the installation of the key manager server and key manager satellites, certificates were
generated that can be trusted by Teamcenter Key Manager.

© 2021 Siemens
Installing a secondary Teamcenter Key Manager server
Installing Teamcenter Key Manager for use with Multi-Site Collaboration
To support Multi-Site Collaboration file transfers, keys must be available on both sites.
Installing a secondary Teamcenter Key Manager server

When using Teamcenter Key Manager for cryptographic services, you can optionally install a secondary
key manager server for redundancy and failover purposes. The primary key manager server and
satellites must be installed and running before the secondary server can be installed.
The secondary key manager server must be installed on a different machine than that on which the
primary key manager server is installed.
Generate the secondary key manager server deployment script
If you have already generated a deployment script for your secondary key manger server as described in
Installing Teamcenter Key Manager, proceed to Install the secondary key manager server. Otherwise,
generate your secondary server script using the following steps.
The secondary key manager server is installed and deployed using Deployment Center. See the
Hardware and Software Certifications knowledge base article on Support Center to verify the version of
Deployment Center required to install and deploy the secondary key manager server.
1. Download the Teamcenter Foundation software kit from Support Center and place it in the
Deployment Center software repository.
2. Log onto Deployment Center and click the Software Repositories tile to view the Teamcenter
Foundation software kit, verifying its availability in the software repository.
3. Click the Environments tile to display the environments scanned by Deployment Center. Choose
the environment in which the primary key manager server has been installed.
4. In the Components task, the key manager server and key manager satellite components are listed
and shown to be 100% complete. Click , check Key Manager Secondary Server, and click
Update Selected Components.
5. Bring the secondary server component to a 100% complete status by supplying any remaining
required settings. Values will all be verified during deployment of the component.
• Set the PKCS#11 Configuration Type value to be the same as that set for the primary key
manager server.
• If your site is using hardware security modules (HSM), the secondary server must use a different
HSM server than that used by the primary server. Alternately, one server can be configured to
use an HSM server and the other server can be configured to use the default Network Security
Services or customized Network Security Services.

© 2021 Siemens
Install the secondary key manager server
Note:
These installation steps require the primary key manager server be disabled during the
deployment of the secondary server installation script. Schedule the timing of this process to
minimize impact at your site.
1. On the machine running the primary key manager server:
• Stop the key manager server.
• Start the Teamcenter Key Manager root certificate authority server if it is not running.
• Start the Teamcenter Key Manager Administration application if it is not running.
See Starting and stopping Teamcenter Key Manager services for instructions on starting and
stopping servers and applications on Windows. See Starting and stopping Teamcenter Key
Manager daemons for instructions on starting and stopping servers and applications on Windows.
secondary server deployment script.
3. The secondary key manager server runs as a service on Windows that is started automatically.
Ensure the Teamcenter Key Manager Server service was successfully started as part of the
deployment. If it is not running, start it using the steps in Starting and stopping Teamcenter Key
Manager services.
On Linux, the secondary key manager server runs as a daemon that may need to be started
manually if Java is not installed on the local machine. Ensure the rc.key.manager.server daemon
is started. If necessary, start it as described in Starting and stopping Teamcenter Key Manager
daemons.
Ensure the Teamcenter Key Manager Administration application remains running on the secondary
server at all times. (As it is read-only, leaving it running does not create a security risk.)
4. On the machine running the primary key manager server:
• Restart the key manager server. The secondary key manager server will automatically begin
synchronizing with the primary server.
• Stop the Teamcenter Key Manager root certificate authority server.

© 2021 Siemens
Key Manager administration
• Stop the Teamcenter Key Manager Administration application.
See Managing a secondary key manager server for more information on working with your secondary
key manager server.
Administering Teamcenter Key Manager
Key Manager administration
Manage keys, certificates, and policies using the web-based Teamcenter Key Manager Administration
application. Key Manager Administration is a web service or daemon that, for security purposes, is not
running by default.
Use care when managing keys, certificates, and policies. Changes have broad impact, affecting users
across the Teamcenter site.
Starting the Key Manager administration application web service or daemon
The process for starting the administration application is the same for the primary key manager server
as it is for the secondary key manager server. On the appropriate machine, start the service or daemon
as follows:
Windows service:
Start the Windows service using the Windows Services application. Its name has the following form:
"Teamcenter Key Manager Admin Web <your_chosen_environment_name>"

Linux daemon:
From the server machine console, navigate to the Teamcenter Key Manager server installation
directory: $INSTALL_DIR/KeyManagerServer/
Run:
key_manager_admin -start
Though you can leave the web service or daemon running on the primary server, for security purposes,
you may wish to just run it when you have an actual need to use Key Manager Administration. The
administration web service or daemon must remain running on the secondary server. (As keys and
policies cannot be changed on the secondary server, doing so is not a security risk.)
Running the Key Manager Administration application
Once the service or daemon is running, open the Teamcenter Key Manager Administration application
by navigating to the following URL and entering the key manager administrator password:

© 2021 Siemens
https://<hostname>:<admin_web_server_port>
• <hostname> is the name of the machine on which the Teamcenter Key Manager Administration web
service is running.
• <admin_web_server_port> is 8204 unless changed when providing the Key Manager Server
Component settings.
• The password is the one specified in Deployment Center for Key Manager Administrator Password
when providing the Key Manager Server Component settings.
Note:
The first time you connect to the Key Manager Administration application, your browser may not
authorize the self-signed CA Root certificate generated during the Key Manager installation. If so,
follow your browser's specific steps for adding the security certificate to its store of trusted Root
Certificate Authorities. These steps typically involve viewing the self-signed certificate, copying or
exporting the certificate to a file, and then importing that certificate to your trusted Root
Certificate Authorities store.
Once you have signed in, the Key Manager Administration application opens to the Policies tab as
shown in the following example:

© 2021 Siemens
Managing policies
Managing policies
Key management policies control the manner in which keys are accessed and managed. Policies are
defined for different uses of Teamcenter Key Manager by different Teamcenter components. Policies are
uniquely identified by the component name in a hierarchical manner as follows:
Secret key policies

• Teamcenter
• Teamcenter.CredToken
Message digest (hashing) policies
• Teamcenter
• KeyManager.AdminWeb.Login
The Teamcenter Key Manager server performs and restricts requests based on these policies.
Separate types of policies are defined depending on the type of cryptography process. Each component
may or may not use each of these types of processes, and may or may not define a component-specific
policy for the process. If a component has no explicit policy defined for the process, the policy of the
component’s hierarchical parent is used for the request if possible. For example,
• If a component attempts to use a policy named "Teamcenter.ABC", and that policy is not defined in
Key Manager, the parent policy "Teamcenter" is used.
• If a component attempts to use a policy named "NX", that policy is not defined in Key Manager, and
there is no parent policy, an error is generated.
Key Manager supports symmetric encryption and hashing processes.
Create and manage your site's policies on the Policies tab of the Teamcenter Key Manager
Administration application. Click the Policies tab to view a list of all of the defined policy instances
sorted by component name.
Viewing a policy's details
On the Policies tab, each of the site's policies are listed. Click on a policy to view details about the policy.
The list is updated after any policy change.
Creating a policy
1. With no policy selected, click Add Policy .
2. Several settings are displayed for you to specify the details of the policy. Select either Secret Key or
Message Digest depending on the type of policy you are creating.

© 2021 Siemens
Specify the settings for the policy. Hover over the settings for descriptions and formatting
requirements for values. You can cancel your policy creation at any time by clicking Close.
3. When you have finished specifying the settings, click Add Policy to save the new policy. (Add
Policy is not available until all required setting values are specified.) The new policy is added to the
list of policies.
Editing and deleting policies
On the Policies tab, click on the policy in the you want to edit or delete.
To edit a policy, click Edit Policy and change the settings.
You can delete policies that have no active keys generated against them. You cannot delete the policies
delivered with Key Manager. Click Delete Policy to delete the policy.
Managing secret keys
Manage your site's keys on the Secret Key tab of the Teamcenter Key Manager Administration
application. Click the Secret Key tab to view a list of current and expired keys in the key store organized
by component. Components can be expanded and collapsed. Click Filter limit the types of keys listed:
• All Keys lists all keys in the secure store.
• Latest Keys lists only keys currently used for encryption and decryption for each component.
• Active Keys lists all keys that have not expired, including the most current keys and keys that may be
used for decryption.
• Expired Keys lists keys that could be archived or deleted as they are no longer used for encryption or
decryption.
Select a key to view its details.
Creating a key
You cannot manually create a key with the Key Manager Administration application. New keys are
generated on demand according to policy settings. Keys can also be imported.
Exporting a key
Exchanging keys between Teamcenter sites is necessary when the sites exchange data. When exporting
a key for use on a target key manager system, the key value is encrypted with a wrapping certificate
created on that target system. This requires that a public certificate exists in the exporting key manager
system's secure store. Before exporting a key from your system, export a wrapping certificate from the

© 2021 Siemens
Managing secret keys
target system and import that certificate into your key store using the procedures in Managing
certificates.
Select the key to export and click Export Secret Key
Select a wrapping certificate created by the target system and save the exported key to an accessible
directory.
Importing a key
Importing a key reads the definition of a key from a file exported by another key manager system and
stores the key and attributes in the local secure store. To import a key exported from another system,
you must first have provided the exporting system with a wrapping certificate in which the key is
wrapped when exported. The imported key is decrypted using the private key corresponding to the
certificate with which the key was wrapped and exported.
With no key selected, click Import Secret Key . Use Choose File to locate and open the key on your
file system and click Choose File to import the key into the key store.
Deactivating (rolling over) a key
A key rolls over with a new key being generated when the old key's key lifetime is reached. You can also
manually roll over keys that have been compromised or for which you have another reason for wanting
a new key.
Select the key to be rolled over. Click Roll Over and confirm the key deactivation.
The key is deactivated, a new key is generated, and the new key is used for future encrypting. The rolled
over key is retained for future decrypting.
Archiving keys
Archiving a key removes it from the key store. Only expired keys can be archived. Archived keys can be
reimported if needed at a later time.
Select the key to be archived. Click Archive Secret Key . The key is removed from the key store and
archived in the key manager server data directory:
INSTALL_DIR\KeyManagerServer\data\AdminWeb\Archive\policy_name

© 2021 Siemens
Managing certificates
Securely export and import keys in encrypted form by wrapping the key using the destination site’s
public certificate. Doing so encrypts key information with the wrapping certificate of the destination
site’s secure store. Use the following procedures to work with wrapping certificates.
Click the Certificates tab to view a list of the certificates in the key store. Click Filter limit the types of
certificates listed:
• All lists wrapping certificates of all types.
• Local Certificates lists only wrapping certificates with public-private key pairs in the secure store that
were generated on this key manager server.
• Imported Certificates lists only wrapping certificates without public-private key pairs in the key store
that were imported from other systems.
In the Certificates list, click a certificate to view its details.
Creating a wrapping certificate
With no certificate selected, click Create Certificate .
Enter the fully-qualified name of the host on which you are running the Teamcenter Key Manager
Administration application and click Create Certificate to generate and save the new certificate. The
certificate is created in the store and appears in the list of certificates.
Exporting a wrapping certificate
Exporting a wrapping certificate to another key manager system enables that site to export keys you can
then import to your key store.
Select a certificate to export, click Export Certificate , and save the exported certificate to an
accessible directory. Provide this certificate to a site that will be exporting keys to your site for import.
Importing a wrapping certificate
Importing a wrapping certificate from another key manager system enables you to use the certificate to
export keys to that key manager system.
1. With no key selected, click Import Certificate .
2. Enter the fully-qualified name of the host of the certificate in the Subject CN field.

© 2021 Siemens
Managing a secondary key manager server
3. Use Choose File to locate and open the certificate on your file system. Click Upload to import the
certificate into the store.
Deleting a wrapping certificate
Click on a certificate. Click Delete Certificate to delete the certificate from the store.
Managing a secondary key manager server
When both your primary and secondary key managers are running, changes made on the primary server
are automatically synchronized with the secondary server. To account for possible network anomalies or
other communication interruptions, the secondary server periodically performs a full synchronization
with the primary server.
Teamcenter satellites typically communicate with the primary key manager server to share keys and
perform cryptography for features and applications. In the event communication with the primary
server is interrupted, satellites automatically begin communicating with the secondary server.
Communication with the secondary server continues until the primary server becomes available.
Monitor the current state of data on the secondary server by running the Teamcenter Key Manager
Administration application. On the secondary server, the Teamcenter Key Manager Administration
application gives a read-only view of the encryption keys and policies being managed by Teamcenter
Key Manager. Run the Teamcenter Key Manager Administration application on the primary server to
modify any keys or policies.
Manage your secondary key manager server using the following processes:
Manually synchronizing servers
The secondary server periodically performs a full synchronization with the primary server to ensure all
changes on the primary server are reflected on the secondary server. Force a manual synchronization
with the secondary key manager server as follows.
1. Run the Teamcenter Key Manager Administration application on the primary server.
2. Click Synchronize . The primary server is synchronized with the secondary server.
Changing the interval for fully synchronizing
By default, the secondary key manager is fully synchronized with the primary server every 1,200
seconds. To change this interval, adjust the value assigned to
KEY_MANAGER_SERVER_PERIODIC_SYNC_INTERVAL in the following file on the primary key manager
server:
%INSTALL_DIR%\KeyManagerServer\config\key_manager_server.properties

© 2021 Siemens
After changing the value, restart the primary key manager server process or daemon.
Viewing satellite logs
Teamcenter satellites log connection data to the following log file on the satellite machine:
%INSTALL_DIR%\KeyManagerSatellite\logs\KeyManager\process\KeyManager.log
Viewing server connection logs
Synchronization and server connection issues are logged to the following file on the primary key
manager server machine:
%INSTALL_DIR%\KeyManagerServer\data\Synchronize\<machine_name>_sync.txt
Back up Teamcenter Key Manager data files
For sites configured to use the default network security services (NSS), data related to Teamcenter Key
Manager operation is stored in the following Teamcenter Key Manager server machine installation
directory. Ensure that you regularly back up the data in this directory as part of your site's broader
backup and recovery plans.
$INSTALL_DIR\KeyManagerServer\data
Having a recent backup of this directory will aid in reestablishing your Teamcenter Key Manager
installation in the case of a broader system data loss.
Sites using hardware security modules or custom NSS should back up their site's data as appropriate.
Starting and stopping Teamcenter Key Manager services
On Windows, Teamcenter Key Manager servers and satellites run automatically as Windows services.
You can start, pause, and stop the following services as necessary using the Windows Services
application. The services are named as follows:
Teamcenter Key Manager server (primary and secondary)

Teamcenter Key Manager Server <your_chosen_environment_name>
Teamcenter Key Manager satellite
Teamcenter Key Manager Satellite <your_chosen_environment_name>
Teamcenter Key Manager Administration application
Teamcenter Key Manager Admin Web <your_chosen_environment_name>
Teamcenter Key Manager root certificate authority server

© 2021 Siemens
Starting and stopping Teamcenter Key Manager daemons
Teamcenter Key Manager CA Server <your_chosen_environment_name>
Starting and stopping Teamcenter Key Manager daemons
On Linux, Teamcenter Key Manager servers and satellites run as daemons. Running these scripts
requires root access. The server and satellite scripts are located in the following Teamcenter Key
Manager installation directories respectively:
• $INSTALL_DIR/KeyManagerServer/
• $INSTALL_DIR/KeyManagerSatellite/
Each script has the following form:
script_name {-status | -start | -stop | -h}
Where
script_name
The script related to a particular daemon:
• key_manager_server
Controls rc.key.manager.server.<your_env_name>, the Teamcenter Key Manager server
daemon (primary and secondary servers).
• key_manager_ca_server
Controls rc.key.manager.ca.server.<your_env_name>, the Teamcenter Key Manager Certificate
Authority server daemon.
• key_manager_admin
rc.key.manager.admin.<your_env_name>, the Teamcenter Key Manager Administration
application daemon.
• key_manager_satellite
rc.key.manager.satellite.<your_env_name>, the Teamcenter Key Manager satellite daemon.
-status
Displays the related daemon's current status.
-start
Starts the related daemon.
-stop
Stops the related daemon.
-h

© 2021 Siemens
Displays help for the script.
Unresponsive Teamcenter Key Manager satellite daemons
If a Teamcenter Key Manager satellite is not shut down properly on a Linux machine prior to a reboot,
related Teamcenter applications connecting to the satellite may experience a hang (become
unresponsive or unable to connect to the satellite). This may occur because a named pipe that is deleted
during a proper shutdown has not been deleted. When the Key Manager satellite restarts, it cannot
create a new named pipe due to the existence of the old named pipe.
Manually delete the named pipe using the following steps:
1. Stop the Key Manager satellite.
2. Locate the old named pipe. The named pipe is defined with the KEY_MANAGER_PIPE property in
KeyManagerSatellite.properties. The default location for the named pipe is /tmp/tctp.
3. Delete the old named pipe.
4. Restart the Key Manager satellite.
5. Run the following command from the Key Manager satellite installation directory to verify that Key
Manager is functioning properly:
%INSTALL_DIR%\KeyManagerSatellite\key_manager_client_test_connection
Installing and uninstalling Teamcenter Key Manager services
Teamcenter Key Manager server and satellites run as services on Windows. If you need to manually
uninstall or reinstall the services, run the following batch files located in the local Teamcenter Key
Manager installation directory (INSTALL_DIR).
Uninstall the key manager server service

%INSTALL_DIR%\KeyManagerServer\uninstall_key_manager_server_as_windows_service.bat
Uninstall the key manager satellite service
%INSTALL_DIR%\KeyManagerSatellite\uninstall_key_manager_satellite_as_windows_service.bat
Install the key manager server service
%INSTALL_DIR%\KeyManagerServer\install_key_manager_server_as_windows_service.bat
Install the key manager satellite service
%INSTALL_DIR%\KeyManagerSatellite\install_key_manager_satellite_as_windows_service.bat

© 2021 Siemens
Granting group access to a Teamcenter Key Manager satellite
Granting group access to a Teamcenter Key Manager satellite
By default, the Teamcenter Key Manager satellite can only be accessed by the operating system user
that starts Key Manager satellite on the workstation. This user is typically the same operating system
user that installs Key Manager satellite.
When Teamcenter Key Manager is enabled, for example, Key Manager satellite access is necessary to
execute Teamcenter utilities on the satellite workstation. To allow additional users to execute
Teamcenter utilities on the workstation, these users must be added to an operating system group that is
granted access to Key Manager satellite using Deployment Center.
Use the following procedure to grant permissions to other users to access the satellite. These steps must
be performed by the user that installed Key Manager on the satellite workstation.
1. Create or use an existing operating system group containing the users that are to be granted group
access to the Key Manager satellite.
2. Log onto Deployment Center.
3. Click the Environments tile to display the environments scanned by Deployment Center. Select the
environment with the Key Manager satellite installed.
4. Click the Deploy Software tab. In the Components task, choose the Key Manager Satellite
component.
5. In the Options task, click Show all parameters and navigate to Group Permission Setting. Check
Enable Group Permission? and enter the name of the operating system group containing the
users requiring access.
deployment scripts for the satellite.
8. If you are deploying Teamcenter Key Manager on Linux as a user without root privileges, log on as
a user with root privileges and run the following script from the Teamcenter Key Manager
installation directory ($INSTALL_DIR):
$INSTALL_DIR/KeyManagerSatellite/
root_post_tasks_key_manager_satellite<id>.ksh
9. The Teamcenter Key Manager satellite is run as a services on Windows, and is started
automatically. Ensure the service was successfully started as part of the deployment. If it is not
running, start it using the steps in Starting and stopping Teamcenter Key Manager services.

© 2021 Siemens
The Teamcenter Key Manager satellite is run as a daemon that may need to be started manually if
Java is not installed on the local machine. Ensure the following daemon is started. If necessary,
start it as described in Starting and stopping Teamcenter Key Manager daemons.
rc.key.manager.satellite.<your_env_name>

© 2021 Siemens
18. Updating property values in bulk
Process for updating property values in bulk
You can update the values of object properties in your Teamcenter database in bulk using the
tc_attribute_bulk_update utility. This utility replaces the previous method for updating property values
in bulk, which entailed using the attribute_export utility to export the property values and the
tcxml_import utility to import the updated property values into the database.
Tip:
You can also use live updates to update property values.
Use the tc_attribute_bulk_update utility to:
• Query for the objects that satisfy the conditions specified through condition property name/property
value pairs.
• Provide new values for the properties to be updated on the found objects.
• Export the data to a TC XML file.
• Import the data from the TC XML file into the database.
The scope of your bulk updates can range from changing a few values on a few properties (simple) to
changing many values on all properties throughout the database (complex). The scope of your planned
update determines which format to use to provide query criteria and replacement values to the
tc_attribute_bulk_update utility.
• Simple updates
Use this method when updating a few values on a small number of properties for a few object types.
Example:
The designers at Manufacturing, Inc. create two new colors for their spinning widgets and
discontinued another color. Accordingly, their Teamcenter administrator must add the
slide_green and twisting_turquoise values to the color property on the widget_spin object
and remove the boring_brown value.
Specify the condition property name/property value pairs and update property name/property value
pairs for the utility. Optionally, you can also specify an operator for condition property name/property
value pairs.
-cond_prop
-cond_value

© 2021 Siemens
-update_prop
-update_value
-cond_operator
• Complex updates
Use this method when changes to your business practices require sweeping changes to existing
property values throughout the database.
Example:
At Acme Company, every workspace object includes Division as a required property. Valid
Division values are the different business divisions of Acme. A reorganization changes the list
of existing business divisions significantly and creates new subsectors. Acme’s Teamcenter
administrator must update the Division values on every workspace object in the database.
Create an XML input file to specify property name/property value pairs to query for the objects to be
updated, and then specify property name/property value pairs to update the found objects.
Using the tc_attribute_bulk_update utility arguments to update

property values in bulk
When performing a simple update using the tc_attribute_bulk_update utility (updating a few values on
a small number of properties on a few different object types), use the command line arguments to
provide the query/update information.
You must use a combination of the -type argument and condition property name/property value pairs,
along with update property name/property value pairs to:
value pairs.
• Export the data to a TC XML file.
• Query arguments
These arguments are the equivalent of the WHERE clause in an SQL phrase. They identify the property
type, property names, and property values to be queried.
-type
-cond_prop
-cond_value
-cond_operator (optional)
The two condition property name/property value arguments must always be used in conjunction with
the update property name/property value arguments.

© 2021 Siemens
Using the tc_attribute_bulk_update utility arguments to update property values in bulk
• The -type argument specifies the object type to be updated, such as item, dataset, or
StructureContext.
This argument accepts only a single value. You can use multiple instances of this argument to
specify multiple object types. Each instance must be paired with the -cond_prop and -cond_value
arguments.
• The -cond_prop argument specifies the internal name of the property to be queried for, as opposed
to the display name.
This argument accepts multiple values in a comma-separated list. Each value must be a valid
property on a Teamcenter object. For example:
-cond_prop=object_name,last_mod_date
You can use multiple instances of this argument, but it must always be paired with the -
cond_value argument.
• The -cond_value argument specifies the current value of the property specified by the -cond_prop
argument.
-cond_value=TextData_es_ES,"01-DEC-2011 00:00"
You can use multiple instances of this argument, but it must always be paired with the -cond_prop
argument.
• You can use the -cond_operator argument to specify an operator to be used with the -cond_prop
and -cond_value arguments.
This argument must be placed after the -cond_prop and -cond_value arguments and accepts the
following values:
EQ Equal
NE Not equal
GT Greater than
GE Greater than and equal
LT Lesser than
LE Lesser than and equal
For example:
-cond_prop=object_name -cond_value="My obj #1"

-cond_prop="last_mod_date"
-cond_value="01-DEC-2011 00:00" -cond_operator="LE"
-cond_prop="last_mod_date"
-cond_value="01-DEC-2010 00:00" -cond_operator="GE"

© 2021 Siemens
• Update arguments
These arguments are the equivalent of the UPDATE clause in an SQL phrase. They identify the
property names and values to be updated.
-update_prop
-update_value
Update property name/property value pairs must always be used in conjunction with the condition
property name/property value pairs.
• The -update_prop argument specifies the internal name of the property to be updated (as opposed
to the display name), for example, object_desc, char VLA, and so on.
-update_prop=object_name,object_desc
You can use multiple instances of this argument. Each instance of this argument should be paired
with the -update_value argument.
• The -update_value argument specifies the new value for the property specified by the -
update_prop argument.
This argument accepts multiple values in a comma-separate list. For example:
-update_value=folder,"Home folder"
You can use multiple instances of this argument. Pair each instance of this argument with the -
update_prop argument.
The following examples illustrate the use of the condition property name/property value pairs and
update property name/property value pairs with the tc_attribute_bulk_update utility:
• To update prop3 to value3 and prop4 to value4 for type1 objects (when prop1 equals value1 and
prop2 is greater than value2) in batches of 400, enter a command with the following form on a
single line:
tc_attribute_bulk_update -u=tc-admin-user -pf=d:\password.txt -g=group

-type=type1 -cond_prop=prop1 -cond_value="value1"
-cond_prop=prop2 -cond_value="value2" -cond_operator="GT"
-update_prop=prop3 -update_value="value3"
-update_prop=prop4 -update_value="value4"
-batchsize=400
• To update an object description to blue Desc and the int_VLA to 10,3,0,99 for all datasets where the
object_name property is TextData_es_ES and the last_mod_date property is 01-DEC-2011 00:00 or
greater, enter the following command on a single line:

© 2021 Siemens
Using an XML input file to update property values in bulk
tc_attribute_bulk_update -u=tc-admin-user -p=password -g=group

-type=Dataset -update_prop=object_desc -update_value="blue Desc"
-update_prop="int_VLA" -update_value="10,3,0,99"
-cond_prop=object_name -cond_value="TextData_es_ES"
-cond_prop="last_mod_date" -cond_value="01-DEC-2011 00:00"
-cond_operator="GE"

When performing a complex update using the tc_attribute_bulk_update utility (updating many values
on many properties throughout the database), use an XML input file to provide the query/update
information with the -inputfileargument. The input file is a more efficient format for listing lengthy
update instructions than using the command line arguments.
You must use a combination of condition property name/property value pairs and update property
name/property value pairs to:
value pairs.
Structure the file as a series of UpdateSets entries. Each update set must contain type, condition, and
update components. The following sample XML file illustrates the required sequence of the XML
components, first type, then where, and then update.
<?xml version="1.0" encoding="utf-8"?>

<BulkUpdate>
<UpdateSets>
<UpdateSet>
<type name = "item" />
<where>
<cond_prop attrName = "int_single" attrValue = "50" cond_operator = "<=" />
<cond_prop attrName = "string attr" attrValue = "Wed, Mon, Sat, Tue" />
<cond_prop attrName = "last_mod_date" cond_operator = ">" attrValue =
"01-DEC-2011 00:00"/>
</where>
<update>
<update_prop attryName = "object_desc" attrValue = "red Desc"/>
<update_prop attryName = "intVLA" attrValue = "10,20,0,9,7"/>
<update_prop attryName = "some_VLA_property" attrValue =
"value1,value2,value3"/>
</update>
</UpdateSet>
</UpdateSets>
</BulkUpdate>

© 2021 Siemens
Note:
There is no required sequence within the cond_prop component for the attrName, attrValue,
and cond_operator components.
• Type component
This component specifies the object type to be updated, such as item, dataset, or StructureContext.
This component accepts only a single value.
• Condition components
These components are placed in the <where> section of the update set. They identify the property
names and values to be queried.
cond_prop
cond_value
cond_operator (optional)
• The cond_prop component specifies the internal name of the property to be queried for, as
opposed to the display name.
This component accepts multiple values in a comma-separated list. Each value must be a valid
cond_prop=object_name,last_mod_date
You can use multiple instances of this component, but it must always be paired with the
cond_value component.
• The cond_value component specifies the current value of the property specified by the cond_prop
component.
cond_value=TextData_es_ES,"01-DEC-2011 00:00"
You can use multiple instances of this component, but it must always be paired with the
cond_prop component.
• You can use the cond_operator component to specify an operator to be used with the cond_prop
and cond_value components.
This component accepts the following values:
= Equal
!= Not equal
> Greater than
>= Greater than and equal

© 2021 Siemens
< Lesser than

<= Lesser than and equal
For example:
<where>
<cond_prop attrName =
"int_single" attrValue = "50" cond_operator = "<=" />
<cond_prop attrName = "string_attr" attrValue = "Wed, Mon, Sat,
Tue" />
<cond_prop attrName =
"last_mod_date" cond_operator = ">" attrValue =
"01-DEC-2011" />
</where>
• Update components
These components identify the property names and values to be updated.
update_prop
update_value
• The update_prop component specifies the internal name of the property to be updated (as
opposed to the display name), for example, object_desc, char VLA, and so on.
update_prop=object_name,object_desc
You can use multiple instances of this component. Each instance of this component should be
paired with the update_value component.
• The update_value component specifies the new value for the property specified by the
update_prop component.
This argument accepts multiple values in a comma-separate list. For example:
update_value=folder,"Home folder"
You can use multiple instances of this component. Each instance of this component should be
paired with the update_prop component.
The input file supports the following persistent properties:
• Single-value properties
• Array properties
• Fixed length array

© 2021 Siemens
• Variable length array (VLA)
Performance statistics
You can estimate the duration of your bulk update gathered on the following performance statistics,
based on custom ADSPart objects.
Custom attribute_expor tcxml_import in Total time

ADSParts t in seconds seconds in seconds
169 11.261 13.115 24.376
602 28.001 27.569 55.57
1,356 52.338 73.519 125.857
9,570 318.393 687.489 1,005.882
29,241 954.282 1,522.68 2,476.962
The statistics are based on the following setup:
• Oracle database running on machineA.
• Teamcenter server running on machineB.
• CPU speed: 3 GHz
• CPU type: Intel Pentium 4 CPU 3.00GHz
• Memory: 2 GB
• Both machineA and machineB are on a LAN network.
• The UGII_CHECKING_LEVEL environment variable is set to 0.
Best practices for updating property values in bulk

Siemens Digital Industries Software recommends observing the following best practices:
• Do not perform this operation when users are accessing Teamcenter data. If objects specified for
update are locked by other processes, the update process is impacted.

© 2021 Siemens
Best practices for updating property values in bulk
• To determine all the current values of attributes you plan to update, with the
tc_attribute_bulk_update utility, use the -untransformed switch with either the -inputfile argument
containing only condition property/value entries (no update entries) or the -cond_prop and -
cond_value arguments.
• To validate the schema of the XML input file, use the -performSchemaValidation switch.
If the schema is invalid, the following information is added to the log file:
Error: attributeUpdateSchemaValidator: XML Exception

during schema file validation.
If the schema is not found, the following information is added to the log file:
Error: AttributeUpdateSchemaValidator: Unable to find schema

file for validation.
• To confirm the updates were made as expected, specify an output directory with the -outdir
argument so that you can review the output log.
• Because extensive updates are time-consuming, Siemens Digital Industries Software recommends you
determine the following before performing a complex bulk update of property values:
• Affected targets
Run the tc_attribute_bulk_update utility with the -queryonly switch to determine the number of
target objects affected by the proposed update. When you specify this switch, the utility does not
perform the update, it merely reports the number of affected objects.
This switch outputs the number of target objects affected by the specified update parameters to a
log file. If the number of objects is less than 100, the object UIDs are included in the log file.
Use this switch in conjunction with either the input file or the condition and update arguments to
determine how many objects are affected by the specified update operation. You can use the
resulting information to determine batch size and to estimate the duration of the update operation.
• Duration
To estimate the duration of various update operations, see the performance tables. If the estimated
time is considerable, there are three methods for managing the operation duration.
■ Run the tc_attribute_bulk_update utility with the -batchsize argument to specify the number
of objects to update in each batch operation per TC XML file.
The default batch size is 500. This is also the maximum batch size.
■ Run the tc_attribute_bulk_update utility with the -islandsize argument to specify the number
of islands to update in each operation. Islands tie logically related objects together. The data in
low-level TC XML is grouped into an island by closure rules.
The default size is 100.
■ Manage the number of objects processed per update by running multiple updates constrained by
dates. The updates can be run in parallel. For example:

© 2021 Siemens
◊ First update

-cond_operator="LT"
◊ Second update

-cond_operator="LE"
-cond_operator="GE"
◊ Third update

-cond_operator="GT"

© 2021 Siemens
19. Configuring Teamcenter for
performance
Configuring the four-tier architecture for performance
Techniques for improving four-tier performance
It can be useful to configure the Teamcenter four-tier architecture for optimum performance. The
default settings for application servers are rarely appropriate for production scalability or good
transactional performance.
Techniques for improving four-tier performance include:
• Disable the display of the checked-out symbol that displays to the right of each Teamcenter object. It
is a quick indicator of whether the object is checked out. When an object is checked out, another user
has exclusive access to it, preventing you from making changes to the object until it is checked in.
Set the TC_show_checkedout_icon preference to True to display the symbol and enhance usability
or to False to hide the symbol and improve rich client startup performance.
• Determine whether your virus scanner monitors all HTTP communications from the host. Because
Teamcenter four-tier clients (such as the rich client, and NX) use HTTP to communicate with the web
tier, such scanning negatively impacts performance.
Deactivate this functionality, or configure your virus scanner to ignore communications from the web
tier.
• Size the server pool appropriately. The pool-specific parameters are set in the serverPooldatabase-
name.properties file in the TC_ROOT\pool_manager\confs\configuration-name\ directory.
Managing server memory
Introduction to managing server memory
Objects loaded on the Teamcenter server remain in the server memory throughout the session. If
unused objects are not removed, long-running sessions generate significant memory usage which can
cause memory errors.
To avoid these errors, Teamcenter provides automatic cleanup of unused objects. The default
configuration of the memory cleanup operation unloads unused objects from the server in the order
they were last accessed. The least recently accessed objects are unloaded first. The operation begins
when the memory server size reaches 12,000 KB, and stops when the memory server size reaches 5,000
KB.
This default configuration of memory cleanup behavior is sufficient for most sites. The default settings
are not optimal when:

© 2021 Siemens
19. Configuring Teamcenter for performance
• Users work with very large assemblies.
• All sessions are short-running sessions with minimal server memory needs; therefore, the site has no
need of automatic memory cleanup.
Default automatic memory cleanup settings
Automatic memory cleanup unloads unused objects from the server in the order they were last
accessed. The least recently accessed objects are unloaded first. The default settings initiates memory
cleanup when the memory server size reaches 12,000 KB, and stops when the memory server size
reaches 5,000 KB.
You can fine-tune automatic cleanup functionality by modifying the default values of the following
preferences.
Preference Default Description

value
UNLOAD_TRIGGER_CEILING 12000 Initiates the memory cleanup operation.

Specifies (in kilobytes) what memory
size must be reached to initiate the
unloading of unused objects from the
server memory. This value must be a
positive integer higher than the value
set for the UNLOAD_TRIGGER_FLOOR
preference. If an invalid value is set, the
default value of 12000 is used.
Automatic cleanup is performed during
the operation occurring after the
specified ceiling is reached, possibly
causing the specified memory size to be
exceeded if the final loading action
uploads a large amount of data.
Setting this value very low reduces the
memory server footprint, but decreases
performance.
UNLOAD_TRIGGER_FLOOR 5000 Stops the memory cleanup operation.

Specifies (in kilobytes) what memory
size must be reached to stop the
unloading of unused objects from the
server memory after memory cleanup
begins. This value must be a positive
integer lower than the value set for the
UNLOAD_TRIGGER_CEILING

© 2021 Siemens
Default automatic memory cleanup settings

value
preference. If an invalid value is set, the

default value of 5000 is used.
Automatic cleanup continues until the
memory size specified by this
preference is achieved. However, if the
total size of unmovable object exceeds
the floor amount, the specified memory
size is not reached. For example, if
objects cannot be removed because
their life span does not meet the
requirements specified by the
UNLOAD_MINIMUM_LIFE preference,
and the memory space consumed by
these objects exceed the specified floor
size, the specified memory size is not
reached.
Determining the optimum value for this
preference requires investigation, and
possibly experimentation in a working
environment.
UNLOAD_MINIMUM_LIFE 1800 Determines which unused objects are

qualified for memory cleanup, based on
when objects were last accessed.
Specifies (in seconds) when an object
was last accessed. Objects accessed
more recently than the specified value
are not removed from server memory.
UNLOAD_LOGGING_LEVEL 0 Determines the level of detail logged in

the in-session and end-session reports
sent to the .unloadlog log file.
0 disables logging. Values 1 through 4
enable logging in progressively more
detail.
Setting this preference to 1 through 4
does not produce a log file unless the
FCC is restarted on the client, for
example:

© 2021 Siemens

value
FMS_HOME\bin\fccstat
-restart
Determining optimum performance settings for a two-tier environment
Individual users running a two-tier environment can set the UNLOAD_TRIGGER_CEILING and
UNLOAD_TRIGGER_FLOOR user preferences to best fit their individual needs.
• Users can use the default settings if they do not work with large amounts of data.
• Users can increase the value of the UNLOAD_TRIGGER_CEILING user preference if they work with
large amounts of data, such as very large assemblies. Increasing the value delays the unloading of
objects, improving performance.
Users can determine the necessary settings by estimating an average object size of .5 KB. For example,
with the UNLOAD_TRIGGER_CEILING default setting of 12000 KB, automatic unload occurs when
approximately 24,000 objects are loaded.
The 5,000 KB default setting for the UNLOAD_TRIGGER_FLOOR preference means unloading continues
until approximately 10,000 objects remain in the unloadable memory area.
These settings are adequate for most two-tier environments, including the default Teamcenter
installation running only the Foundation template.
Determining optimum performance settings for a four-tier environment
In a four-tier environment, site administrators must determine the needs of a typical user at the site and
configure the UNLOAD_TRIGGER_CEILING and UNLOAD_TRIGGER_FLOOR preferences accordingly.
To determine the optimum setting of the UNLOAD_TRIGGER_CEILING preference at your site:
• Determine the size of the free memory available before any Teamcenter server is started.
• Determine the number of users at the site accessing the server concurrently.
• Determine the size of the Teamcenter server instance (including all site customizations and
configurations) immediately after user logon.
• Divide the amount of free memory available by the number of concurrent users to determine the
average size of memory required for each user per session.

© 2021 Siemens
Disabling automatic memory cleanup
For example, if the average size of the free memory required per user session is 100 MB, and if users
typically work with assemblies containing approximately 100,000 objects, the site administrator must
increase the value of the UNLOAD_TRIGGER_CEILING preference to a minimum value of 50,000 KB,
based on an estimated average size for an object being 0.5 KB. Because the total size of free memory in
this case is 100 MB, a value between 50,000 KB and 100,000 KB is acceptable, but it should not exceed
100,000 KB to give the optimal result for all users.
Disabling automatic memory cleanup
Automatic memory cleanup cannot be disabled with a preference or with a button in the interface.
However, you can stop automatic memory cleanup from functioning at your site by either:
• Setting the UNLOAD_TRIGGER_CEILING preference very high. Setting the ceiling value near the size
of total memory essentially prevents the cleanup operations from initiating.
Siemens Digital Industries Software recommends using this method to disable automatic memory
cleanup.
• Setting the UNLOAD_MINIMUM_LIFE preference very high. Setting the length of time in which an
object must not have been accessed very high (years) prevents any objects from qualifying for
memory cleanup.
• Adding the ObjectUnloadable business object constant to the POM_object and setting the constant
to false. This setting makes all POM_object children invalid for unloading; therefore, no objects are
ever selected for automatic memory cleanup.
Server memory cleanup log files
While the Teamcenter server is running, object unloading activity is logged in a log file. At the end of the
session, a summary of the unloading operation is also logged. The data is stored in the .unloadlog file,
typically stored in the TC_TMP_DIR directory. The file contains information such as the peak/least
memory used by unloadable objects, the total number of unloaded objects, the total number of unload
operations, the average time for an unload operation, and so on.
Determine the level of detail reported to the log file by setting the UNLOAD_LOGGING_LEVEL
preference to a value between 0 and 4. Setting this preference to 0 disables logging.
Following is the data logged in the files for each logging level.
Level 0
In-session report Creates no log file.

No log information is reported.
End-session report N/A

© 2021 Siemens
Level 1
In-session report Specifies the number of objects in the cache.

Specifies the number of objects removed from the cache.
Specifies the time (in seconds) to unload the cache.
Specifies the number of objects remaining in the cache.
End-session report Specifies the peak memory used by unloadable objects for the entire
session.
Specifies the least amount of memory used by unloadable objects
for the entire session.
Specifies the total number of objects unloaded.
Specifies the total number of unloading operation requests.
Specifies the total number of actual unloading operation.
Specifies the average time of an unloading operation.
Level 2

Specifies the number of objects removed from the cache.
Specifies total memory usage of all areas (in bytes) before
unloading.
Specifies total memory usage of all areas (in bytes) after unloading.
session.
Specifies the total number of actual unloading operations.

© 2021 Siemens
Server memory cleanup log files
Level 3

Specifies the number of objects removed from cache.
Specifies total memory usage of all areas (in bytes) before unloading
and before callbacks. Usage shown by area.
Specifies total memory usage of all areas (in bytes) after unloading
Setting the UGII_CHECKING_LEVEL environment variable to 1

provides the following callback and memory usage information:
Callbacks. (Lists callbacks triggered. Specifies the time (in seconds)
callbacks took.)
Specifies memory usage of all areas (in bytes) before callbacks after
unloading. Usage shown by area.
Specifies memory usage of all areas (in bytes) after callbacks after
Specifies the time (in seconds) to complete the call.
session.
Provides a summary of unloading per type, including type name and
unload count.
Level 4
In-session report Specifies, if adding to the cache:

Object String =object string , type: type of
object, time: when it was accessed
Specifies, if removing from the cache:
Unloading Object: Object String =object string ,

© 2021 Siemens
Level 4
type: type of object, time: when it was accessed

Specifies the number of objects in the cache.
Specifies the number of objects removed from cache.
Specifies total memory usage of all areas (in bytes) before unloading
Specifies total memory usage of all areas (in bytes) after unloading
Setting the UGII_CHECKING_LEVEL environment variable to 1

provides the following callback and memory usage information:
Callbacks. (Lists callbacks triggered. Specifies the time (in seconds)
callbacks took.)
Specifies memory usage of all areas (in bytes) before callbacks after
Specifies memory usage of all areas (in bytes) after callbacks after
Specifies the time (in seconds) to complete the call.
session.
Provides a summary of unloading per type, including type name and
unload count.
Shared memory
Shared memory overview
Shared memory is a mechanism for sharing commonly used data across multiple Teamcenter processes.
The shared memory implementation is applied to all the collocated Teamcenter processes that are run
on the same machine, and the shared memory appears in the address space of all Teamcenter servers,
utility processes, and service (daemon) processes on the machine.

© 2021 Siemens
Configure shared memory
When large amounts of data need to be shared, shared memory is the fastest interprocess
communication mechanism between co-located processes. After the memory is mapped into the
address space of the processes that are sharing the memory region, the processes can access the shared
memory area like regular working memory with no overhead incurred. Because only one copy of the
data in the shared memory is resident for all the processes that are sharing the memory region, using
shared memory for common data reduces the overall system memory footprint.
Shared memory provides the following benefits:
• Reduces the memory footprint for each server process and utility process.
• Large amounts of data are loaded into shared memory. This data includes text server data, site
preference data, localized list of values data, and metadata. As a result, the private memory footprint
for a server process is reduced. For example, in a Teamcenter 9.1.2 environment, the savings in the
private memory footprint for a server process are as follows:
Text server: 6MB

Preferences: 2–4 MB
Lists of values: 5 MB
Metadata: 19MB
• Improves Teamcenter scalability

Because the private memory footprint is reduced per server, more Teamcenter servers can be
configured on the same machine than previously.
• Improves Teamcenter performance

All the shared data is populated once in shared memory and saved in local backing store files. After
backing store files are generated, all the subsequent servers do not need to populate data into shared
memory. Therefore, the logon time for all the subsequent servers is improved.
In the case of the shared metadata, the metadata cache is pregenerated (for example, during install
and upgrade). This helps to reduce further the metadata population time. As a result, there is
approximately 18% improvement in logon time.
Shared metadata memory helps to improve overall performance for other use cases as well. Each
server is able to access the already-populated shared metadata cache that would otherwise have to be
on-demand initialized by each server if shared metadata cache were not used.
Configure shared memory
Set the TC_SHARED_MEMORY_DIR environment variable to specify the root directory where the
backing store files are stored. Set this to a valid directory and do not change it. If you do not set this
environment variable on Windows systems, the directory specified by the TEMP environment variable is
used, and on Linux systems, the /tmp directory is used. On Windows systems, if the TEMP environment
variable is not specified, the C:\temp directory is used.
The shared memory root directory name is also used for making a unique semaphore name among all
the collocated Teamcenter servers. When the TC_SHARED_MEMORY_DIR environment variable is set to
a different root directory, a new semaphore with a new name is created per shared memory module.

© 2021 Siemens
Define a fixed directory for shared memory map files
Each time a process stores a shared memory map file in a new location, a new semaphore is created.
Defining a fixed directory for shared memory map files minimizes the semaphore count. This is
particularly useful on Windows if the value of your TEMP environment variable is frequently modified,
and on Linux systems because the operating system does not relinquish semaphores when processes
are complete.
1. Set the TC_SHARED_MEMORY_DIR environment variable to a valid, fixed directory.

The shared memory map files are created in a subdirectory of the directory defined by this
2. Stop the text server process (TcServer).
3. Log on as root.
4. Display the list of semaphores owned by Teamcenter by typing:
ipcs -sb |grep user-id-used-to-start-pool-manager
5. Free all the semaphores in the list by typing:
ipcrm -s ID_1... -s ID_n
ID_1 is the semaphore identifying number from the list.
The first process started after this change creates the shared memory map files and required
semaphores. All following processes use this existing information, with no need to re-create the map
files or additional semaphores.
Clean up semaphores
Shared memory functionality consumes named semaphores. On Linux platforms, the count of the used
semaphores may reach the operating system limit. In such a scenario, the following message is logged
in the Teamcenter server syslog files and the Teamcenter server reverts to its in-process memory mode.
ACE_Malloc_T<ACE_MEM_POOL_2, ACE_LOCK, ACE_CB>::ACE_Malloc_T: Not enough space
If this problem occurs, you must clean up semaphores in the following steps:
1. Ensure the system is idle.

No Teamcenter process (for example, Teamcenter server, utility process, and service process) can
be running.
2. Log on as root.
3. Display the list of semaphores owned by Teamcenter by typing the following command:

© 2021 Siemens
Introduction to shared memory for metadata
ipcs -sb | grep user-id-used-to-start-pool-manager
4. Free all the semaphores in the list by typing the following command:
ipcrm -s ID_1... -s ID_n
ID_1 is the semaphore identifying number from the list.
Shared memory for metadata
Introduction to shared memory for metadata
You can configure Teamcenter to use a shared memory cache, which reduces the memory footprint by
eliminating metadata duplication among Teamcenter servers. The following types of metadata are
stored in the shared memory cache:
• Types
• Property descriptors
• Constants
In a four-tier environment, multiple Teamcenter servers access the shared memory cache (reducing the
overall footprint of the deployment). A metadata cache file is exported and mapped to the shared
memory cache during each TcServer startup. By default, all Teamcenter servers access the shared
memory cache.
To enable shared memory for metadata, set the TC_USE_METADATA_SHARED_MEMORY environment

variable to TRUE. The metadata cache is stored within the Metadata subdirectory created within the
directory specified by the TC_SHARED_MEMORY_DIR environment variable. The metadata cache files
are stored as sequentially numbered files.
Note:
If a Teamcenter server cannot access the Metadata directory, it accesses its local metadata cache.
For example, if the system runs out of semaphores, each Teamcenter server accesses its own local
metadata cache.
Configuring the shared memory cache
You can enable shared memory cache for metadata from either Business Modeler IDE while performing
live updates or from Teamcenter Environment Manager (TEM) during installation or upgrade.
• From Business Modeler IDE, when deploying a template, select the Generate Server Cache check
box.

© 2021 Siemens
• From TEM, select the Generate Server Cache check box in the Foundation Settings panel.
Synchronizing the shared memory cache
When you create new types, property descriptors or constants in the Business Modeler IDE, the changes
made to the metadata in running Teamcenter servers must be synchronized with the database.
The synchronization is accomplished by the shared_server_metadata_cache_mgr executable. This

executable runs as a service on Windows and as a daemon on Linux. By default, the service/daemon
starts automatically. To install the daemon, in the Features panel in Teamcenter Environment Manager
(TEM), choose Server Enhancements→Database Daemons→Teamcenter Shared Metadata Cache
Service.
Two preferences manage the behavior of this executable:
• You can use the TC_shared_server_metadata_cache_mgr_cloning_interval preference to stop and

restart the service to avoid any possible memory leaks. Typically, this is not necessary. Accept the
default setting (100 minutes).
• Use the TC_shared_server_metadata_cache_mgr_sleep_minutes preference to specify how

frequently the service/daemon compares the latest metadata cache file against the database,
exporting the latest metadata cache file in the Metadata directory if changes are found, and then
mapping the file to the shared memory cache.
To force the regeneration of the cache, even though no metadata changes exist in the database, run the
generate_metadata_cache utility using the -force argument.
Shared memory for Text Server data
Introduction to shared memory for Text Server data
Shared memory functionality improves memory performance; memory consumption is reduced and
performance is increased. However, this implementation requires some administration that in-process
memory functionality does not:
• Users must manage memory mapped files when new text key-value pairs are added to the Text Server
XML files. When this occurs, all Text Server related memory backing store files must be removed.
• Administrators running on a Linux platform must manage semaphore usage.
The memory backing store files represent the persistent cache for the shared memory contents. As long
as the physical backing store file exists, the file contents are used for the Text Server shared memory
data on that machine. The initial XML text files are only read and parsed by the very first Teamcenter
server process, to populate the shared memory cache. Subsequent processes use the shared memory
technique. Updating the XML files through installation or customization requires a refresh of the shared
memory cache, which is done by removing the backing store files (its persistent representation).

© 2021 Siemens
Remove memory backing store files
Shared memory functionality consumes semaphores. Each time a process stores a shared memory map
file in a new location, a new semaphore is created. When a process reuses a location for a shared
memory map file, the same semaphores are reused.
Remove memory backing store files
If you are using shared memory and have updated your text XML files, you must refresh the shared
memory cache by removing the memory backing store files.
1. Ensure the system is idle. No Teamcenter server processes can be running.
2. Remove the memory backing store files. The TC_SHARED_MEMORY_DIR environment variable
value specifies the directory where the backing store files are stored. If you do not set this
environment variable, the TEMP environment variable (Windows) or /tmp (Linux) directory is used.
Note:
On Windows, if the TEMP environment variable is not available, the C:\temp directory is
used.
The shared memory files are created under the version/last-build-date/database-site-ID/TextSrv/

language directory located in the temporary repository. The many values of the language directory
depend on the language used by the Teamcenter server processes, which are the ones used by the
connection with Teamcenter. Server error messages and strings are saved respectively in the
emh_text.xml.mem and tc_text.xml.mem files.
At the next process startup, the system finds the shared memory state is no longer initialized, reads
the text XML files, and populates the shared memory cache, thus creating and populating the
shared memory backing store file.
Note:
You can disable shared memory functionality and revert system behavior to in-process text
storage by setting the TC_NO_TEXTSRV_SHARED_MEMORY environment variable to TRUE.
Shared memory for localized LOV data
The TC_USE_LOV_SHARED_MEMORY environment variable determines whether the Teamcenter server

loads localized LOV display names into shared memory. Set this environment variable to either TRUE or
FALSE. The default setting is TRUE.
If shared memory cannot be used, the system uses process memory. In rare instances when the system
reports a problem with shared memory and cannot fall back to using process memory, set this
environment variable to FALSE and restart the system.

© 2021 Siemens
Note:
Because localized LOV display can slow system performance, you can use the
Fnd0LOVDisplayAsEnabled global constant to disable loading localized LOV display names.
Sharing a TcServer instance with multiple applications
A TcServer instance can sometimes be shared by multiple applications on the same machine. If clients
log on with the same user from applications that use sharing, the server is shared, and the clients stay
synchronized.
While the TcServer architecture does not support threading service requests from different users, it can
support multiple sessions (client applications) for a single user. In the rich client, this sharing is enabled
by default. In a four-tier environment, whether the rich client connects to the same TcServer as other
clients on the same machine can be controlled by the shareSession property in the
site_specific.properties file. This file is stored in the following location:
Teamcenter-install-location/portal/plugins/configuration_version
• Setting the shareSession property to true enables sharing.

All rich client sessions on the client desktop to which the user logs on with the same user name share
the same instance of the Teamcenter server.
Other client applications that are also configured for session sharing, and logged on with the same
user name, also share the same instance of the Teamcenter server. Any changes in session state (for
example, a change of group or role) made for a client are reflected in the other clients.
• Setting the shareSession property to false disables sharing.

Each rich client session on the client desktop has its own dedicated instance of the Teamcenter server.
Tuning the web tier
Tuning application servers
The Teamcenter web tier manages communication between the Teamcenter clients and the enterprise
tier. Tune the web tier to ensure performance. The successful deployment of the Teamcenter web
application or Enterprise application is not complete without tuning the application server. The default
settings for application servers (for example, WebSphere, WebLogic, and so on) are rarely appropriate
for production scalability or good transactional performance.
Ensure that the applicable application server vendor tuning documentation is followed. Of critical
importance are items such as the following:
• Set any JSP or servlet check intervals to very long values.

This prevents unwanted and expensive extraction of these components from the deployed WAR files.
In some cases, application servers may be configured by default to check these upon every
invocation. That is good for a developer environment but very bad for performance.

© 2021 Siemens
Web tier monitoring
A good value is on the order of once a day or longer.
• Tune the application Java Virtual Machine (JVM) run-time parameters appropriate for high
transactional throughput (server) applications:
• Set JVM heap sizes to match the RAM available on the machine, while keeping the size to a limit
manageable by the garbage collection (GC) algorithm and the power of the CPU(s) available to
implement that algorithm. In this case, both too small and too large are potential performance
problems.
• Select the appropriate garbage collection algorithm to match the number of CPUs available to
implement it.
• Set the JVM heap generational sizes to be appropriate for the GC algorithms and available heap.
In all cases, the relevant performance tuning documentation provided by the application vendor and
Java Runtime Environment (JRE) should be consulted for optimum tuning values. Each distinct
application server has distinct configuration mechanisms. For example, the weblogic.xml file is unique
to WebLogic, and is where application JSP and servlet check intervals are specified.
Each major version of the JRE has unique Garbage Collection tuning options available.
You can use third-party applications to view web tier administration interface data in a more
comprehensive manner.
Web tier monitoring
Web tier monitoring provides notification when the following metrics reach the specified level,
indicating a critical event. Use the Teamcenter Management Console to manage the Server Manager
and the web tier.
The following metrics are defined in the webtierMonitorConfig.xml file:
Metric Description
Abandoned Servers Servers are assigned, but attempts to connect fail.
No Server Available The web tier is unable to assign a server to a user because none are
available.
Server Comm Failure A Teamcenter server closed the connection while the web tier was
waiting for a response.
Failed Login Attempts A user provided invalid credentials.

© 2021 Siemens
Metric Description
Number Pending The number of client requests for which the web tier is awaiting a
Requests response.
Long-running Requests The web tier waited longer than the specified time for a server
Current response
Long-running Request The number of requests taking longer than the specified amount of
Completed time to complete.
Grave Events Fatal or unexpected errors occurring in the web tier.
Configure web tier monitoring using the webtierMonitorConfig.xml file, located in the
deployed .war file in the lib\mldcfg.jar file.
You can revise the webtierMonitorConfig.xml file and save it back into the .war file before deployment
by the web application. Or if you prefer, you can place the revised file directly into the root directory of
the web application server’s run-time environment, and thus override the version of the file in the .war
file. For example, on WebLogic place the revised file into the domain directory, on WebSphere place it
into the profile directory, or on JBoss place it into the bin directory.
Tip:
• You should review all monitoring settings and ensure that the thresholds are set correctly for
your site.
If you do not know the optimum monitoring setting for any given critical event, then set the
value to COLLECT. Collect the data and review it to determine normal activity levels. Then set
notification values slightly higher than normal activity levels.
• The contents of the email notifications are generated from the webtierMonitorConfigInfo.xml
file. (This is a companion file to the webtierMonitorConfig.xml file.) See this file for a
complete list of possible causes and recommended actions for web tier monitoring.
The webtierMonitorConfigInfo.xml file is stored in the WAR file by default in the lib
\mldcfg.jar file. A copy can be placed on the application server’s current directory to override
the default version.
You can configure web tier metrics and logging behavior to better administer web tier processes. Use
the pref_export.xml file to enable web tier metrics. This file is stored in the WAR file by default in the lib
\mldcfg.jar file. A copy can be placed on the application server’s current directory to override the default
version.
• Use the ExtendedEnabled element to enable extended nested metrics upon reset.

© 2021 Siemens
Configure monitoring with the webtierMonitorConfig.xml file
• Use the ResponseTimeSampler element to enable sampling and logging of response times.
Configure monitoring with the webtierMonitorConfig.xml file
1. Open the webtierMonitorConfig.xml file stored in the WAR file, application sever startup
directory, or on the application server classpath (allowing settings to be tailored to a machine if
required). By default, the webtierMonitorConfig.xml file is stored in the .war file in the lib
\mldcfg.jar file.
2. On the ApplicationConfig tag, set the mode to one of the following:
• Normal
• Disable_Alerts
• Off
EmailResponder values.
• protocol
Specify the email protocol by which notifications are sent. SMTP is the only supported protocol.
• hostAddress
• fromAddress
• toAddress
addresses, separated by semi-colons.

© 2021 Siemens
• emailFormat
4. (Optional) To be notified when criteria reaches the specified threshold, specify to which file critical
events are logged by setting the following LoggerResponder values.
• logFileName
a. Specifying a particular EmailResponder.
b. Specifying a particular LoggerResponder.
c. Setting the metric monitoring mode to one of the following:
• Collect
for this metric.
• Alert
When critical events exceed the specified threshold, collect metric data, send email
notifications (set up with EmailResponder values), write messages to log files (set up with
LoggerResponder values), and display results in the server manager administrative
interfaces for this metric. Log file messages and email notifications are only issued when
monitoring mode is set to Alert.
• Off
d. Setting the remaining values to specify criteria that must be met to trigger a critical event for
the metric.

© 2021 Siemens
Sample webtierMonitorConfig.xml code
6. Save the file.

web tier monitoring is enabled for the metrics you configured.
Note:
You can revise the webtierMonitorConfig.xml file and save it in the .war file before
deployment by the web application. Or if you prefer, you can place the revised file directly
into the root directory of the web application server’s run-time environment, and override
the version of the file in the .war file. For example, on WebLogic, place the revised file into
the domain directory; on WebSphere, place it in the profile directory; or on JBoss, place it
into the bin directory.
Sample webtierMonitorConfig.xml code
In the following example, two of the four monitoring metrics are configured for email notification of
critical events. And two EmailResponder elements are configured. Email notification is sent to
EmailResponder1 when the No Server Available metric achieves critical event status. Email
notification is sent to EmailResponder2 when the Grave Events metric achieves critical event status.
Data is collected for the other metrics, but no email notifications are sent.



<ApplicationConfig id="Webtier" mode="Off" version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=
"healthMonitorV1.0.xsd">
<RespondersConfig>
</EmailResponder>
</EmailResponder>
<logFileName value="WebtierMonitoring.log" />
</LoggerResponder>

© 2021 Siemens
</RespondersConfig>
<MetricsConfig>
<Metric name="Abandoned Servers" id="AbandonedServers" maxEntries="100" mode="Collect"
description="The web tier was unable to connect to the tcserver that the tree cache
indicates is assigned to the session.">
<ThresholdValue name="NumberAbandonedServers" value="10"
description="Alert if number of abandoned servers exceeds this limit for
time period" />
description="Period over which this metric is monitored for exceeding
threshold" />
<Responders>
</Responders>
</Metric>
<Metric name="No Server Available" id="NoServerAvailable" maxEntries="100"
mode="Alert"
description="The server pool was unable to assign a tcserver.">
<ThresholdValue name="NumberNoServerAvailable" value="10"
description="Alert if number of times no server available exceeds this limit
during time period" />
threshold" />
<Responders>
</Responders>
</Metric>
<Metric name="Failed Login Attempts" id="FailedLoginAttempts" maxEntries="100"
mode="Collect" metricType="integer"
description="Excessive failed login attempts have been detected.">
<ThresholdValue name="NumberFailedLoginAttempts" value="2"
description="Alert if number of failed login attempts exceeds this limit
during time period" />
threshold" />
<Responders>
</Responders>
</Metric>
<Metric name="Grave Events" id="GraveEvents" maxEntries="100" mode="Alert">
<Responders>
</Responders>
</Metric>
</MetricsConfig>

© 2021 Siemens
Overview of configuring the rich client for startup performance
Configuring the rich client for startup performance
Overview of configuring the rich client for startup performance
For the Teamcenter rich client to start up and logon to the Teamcenter server, hundreds of megabytes of
resources are loaded from the local hard disk into memory. In the warm case where the files were
recently read into memory and remain in the RAM file cache of the operating system, this initial load can
take a few seconds. However, in a cold case such as after reboot of the client computer, the limiting
factor on performance is how quickly the bytes are read from the hard disk into RAM.
The following situations negatively impact cold file read performance:
• Virus scanning software

Exclude the entire TC_ROOT/portal folder and all of its subfolders from virus scanning, as well as the
Teamcenter/RAC folder under the user folder where the rich client workspace folder is maintained.
• Large PATH statement

Minimize the size of your system PATH environment variable and remove non-local folders from the
PATH statement.
• Low hard disk space

Ensure the hard drive where the rich client is installed remains defragmented and never exceeds 75
percent capacity.
• Running additional applications

Minimize use of other resource intensive applications that are competing for pages in memory while
the rich client starts.
• Starting the FCC at rich client logon

Start the FMS client cache (FCC) at operating system logon and keep it running in the background so
the rich client does not have to start the FCC while the rich client is logging on.
One way to achieve near warm startup times in a cold situation is to warm the rich client files found
under the TC_ROOT/portal folder using the file warmer capability of the FCC application. The file warmer
loads the specified files from the hard disk to the disk cache, effectively changing them to a warm state.
It is beneficial to configure file warmer functionality when all the following conditions exist at your site:
• Rich client startup is very slow.
• The FCC can be started when the user logs on to the operating system or can be manually started a
few minutes before the rich client.
• The FCC can be kept active in memory until the user logs off.
And when none of the following conditions exist at your site:

© 2021 Siemens
• The client workstation employs very fast media, such as solid-state disk (SSD) media. In this situation,
startup is already as fast as possible.
• The client workstation supports multiple simultaneous users on Linux or Citrix server machines.
• There is not enough hard disk cache on the machine to cache the necessary rich client startup files.
The hard disk cache requirement is related to the amount of memory (RAM) on the system more than
the capacity of the hard disk media. Siemens Digital Industries Software recommends a minimum of
512 MB of available hard disk cache, which provides approximately 2 GB of RAM on Windows.
• There is significant competition for the available disk cache. For example, additional third-party
applications are using a similar technique to warm their files.
If all the requiring conditions are met, and none of the preventative conditions exist, configuring the
FCC to warm rich client startup files can improve startup performance.
Configuring the FCC file warmer
Configure the filewarmer.properties file
File warmer behavior is controlled by property settings in the filewarmer.properties file that are read by
the FCC at startup. A sample of this file is provided at FMS_HOME/filewarmer.properties.template.
1. Open the filewarmer.properties file in the FMS_HOME directory.

If this file does not exist, copy the filewarmer.properties.template file to the FMS_HOME
directory and rename it as filewarmer.properties.
2. Set the filewarmer.filelist option to the name and location of the file containing the list of files to
be warmed.
If a list file is not specified, file warming is disabled. If the file is modified, you must restart the FCC
for the changes to take effect.
3. Set the filewarmer.interval option to the amount of time (in seconds) between warming updates.
The default setting is 1800 (30 minutes.)
4. Set the filewarmer.mapfiles option.

If set to true, the system memory maps each file and reads a selected part of the data. This method
is more efficient for files larger than a few tens of kilobytes.
If set to false, the reading option is used.
5. Set the filewarmer.readfiles option.

If set to true, the system opens and reads each file into a large buffer.
If both the mapping and reading options are set to true, the mapping option is performed first.
For sample settings, see the FMS_HOME/filewarmer.properties.template file.

© 2021 Siemens
Configure the filelist.txt file
Configure the filelist.txt file
The filelist.txt file contains the list of files to be warmed. This file is used by the filewarmer.filelist
option in the filewarmer.properties file.
1. Open the filelist.txt file in the FMS_HOME directory.

If this file does not exist, copy the filelist.txt.template file to the FMS_HOME directory and rename
it as filelist.txt.
2. List the files and directories to be included (or excluded) from file warming, using the following
formatting rules:
• Commented lines (lines beginning with a hash mark (#)) and blank lines are ignored.
• Specify include mode by typing @include alone on a line. Specify exclude mode by typing
@exclude alone on a line.
By default, the file begins in include mode. All files and directories listed in this mode are
included in the file warming process. All files and directories listed in exclude mode are
excluded from the file warming process.
• Enter one file or directory per line.
• Do not use quotation marks.
• Do not specify environment variables.
• Do not use wildcards.
• Do not use relative paths.
• Use any platform-specific directory separators consistently. Do not use double backslashes to
represent Windows directory separators.
• Use any path aliases consistently.
The specified directories are scanned at the start of each cycle, allowing the file warmer to adapt to
dynamic content changes. The directories are scanned recursively, unless otherwise specified.
If the same file or directory is listed as both included and excluded, the exclusion is ignored.
Example:
Siemens Digital Industries Software recommends setting the following paths:
@include
rich client -install-path\portal\plugins
rich client -install-path\portal\features
rich client -install-path\portal\registry

© 2021 Siemens
rich client -install-path\portal\configuration

rich client -install-path\portal\Teamcenter.exe
rich client -install-path\portal\Teamcenter.ini
rich client -install-path\portal\.eclipseproduct
RAC-install-path\portal\jre\lib\rt.jar
@exclude
RAC-install-path\portal\plugins\FoundationViewer
For additional sample settings, see the FMS_HOME/filelist.txt.template file.
Configure file warmer logging behavior
You can use file warmer log files as a diagnostic tool. Logging should not be configured for a production
environment.
By default, file warmer logs CONFIG output to the FCC log on startup and EVENT output to the FCC log
at each cycle.
To configure more detailed logging:
1. Set the FCC_LogLevel element in the fcc.xml file to TRACE.
2. Set the FCC_TraceLevel element in the fcc.xml file to ADMIN.
Configure the FCC to locate the filewarmer.properties file
The FCC looks for the filewarmer.properties system property at startup. If this value is undefined, file
warmer functionality is not enabled. You can define this system property by either editing the
fcc.properties file or by editing the startfcc script.
To edit the fcc.properties file:
1. Open the fcc.properties file in the FMS_HOME directory.

If this file does not exist, copy the fcc.properties.template file to the FMS_HOME directory and
rename it as fcc.properties.
2. Add one of the following properties:
filewarmer.properties=C:\\Program Files\\Teamcenter\\fcc\\filewarmer.properties
Use the full path to the properties file. Use double backslashes as directory separators.
• Linux systems:
filewarmer.properties=/usr/bin/teamcenter/fcc/filewarmer.properties

© 2021 Siemens
Configuring TCCS to start when users log on to a Windows operating system
Use the full path to the properties file. Use single forward slashes as directory separators.
To edit the startfcc script:
1. Open the startfcc.bat (Windows) or startfcc.sh (Linux) file in the FMS_HOME directory.
2. Add one of the following properties:
-Dfilewarmer.properties=C:\\Program Files\\Teamcenter\\fcc\\filewarmer.properties
Use the full path to the properties file. Use double backslashes as directory separators.
• Linux systems:
-Dfilewarmer.properties=/usr/bin/Teamcenter/fcc/filewarmer.properties
Use the full path to the properties file. Use single forward slashes as directory separators.
If file warming for the FMS client cache (FCC) is configured, you can also configure a Windows system to
launch TCCS each time the system starts and cache rich client files to main memory. Using this
functionality in conjunction with FCC file warming improves system startup performance
Note:
If implemented when Kerberos authentication is not configured for zero sign-on, users are
prompted to authenticate any proxy servers when TCCS is started. The consequence is that each
time users log on to Windows, they are prompted to authenticate any proxy servers.
Warning:
JRE shutdown hooks are not honored, preventing the FCC from closing cleanly. If the TCCS/FCC
instance remains running when users log off (or shut down), these operating systems, the FCC
segment cache may be corrupted.
Siemens Digital Industries Software recommends you add the fccstat -kill command to all user
logoff scripts and to any relevant Windows shutdown scripts for Teamcenter clients.
1. Create a script to automatically start TCCS.

Create a batch (.bat) script containing the following instructions:
a. Set the FMS_HOME environment variable.

The FMS_HOME environment variable points to the folder where FMS is installed. By default,
this location is the tccs directory in the Teamcenter installation folder.

© 2021 Siemens
For example:
set FMS_HOME=C:\Progra~1\Siemens\Teamcenterversion-number\tccs
C:\Progra~1\Siemens\Teamcenterversion-number is the Teamcenter installation folder. The

FCC runs as a part of TCCS and is installed in the same folder.
b. Set the JRE_HOME environment variable.

The JRE_HOME folder points to the directory where the Java JRE is installed on the system.
The Java version must be 1.7 or later.
For example:
set JRE_HOME=C:\Progra~2\Java\jre7
c. (Optional) Enable startup logging for the FCC.

Include this instruction only if the script is being used for debugging purposes. If included, the
FCC creates a log for its startup events at the given file path.
For example:
set FMS_FCCSTARTUPLOG=C:\fccstartup.log
d. Start TCCS.
call FMS_HOME\bin\fccstat -start
FMS_HOME is the value set in the first step.
e. Set the _EL variable to the correct FCC error level.

If the FCC does not start correctly, exiting with an error code, the FCC sets ERRORLEVEL to the
correct FCC error code. You can use this value for debugging.
For example:
set _EL=%ERRORLEVEL%
ERRORLEVEL is the level set by the FCC.
f. Exit if startup is successful.

If TCCS starts correctly, the script is instructed to close.
if "%_EL%" == "0" goto worked
g. Retry TCCS startup.

If TCCS did not start correctly in the previous step, instruct the script to retry FCC startup step
a few seconds later. The number after -n is the approximate number of seconds to wait.
Siemens Digital Industries Software recommends setting this between 10 and 30 seconds.
(Accuracy of this timing is not critical to the operation of this script.)
For example:

© 2021 Siemens
@ping 127.0.0.1 -n 30 -w 1000 > nul

goto retry
h. Mark the completion of script execution.

Instruct the script to print FCC successfully started on the console upon successful
completion.
:worked
echo FCC successfully started.
An example of the completed script is:
set FMS_HOME=C:\Progra~1\Siemens\Teamcenter9\tccs
set JRE_HOME=C:\Progra~2\Java\jre7
set FMS_FCCSTARTUPLOG=C:\fccstartup.log
:retry
call %FMS_HOME%\bin\fccstat -start
set _EL=%ERRORLEVEL%
if "%_EL%" == "0" goto worked
@ping 127.0.0.1 -n 30 -w 1000 > nul
goto retry:
:worked
echo FCC successfully started.
2. Configure TCCS to use the script.
a. Store the script in the appropriate Windows startup directory (Windows 7 or Server2008):
• Single-user system:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
• Multiuser system:
C:\Users\user-name\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
\Startup
Note:
These directories may be hidden by default.
b. (Optional) Set the TCCS_CONFIG_HOME environment variable to the TCCS home directory.
This step is required only when the default home location is not used and a custom TCCS
home location is created.
c. (Optional) Set the TCCS_CONFIG environment variable to the TCCS configuration directory
containing information about the various TCCS environments.
This step is required only when the default TCCS configuration name is not used.

© 2021 Siemens
Setting the PATH and AUX_PATH environment variables for enhanced

performance
Cold start performance is improved when the operating system’s PATH environment variable is
shortened to its minimum. When this operating system environment variable is used to track a large
number of locations, performance declines.
The rich client startup script sets the operating system PATH environment variable before opening the
client. To reduce the overall size of the environment variable’s value, Teamcenter excludes the existing
system PATH value from the final PATH value used for the rich client startup.
If your Teamcenter deployment integrates applications with the rich client, and the integrations require
that path locations are added to the operating system’s PATH environment variable, add the paths to the
AUX_PATH Teamcenter environment variable. For example:
set AUX_PATH=C:\new\path;%AUX_PATH%
• Linux systems (using ksh):
export AUX_PATH=/new/path:$AUX_PATH
Note:
Adding too many paths to the AUX_PATH environment variable defeats the purpose of shortening
PATH.
Might deleting my rich client cache improve performance?
In some cases, deleting the rich client cache may improve Teamcenter performance.
To improve performance and tailor the user experience, the Teamcenter rich client caches information
that is local and specific to each user. The cache includes information about session windows, current
plug-ins, system configuration, dialogs, display preferences, and so on. However, in the following
situations, contents of the cache can degrade performance:
• When a plug-in is updated with new or modified code, the cached information does not match the
new or modified plug-in, and the client may not work properly.
• When a user opens thousands of items, the current application can become slow to respond. The next
time that user logs on to the rich client, the system attempts to open the previously accessed items
and can take a long time to complete the startup.
In these situations, removing the cache is recommended. The cached information can be safely removed
because the client regenerates any needed information when the user next logs in.

© 2021 Siemens
What can I do to improve my startup performance?
Caution:
If TCCS advanced configurations are enabled, a TCCS configuration (cfg) directory exists within
the ...\Siemens cache folder. While user cache files can be deleted, the ...\Siemens\cfg
configuration directory must not be deleted or TCCS will stop working correctly.
The configuration directory is here

When TCCS is configured for Windows operating system Linux operating system
Public (shared) C:\ProgramData\Siemens\cfg /etc/Siemens/cfg
Private C:\users\{USERID}\Siemens\cfg $HOME/Siemens/cfg
What can I do to improve my startup performance?
By default, in rich client tree views a checked-out symbol displays to the right of checked out
Teamcenter objects. It is a quick indicator of whether the object is checked out. When an object is
checked out, a user has exclusive access to it, preventing others from making changes to the object until
it is checked back in.
However, displaying this symbol for every object in a very large assembly (5,000 or more objects) can
degrade performance. Turning off the display of this symbol in tree views (assembly trees, attachment
trees, and so forth) improves performance. Turn off the display of the symbol by setting the
TC_show_checkedout_icon preference to FALSE.
Checkout status always appears in the Details view, regardless of how you set the display of the
checked-out symbol. If you turn off the display of the checked-out symbol, refer to the Checked Out
column in this view to determine the check out status of objects.
To turn off the display of the checked-out symbol:
1. Choose Edit→Options to display the Options dialog box.

© 2021 Siemens
2. At the bottom left of the dialog box, click the Filters tab to display the Preferences by Filters pane.
3. In the first Filters box, type as much of TC_show_checkedout_icon as needed to reduce the list of
preferences so that the preference displays in the Preferences List.
4. Select the preference from the list. In the Value box, change the value to FALSE.
5. Click Save.
6. Click Close to close the dialog box.
7. Log off your session. Log on again to see the change take effect. The symbol no longer appears to
the right of objects in tree views.

© 2021 Siemens
POM_timestamp maintenance
POM_timestamp maintenance
The POM_timestamp table records the time of an object’s most recent modification. The
POM_timestamp table holds timestamps for a configured amount of time. (The default is 96 hours.) By
default, Teamcenter performs maintenance on the POM_timestamp table at session logout. If this
becomes a bottleneck due to the volume of concurrent session logouts, moving to manual maintenance
offers better control.
To alleviate bottlenecks during logout processing, the system administrator may choose to enable
manual maintenance of the POM_timestamp table. The manual mode requires the system administer
to provide periodic maintenance of the POM_timestamp table.
This is accomplished by running the following command on a periodic basis:
install -tidy_timestamps -u=user -p=password -g=group
The system administrator should set up a timed job that executes the previous command from within
the Teamcenter environment.
The following commands are required to manage the maintenance of the POM_timestamp table.
• To enable manual mode:
install -set_pom_param -u=user -p=password -g=group TC_TIMESTAMP_TIDY_MODE manual
• To perform manual maintenance on the POM_timestamp table (nightly or as appropriate):
install -tidy_timestamps -u=user -p=password -g=group
• To disable manual mode, remove the manual parameter configuration:

© 2021 Siemens
install -set_pom_param -u=user -p=password -g=group TC_TIMESTAMP_TIDY_MODE
• To view the current configuration:
install -ask_pom_param -u=user -p=password -g=group TC_TIMESTAMP_TIDY_MODE
Note:
If a configuration is not displayed then the default configuration (automatic mode) is in effect.
• To adjust the timestamp threshold value:
install -set_pom_param -u=user -p=password -g=group TC_TIMESTAMP_THRESHOLD hours
Tip:
hours must be an integer
• To reset the timestamp threshold to its default value (96 hours):
install -set_pom_param -u=user -p=password -g=group TC_TIMESTAMP_THRESHOLD
Cleaning the backpointer table after upgrade

As of Teamcenter 9.1, relation_type object references and ImanRelation primary and secondary object
references are no longer stored in the backpointer table. They are stored only in the ImanRelation table.
Note:
Where-referenced queries now search the ImanRelation table for ImanRelation references,
rather than searching the backpointer table.
This significant reduction in the size of the backpointer table can improve product performance. To take
advantage of this performance improvement, you must run the clean_backpointer utility on your
Teamcenter database after upgrading from a previous version (to Teamcenter 9.1 or a later version).
This utility is not run during upgrade, as the cleanup operation may be time-consuming.
The utility scans the backpointer table for relation_type object references and ImanRelation primary
and secondary object references, confirms their existence in the ImanRelation table, and deletes the
instances from the backpointer table.
The utility’s performance varies from site to site, depending on infrastructure elements such as database
load, network performance, server configuration, and so on. Because performance varies, Siemens
Digital Industries Software recommends following these best practices:

© 2021 Siemens
Improve Eclipse expression evaluation
1. Run the utility with the -m argument set to INFO to determine the number of objects stored in the
backpointer table.
2. Run the utility with the -s argument set to a few thousand objects and note how long it takes to
delete the objects.
3. Use the results of these first two operations to determine the length of time it takes to clear the
entire backpointer table (-s=ALL) and schedule accordingly.
Improve Eclipse expression evaluation

The rich client uses Eclipse menus, commands, and the shortcut menu. Eclipse may evaluate several
hundreds or thousands of expressions to control the visibility of any specific command in a menu. In
some cases, the Eclipse expression evaluation mechanism may cause problems.
Possible cause Problem
In the Manufacturing Process Planner This may cause Teamcenter to hang.

and Structure Manager applications,
a user performs Select All, Copy,
Paste or Remove actions on a large
number of BOM lines.
In the My Teamcenter application The Check-in and Check-Out menus are disabled.
with a dataset attached to an item
revision, a user:
• Opens an item revision into the

Details pane, right-clicks the
dataset, and chooses Check In/
Out→Check Out.
• Selects an item revision in the

Home view and chooses
Tools→Check In/Out→Check
Out.
• Right-clicks an item revision in the

Home view and chooses Check In/
Out→Check Out.
To avoid the these issues, Siemens Digital Industries Software recommends adding -
Dexpressioncache.enable=Y to the TC_ROOT/portal/portal.bat file installed by Teamcenter
Environment Manager (TEM). For example:
start Teamcenter.exe %* -vm "%JRE_HOME%\bin\javaw.exe" -vmargs -Xmx%VM_XMX%

-XX:MaxPermSize=128m

© 2021 Siemens
-Dexpressioncache.enable=Y -Xbootclasspath/a:"%JRE_HOME%\lib\plugin.jar";
"%JRE_HOME%\lib\deploy.jar";"%JRE_HOME%\lib\javaws.jar" %DJIPJL_VMARG%

© 2021 Siemens
20. Edit a Teamcenter registry file
What is Registry Editor?
Registry Editor is a rich client application for editing registry files of applications registered in the
Teamcenter framework. Such registry files may need modification for purposes of internationalization,
dynamic class invocation, or configuration. While administrators can use any standard text editor to edit
a registry file, Registry Editor simplifies the tasks of editing the registry files.
When a property in a registry file must be modified for a site, a system administrator locates the file in
the rich client and opens the file using Registry Editor. The system administrator navigates to the desired
key name and changes the value. If a new property is required, the administrator inserts a blank line and
enters the new key name and key value.
Registry Editor does not need to be enabled before use, but the feature must be selected during
Teamcenter installation.
Registry Editor interface
1 Properties tab The Properties pane displays a two-column table populated

with key names and key values contained in the currently
open .properties file.

© 2021 Siemens
You can edit key names and values in this pane.
2 Editor tab The Editor pane displays the full text within the currently
open .properties file, including comments. You can directly edit
the text.
You may want to use the Editor pane so that you can add your
own comments about any changes you make.
3 Find box Field for entering a Key name search string.
4 Find Starts the search operation.

If the registry file contains a Key whose name exactly matches
the string entered in the Find box, then clicking Find (or
pressing Enter while focus is on the Find box) highlights the
row containing the key. If the row is not already visible, the
dialog box scrolls to display the row.
5 Create Adds a row to the properties table for a new key/value pair.
6 Remove Deletes the selected row.
All Registry Editor menus are standard Teamcenter rich client menus.
Registry files in Teamcenter

Each application that is registered in Teamcenter has a registry file named with the
extension .properties. A registry file contains user-defined configuration settings (keys/values) that
influence how the application appears and performs in the interface. Property files are located in
various .jar files.
• A key is a field in a record that contains unique data and identifies the record in the file or database.
Each key value must be unique in each record.
• A value is the content of a field or variable. It can refer to alphabetic, numeric, or alphanumeric data.
• Properties are the keys and values in a registry file that specify the configuration settings for an
application.
The following figures contain examples of registry files, as viewed in the Registry Editor Editor pane.
These files are contained in the com.teamcenter.rac.aifrcp_1.0.0.jar file.
import=com.teamcenter.rac.aif.aif
com.teamcenter.rac.aif.registryeditor.RegistryEditorApplication.
PANEL=com.teamcenter.rac.aif.registryeditor.RegistryEditorApplicationPanel
MENUBAR=com.teamcenter.rac.aif.registryeditor.RegistryEditorApplicationMenuBar

© 2021 Siemens
Registry files in Teamcenter
TOOLBAR=com.teamcenter.rac.aif.registryeditor.RegistryEditorApplicationToolBar
### helpPage address ###
helpPage=/registry_editor/WebHelp/WHStart.htm
# New Key
# ------------------------------
newKey.ICON=images/add_16.png
# Remove a Key
# ------------------------------
removeKey.ICON=images/remove_16.png
registryeditor.properties file

© 2021 Siemens
# Find in Display Keys

# ------------------------------
findInDisplay.TIP=Find In Display
# Read-Only Text
# ------------------------------
readOnly=(Read-Only)
# New Key
# ------------------------------
newKey.TIP=Create a New Key
# Remove a Key
# ------------------------------
removeKey.TIP=Remove a Key
# File Type description key.
# ------------------------------
RegistryFiles=AIF Registry Files
# Unable to Save keys.
# ------------------------------
UnableToSave.MESSAGE=Unable to Save...File is Read Only!
UnableToSave.TITLE=Unable to Save
# No File Open
# ------------------------------
NoFileOpen.MESSAGE=Can't Save...No file open!
NoFileOpen.TITLE=Can't Save
# Overwrite File
# ------------------------------
Overwrite.TITLE=File Already Exists
Overwrite.MESSAGE=Overwrite the existing file?
# About Dialog keys
# ------------------------
application.TITLE=Registry Editor
application.DESCRIPTION=Registry Editor is used to edit
Portal Registry files. This application is used\only
for editing Registry files that are used for internationalization,
dynamic\nclass invocation, and configuration in the Portal.
# Title for the Save-As dialog
# -------------------------------
saveAs.TITLE=Save-As
open.TITLE=Open
untitled.FILE=Untitled
saveModified.TITLE=Save Modified File
saveModified.MESSAGE=Should the changes be saved before closing?
saveModified.TIP=Save modified file.
openFile.TIP=Open registry file.
registryeditor_locale.properties file

© 2021 Siemens
Open a Teamcenter registry file
Open a Teamcenter registry file

1. In the rich client, open the Registry Editor application.
2. Choose File→Open.
3. Browse to and select a registry file, and then click Open.
Modify a registry file

1. Open the registry file.
2. In the Properties pane, modify the file:
To perform this Do this

action
Change an existing Double-click the value to change and update the value.
value
Add a new key and Click Create Key and enter a new key/value pair.
value
Remove a key and Click the key/value pair in the row that you want to remove and click
value Remove Key .
Alternatively, you can click the Editor tab and directly edit the registry file text in the Editor pane.
You may want to use the Editor pane so that you can add your own comments about any changes
you make.
3. Choose either File→Save or File→Save-As.

If you choose File→Save-As, Teamcenter appends the .properties extension to the file name.

© 2021 Siemens

© 2021 Siemens
21. Logging
Introduction to logging
Log files are generated in each Teamcenter tier, as well as in third-party applications used to provide
Teamcenter capabilities.
System log files provide system-level logging from the business logic layer.
Teamcenter tier log files provide logging generated in each Teamcenter tier.
Logging for business logic servers
System log files
All system log files provide the following information:
• Priority level
• Date/time (UTC format)
• Log correlation ID of the client request
• Error code (when applicable)
• Error message (if Error code provided)
• Message
• Logger name
• Caller file and line number (if specified)
You can dynamically change logging levels for the system log file.
FATAL Logs only severe error events that cause the application to abort. This is the
least verbose logging level.
ERROR Logs error events that may allow the application to continue running.

© 2021 Siemens
21. Logging
WARN Logs potentially harmful situations, such as incomplete configuration, use of

deprecated APIs, poor use of APIs, and other run-time situations that are
undesirable or unexpected but do not prevent correct execution.
INFO Logs informational messages highlighting the progress of the application at a

coarse-grained level.
DEBUG Logs fine-grained informational events that are useful for debugging an
application.
TRACE Logs detailed information, tracing any significant step of execution. This is the
most verbose logging level.
You must configure loggers to write messages of the desired priority level. Setting a logger at DEFAULT
causes it to inherit its priority level from its parent logger.
Configuring business logic server logging
There are two methods available to manage logging levels for business logic servers.
• You can make persistent changes to logging levels of business logic servers using the
logger.properties file, which is stored in the TC_DATA directory.
Changing logging levels in this file affects all servers in the server pool. If multiple pools use the
TC_DATA directory, all servers in all server pools using this directory are affected. This method is
useful for updating deployment environments.
Note:
Changes to the file take effect only after the server is restarted. You can use the Restart Warm
Servers button in the server manager administrative interface to restart all warm servers and
implement the changes to the logging levels.
• You can dynamically change logging levels for a particular user session using the Teamcenter
Management Console.
Changing logging methods in this manner affects only the selected business logic server, and the
changes last only throughout the user session.
Configure logging with the logger.properties file
The logger.properties file lists all loggers used by the business logic servers.
1. Open the TC_DATA/logger.properties file.

© 2021 Siemens
Debugging using business logic server logging
2. Change the logging level of any logger:
a. Scroll to the logger whose logging level you want to change.
b. Type a valid logging level after the equal (=) sign.

Setting a logger at DEFAULT causes it to inherit its priority level from its parent logger.
c. Choose File→Save to save your changes.
Note:
Changes to the file take effect only after the server is restarted. You can use the Restart Warm
Servers button in the server manager administrative interface to restart all warm servers and
implement the changes to the logging levels.
Debugging using business logic server logging
There are two methods available for setting business logic server logging for debugging.
• Set the UGII_CHECKING_LEVEL environment variable to 1 to enable server checking. When checking
is enabled, the system uses the logger.debug.properties file for logging instead of the
logger.properties file. The default settings of the debug file generate useful debugging messages.
Caution:
Enabling checking significantly increases the size of log files. Only enable checking for
debugging purposes or when requested by Siemens Digital Industries Software support.
• Set the TC_LOGGER_CONFIGURATION environment variable to the whole file path of a properties file
or the path of the directory containing the logger.properties file to use for debugging. You can
specify a custom logger properties file or the TC_DATA/logger.debug.properties file.
Logging for Teamcenter tiers
Overview of logging for Teamcenter tiers
Log files can be generated in each Teamcenter tier. The four-tier architecture comprises the following
tiers:

© 2021 Siemens
21. Logging
Client tier The client tier hosts client applications, provides user interface input and output
processing, and hosts secure file caches.
Web tier The web tier routes client requests to business logic servers, serves static content to
clients, and processes login requests.
Enterprise The enterprise tier hosts business logic, makes queries and performs transactions for
tier clients, applies security rules to control access to product data, and serves dynamic
content to clients.
Resource tier The resource tier stores persistent data, such as the database where product data and
managed files are stored. It also stores administrative data, including user data in
LDAP-compliant repositories.
The log correlation ID is a unique ID that records the path of a service request starting from the web tier
through the enterprise tier. This log correlation ID is recorded in the log messages on each tier that
processes the request. The log correlation ID has the following structure:
Client-or-Proxy-Host.Thread-ID.User-Name.Request-Count
• Client-or-Proxy-Host indicates the client host name or the proxy server host name.

© 2021 Siemens
Overview of logging for Teamcenter tiers
• Thread-ID is a unique, randomly generated value.
• User-Name is the user name associated with the request. The default is set to Anonymous.
• Request-Count is a counter that gets incremented for each request.
The client sends the request that is received first by the web tier. The WebTier.log file records the
request with the correlation ID as follows:
DEBUG - cmh6p199.net.plm.eds.com.05340.Anonymous.00002 -
2011/04/21-02:00:38,223 UTC - cii6p199 - Begin - WebclientPreProcess
[com.teamcenter.presentation.webclient.actions.WebclientPreProcess.
handleAction(WebclientPreProcess.java:226):Thread[[ACTIVE]
ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)
',5,Pooled Threads]]
…
The same log correlation ID is recorded in ServerManager.log file, where the server manager assigns
the tcserver1 process for this user. (This log is located the TC_ROOT\pool_manager\confs
\configuration-name\logs\ServerManager\process directory.)
DEBUG - cmh6p199.net.plm.eds.com.05340.Anonymous.00002 -
2011/04/21-02:02:20,921
UTC - cmh6p199 - Server assigned: tcserver1@poolA@5920@cii6p199
[com.teamcenter.jeti.serversubpoolmanager.ServerPoolManager$Assign
er.publishAssignment(ServerPoolManager.java:7934):Thread[RequestPr
ocessor-40,10,main]]
The request path can be traced in the tcserver1.syslog file using the same log correlation ID.
2011-04-20 22:03:03 cmnh6p199.net.plm.eds.com.05340.Anonymous.00002 -

Service Request: T2LWebMethodService:process_request_raw
Successfully loaded dynamic module D:\udu\ref\tc9.0.0.2011041800\wnti32\lib\libweb.dll
Loaded module D:\udu\ref\tc9.0.0.2011041800\wnti32\lib\libvis.dll 129c0000 90000
3cc8fdcd-4dd74f64-12a895a6-4c835394-1=libvis___1303160187 version = 9000.0.0.4104
Loaded module D:\udu\ref\tc9.0.0.2011041800\wnti32\lib\libweb.dll 12500000 4a8000
65af7f91-4e213a95-24a44db3-b6e6544-1=libweb___1303161766 version = 9000.0.0.4104
INFO - 2011/4/21-02:03:03.190 UTC - cmh6p199.net.plm.eds.com.05340.Anonymous.00002 -
Loaded library libweb - Teamcenter.Soa.TcServerUtil
tcscript took 0.078000s cpu, 0.085000s real to parse file - toplevel.html
On the next client request, this log correlation ID is updated with the authenticated user name and an
incremented request counter.
DEBUG - cmh6p199.net.plm.eds.com.05340.tcdba.00003 -
2011/04/21-02:03:04,777 UTC - cmh6p199 - Begin - WebclientPreProcess
[com.teamcenter.presentation.webclient.actions.WebclientPreProcess.
handleAction(WebclientPreProcess.java:226):Thread[[ACTIVE]
ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)
',5,Pooled Threads]]

© 2021 Siemens
21. Logging
Web tier logging
By default, log files for Teamcenter web application servers are located on the file system within the
web server root. The default LogVolumeLocation directory name is logs.
Web Server Default log directory (LogVolumeLocation)

WebLogic WebLogic-Domain-Root\logs
JBoss JBoss-Installation-Root\logs
WildFly WildFly-Installation-Root\logs
Tomcat Tomcat-Installation-Root\logs
Analogous logs for applications hosted by a .NET web server are written to Windows event logs in
C:\Windows\System32\winevt\LogsTcWebTier.evtx.
If you prefer some log volume directory name other than logs, you can use Web Application Manager to
change the name.
1. To open Web Application Manager, run WEB_ROOT\insweb.bat.
2. In Web Application Manager, select Modify, and then select Modify Context Parameters.
3. Set the LogVolumeLocation (the default value is logs) and click OK.
The new tc.war file is generated.
4. Deploy the new tc.war file in the application server.
The log file LogVolumeLocation\WebTier\process\WebTier.log contains transaction messages sent to

application process logs. Its configuration is defined in the file LogVolumeLocation\Webtier\metadata
\process\WebTier.log.xml.
The following application process log files are located in LogVolumeLocation\MLD\process\.
Log file Log contents

plmconsole.txt Console messages from the application implementing MLD.
RTEvents.txt Sampled gauge values and threshold notifications. This local file is overridden by any
JMX interface configuration.
RTConsole.txt Default log file for response time monitoring.
RTRemotes.txt Notifications processed by remote Response Time GaugeListeners and
TraceListeners.
RTTraces.txt Local file for response time tracing messages and logging.

© 2021 Siemens
Enterprise tier logging
Enterprise tier logging
Log file Log contents Log location

Teamcenter server logs
ServerManager.log Messages from the server manager TC_ROOT/pool_manager/confs/
application. configuration-name
/logs/ServerManager/process
ServerManager.log configuration:
Increase the information logged to this file by increasing the severity
level of the TC_ROOT/pool_manager/confs/configuration-name/
log4j.xml file.
Change the location of this file by resetting the LogVolumeLocation
value of the TC_ROOT/pool_manager/confs/configuration-name/
log.properties file. By default, the LogVolumeLocation is set to logs.
tcserverpid.syslog Diagnoses errors. Captures TC_LOG_VOLUME_DIR or
information, errors, and warnings. TC_TMP_DIR
This value is typically C:\Temp on
Windows and /tmp on Linux.
tcserverpid.syslog configuration:
For information on logging levels, see Configuring business logic
server logging.
Define the TC_TMP_DIR environment variable in the TC_DATA/
tc_profilevars.bat file.
Or set the TC_LOG_VOLUME_DIR environment variable to the desired
top level directory and the TC_LOG_VOLUME_NAME to the desired
subdirectory, for example, TcServer.
tcserverpid.jnl Tracks objects accessed from the The journal file is written to the
database and the activities same location as the syslog.
performed on those objects. This
TC_LOG_VOLUME_DIR or
session log also performs a trace
TC_TMP_DIR
through software modules. Each
time you invoke or exit a module,
the Log Manager posts an entry to
this file.
tcserverpid.jnl configuration:
Or set the TC_LOG_VOLUME_DIR environment variable to the desired
top level directory and the TC_TMP_DIR environment variable in the
TC_DATA/tc_profilevars.bat file.

© 2021 Siemens
21. Logging

install.log Tracks Teamcenter installation TC_TMP_DIR
messages. The date-time stamp
represents the date and time
Teamcenter Environment Manager
was run. For example,
install1322241627.log indicates
that Teamcenter Environment
Manager was run at 4:27 on
February 24, 2013.
install.log configuration:
pomutilities.log Standard output from the POM TC_TMP_DIR
utilities called by Teamcenter
Environment Manager.
pomutilities.log configuration:
audit.log Tracks selected properties for TC_LOG
specified actions in the database.
The default setting is TC_DATA/
These audit logs are created in Audit
log_ORACLE-SERVER_ORACLE-SID
Manager.
where ORACLE-SERVER is the
Oracle server network node and
ORACLE-SID is the unique name
of the Oracle database instance.
fscid_startup.log on Linux. Captures all FMS server cache (FSC) /tmp on Linux.
process output generated from
fscidstdout.log and FSC_HOME on Windows.
stdout and stderr. This output is
fscidstderr.log on Windows.
useful in diagnosing failure-to-start
Replace fscid with the FSC ID issues. The file also contains the
defined in FSC_HOME entries generated to the runtime
\fsc.xml. log.
PLM XML logs
xml-file-name.log or Provides complete information TC_TMP_DIR
plmxml_log_timestamp.log regarding the current PLM XML
For command line export, if
export or import.
TC_TMP_DIR is not set, the log
file is generated at the same
location as the XML file.

© 2021 Siemens
Resource tier logging

For rich client export, the log file
is generated at the same location
as the XML file.
xml-file-name.log or plmxml_log_timestamp.log configuration:
Determine the logging level with the PLMXML_log_file_content
preference.
Multi-Site logs
idsmID.log Tracks actions performed on objects TC_TMP_DIR on the machine
at a session level, such as imported hosting the IDSM server.
or exported objects.
idsmID.syslog Diagnoses errors. Captures TC_TMP_DIR on the machine
information, errors and warnings. hosting the IDSM server.
idsmID.jnl Tracks objects accessed from the TC_TMP_DIR on the machine
database, and the activities hosting the IDSM server.
this file.
odsID.log Tracks actions performed on objects TC_TMP_DIR on the machine
at a session level. hosting the ODS server.
odsID.syslog Diagnoses errors. Captures TC_TMP_DIR on the machine
information, errors and warnings. hosting the ODS server.
odsID.jnl Tracks objects accessed from the TC_TMP_DIR on the machine
database, and the activities hosting the ODS server.
this file.
Resource tier logging

File Management System (FMS)
fscid_startup.log on Linux. Log entries regarding server run- /tmp on Linux.
fscidstdout.log and time operations.
FSC_HOME on Windows.
fscidstderr.log on Windows.

© 2021 Siemens
21. Logging

File Management System (FMS)
Replace fscid with the FSC ID fscidxxstxx.log configuration:
defined in FSC_HOME
\fsc.xml. Determine the logging level by setting $FSC_HOME/FSC_$fscid_
$USER.xml in the fsc.xml file on Linux. (FMS resolves $HOME to
%USERPROFILE% on Windows.
Valid values are FATAL, ERROR, WARN, INFO, and DEBUG.
Siemens Digital Industries Software recommends that you never run an
FSC in debug mode. Generally, WARN and INFO provide sufficient
logging information.
Replace fscid with the FSC ID defined in the FSC_HOME\fsc.xml file.
fscid.log Log entries regarding server run- FSC_HOME/logs/FSC/process
time operations.
Replace fscid with the FSC ID
defined in FSC_HOME fscid.log configuration:
\fsc.xml. Change the location of this file by setting the LogVolumeLocation
property in the FSC_HOME/log.properties file.
FSC_host-name_user- Default console log file for FSC_HOME/logs/MLD/process
ID_plmconsole.txt response time logging
FSC_host-name_user- Sampled gauge values and FSC_HOME/logs/MLD/process
ID_RTEvents.txt threshold notifications. This file is
overridden by any JMX interface
configuration.
FSC_host-name_user- Response time tracing messages FSC_HOME/logs/MLD/process
ID_RTTraces.txt and logging.
FSC_host-name_user- Notifications processed by remote FSC_HOME/logs/MLD/process
ID_RTRemotes.txt Response Time GaugeListeners
and TraceListeners.
Business Modeler IDE
deploy.log Deployment messages. output/deploy/serverProfileName/
date-timestamp
Migration logs Migration logging messages. output/migration
Dispatcher logging
The Dispatcher asynchronously distributes Dispatcher requests to machines with the resource capacity to
execute the requests. A grid technology manages the job distribution, communication, translator
execution, security, and error handling for Dispatcher requests. Dispatcher requests are triggered by
workflow, data checkin, batch mode, or on-demand operations.
The following logs are all for the Dispatcher component. None of the logs requires configuration.

© 2021 Siemens
Performance journaling
Log file and location within

Log contents LogVolumeDirectory/Dispatcher Server/
Dispatcher Module messages while processing the task-ID/task-ID_m.log
task.
Dispatcher Scheduler messages while processing the task-ID/task-ID_s.log
task.
Dispatcher Client messages while processing the task-ID/task-ID_dc.log
task. The Dispatcher Client receives Dispatcher
Requests from the client and sends them to the
Dispatcher Scheduler.
Scheduler messages. process/Scheduler.log
Module messages. process/Module_ID.log
Adminclient messages. process/Adminclient.log
A history of events and of state transitions performed process/History_DispatcherClient_IP-
on all the requests. Address_port.log
Dispatcher Client process messages such as startup process/DispatcherClient_IP-Address_port.log
and cleanups.
Performance journaling
In order to analyze the performance of Teamcenter processes and programs, you can generate
performance journal files (.pjl). The .pjl file format can also be generated by processes or programs other
than Teamcenter. You can simultaneously open .pjl files generated by different processes in a system,
for example from a Teamcenter client and the corresponding Teamcenter server session, and view the
performance of the entire session as a whole.
You can use the Siemens Digital Industries Software application JournalWorkbench to read the .pjl files
and analyze the data. The JournalWorkbench is a licensed application.
For configuration settings and tuning methods to optimize Teamcenter performance with Oracle or
Microsoft SQL Server, see the Teamcenter Deployment Guide available on Support Center. The
Teamcenter Deployment Guide also provides an in-depth review of database performance issues and
diagnosis, and configuration and tuning guidelines.
Finding error codes

All error codes are documented in the Integration Toolkit Function Reference. Error codes are grouped
by module. For example, Application Encapsulation (AE) errors are listed within the AE module,
Appearances errors are listed within the Appearances module, most workflow errors are displayed in the
Enterprise Process Modeling (EPM) module, and so forth.
To display a list of error messages:

© 2021 Siemens
21. Logging
1. Go to the Help Library and open the Integration Toolkit Function Reference.
Note:
To access the Integration Toolkit Function Reference, go to Support Center.
2. At the top of the page, select the Modules header.
3. In the Modules page, scroll down to the appropriate module.

For example, to see all Enterprise Process Modeling (EPM) errors, which contain the majority of
workflow errors, scroll to EPM Errors and click the link.
4. The error page displays all errors for that module. Error numbers are defined as module base value
+ error code.
For example, the EPM_internal_error error has an error code of EMH_EPM_error_base + 1.
5. To determine the error base value for the selected module:
a. Return to the Modules page.
b. Scroll down to EMH Constants and click the link.
c. The Error Message Handler (EMH) Constants page displays the error base of each module.
For example, the error base value of EMH_EMP_error_base is 33000.
Thus, the error number for the EPM_internal_error error is the concatenation of the EPM
modules error base (33000) and the error code (1), creating an error code of 33001.

© 2021 Siemens
22. Rich client tweaks
Configure rich client web browser home page and window
The rich client Web Browser view lets users browse the Web in a view within the rich client, using the
browser defined by the client’s operating system, rather than switching to a separate Web browser
window. The Web Browser view also allows users to access MIME (Multipurpose Internet Mail Extension)
file types and view files created in other applications, such as Microsoft Word and Excel.
Users access the view by choosing Window→Show View→Web Browser.
To change the Web Browser home page, use the TC_Web_Browser_Home_URL preference. By default,
the URL is specified as http://www.plm.automation.siemens.com.
To specify whether Web link content from the rich client is displayed in the internal browser or in an
external browser window, use the browserWindowMode preference.
Configuring forms
Master forms
Master forms are created and deleted when an item or item revision is created or deleted.
• Master forms display specific product information to the rest of the enterprise in a standardized
format.
• When a new item is created, an Item Master form object is created automatically. Similarly, when a
new item revision object is created, an ItemRevision Master form object is created automatically.

© 2021 Siemens
You can enter data in the item master and item revision master forms when you create an item or by
opening an Item Master or ItemRevision Master form object.
Note:
• Master forms inherit access privileges from the parent item or item revision, so if you change
access privileges to an item or item revision you affect the privileges on the master form.
You can use the TC_MASTERFORM_DELEGATE environment variable to change this default
behavior.
• An item can have only one Item Master form.
• An item revision can have only one ItemRevision Master form.
Configure edit and view for forms
For form objects, the Form_double_click preference value can be set to either View or Edit to cause the
double-click action on a form to open that form in either edit or view mode.
Note:
To ensure consistent behavior on forms in both edit and view mode, set the
Configuration_shown_on_reservation_dialogs value to true, and set the following preferences
as required:
• Confirm_cancel_checkout_suppressed
Set this preference to true to proceed without user input on the cancel checkout confirmation
dialog box.
• Confirm_checkin_suppressed
Set this preference to true to proceed without user input on the checkin confirmation dialog
box.
• Confirm_checkout_suppressed
Set this preference to true to proceed without user input on the checkout confirmation dialog
box.
Hiding commands in Rich Client
As an administrator, you can limit the Teamcenter application commands that appear in the rich client
for members of specific groups or roles. Control of command visibility in other clients, such as Active
Workspace, is described in documentation for those clients.

© 2021 Siemens
Suppressing commands for specific groups or roles provides at least two benefits:
• Suppressed commands are not available to unauthorized group or role members; you control access.
• Members of the group or role are not distracted by commands that they do not want or need.
You have three methods to limit commands that appear in the rich client:
Method Effect Comments
Manually create a command In the specified application or You can use a manually created
suppression preference. perspective, for the specified preference to suppress a
group(s) or role(s), the command for a role in all groups
commands for specified where the role appears.
command IDs are suppressed
from drop-down menus,
toolbars, and context menus.
Use the Suppress Commands In the selected perspective, for You can choose to apply the
view in the Command the selected group or role within suppression to either
Suppression application to a group, the selected command
automatically create a is suppressed from drop-down • all perspectives in the
command suppression menus, toolbars, and context application to which the
preference. menus. selected perspective belongs
(default mode)
Note:
It is possible that a context • only the selected perspective.
menu command may have
the same name as a You can use a role preference to
command that appears on show on menus and toolbars
a drop-down menu or the commands that are hidden
toolbar, but actually refer by a group preference.
to a different command Commands hidden for a group
ID. In that case, it would are always hidden on context
not be suppressed. menus for all the group's roles.
Use the Suppress Context In the selected perspective, for You can choose to apply the
Menus view in the Command the selected group or role within suppression to the context
Suppression application to a group, the selected command menu for an object selected in
suppress commands on context is suppressed from context either
menus. menus that appear for objects.
Suppressions defined by this • all views in the selected
means are in addition to perspective
suppressions that apply because
of settings defined using the • only a selected view
Suppress Commands view.

© 2021 Siemens
Method Effect Comments
and to either
• all object types
• only a selected object type.
Example: If a group does not use Multi-Site Collaboration, then for the My Teamcenter
Suppress perspective, for all members of the group, you may want to suppress the Multi-Site
display of a Synchronization commands.
command
for an entire
group
Example: If a business process expects only managers in the logistics group to be able to import
Suppress and export data, then for all member roles in the Logistics group except the Manager
display of a role, you could suppress the Import and Export commands.
command
for selected
roles in a
group
Example: If a perspective is intended for focusing on a particular application task, then you might
Suppress suppress the Open command in the Manufacturing – Work Instructions perspective,
display of a while the Open command is available in the Manufacturing – BOM Reconciliation
command in perspective.
a
perspective
Limits to command suppression
You cannot limit visibility of commands that are:
• Contributed statically in the code (for example, Window menu), with the exception of
savePerspective, resetPerspective, and closePerspective in the Window menu.
• Contributed using Eclipse actions.
• Contributed dynamically. If there are static and dynamic commands within the same parent group,
suppressing the parent group also suppresses any contained static commands. It does not suppress
the dynamic commands, and the parent group still appears.
To determine whether a command is dynamic, use the DumpCMSConfigInfo utility.

© 2021 Siemens
Command Suppression interface
Tip:
To hide an entire perspective in the rich client, find the perspective's row in the
DumpCMSConfigInfo output activityxxx.csv file and add the value in the ID column to the
Teamcenter preference HiddenPerspectives.
Command Suppression interface
1 Applications view Displays a list of application perspectives. Select a perspective in the list
to display its application's commands in the Suppress Commands and
Suppress Context Menus views.
2 Organization view Displays a tree of the groups and roles that you can select when
suppressing commands.
3 Suppress Commands Displays a tree of the menus, submenus, and commands for the
view application of the selected perspective.
To expand a tree node and display its submenus and commands, click the
plus symbol next to the node.
In the example above, View is a menu, Audit is a sub-menu, and View
Audit Logs is a command.

© 2021 Siemens
4 Suppress Context Displays a set of controls for suppressing application commands that
Menus view might be found on context menus for objects shown in a perspective
view. The list of available application commands depends on the
perspective selected in the Applications view.
The View and Object Type values can be used to limit command
suppression to a certain view within the perspective, and to a certain
type of object.
5 Perspective Mode The Perspective Mode button is displayed and applicable when the
button Suppress Commands view is active. The button can be set to one of two
states, Off (default) or On . The active mode at the time a
command is hidden determines whether the command is hidden for all
of the application's perspectives (Off), or only the selected perspective of
the application (On).
6 Hide and Show The Hide and Show buttons are displayed when the Suppress
buttons Commands view is active.
You can click a button to set the respective status for the menu or
command that is currently selected.

© 2021 Siemens
Suppress menu bar commands
Suppress menu bar commands
1. In the rich client, open the Command Suppression perspective.
2. Click the Suppress Commands view to make it active.
3. In the Applications view, select the perspective containing the commands that you want to
suppress.
Many applications have only one perspective. Some have multiple perspectives. For example,
Manufacturing – BOM Reconciliation and Manufacturing – Process Sequencing are
perspectives of the Manufacturing Process Planner application. By default, new command
suppression settings apply to all perspectives of an application; but, if Perspective Mode is on,
then new command suppression settings apply only to the selected perspective.
4. Select a group, subgroup, or role from the Organization tree.
For information about how command suppression for group and role interact, see Manually create
preferences to suppress commands in the rich client.
5. If you want to limit new command suppression settings to only the selected perspective, then turn
Perspective Mode on.
Off This is the default mode. In this mode, when you hide menus and commands, they are
suppressed for all perspectives of the application to which the perspective selected in
the Applications view belongs.
Menus and commands hidden while in this mode are struck through with a red line and
annotated with [Hidden by Application].
On In this mode, when you hide menus and commands, they are suppressed only in the
selected perspective.
Menus and commands hidden while in this mode are struck through with a red line and
annotated with [Hidden by Perspective].
6. In the Suppress Commands view, select a menu, submenu, or command from the tree.
7. Click Hide.
The menu, submenu, or command name nodes selected for suppression are struck through with a
red line and an annotation identifying the suppression as perspective- or application-based is
added.
To remove the suppression, click Show.
8. Choose File→Save.

© 2021 Siemens
Suppress context menu commands
Preferences that hide commands on drop-down menus and toolbars also hide commands on context
menus, if the command ID is the same. You can use the following procedure to hide commands on
context menus in addition to those hidden by preferences.
Suppressions defined using the following procedure do not hide commands on drop-down menus and
toolbars.
1. In the rich client, open the Command Suppression perspective.
2. Click the Suppress Context Menus view to make it active.
3. In the Applications view, select the perspective in which you want to suppress context menu
commands.
4. Select a group, subgroup, or role from the Organization tree.
For information about how command suppression for group and role interact, see Manually create
preferences to suppress commands in the rich client.
5. If you want to limit command suppression to a particular view in the perspective, then from the
View list, select a view.
If no view is selected, command suppression applies to all views in the perspective.
6. If you want to limit command suppression to a particular item type, then from the Object Type list,
select an object type.
If no object type is selected, the command suppression applies to all object types.
By default, only children of the item object type are included in the Object Type list. If you want to
select an object type other than one based on the item type, then clear the Show Item Types Only
check box.
7. If you want to filter the list of available commands, then enter a filter pattern in the box above the
list of commands.
The list of commands available for a perspective is often very long. Entering a few characters of the
command name can make it much easier to find and select the command you are interested in.
8. In the Available Commands list, select a command from the list and click to move it to the
Suppressed Commands list.

© 2021 Siemens
Inheritance of group command suppression
Note:
Inherited suppressions are not shown in the list.
9. Choose File→Save.
Inheritance of group command suppression
The potential for command suppression inheritance differs, depending on whether a command
suppression preference has been defined for the role, and on the command location in the user
interface.
Command suppression preference Then group

For these UI locations for the role exists? command suppressions
drop-down menus and toolbars No Do apply
drop-down menus and toolbars Yes Do not apply
context menus either No or Yes Do apply
Note that even if the command suppression preference defined for a role does not contain any values,
the command suppression preference for the role must be deleted in order to restore the role's
inheritance of group command suppression on drop-down menus and toolbars.
Suppressions defined using the Suppress Context Menus view in the Command Suppression
application do not affect drop-down menus and toolbars.
Example interactions of group and role suppressions on command display
Consider the commands Aaaa, Bbbb, and Cccc. The following table shows the interaction of a
command suppression preference defined for Group and a command suppression preference defined
for Role A within Group. In this example, no additional context menu command suppression has been
defined.

© 2021 Siemens
Commands
Command Commands shown shown on Commands shown
suppression Command on menus and context menus on menus and
preference suppression toolbars when when logged in toolbars when
values preference values logged in as as logged in as
Group Role A Group / Role A Group / Role A Group / Role B
Aaaa No preference Bbbb Bbbb Bbbb

defined Cccc Cccc Cccc
Aaaa Aaaa Cccc Cccc Bbbb

Bbbb Cccc
Aaaa Cccc Aaaa Bbbb Bbbb

Cccc Bbbb
No preference Aaaa Bbbb Bbbb Aaaa

defined Cccc Cccc Bbbb
Cccc
Bbbb Aaaa Bbbb Cccc Aaaa

Cccc Cccc
Bbbb Preference exists, Aaaa Aaaa Aaaa

but no value Bbbb Cccc Cccc
defined Cccc
Manually create preferences to suppress commands in the rich client
While the Command Suppression application provides an easy way to hide a command for all members
of a group, or for a role within a group, you may want to suppress an application command for a
member role in all the groups where the role appears. You can manually create a preference to
accomplish this general role-based suppression.
Many examples of such command suppression preferences can be found in an Administration Data
Documentation Report of Teamcenter preferences.
Note:
You cannot suppress a command for all groups and all roles.
The following example procedure shows how to suppress commands in the Navigator (My Teamcenter)
perspective for a role in all groups.
1. In My Teamcenter, choose Edit→Options.
2. Click Filters.

© 2021 Siemens
Enable Command Suppression for a custom application
3. Click Create new preference definition .
4. In the Create new preference panel, type the following statement in the Name box:
com.teamcenter.rac.ui.perspectives.navigatorPerspective\\*\\[role]\\HIDDEN_COMMANDS
Replace [role] with the name of the role for which you want to suppress commands.
5. In the Create new preference panel, in the Values box, type a comma-separated list of command
IDs for the commands that you want to suppress.
6. Click Create.
Example:
Following are three examples of using a preference to suppress commands.
To suppress the Cut, Copy, and Paste commands for the My Teamcenter perspective for all groups
and the DBA role only:
com.teamcenter.rac.ui.perspectives.navigatorPerspective\\*\\DBA\\HIDDEN_COMMANDS
Values: cutAction,copyAction,pasteAction
Note that these command names are unusually simple. See command IDs for examples of typical
Teamcenter application commands.
To suppress the Cut, Copy, and Paste actions for the My Teamcenter perspective for the dba
group only and all roles defined in the group:
com.teamcenter.rac.ui.perspectives.navigatorPerspective\\dba\\*\\HIDDEN_COMMANDS
Values: cutAction,copyAction,pasteAction
To suppress the Cut action for the Structure Manager application for all groups and the DBA role
only:
com.teamcenter.rac.pse.PSEApplication\\*\\DBA\\HIDDEN_COMMANDS
Values: cutAction
Enable Command Suppression for a custom application
You can make custom Teamcenter application perspectives available in the Command Suppression
application.
1. Copy the TC_CS.APPLICATIONS key and its value from the portal.properties file to the
portal_user.properties file.

© 2021 Siemens
2. Append the path name of the new application to the value.

© 2021 Siemens

System - Admin TC

Uploaded by

Copyright:

Available Formats

System - Admin TC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System - Admin TC

Uploaded by

Copyright:

Available Formats

Teamcenter 14.

About Siemens Digital Industries Software

Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form

Teamcenter system administration 1-1

Maintaining Teamcenter servers

Maintaining the database server

System Administration, Teamcenter 14.0 PLM00102 14.0 3

File Management System

4 PLM00102 14.0 System Administration, Teamcenter 14.0

Administering FMS ──────────────────────────────────── 5-28

Volume Management application

System Administration, Teamcenter 14.0 PLM00102 14.0 5

Administering Teamcenter client communication system (TCCS)

6 PLM00102 14.0 System Administration, Teamcenter 14.0

TCCS and container applications ─────────────────────────── 7-23

Configuring external management of passwords

Configuring Teamcenter mail and instant messaging

Configuring Teamcenter email polling

Configuring Teamcenter notes and parametric requirements

System Administration, Teamcenter 14.0 PLM00102 14.0 7

Configuring access to administrative applications and utilities

Backing up and recovering a Teamcenter environment

Import, Export, and Report Administration Data

8 PLM00102 14.0 System Administration, Teamcenter 14.0

Manage administration data across environments ──────────────────── 15-2

Cryptography and FIPS compliance in Teamcenter server 16-1

Encryption key management

System Administration, Teamcenter 14.0 PLM00102 14.0 9

Updating property values in bulk

Configuring Teamcenter for performance

Edit a Teamcenter registry file

10 PLM00102 14.0 System Administration, Teamcenter 14.0

Enterprise tier logging ──────────────────────────────────── 21-7

Rich client tweaks

System Administration, Teamcenter 14.0 PLM00102 14.0 11

Where do I go from here?

System Administration, Teamcenter 14.0 PLM00102 14.0 1-1

1-2 PLM00102 14.0 System Administration, Teamcenter 14.0

• The dataset has no reference to an imanFile object.

• The anchor refers to datasets that do not exist.

• The anchor size is 0.

System Administration, Teamcenter 14.0 PLM00102 14.0 2-1

2-2 PLM00102 14.0 System Administration, Teamcenter 14.0

Useful administration tools

System Administration, Teamcenter 14.0 PLM00102 14.0 2-3

Using process daemons

Process daemons include the following:

• Shared Metadata Cache Service

2-4 PLM00102 14.0 System Administration, Teamcenter 14.0

Set Oracle-dependent services to automatically restart

• Action Manager service

• Shared Metadata Cache service

• Subscription Manager service

• Task Monitor service

sc config actionmgrd depend=OracleServiceTC

Application process monitoring

System Administration, Teamcenter 14.0 PLM00102 14.0 2-5

Source (in event Typical log file