Summary

This article describes some common uses cases and gives hints how to successfully migrate your user accounts.

Synopsis

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.

Discussion

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 1^st 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 ?1^st 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:

• Direct assignments are migrated automatically.
• Membership assignments will be migrated in most cases.
• Child-parent relationships will NEVER be migrated.
• In the best case, you only have direct assignments or membership assignments that fit your requirements. Then the migration is a quick and easy process.
• But more likely you also have child/parent assignments or the new organisational structure does not fit your requirements, then you have to add the missing assignments manually after the migration (see later).
  
  

Starting the Migration

Precondition:

• The new (target) user is already created/imported.
• You need to be System Administrator (e.g wnadmin)
• The migration requires the following steps:
• Logout the user from OperationsManager
• Migrate the user
• Validate the migrated user
• Identify missing assignments
• Create missing assignments
• Remove old OM/OUs

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 ?1^st 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

• Start the Administration Client application and login as System Administrator (e.g.wnadmin).
• Navigate to the old user you want to migrate.
• Right-click on the user and select ?Migrate??
• In the migration window, navigate to the target user and click OK.
• In the next window you can optionally lock the old user account after the migration.
  

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:

1. Login in OperationsManager Webapp as System Administrator and navigate to ?System Administration?.
2. In ?Impersonate User? field, search for the new user by its login name and click the user name link.
3. You are now impersonated as the other user.

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:

• In the Administration Client right-click the old user and select Reports ->Assignments
• Select only the indirect assignments in the filter.

Now the assignments report shows you all indirect assignments. In the following example the old user is indirectly assigned to ?1^st 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 ?1^st 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 ?1^st Level Support? contains still the old ?Office? OU:

The consequences are that the migrated user Peter Smith (AD-Company) is not yet in the 1^st 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 ?1^st Level Support? role by drag&drop the ?Office? OU into the ?1^st 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 à 1^st 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:

• Sometimes it is useful to create a helper organisational structure if the AD structure does not reflect your existing organisational structure.
• Remove the old indirect assignments when they are not required anymore.
• Lock the old user after migration to prevent him to login with the ?wrong? (old)account.
• Keep the old and locked user account and organisational structure for a few moredays until the migrated account is confirmed as working.

Products

Applies to OM4