The focus of this tutorial is to show How to Migrate Users and Groups With ACL Permissions in AEM from one server to another or from one AEM instance to another in project.
In a real time scenario, Most of us used to have multiple CQ Publisher instances in different environments (DEV, QA, PROD, etc.). And for testing purpose we want to keep all environments in sync . In such scenario, you have to copy over both user group and the acls permission to lower versions like (DEV, QA, PROD, etc.), that we are going to learn in this tutorials and trouble shoot most of the common errors or mistakes that you might face.
Steps to Migrate User and groups with ACL Permissions:
For migrating or copying users and groups definition from one AEM instance to another, we follow the approach of creating a package of users/groups definition , then install the package to the destination AEM instance.
Note :- Take a back of existing User/group definitions . By adding /home in filter.
- Go to crx package manager.
- Create a new package and enter below details in Filters tab.
- Add one more exclude rule to remove admin user and replication-receiver user, as these users has lockable node property hence cannot be copied on destination instance. If still you are getting same error check where admin user is stored in destination instance and exclude that path also.
- Add rep:policy to include permissions of individual nodes as a part of package.
Note:- Add all rep:policy nodes where you have stores the permissions like /content/rep:policy.
- Go to Advanced tab and set ACL Handling to overwrite from dropdown.
Note:- The Overwrite access control tells Jcr Package to overwrite the ACLs in the destination AEM instance during installation
- Click save.
- Build the package and click download.
- Your package is ready upload it on new AEM instance and your users and groups will be migrated with appropriate Acls permissions.
Important Points to remember while migrating Users and Groups with ACL Permissions:
- Always take a backup of /home folder at both instances.
- Same user should not be present on both instances else it’s password will be overwritten.
- The above method will replace users and groups with Users of new instance, if users are present on destination instance which are not available at source instance then they will be deleted. To resolve it take a individual backup of users and groups in a separate package and run this package on top of our package.
Note:- Above method replaces users and groups folder to destination instance. Carefully use exclude scripts.