Wt.properties changes not taking effect after method server restart in Windchill 11.1

Hi everyone,

I’m running into a frustrating issue with wt.properties changes not being picked up after restarting the Windchill Method Server on our 11.1 M030 instance.

Here’s what I’m doing:

  1. SSH into the Windchill server as the windchill OS user.
  2. Edit $WT_HOME/codebase/WEB-INF/conf/wt.properties directly and add/modify a property, for example:
wt.org.defaultOrganization=MyOrg
wt.queue.processors=8
  1. Stop the Method Server using windchill stop.
  2. Start it again using windchill start.
  3. Verify using windchill wt.method.RemoteMethodServer — but the old property values are still being reported.

I also tried modifying xconf/wt.properties.xconf and running ant -f bin/projMake.xml but no luck either. The logs at $WT_HOME/logs/method/MethodServerLog.txt show the server is starting cleanly with no errors.

I noticed there’s also a site.xconf and a wt.properties under $WT_HOME/wtSiteData — not sure if those are related or take precedence.

We’re on:

  • Windchill 11.1 M030
  • Oracle JDK 1.8.0_291
  • Oracle DB 19c
  • RHEL 7.9

Any ideas on why the method server isn’t picking up the updated properties? Is there a correct precedence order for these files that I’m missing?

Thanks in advance.

This is a classic Windchill configuration precedence issue. Let me walk you through the full picture so you understand what’s happening and how to fix it properly.

Root Cause

Windchill 11.1 uses a layered xconf-based property management system. There is a strict precedence order for property resolution, and editing codebase/WEB-INF/conf/wt.properties directly is not the supported method because that file is auto-generated by the xconf build pipeline.

Property Precedence Order (highest to lowest):

  1. $WT_HOME/wtSiteData/wt.properties — site-level overrides, highest precedence
  2. $WT_HOME/codebase/WEB-INF/conf/wt.properties — generated from xconf processing
  3. Default values embedded in PTC JARs

Within the xconf pipeline, site.xconf overrides wt.properties.xconf, which overrides component-level .xconf files.

Correct Procedure for Persistent Property Changes:

Step 1 — Edit site.xconf:

vi $WT_HOME/site.xconf

Add your property entries using xconf syntax:

<Property name="wt.org.defaultOrganization" overridable="true">
  <value>MyOrg</value>
</Property>
<Property name="wt.queue.processors" overridable="true">
  <value>8</value>
</Property>

Step 2 — Run the xconf ant target to regenerate wt.properties:

cd $WT_HOME
ant -f bin/projMake.xml -Dforce=true

This will process all .xconf files and regenerate codebase/WEB-INF/conf/wt.properties with your values merged in.

Step 3 — Verify the generated file contains your entries:

grep 'wt.org.defaultOrganization' $WT_HOME/codebase/WEB-INF/conf/wt.properties
grep 'wt.queue.processors' $WT_HOME/codebase/WEB-INF/conf/wt.properties

Step 4 — Restart the Method Server:

windchill stop
windchill start

Step 5 — Confirm the property is live:

windchill wt.properties wt.queue.processors

If You Need an Emergency Change Without a Full Build:

Add directly to $WT_HOME/wtSiteData/wt.properties (plain key=value format, no xconf XML). This file is not overwritten by ant builds and takes the highest precedence:

wt.org.defaultOrganization=MyOrg
wt.queue.processors=8

Restart the method server afterward. Be aware this is a manual bypass and you should reconcile these into site.xconf during your next scheduled maintenance window to keep the configuration clean and version-controllable.

Why Your Changes Were Being Lost:

You were editing the generated wt.properties file and then running ant -f bin/projMake.xml, which regenerated the file from the .xconf sources — overwriting your edits. Always treat codebase/WEB-INF/conf/wt.properties as a build artifact, not a source file.

Also verify there are no duplicate keys in wtSiteData/wt.properties from a previous admin that might be shadowing your xconf changes.

Hope this clears things up completely. Let us know if you still see issues after following the xconf approach.


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.

Hey raj, the first thing to check is whether your changes are actually in the right file. In 11.1, wt.properties under codebase/WEB-INF/conf/ can be overridden by xconf processing. If you ran ant -f bin/projMake.xml after your edits, it may have regenerated the file and overwritten your manual changes. Try checking the timestamp on the file after the ant build completes — it likely reset your values.

Also worth checking: do you have a wt.properties under $WT_HOME/wtSiteData? That directory’s properties file typically has the highest precedence for site-level overrides. If a property is defined there with an old value, it will win over what you set in codebase/WEB-INF/conf/wt.properties. I got burned by this exact thing on a 11.1 M020 upgrade.

Thanks both. I checked the timestamp — you’re right, the ant build did regenerate the file and wiped my edits. But even when I add the properties after the ant run and before the restart, they still don’t take effect. And yes, there is a wt.properties under wtSiteData. Should that be the only place I make changes? How does xconf tie into all of this? I’m confused about the correct workflow for persistent property changes.

The correct pattern is to define your custom properties in site.xconf rather than editing wt.properties directly. When you run the ant target, it processes all .xconf files and writes the merged result. If you need something quick without a full rebuild, adding to wtSiteData/wt.properties directly can work but you still need to be aware of any overlapping keys. Also double-check there’s no wt.properties.xconf in the xconf directory with a conflicting entry for your keys.

Tested this on Windchill 11.1 M030, and adding our custom properties to wtSiteData/wt.properties instead of editing codebase/WEB-INF/conf/wt.properties directly survived the xconf rebuild and took effect after method server restart.