When you migrate to Shared Services, all native Essbase users and groups that do not already exist in an external authentication directory are converted to native Shared Services users and groups in the native Shared Services user directory and are given equivalent roles. For example, a native Essbase Administrator (previously known as Supervisor) becomes a Shared Services user with the Essbase Administrator and the Provisioning Manager roles assigned, and a native Essbase user with Calc privileges on a database becomes a Shared Services user with the Calc role assigned on the application that contains the database. During migration, Administrators and Application Managers are automatically given the Provisioning Manager role for the appropriate applications.
Note: | When Essbase runs in EPM System security mode, the Essbase create/delete user privilege becomes obsolete. You must be an Essbase administrator to create/delete Essbase users and, additionally, you must be a Shared Services administrator to create/delete users in Shared Services. |
Any externally authenticated users are registered with Shared Services but remain stored in their original authentication directory. If a user directory is not running, the entire migration fails.
Any disabled Essbase users or groups do not migrate.
An Essbase user name cannot exist as a group name in Shared Services. If it does, the Essbase user does not migrate.
In Shared Services, if an Essbase application contains multiple databases, the databases must have the same user security access levels. During migration, if a user has different access levels for two databases in the same application, the user is given the more restrictive access level for both databases. In such cases, a warning is sent to the Administrator who ran the migration and the information is logged in the AccessModifiedUsers_n.txt file, which is located in the ARBORPATH/bin directory.
Users and groups are migrated in the following order:
If a migration fails, the status of the migration depends on the point at which it fails. For example, if the migration fails at step 1, then the total migration fails. If a migration fails at step 2, the result depends on the reason for failure. If a migration fails at step 3, when one or more users fails to migrate, then applications and groups may have been migrated.
Users and groups that fail migration are listed in the essbase.sec file, which is located in the ARBORPATH/bin directory.
When you use Administration Services Externalize Users Wizard to migrate Administration Services users or to remigrate Essbase users that previously failed to be migrated, migration errors are logged in the file that you specify in the wizard, as well as in the Essbase Server log (EPM_ORACLE_HOME/logs/essbase/essbase.log).
If a group fails migration, all users in the group fail migration; you must repair and migrate the group in order for the users to migrate successfully.
If a group exists in both Essbase and Shared Services, the following conditions apply:
Shared Services cannot contain two groups at different levels in the same hierarchy (an ancestor-child relationship) when the groups exist in Essbase (see Example 2). If it does, the entire migration process fails.
The Shared Services group cannot contain a user that does not exist in the Essbase group of the same name. If it does, the Essbase group, and all users in the group, do not migrate.
The Essbase group cannot contain a user that exists in Shared Services, unless the Shared Services user belongs to the Shared Services group of the same name. If it does, the Essbase group, and all users in the group, do not migrate.
The following examples highlight group migration considerations:
Example 1: The groups in this example migrate successfully from Essbase to Shared Services.
Essbase has groups named group 1 and group 2:
group 1, group 2
Shared Services has two identical groups and also has a group 3, which contains group 1 and group 2:
group 3 | group 1, group 2
The groups migrate successfully because group 1 and group 2 are at the same level as each other in Shared Services and because Essbase does not have a group 3.
If group 3 has Administrator (previously known as Supervisor) access to the Essbase Server instance and Essbase group 1 and group 2 have user access, the resulting group 1 and group 2 in Shared Services will have Administrator access. |
Example 2: The migration in this example fails because Shared Services contains group 1 and group 2 at different levels.
Essbase has groups named group 1 and group 2:
group 1, group 2
Shared Services has group 1 and group 2, but group 1 contains group 2:
group 1 | group 2
Example 3: The migration in this example fails because Essbase contains group 1, group 2, and group 3 and Shared Services contains group 3 at a different level from group 1 and group 2.
Essbase has groups named group 1, group 2, and group 3:
group 1, group 2, group 3
Shared Services has group 1 and group 2, but has a group 3, which contains group 1 and group 2:
group 3 | group 1, group 2