Migrating Imported Groups between BusinessObjects Instances

If you just thought that migrating groups is not a problem since I only have one instance, then shame on you, but that is a topic for another day. Assuming you do have separate CMS’s for Development, Test, and Production, in an idea world you would set up your security in your development instance, test to make sure it works and them migrate those setting through test and into production. Unfortunately using an external authentication group prevents you migrating your groups. This is because when migrating an object between SAP BusinessObjects instance the Cluster Unique Identifier (CUID) is used. When using external groups you cannot migrate them you have to import them into each instance. This causes the same group to have a different CUID in each instance. This means that as far as SAP BusinessObjects is concerned they are not the same group.

Since the security you build in development is actually tied to the CUID when you migrate the report the security will be lost and you will have to rebuild it in each instance.

Imported group development CUID


Imported group in production has the same name but different CUID


If you use an enterprise group instead since they can be migrated and have the same CUID on all instances.

Enterprise group development CUID


The enterprise group production has both name and CUID in sync.


So how do we get our imported groups to work like our Enterprise groups? Short answer: Group Hierarchy’s. Child groups in a hierarchy inherit SAP BusinessObjects security applied to a parent group. With this in mind we can create enterprise groups to correspond to all of our externally imported groups. Create a hierarchical relationship with the enterprise group the parent and the imported group the child.



When we apply group security we should only apply security to enterprise groups. Always make sure to migrate a new enterprise group by itself before any security is applied to it, if the group does not exist in the target environment its security setting will be lost during migration.

You will notice that the imported group is not a child of the enterprise group in the environment you just migrated it to since it could not be migrated the relationship is lost. So you will have to do a one-time set-up in each environment to map the hierarchical relationship between the enterprise group and the imported group.

Now when you migrate an object with security assigned to an enterprise group the security setting will also be migrated, and applied to your imported groups also.

A special thanks to my colleague Josh Koch who taught me this technique awhile back.

Leave a Reply
