This article describes some common uses cases and gives hints how to successfully migrate your user accounts.
You want to migrate an Spider Operations Manager user account to another one. This is often required when switching from a local organisational model to an AD/LDAPimported organisational structure.
User account migration is never an easy task! The migration depends a lot how the old and the new organisational models are structured and how the users are assigned to the workflow roles.
This article describes some common uses cases and gives hints how to successfully migrate your user accounts. However it will probably not fully cover your individual requirements. Our consultants can support you with the migration if you have any requirements/questions that are not covered by this article.
Terminology
Please read the terminology to better understand what can be migrated automatically and what cannot:
Direct assignment: A user is directly assigned to a container (workflow or organisational).
Example: John Doe is directly assigned to 1st Level Support:
Indirect assignment: A user is not directly assigned to a container. It is indirectly assigned over one of his parents or via another container.
Example: John Doe is indirectly assigned to ?1st Level Support? via?OM 1/Support? organizational unit membership.
Whereas the OU membership itself is a direct assignment of John Doe. :
Member: A user may be member of a container (workflow role, organisational unit/role). This can be a direct or an indirect assignment. A user can be member of more than one container. Also container scan be members of other containers.
Child (of a parent container): For a user there is exactly one parent-child relationship. This is the ?organisational home? of the user, the place where the user belongs to. Note: This is not a direct assignment nor is it a membership assignment.
Example: John Doe is child of OU 1.User 2 is member of OU 1
Account migration rules:
Starting the Migration
Precondition:
As a working example, we migrate ?John Doe? from ?OM 1? to ?AD-OM2?.
Current workflow assignments:
John Doe is member of the ?Support? organisational unit.
The ?Support? OU is member of ?1st Level Support? participant group inthe Incident workflow model ?My Helpdesk?.
Logout the user from OperationsManager
First, the user has to be logged out in OperationsManager. Go to the OperationsManager Webapp and login as System Administrator (e.g. wnadmin) and go to ?Who isOnline?. If the user you want to migrate has active sessions, invalidate them by clicking ?Logout?.
Migrate the user
Locking the old account is a good choice if the old account should not be used anymore but not deleted yet.
This will migrate all direct user assignments and configurations for OperationsManager and anyworkflow model.
In the easiest use case, e.g. when the migrated user was directly assigned or via membership (as in our example) the migration is already done.
In this example, John Doe from OM 1 was migrated to John Doe from OM 2.
Note: The migrated user John Doe (OM 2) is now member of the old ?OM 1/Support? OU! This means that the user migration was successful. However, you should not delete the organisational structure of ?OM1? yet, since it is still required and assigned to the workflow roles. To completely clean up the old OM 1, you would have to migrate away these memberships too .
Validating the migration
There are two ways to validate the user account migration and to see if there are assignments left that have to be reassigned manually.
The first and most pragmatic way is to login as the new migrated user and checking if it has still the same work items/tickets assigned and has access to the previous workflow operations and -objects e.g. ?Create Ticket?.
For doing this,the System Administrator can impersonate as another user without knowing its password:
Now you can verify if the migrated user has access to all previous workflow operations and-objects.
If all your assignments have been migrated automatically and everything looks good, thenyou can skip this and go to the next chapter.
The secondand more accurate (but also more complex) method is to verify the user?s indirect assignments via the assignment report:
Now the assignments report shows you all indirect assignments. In the following example the old user is indirectly assigned to ?1st Level Support? via OU 1(OM 1):
Validate the result against the list of indirect assignments of the migrated user.
Identify missing assignments
Some indirect assignments cannot automatically be migrated and are now probably missing. They need to be reassigned manually. One example is the Child/Parent relationship.
Example:The parent object of Peter Smith (Office) was assigned to ?1st LevelSupport?. This is a Parent/Child-Assignment and not a membership assignment. Therefore it cannot be migrated automatically.
So after the successful user migration, the ?1st Level Support? contains still the old ?Office? OU:
The consequences are that the migrated user Peter Smith (AD-Company) is not yet in the 1st Level Support.
Create missing assignments
So what we have to do, is to manually assign the parent OU (Office) from Peter Smith (AD-Company)to the ?1st Level Support? role by drag&drop the ?Office? OU into the ?1st Level Support? role.
This has tobe done for all missing assignments until the migrated user has the same indirect assignments the old user had.
Note: If the old assignment (Office à 1st Level Support) is not required anymore, it can be removed. This helps to reduce the complexity.
Remove old Organisational Model
After all users and organisational structures (including their indirect assignments) are properly migrated, the old organisational model can be deleted.
Tips & Tricks:
Applies to OM4
on Nov 06, 2018 09:03 PM - edited on Aug 27, 2019 04:57 AM by jborchers