Our organization has grown to four Windchill sites spread across North America, Europe, and APAC, all running 11.1 M030. We’re wrestling with a challenge that I suspect many multi-site shops face: how do you maintain consistent Windchill preference settings across all sites without creating a maintenance nightmare?
Currently, we manage preferences at three levels — site, organization, and context — and the interplay between them is causing headaches. Some preferences set at the org level get overridden locally by well-meaning site admins, and we have no easy audit trail to track who changed what and when.
Specifically, we’re debating a few trade-offs:
Centralized vs. distributed wt.properties management: Should we push a master wt.properties from a configuration management repo (we use Git) and accept that site-specific overrides require a formal change request, or should each site own their properties with a shared baseline?
Preference locking: Windchill lets you lock preferences at certain levels so lower-level admins can’t override. How aggressively are others locking preferences? We’ve found that over-locking creates support tickets, but under-locking creates inconsistency.
Organizational vaults across WAN links: Our APAC site has latency issues when accessing the primary vault. We’ve deployed a replica vault, but keeping preference pointers consistent is tricky.
Would love to hear how other teams have tackled this, especially those managing more than two sites. Are there any third-party or homegrown tooling approaches that have worked well for preference drift detection?
Preference drift across distributed Windchill sites is a well-documented operational pain point, particularly when the three-tier hierarchy (site → organization → context) is administered by teams with different change discipline levels.
Diagnostic Steps — Establishing Baseline State
Export current preferences from all four sites using Preference Manager (wt.clients.applicationframework.preferences.PreferenceManager) and diff the XML outputs. Store snapshots in Git alongside your wt.properties baseline.
Audit the xconfmanager layer: run xconfmanager -d wt.properties on each server and compare. Properties set outside of site.xconf inheritance can silently override without tracing.
Query wt.preferences.WTPreference directly via the Windchill database to identify preferences with locked=false at org scope that have been overridden at context scope — this surfaces the “well-meaning admin” problem precisely.
Enable method server logging at DEBUG for wt.clients.applicationframework.preferences temporarily to capture runtime preference resolution; correlates override timing to user sessions (verify in your version for log category names).
Review MethodServerLog and correlate with wt.pds.server.ContentServiceMgr entries for vault-related latency spikes — separates vault-pointer issues from pure preference inconsistency.
Tuning Parameters
Parameter
Recommended Value
Notes
wt.replication.policyproperties.sync.interval
300 (seconds)
Reduce if replica vault pointer drift is frequent (verify in your version)
wt.pds.replica.readLocalThreshold
50 (ms)
Forces APAC to read local replica below this WAN latency threshold
wt.method.clientTimeout
120000 (ms)
Prevents preference fetch timeouts over high-latency WAN
Preference Locking Strategy
Lock at organization scope for anything security- or compliance-relevant (CAD worker roles, access control defaults, numbering schemes). Leave context-level unlocked for workflow and display preferences — this is the practical threshold that reduces support noise without creating drift on material settings. Document locked preferences in your Git repo as a preference_lock_manifest.xml with owner and justification.
For drift detection, a lightweight homegrown approach: schedule a nightly Python script pulling preference exports via the Windchill REST API (/Windchill/servlet/WindchillAuthGW/wt.enterprise.RevisionControlled) and committing diffs to Git with automated email on delta. No third-party tooling required.
Monitoring / Verification
After any push from your master wt.properties, run xconfmanager -p on each node and compare checksums. Set up a Windchill Info*Engine task (verify task adapter availability in 11.1 M030) to query WTPreference objects weekly and flag any locked=false overrides at context scope against your manifest.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We went through exactly this about 18 months ago with three sites (US, Germany, India). The Git-based wt.properties approach you mentioned is what we landed on, and it’s been mostly positive. We use a templated properties file with site-specific variable substitution handled by Ansible at deploy time. The key insight was separating infrastructure properties (cache sizes, thread pools, LDAP endpoints) from behavioral properties (workflow timeouts, numbering schemes). Infrastructure ones we lock down via Git and require a change ticket. Behavioral ones we allow org-level override but require documentation in a shared Confluence space.
One thing I’d strongly recommend: use the Windchill Preference Manager UI audit capabilities alongside your own logging. In 11.1 M030, preference changes do get logged to the method server log, but you have to explicitly enable the wt.pref.PrefMgr debug category to get useful detail. We pipe those logs into Splunk and have alerts for unauthorized changes to a defined set of critical preferences.
For your latency/vault concern — are you using Content Replication Server (CRS)? That’s the supported path for APAC vault consistency, though setup is non-trivial.
The preference locking question is the one I have the strongest opinions on. We over-locked early on and regretted it. When everything is locked at the site level, regional admins lose the ability to adapt to legitimate local requirements — think different document numbering conventions for Japanese JIS standards vs. US ASME. We ended up creating a three-tier classification:
Red preferences: Always locked at site level, no exceptions. These are things like LDAP server addresses, replication schedules, security-related settings like wt.auth.sso.enabled.
Yellow preferences: Locked at org level, can be changed by org admins with approval workflow. CAD integration paths, default lifecycle templates.
Green preferences: Free for context-level admins to set. UI customizations, notification email thresholds, personal default searches.
Documenting this classification and communicating it to all admins cut our support tickets by roughly 40%. The key is writing it down explicitly — don’t assume people know what they can and can’t touch. We maintain a preference governance document on our internal wiki and review it quarterly.
From a consulting perspective I’ve seen this problem at probably a dozen clients. One thing that consistently trips people up in 11.1 M030 specifically: the interaction between site.xconf, wt.properties, and the Preference Manager database entries is not always intuitive. Properties set in wt.properties take precedence over the database-stored preferences for the same key in many cases, but not all — there are some preference categories where the database wins. Always test your precedence assumptions explicitly after an upgrade or patch.
Also worth noting: PTC’s xconfmanager utility is your friend for programmatic property management. Rather than hand-editing wt.properties directly, scripting changes through xconfmanager gives you a cleaner change record and handles the site.xconf overlay properly. We’ve built wrapper scripts around it for clients that write to a log file with timestamp and operator ID before executing any property change.
I’ll offer a slight counterpoint to the Git-for-everything approach. We tried it and found that the overhead of formalizing every property change into a Git commit and PR was too slow for incident response. When a method server is misbehaving at 2 AM APAC time, the last thing an on-call engineer needs is a code review gate before they can adjust a connection pool setting.
What we do now is a hybrid: Git holds the desired state configuration, but we allow emergency out-of-band changes with a mandatory post-hoc pull request within 24 hours. We use a nightly drift detection script that compares the live wt.properties against the Git baseline and emails the config team if deviations exist. It’s not perfect — the script is fairly brittle around comment formatting — but it catches the cases where a 2 AM fix never got formalized.
For preference drift specifically in the Preference Manager UI, I’m not aware of a native export/compare tool in 11.1 M030 that works well for cross-site comparison. If anyone has solved this cleanly I’d genuinely like to know.
Thank you all — this has been genuinely one of the more useful threads I’ve started here. Let me try to synthesize what I’m taking away, both for my own thinking and for anyone who finds this later.
On wt.properties management: The consensus seems to lean toward Git-backed desired state with tooling (Ansible, xconfmanager wrappers) handling the actual deployment. The hybrid approach from tchenoweth resonates with us — we need the governance structure of Git without it becoming a bottleneck during incidents. We’ll look at implementing that emergency-override + 24h PR policy.
On preference locking: The red/yellow/green classification from mlarsson is something we’re going to adopt almost verbatim. It maps cleanly onto our organizational structure. I particularly like that it puts the governance conversation in human terms that non-technical site managers can understand, rather than saying ‘locked at org scope vs. context scope.’
On audit/drift detection: kpatel’s suggestion about enabling wt.pref.PrefMgr debug logging and routing to Splunk is actionable immediately. We already have a Splunk instance. The xconfmanager wrapper logging that abowen mentioned is also something we can build in a sprint. tchenoweth’s point about the lack of a native cross-site preference comparison tool is unfortunately true in our experience too — we may have to build something custom using the Windchill REST APIs to export preference values and diff them.
On the APAC vault: We do have CRS licensed but haven’t fully configured it. kpatel’s confirmation that it’s the right path gives us confidence to invest in that setup properly.
One follow-up question if anyone is still watching: for those using xconfmanager in scripted pipelines, are you running it as the windchill OS user directly, or through a service account with sudo rules? We’ve had some permission inconsistencies that might be related to this.