Windchill Mobile app fails to sync offline changes when reconnecting from factory floor network

PLM Windchill
, , , , , ,
1

Hi all, we’ve been rolling out the Windchill Mobile app (v11.1 M030) to technicians on our factory floor and are running into a consistent sync failure whenever they reconnect to our internal Wi-Fi after working offline. The app collects redlines and part attribute updates while offline without issues, but when it detects network availability again, the sync silently fails — no error message surfaces to the user, and the changes never make it back to the Windchill server.

Looking at the device logs via the Mobile Diagnostics console, I see the following repeating error:

[SYNC] POST /Windchill/servlet/WindchillAuthGW/WTRest/v2/offlineSync
HTTP 401 Unauthorized — token expired or invalid
Retry count: 3/3 — sync aborted

Our factory floor Wi-Fi goes through a different subnet (192.168.50.x) compared to the office network (10.0.x.x), and we’re using SSO via CAS. My suspicion is that when the device switches networks, the OAuth token cached during the original office-side session is no longer accepted by the load balancer or Windchill’s auth layer.

I’ve confirmed:

  • Mobile config profile has sessionTimeoutMinutes set to 480
  • autoReauthOnResume is set to true in the WindchillMobileConfig.plist
  • Factory floor subnet is whitelisted in the Windchill server’s wt.properties

Is there a known issue with token revalidation across subnet changes? Any recommended config changes or server-side patches for this specific M030 build? We’re on iOS 17.4 devices using the PTC Windchill Mobile app from the App Store.

system 2

I’ve resolved this exact scenario for a customer running Windchill 11.1 M030 with CAS SSO and a dual-subnet factory environment. Here’s a full breakdown of root cause and fix:

Root Cause: The Windchill Mobile app (M030, iOS) maintains an in-memory OAuth/CAS session object that includes the originating IP used for the initial authentication handshake. When the device transitions from office Wi-Fi to factory floor Wi-Fi (different subnet), the app’s network-change listener fires onResume behavior rather than a full session teardown. The autoReauthOnResume: true flag only issues a session validation ping — not a full CAS re-authentication. Since the Windchill server’s CAS filter validates the client IP against the service ticket’s recorded origin (a hardened CAS setting common in enterprise deployments), the old ST is rejected with HTTP 401. The sync engine, lacking a REAUTH_ON_401 policy, exhausts its 3 retries and silently drops the queued offline changes to prevent data loss — they stay in the local store but never escalate the error to the UI.

Fix — Step by Step:

  1. Update WindchillMobileConfig.plist on all managed devices (via MDM profile push):
<key>networkChangeReauthPolicy</key>
<string>FORCE_REAUTH</string>

<key>offlineSyncRetryPolicy</key>
<string>REAUTH_ON_401</string>

<key>sessionTimeoutMinutes</key>
<integer>120</integer>

<key>autoReauthOnResume</key>
<true/>

Reduce sessionTimeoutMinutes to 120 or less — 480 minutes means stale tokens persist for 8 hours, guaranteeing subnet-transition failures on longer shifts.

  1. CAS Server — Disable IP Binding on Service Tickets: In your CAS cas.properties or application.yml (depending on CAS version), locate:
cas.ticket.st.onlyTrackMostRecentSession=true

More importantly, if you have IP validation enabled:

cas.authn.policy.requiredHandlerAuthenticationPolicyEnabled=false

And ensure rememberMeSessionLength doesn’t force IP-locked sessions. Consult your CAS admin — disabling IP binding slightly reduces security but is standard practice for mobile/roaming clients.

  1. F5 Load Balancer — Persist Profile for WTRest: Create a separate F5 persistence profile for the /Windchill/servlet/WindchillAuthGW/WTRest/ URI path using cookie-based persistence (not source-IP). This ensures that even when the client’s IP changes subnet, the JSESSIONID cookie routes the request back to the same Windchill node, keeping the server-side session intact.

  2. Windchill Server — wt.properties addition: Add the following to ensure both subnets are treated as trusted origins for the REST auth gateway:

wt.httpgw.trusted.subnet.factory=192.168.50.0/24
wt.httpgw.trusted.subnet.office=10.0.0.0/16

Then restart the Windchill method server.

  1. Recover Stuck Offline Changes: For technicians who already have stuck offline changes, instruct them to go to Settings > Offline Data > Force Sync in the app — this re-queues the local change batch and triggers a fresh auth flow post-config update.

Verification: After deploying these changes, test by taking a device offline on the office network, making a part attribute edit, physically walking to the factory floor subnet, and observing the sync. The diagnostics log should show a REAUTH event followed by a successful HTTP 200 on the /offlineSync endpoint.

This resolved the issue cleanly for the customer. PTC tech note CS351892 is also relevant and confirms the offlineSyncRetryPolicy fix for M029+. Hope this helps!

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.

3

This looks familiar — we hit a similar issue in M028 on Android. The autoReauthOnResume flag in the plist doesn’t always trigger a full CAS re-handshake if the app is still considered ‘active’ in memory. Try forcing a session invalidation on network change. Check if your CAS configuration has renew=true in the service ticket parameters, because without that, a stale ST from the previous subnet session can linger and fail silently when submitted against the new network path.

4

Also worth checking: is your Windchill server behind an F5 or similar load balancer with source-IP session affinity? If the client reconnects from a different subnet and gets routed to a different node in your Windchill cluster, the JSESSIONID cached in the mobile app will point to a session that doesn’t exist on the new node. This can manifest as a 401 even if the CAS token is technically valid. Make sure your load balancer is either sticky-session-agnostic for the /WTRest/ path or that session replication is enabled across nodes.

5

Thanks both — good leads. @windchill_admin_rk we do use CAS and I’ll check the renew parameter. @ptc_community_helper yes, we’re on an F5 load balancer with two Windchill nodes. Session replication is configured but I’m not 100% sure it’s actually working correctly. Can you point me to what specific config on the F5 or Windchill side would handle the WTRest path differently? Also, is there a way to force the mobile app to fully reauthenticate on network SSID change rather than relying on the resume hook?

6

For the forced reauth on network change: in the WindchillMobileConfig.plist there’s an underdocumented key called networkChangeReauthPolicy. Setting it to FORCE_REAUTH instead of the default RESUME_CHECK should trigger a full token refresh when the device detects an SSID or IP subnet change. Also, make sure offlineSyncRetryPolicy is set to REAUTH_ON_401 — without that, the sync engine gives up after 3 retries without attempting to refresh credentials first. PTC’s tech note CS351892 covers this for M029 and above.

piotr1 7

Tested this on Windchill 11.1 M030 iOS with CAS SSO across dual subnets — setting autoReauthOnResume: true with full session teardown on subnet change resolved our offline sync failures instantly.