Symptoms
Certain AD DS domain migration scenarios involve changes in the AD integration with K2.
Simple update of the security label configuration and pointing it to a different AD domain along with re-running of the K2 configuration works in this scenario, but certain things become broken afterwards:
- Process permissions are not setup correctly anymore, as the FQN contains the domain name
- Process history now points to other users, rendering it useless
- The Identity tables will be flooded with "duplicate" users, meaning, the old FQN will be disabled, while the new FQN will be added.
You may think of some alternative way which could in theory solve all the issues listed above by direct edits of K2 database. This is not recommended or supported operation. You either use what is availabe from GUI or K2 API for any tasks and purposes but not direct database changes unless guided specifcally to do so by K2 support.
Diagnoses
Most of the time direct edits in K2 database are not supported and this is also the case for scenario described above. Approach which involves direct edits in the K2 (Identity, reporting, permissions etc.) to change to new domain is not supported.
And as for now moving between different domains using supported approach will imply that when moving from domain A to domain B, migrated users (i.e. their K2 FQNs) will be seen as new users and they will be cached as that and it will be necessary to re-assign permissions using the new domain name.
Theoretically process side issues can be addressed in a following way:
1. Deployed processes will need to be updated and redeployed, as needed, to reflect new users (in case if you hard-code users anywhere in your processes). Roles can be updated via Workspace easily.
2. Live process instances will need to be updated (redirected) to reflect the new domainuser. Any active process instances could theoretically be redirected using Workspace or the API to the user's new userID in the new domain. Doing a redirect has the added benefit of automatically updating process instance rights. There is still the issue with things like process originator.
3. Historical data. I am not really sure you need to do anything with historical data for completed process instances. I suspect you will actually want to leave completed instances alone, so they will accurately reflect which account(s) truly interacted with them.
These are things to think about while planning for this change. Some places in the documentation to review include:
Live Instance Management (LIM):
http://help.k2.com/onlinehelp/K2blackpearl/DevRef/current/default.htm#Live_Instance_Management.html#tracksearch=live instance management
LIM will allow you to change which process version a single instance completes against. This is handy, for example, when you need to deploy a new version update destination users, and then want to migrate existing process instances to use that new version.
How to use K2 Workspace to redirect process instances:
http://help.k2.com/onlinehelp/K2blackpearl/UserGuide/current/webframe.html#Reference-WS_MCon-Workflow-WorklistRedirect.html#tracksearch=worklist redirect
K2 Designer for Visual Studio - K2 Process Management:
http://help.k2.com/onlinehelp/K2blackpearl/UserGuide/current/webframe.html#Reference-ST-Error_Repair.html
Also check the K2 Developer Reference (http://help.k2.com/files/7549).
Resolution
Current supported way of changing K2 AD DS integration when domains are changing assumes that when moving from domain A to domain B migrated users (their K2 FQNs) will be seen as new users and they will be cached as that.
To perform such migration from K2 side it is necessary to update security label configuration pointing it to a different AD DS domain and re-run K2 configuration wizard. Following that, it will be necessary to re-assign permissions using the new domain name.
To improve handling of such migrations in the future there is an existing feature request to add some utility/option which will allow to update K2 Identities to reflect migrated domain (internal TFS item ID 577956).
There is also an existing request to create official KB article on domain migration topic (internal TFS item ID 635941).
As domain consolidation is a difficult process which may involve different complexities it is usually recommended to engage with K2 professional services for such projects.
Some other general recommendations to make this process a bit more smooth:
1) Do some testing in staging environment to verify your migration approach. Consider using Active Directory Lightweight Directory Services to simulate new domain/security label and test out your users/process migration approach.
If side-by-side migration is possible (without immediate removal of old domains) consider using it as it leaves you some safety margin/flexibility.
2) Disable OOF for all users and try to complete all process instances before merging your domain to avoid any issues with live process instances post-migration.
