Windchill PDMLink from 11.1 (On Prem) to 12.1 (AWS Cloud) upgrade WindchillDS related queries

[mprasad]

Source: Windchill 11.1 MO20

Target : Windchill 12.1.0

Question --The source system uses windchillDS for authencitcation, as i understand the target system does not support windchillDS , also the taget system is on AWS ,.Then what options we have , shall we migrate it to openDS or to some AWS services , kindly suggest. 

[mmeadows-3]

Upgrade and changing LDAP providers are two separate tasks.  The upgrade from 11.1 to 12.1 must use WindchillDS.  So, plan to do the upgrade on premise.  Once upgraded, rehost Windchill into the AWS environment and redirect user accounts from WinchillDS to the target LDAP service provider.

According to PTC, provided it is a v3 compliant LDAP, the target LDAP is up to your IT department and security policies.  WindchillDS will still work with Windchill 12.1, but PTC no longer supports WindchillDS and does not encourage using it in production with Windchill 12.1 and later.  OpenDJ is the foundation of WindchillDS and the natural standalone LDAP replacement.  It is possible to export the users' DNs from Windchill DS and import into OpenDJ (see my lengthy post half way through this thread).  But only the community edition is available.  If your IT policy forbids open source software, you may need another option independent LDAP option as discussed in this thread.

Most companies we support are switching from an independent Windchill LDAP server to the corporate LDAP server.  They are using Windows credentials and sometimes setting up Single Sign On for logging into Windchill.  This transition requires converting the Windchill user accounts in the database from WindchillDS to the corporate LDAP (e.g. Active Directory).  A key performance requirement in these configurations is to ensure the LDAP response times are fast and fault tolerant.  Windchill performance and stability will suffer if a US based Windchill server has to go to the EU to validate user accounts.  Pointing to two identical nodes or an LDAP load balancer helps avoid outages when one node goes down.

WindchillDS didn't require cleanup or deletion of old accounts.  So, the first step (even before upgrade) is to determine what accounts are no longer in use, clean them up and delete them from Windchill and LDAP.  Someone at the company should know who is still there and who is gone.  You can use a last login report to make it easier to identify inactive accounts.  After cleanup, you only have to worry about migrating the active accounts from WindchillDS to the target LDAP (CS341008).

[mprasad]

Thanks, it helps.

[jbailey]

Theoretically, it could be rehosted first and then upgraded. It seems the question is around Windchill 12.1 not supporting Windchill DS, not necessarily the AWS instance not supporting it. What is important to take from this though, is that if there is a base domain change, that is what requires this to be done in two steps (https://www.ptc.com/en/support/article/CS235106?source=search). If their hosts on AWS are using the same domain as the source system, they also theoretically could do a Rehost Upgrade - all in one step, and address the moving of data to an enter. 

Also, they could split the project into having a third activity - Migrating users to another v3 compliant LDAP before upgrade, and then the upgrade process would only include moving the non user Windchill DS data to the DB during the upgrade process. This option might be preferred if they need to compress the upgrade window.

From an enterprise LDAP standpoint, I would hope if they have replication LDAP for different locations - and if that is the case, and if users are segregated in LDAP by region, you could add additional adapters to point to distinct DC's for each region. One thing to remember though is that they have to have a completely different search base.

Additionally, if they are using a tool like Veeam for backup/recovery, it can theoretically migrate servers from On-Prem to AWS, and then you would just run the rehost script (Although I don't know how well Veeam handles the DB side of things).