Windchill Deleted / Deactivated User Process

[JoePriest]

I know that there are other topics on this over the years but I have some specific questions that I don't know if I've seen them explained fully and all in one place.  We connect to our corporate AD for users and it's read-only.  When a user leaves the company, they are removed from the AD group that Windchill points to and they are left in a Disconnected state.  We don't have access to that process.  We just end up with a Disconnected user.  

Given that setup:

1. If you don't delete Windchill Disconnected users, what do you do with them?  We think that we would need to create a new WindchillDS user that we would reconnect them to.  We would have to alter the display of the name to indicate that it's inactive.  We would also remove them from all groups which is good enough for us as we don't put individuals into profiles.  How has your process worked for you?  How is your process different?  What challenges do you have with that process?
2. Under 11.1, we are dealing with the licensing profiles.  Does anyone have experience with the inactive users negatively impacting the license counts?  Were any new challenges introduced to your user deletion/deactivation process with these profiles?

Thanks for any input you have.

Joe Priest

Johnson and Johnson

[MikeLockwood]

Joe, really good questions.  We're very hesitant to go to 11.1 for this type of thing - collecting all related info and trying hard to plan for it.

We're still manually creating user accounts but using network passwords.  Monthly, we see who has not logged in for at least 45 days and move them to a Site level DeactivatedUsers group that WINDU picks up and recognizes and not active, then remove from all other groups, etc.  There is a related property that has to have that group name exactly.

Please share what you learn on this and ideally any procedure that you develop for handling.

[JHall]

@JoePriest 

Joe,

We have just recently (a couple weeks ago) added Active Directory to our Windchill installation.  But I am VERY interested in this converstation, so I can give you the answers I have so far below.

If you don't delete Windchill Disconnected users, what do you do with them?
Historically I've changed their password, deleted their email, renamed them to Jane Doe [Deactivated], and moved them to a Deactivated Users group that has restricted permissions.

We think that we would need to create a new Windchill DS user that we would reconnect them to.
Do you mean if they are reactivated somehow? I'm not sure what you mean here.

We would have to alter the display of the name to indicate that it's inactive.
This is something that I' don't know what happens to AD users that are disconnected.

We would also remove them from all groups which is good enough for us as we don't put individuals into profiles.
I think our Deactivated Users group would work for this. We could put them in there.

How has your process worked for you?
Before AD it's worked very well.

How is your process different?
We have contractors that we reactivated by editing their Windchill DS accounts and moving them back to the groups where they had their permissions restored.

What challenges do you have with that process?
I had to get hooked up with the HR termination process, but after that it's been fine.

We are currently on Windchill 11.0 and this licensing issue on 11.1 is not very appealing.

James

[LewisLawrence]

We have the exact same setup as you. Every week we check for disconnected participants. If it has been more than 60 days since the user last logged onto active directory (easily accessible info using a "net user" command), then we remove them from Windchill. We use the 60 day threshold to avoid accidentally deleting someone who may just be out, if the AD account is marked Inactive it marks the Windchill user as disconnected.

The removal process involves handling any workflow tasks they have (tasks are re-assigned to responsible people in the contexts where they exist), cleaning up any workspaces and checked out objects they have, then deleting the user from Windchill. They are then removed from all role memberships, deleting the user automatically removes them from all groups but not all roles.

I am curious why you wouldn't want to delete the user if they have left your organisation? Deleted users are unable to receive new workflow tasks, don't show up in any groups and are nicely marked as deleted in the user interface. There is also a command line utility to "undelete" a user, so worst case you can get them back if you ever need to.

[JoePriest]

What is this undelete command line utility to un-delete that you speak of?

[JHall]

@LewisLawrence 

The main reason we have kept deactivated users in the past was because they had created CAD or other content and we wanted their names to remain on that content history. 

However you stated "nicely marked as deleted in the user interface."  Since I'm new to Active Directly, could you say more about this?  Do the Users remain on the history but appear as deleted somehow?

Also, I'm very interested in 'un-delete' also, because we have contractors that come and go from our system.

James

[TomU]

Deleting a user from Windchill doesn't remove all trace of them from the system.  Their entry in the WTUser table continues to exist, but they are no longer linked to an LDAP account (Windchill DS or Active Directory), they no longer have a personal cabinet (think workspaces), and they cannot participate in workflows or be a member of a group.

[JHall]

@TomU 

That looks really good Tom, thanks!

[LewisLawrence]

The names still show up in the user interface, they clearly show deleted and you can still search for them and use them in Advanced search etc. An added bonus is that they cannot receive any new tasks in the system.

The only weird thing is that upon deletion the username is changed;

"lewis" would become "{wt.org.WTUser:XXXXXXXXX}lewis" where XXXXXXXXX is the internal database ID for the user account.

This also means (I think because of the curly brackets) that to search for the user you have to use wildcards; "*lewis*" would return the account above after it has been deleted, but the full txt above would not. Only a nuisance if you need to search up the user for an advanced search or similar.

If you have a test system you could easily do some experimentation.

[LewisLawrence]

https://www.ptc.com/en/support/article?n=CS200852&language=en&posno=1&q=restore%20deleted%20user&source=search

[mweicheld]

Hi Lewis,

I work with Joe Priest, we're curious about the removal process/procedure you described. Are there out of the box admin tools to identify the user's workflow tasks, are you using standard search functionality, or did you develop custom reports? Have you automated this process, it seems that it will be laborious to perform on a regular basis?

With regards to not deleting users, we have found and issue where deleting the users leaves resolved tasks blank in our custom Impact Assessment within our CR process, which is not acceptable in our environment.

[LewisLawrence]

I am not aware of any out of the box admin tools to move tasks around, we developed a command line utility that does it. We added a role "Task Administrator" to our contexts and by default anyone in there gets added to the role for the workflow/object in place of the disconnected user, many contexts have more than one Task Administrator. The only stumbling block with using this role approach is that once a task has been "Accepted" by the user I don't believe it is possible to "Un-accept" on their behalf. Those tasks you have to re-assign and you can only re-assign a task to one person. Before we had the utility we used a report template to return all the tasks for a user, then navigated to the object and updated the roles or re-assigned tasks as needed.

There were a few reasons we started this user clean up;

• Reducing Support, we often had users following up on "lost" things
• Licensing, we only have user accounts in the system for "Active" users
• Internal Audit, our internal security teams don't like accounts living on in systems after a user has departed the organisation
• Trying to reduce the number of old workflows we have running.
  I know what we did helped with that, but it is really an ongoing issue for us and probably most Windchill customers. Issues come at upgrade time when you need to retest processes, if there are old processes running then you really need to test those execute in the new system too. We have had Windchill running since 2002, for our 10.1 upgrade back in 2013 we forced anything older than 9.1 (it was in production for a couple of years) to be completed or we killed it off. Where possible newer processes we deploy have an automatic routing of "decline/fail/end/cancel/whatever" after X days to avoid this situation going forward, but we still have an issue with old/stale running processes that I don't have a fix for.

[LewisLawrence]

Regards your custom impact report "losing" the user details, I suspect you need to review how you are returning the user for that report. The user object is still there, just marked as deleted and is probably being filtered somehow when you don't want that.

[TomU]

We also have the same configuration here where Windchill is fully integrated with Active Directory.  Let me copy @JHall's format and also try to answer each of your questions.

If you don't delete Windchill Disconnected users, what do you do with them?

The main problem with disconnected users is that they become 'invisible' to Windchill.  While a user is disconnected you can't find them in any of the normal participant lists.  This means you can't locate objects (CAD files, promotion requests, etc.) based on their user name.  For 'view only' users, having them disconnected and unsearchable isn't a big deal, but for content creators you will want to either reconnect them to a different account or delete them from Windchill.

We think that we would need to create a new Windchill DS user that we would reconnect them to.

This is more of a preference thing.  Do you want to allow users to be actually deleted from Windchill or just look like they're deleted?  If you intend to actually delete them, then there is no need for a dummy account to connect them to.  If you prefer to never delete anyone, then yes, you will need a different account to connect them to - either in Active Directory or in Windchill DS.

We would also remove them from all groups which is good enough for us as we don't put individuals into profiles.

Same here.  We generally use profiles to define permissions and then add groups to those profiles at the product/library level.

How has your process worked for you?

Works good.  Because certain Active Directory groups (that Windchill can see) have been added to corresponding Windchill groups, I don't have to manually assign permissions in Windchill every time I.T. creates a new user account.  As long as I.T. puts people into the correct groups in Active Directory, they are automatically given the correct permissions in Windchill.  Yes, I.T. still makes sure they let me know when a new user is being added (for license compliance reasons), but it really simplifies the process of adding new people to the system.

How is your process different?

Possibly closer communication with I.T. and H.R., especially when it comes to people who are returning to the organization.  As soon as an account is visible to Windchill, Windchill will immediately create a new user account for the corresponding AD account and then there will be two separate, unrelated accounts with the same name - one that says 'Deleted' and one that doesn't.  To prevent this I make sure I.T. notifies me BEFORE someone is re-added to Active Directory who existed previously.  This gives me a chance to undelete their Windchill account (cause it to become disconnected again) so when the AD account reappears it has something to snap to.

What challenges do you have with that process?

Again, if I.T. forgets to tell me about users getting getting re-added, I end up with double accounts in the system.  Yes, it is possible to delete them from the database, but it's a real pain.

Windchill 11.1

We have not made the jump to 11.1 yet.  Probably will wait until 11.2 drops in June.  At this point I don't expect any major changes to my approach.  I just have to make sure I'm aware of who is getting added to the system so I can maintain sufficient license counts.

One other thing to consider.  Certain processes in Windchill require an email address.  Giving more than one user the same email address will cause the upgrade/migration process to fail.  If a user is given an email address, it must be unique.