Happy to give you a comprehensive answer here since I’ve hit this exact wall before.
Root Cause
The Windchill Deployment Manager (WDM) computes a SHA-256 hash for every file in the package and embeds a signed manifest (package-manifest.xml) at package creation time. Any modification to the ZIP after sealing — whether you’re swapping tokens, re-compressing, or even just re-saving with a different ZIP utility — will change one or more file hashes, making the manifest stale and causing the integrity check to abort deployment. Cross-platform issues (Linux → Windows CRLF translations) compound this.
The Correct Architecture: Separate Static Artifact from Environment Config
Do NOT embed environment-specific values (URLs, DB credentials, LDAP endpoints) inside the sealed deployment package. Instead, follow this two-layer pattern:
Layer 1 — Static Package (sealed by WDM):
Build the package once with placeholder-neutral defaults or empty values for environment properties. Seal it with Deployment Manager. This artifact is promoted unchanged through every environment.
Layer 2 — Environment Override (applied post-deploy):
Store env-specific .xconf files in your source repo under config/env/prod/, config/env/qa/, etc. These are NOT part of the WDM package.
Example override file (prod-overrides.xconf):
<?xml version="1.0" encoding="UTF-8"?>
<Configuration targetFile="codebase/WEB-INF/conf/wt.properties">
<Property name="wt.rmi.server.hostname" value="prod-wc-host.corp.com"/>
<Property name="wt.db.user" value="wt_prod_user"/>
<Property name="wt.server.codebase" value="http://prod-wc-host.corp.com/Windchill"/>
</Configuration>
In your Jenkins PROD deployment stage, after WDM deploys the sealed package successfully, run:
# Apply PROD environment overrides
$WT_HOME/bin/xconfmanager -p config/env/prod/prod-overrides.xconf -t codebase/WEB-INF/conf/wt.properties -s
The -s flag saves and propagates changes without requiring a restart at this stage. Then bounce the Windchill services normally.
Fixing the Jenkins Pipeline
- Remove the sed token replacement step entirely.
- Store your WDM-sealed ZIP in Nexus/Artifactory. Reference it by artifact coordinates (groupId, artifactId, version) — never re-download and re-archive through Jenkins.
- Add a post-deploy stage in Jenkinsfile:
stage('Apply PROD Config Overrides') {
steps {
script {
def wtHome = env.WT_HOME ?: '/opt/ptc/Windchill'
sh """
${wtHome}/bin/xconfmanager \\
-p ${WORKSPACE}/config/env/prod/prod-overrides.xconf \\
-t ${wtHome}/codebase/WEB-INF/conf/wt.properties -s
"""
}
}
}
- For secrets (DB passwords), pipe them from your vault (HashiCorp Vault / Jenkins Credentials) into the xconfmanager call at runtime rather than storing them in the xconf file.
Cross-Platform Note
If you must transfer ZIPs between Linux build agents and Windows PROD servers, always use binary-mode transfers (SCP, Artifactory binary download, or robocopy /b). Never use FTP in ASCII mode or Jenkins workspace copy between heterogeneous OS agents — both can introduce CRLF corruption.
Verification Step
Before deploying to PROD, add a pipeline stage that independently verifies the SHA-256 of the artifact:
sha256sum MyCustomization_v2.4.0.zip # Linux
Get-FileHash MyCustomization_v2.4.0.zip -Algorithm SHA256 # PowerShell
Compare against the hash stored in Nexus at publish time. If they differ, halt the pipeline before WDM even sees it.
This pattern has worked reliably for us across 11.1 M020 through M030. The key insight is: the WDM package is your immutable artifact; xconfmanager is your environment injection tool.
Hope that unblocks you!
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.