Teamcenter Environment Variables: Third-Party Integration Gotchas (Community Sources)

Scope: the recurring practitioner pain point of third-party tools/connectors (NX, Cameo/HCL connector, Capital, generic TCCS clients) failing to connect to Teamcenter because of a misconfigured or mismatched environment variable — gathered from Siemens community threads, Eng-Tips, and blog posts, cross-referenced against what this KB already knows from live connector work (HCL Cameo→TC connector, Capital↔TC integration).

The baseline two variables everything else builds on

• TC_ROOT — Teamcenter install directory; TC_ROOT\bin holds the utilities and (for TCCS-based clients) the connectivity libraries.
• TC_DATA — the data model directory; one per site. tc_profilevars (the file, not just the variable) lives here and is the source of truth for the full variable set a properly-configured client machine should have.

These two are described as "the only environment variable settings required to run the core Teamcenter application" — everything else (integration-specific variables) layers on top of this base.

Source: Quora/community summary reflected in search results for TC_ROOT/TC_DATA, corroborated by Tutorial: Learn the Teamcenter Command Prompt

TCCS (Teamcenter Client Communication System) — the variable that trips up third-party/remote clients

TCCS is the layer most third-party integrations (NX, and generically any client not running on the same box as the web tier) actually depend on for locating and authenticating to a Teamcenter server. The recurring failure pattern reported by practitioners:

• TCCS_CONFIG_HOME — if this doesn't point at the correct TCCS config directory (or is left pointing at a stale/previous install's config), the client can't resolve which Teamcenter environment to talk to. One practitioner reported that correcting a mismatch in TCCS_CONFIG_HOME was what actually fixed an NX-to-Teamcenter-via-TCCS-and-proxy connection failure — the symptom looked like a generic connection error, not an obvious "wrong env var" error.
• FMS_HOME — a stray USER or SYSTEM-level FMS_HOME variable pointing at the wrong TC_ROOT\tccs folder (e.g., left over from a previous Teamcenter version install) was called out as a separate, easy-to-miss cause of connection failures, because Windows will happily keep an old system-level env var around across upgrades unless it's explicitly cleaned up.
• UGII_TCCS_ENV_NAME — for NX specifically, this variable (set before launching NX from the command line) selects which named TCCS environment to use. If a machine has multiple TCCS environments configured (e.g., pointing at DEV vs PROD Teamcenter), forgetting to set this — or having it set to the wrong name — silently connects the client to the wrong server rather than failing outright, which is a nastier failure mode than an outright connection refusal.

Source: Using TCCS with NX – Eng-Tips (title/topic confirmed; full thread body returned HTTP 403 on direct fetch, so specifics above come from the search-engine's summarized snippets of the thread, not a verified full read), TCCS cannot connect to Teamcenter server from client PC – Siemens community KB article (article exists per search index; direct WebFetch returned only a loading shell with no article body — content not independently verified, flagged as a dead end below)

Licensing environment variable (adjacent but frequently confused with connection failures)

• SPLM_LICENSE_SERVER — set inside tc_profilevars.bat, format <port>@<host>, e.g. 28000@licenseserver. Default license-server port is 28000.
• Reported gotcha: if SPLM_LICENSE_SERVER is set to a semicolon-separated list of multiple license servers, Teamcenter is reported to only actually read the first entry in that list — so a failover-style multi-server list does not behave as a practitioner might assume; each client effectively only tries one server.
• Also flagged: firewall blocking of port 28000 between client and license server presents as a licensing failure that can look identical to a connection/env-var misconfiguration from the user's point of view — worth checking port reachability before chasing env vars.
• This is relevant to connector troubleshooting specifically because a bad license-server env var can produce an error message that looks like a connector/credential problem (e.g., a third-party connector reporting a generic "license problem" on login) when the real fault is server-side or network-side, not in the connector's own config. This exact failure signature (a connector's login flow surfacing a bogus "licence problem" that was actually caused by something else entirely — in that case a WinNAT port-reservation conflict, not an env var) has already been independently confirmed in this workspace's own Capital Manager / HCL connector troubleshooting; see this KB's capital-manager-winnat-port-conflict notes for the internally-verified case.

Source: search-engine summary of Siemens community threads on SPLM_LICENSE_SERVER and license-server port configuration (specific thread URLs were not individually fetched/verified beyond the summarized snippet)

Active Workspace / web-tier side gotchas

• Port mismatches between the various pieces of a Teamcenter + Active Workspace install (web tier, AWC, FMS) are called out generically as a common source of "it looks configured but doesn't connect" problems.
• If the web-tier instance is named anything other than the OOTB default (tc) — e.g., tcprod — this has been reported as a source of compatibility friction specifically with Active Workspace on .NET, because some client-side config assumes the default instance name unless explicitly told otherwise.
• initEnv.cmd is the script that sets up the Windows command-line environment variables needed for Active Workspace development/customization work specifically (distinct from the core tc_profilevars used for the base Teamcenter environment).

Source: search-engine summaries citing SpiritPLM's Active Workspace Installation write-up and Global PLM's Active Workspace Installation page (neither page was independently fetched/verified in full; titles and the summarized claims above came from WebSearch's own snippet synthesis)

Third-party MBSE/EA connector angle (Cameo/HCL, Capital)

• A dedicated Siemens Support KB article exists titled "Teamcenter and Capital Integration – Integration Architecture, Versions, Environment Variables" (KB000131740) confirming that Siemens does document required environment variables for the Capital↔Teamcenter integration specifically — but the article sits behind the authenticated Siemens support portal, and this research pass could not retrieve its body (WebFetch returned only the page's title/header, no content). This is a known dead end: the KB article's existence is confirmed, its content is not.
• No independently-fetchable web source was found describing the HCL Cameo Connector's TC_SERVER_URL-style variables in detail; the only concrete, verified information already available on this exact point lives in this workspace's own prior work (hcl-cameo-tc-connector.md memory: cloud TC server URL needs a /tc suffix, and USE_JCEF_BROWSER=false is required) rather than in any new web source surfaced this pass.

Summary of dead ends (be honest about these)

1. community.sw.siemens.com KB article on TCCS connection troubleshooting — exists, body not retrievable (login/JS wall).
2. Siemens Support KB000131740 on Capital↔Teamcenter environment variables — exists, body not retrievable (authenticated portal).
3. Eng-Tips NX/TCCS thread — full body not retrievable (403); only search-snippet summary available.
4. No web source (beyond this KB's own prior HCL connector notes) documents the actual HCL Cameo Connector environment-variable names/values in detail.