Issue with the disconnected participants in upgrades

[HJ1]

I'm curious whether it's always an issue with the disconnected participants.

Not any of the previous upgrades we've had done by VAR (10.2 -> 11.0 -> 11.1) even on the same servers have gone without manually reconnecting each user after upgrade.

Upgrading 11.1 -> 12 and servers changing it seems even more like mission impossible. Tried both, either picking the AD adapter config in Upgrade Manager and editing not to point to source production system, or rebuilding AD from scratch.

[rleir]

It seems that you need to understand how DS works too. I mean WindchillDS (the old discontinued system) or 389DS (the new recommended system) or Redhat's integrated DS (based on the 389DS project). 

Corrections please on this: authentication at login checks a user's credentials: first in DS, and then goes to the AD or other LDAP system.

[vnamboodheri]

Hello @HJ1 

It looks like you have a response from a community member. If it helped you solve your question please mark the reply as the Accepted Solution. 

Of course, if you have more to share on your issue, please let the Community know so other community members can continue to help you.

Thanks,

Vivek N
Community Moderation Team.

[mmeadows-3 · Accepted solution]

It really depends on how you are planning to integrate with LDAP in 12.0 and later.  If this is an upgrade from pre-12.0 to 12.1 or later, you can/need to use PTC's WindchillDS through the upgrade process.  The upgrade manager will handle all updates and pointers for WindchillDS.  At the end of the upgrade, there should not be any disconnected participants.  If so, someone probably made the wrong picks in the upgrade manager.

Prior to upgrade, on the upgrade source, are you running WinDU's "Upgrade Property Viewer" task to generate the input values for the upgrade manager?  This will generate the correct LDAP settings.  Just copy the output file (...\Windchill_11.0\Windchill\Upgrade\ReviewedSourceUpgrade.properties) to the upgrade target (...\Windchill_11.0\Windchill\Upgrade\UpgradePhases\GatherUpgradeProperties\upgradeUser.properties) before upgrade.  That 'should' provide a clean upgrade for the LDAP entries.

I've seen upgrades go sideways where all the users were left in an old LDAP structure (e.g. ...,OU=people,DN=Windchill_10.2,...) when they should have been moved to the target release LDAP structure (e.g. ...,OU=people,DN=Windchill_12.1,...).  I don't recall the bad picks in the upgrade manager that caused this.  I just manually manipulate WindchillDS post-upgrade using Apache Directory Studio to correct the issue and update all the DNs in the Windchill database to correct the issue.  If just the DN is changing, this one liner can fix it.

update RemoteObjectId set remoteObjectId=replace(remoteObjectId,',cn=windchill_10.2,o=ptc',',cn=windchill_11.1,o=ptc') where path like '%,cn=windchill_10.2,o=ptc';

If the JNDI Adapter is changing, the database change are more extensive.

After reaching your target release (post 12.0), integrate with the chosen LDAP going forward (not WindchillDS) and redirect all LDAP entries to the chosen LDAP.  This is more tedious (https://www.ptc.com/en/support/article/CS109367), but it is a one-time task.  Future upgrades won't manipulate user accounts.  I manually repair the default Windchill site administrator to the corporate LDAP server first.  Then, once Windchill starts, I login as the site administrator, search disconnected participants, and repair the others.  If there are hundreds or thousands of users, I do the repairs at the DB level, following the article, and then search disconnected participants to ensure they are really repaired.

What LDAP are you planning to use post-upgrade: a corporate LDAP like Active Directory, a Windchill dedicated read-write LDAP like OpenDJ, multiple LDAP servers?  @rleir mentioned 389DS because that is what PTC uses internally to support their hosted offering.  Most customers with a Windchill dedicated LDAP are using OpenDJ because that is the source code for PTC's WindchillDS.  However, PTC supports using any L3 compliant LDAP.  They do not support the LDAP products themselves, just integrating with them.  Most companies are switching to the corporate LDAP (usually Active Directory), and a few have a mixed environment of corporate and Windchill dedicated LDAPs.

[HJ1]

Thanks for this, really appreciate it! I opened the topic just before vacation, therefore quiet for some time   🙂 

The scenario is an upgrade from pre 12.0 to 12.1, using WindchillDS for the upgrade. Then going to migrate to OpenDJ.

I maybe should've emphasized the fact that the issue is with the users authenticated in company Active Directory, ie the 'actual' licensed users. These end up as disconnected participants. However, the test and admin users maintained only in WindchillDS are ok.

Whether the AD connection was included in Upgrade manager "Additional Adapters" or not made no difference, disconnected participants all the same.

However, as the source/current Production is active during the upgrade, naturally, I want to rename / recreate the AD adapter for the upgraded system. Also, Windchill 12.1 will go live on entirely different servers from the previous.

Now, I just followed the article CS109367 and it seems to have provided the missing link: I did not know to update table OwningRepositoryLocalObject with the reference to the new repository for the AD adapter. Also, table WTUser repairNeeded -flag needed to be set to "0"...

All in all, way too tedious indeed!

[Shashwath]

Hello,

You need to import the DS backup to the New Upgraded Machine properly.

Check this below point. This might resolve the issue.

1. DS is not imported Properly.

2. Check if the user's are deleted from LDAP Directly.

3. Check Personal cabinet administrator.

4. Check participate Administrator> Action> Disconnect the User