Businesses want to move the whole legacy CQ application to new AEM 6.0/ AEM 6.1. There are different types of migration from legacy to new AEM version and it all depends on the version of the legacy application. If it is below CQ5.6 then there might be a lot of effort needed to make things work. Assets & static data can be moved easily but moving components & bundles might be a big hurdle.
However, we are here to talk about how do we move users to new AEM instance without any manual effort. When we proceed to migrate users & their groups, the first thing that comes to our mind is that let’s create a package of all the users & their groups and install it in another instance. This seems pretty right approach and convincing as well. To be fair, the AEM package manager module is built for such things (Importing/Exporting content & AEM stuff).
But when you try to install a package that contains users & groups info of legacy system, it throws a big exception and leaves you with no hope. Let’s see the exception first..
com.day.jcr.vault.packaging.PackageException: org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0025: Authorizable property rep:authorizableId may not be removed.
|—————————————-Big LOG——————————————————
| —————————————————————————————-
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0025: Authorizable property
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0025: Authorizable property rep:authorizableId may not be removed.
|—————————————-Big LOG——————————————————
| —————————————————————————————-
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0025: Authorizable property
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0025: Authorizable property rep:authorizableId may not be removed.
What to do now? Create all the users & their groups in another system? Not a good idea, you can’t simply do that. What about their passwords?
Here is the solution:
Well, many of us as AEM developers agree that package manager is the right tool for moving content (even taking backup of content). Though it does not work efficiently for moving large content and assets. There are multiple open source solutions. For instance, “GRABBIT” is one of the best and fastest tools to transfer content from one system to another.
Let’s get back to our problem in hand. In this case, the package manager throws a big exception and does not provide a clue here.
But if you look closely, it seems, the package manager is not able to override the admin accounts. Actually, CRX is not allowing admin users to be overridden. In a way, it is right in doing so. Our personal opinion is that CRX is not allowing admin users to be overridden because admin has all the privileges and AEM stores permissions information in a different way. It maintains “rep:policy” nodes to keep privileges and can’t be overridden just like that.
Package manager does help when you want to move users & groups privileges from one instance to another which is a different case.
In order to solve the above problem, we are still going to use the package manager. Follow the steps below:
- Create a package and put all the users & their groups.
Exclude a few users & groups :- admin & administrative anonymous (not necessary but good to keep it excluded)
- If the same user & group are found in both environments; delete from AEM 6 instance before installing a 5.6 user package. You should ignore admin & anonymous here too
- Install it
- To verify your accounts, log in with any of your groups. Also you can verify logged-in user’s privileges.
Note :
This solution is tested and proven in one of our applications. However, if you still find any issue, leave a comment, we will try to help you.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.