Troubleshooting AEM MSM issues

This article describes ways to troubleshoot any AEM MSM issues. Further, it discusses the following:

  • Finding advanced information about your Blueprint and Livecopies status
  • Checking the MSM-specific information in the repository
  • Information to provide when raising a MSM Support ticket

Description description


Experience Manager


Basic verifications to start with:

Resolution resolution

Finding advanced information about your Blueprint and Livecopies status

Multi-Site Manager (MSM) registers several servlets that can be requested with selectors on the resource URLs.

They are used by the UI but can also be requested directly to see directly additional advanced computed MSM statuses for your pages:

  1. http://host:port/content/path/to/bluprint/page.blueprint.json?&maxSize=500&advancedStatus=true&returnRelationships=true&msm%3Atrigger=ROLLOUT
    Use on a Blueprint page to retrieve the list of all livecopies linked to it, with advanced LC status.

  2. http://host:port/content/path/to/livecopy/page.msm.json
    Use on Livecopy pages to get advanced information on their connection with their Blueprint page.

    If the page is not a Livecopy, nothing is returned.

Those servlets generate DEBUG Log messages through the logger that are worth checking as well.

Checking the MSM-specific information in the repository

The servlets above returned computed information based on the MSM specific nodes and Mixins.
The information is stored the following way.

  • cq:LiveSync mixin type

    This is set on jcr:content nodes and define root Livecopy pages.

    Those pages will have a cq:LiveSyncConfig child node of type cq:LiveCopy that will contain basic and mandatory information on the Livecopy through the following properties:

    • cq:master - points to the Blueprint page of the Livecopy
    • cq:rolloutConfigs - indicates active Rollout Configurations applied on the Livecopy
    • cq:isDeep - is true if the child pages of this root Livecopy page are included in the Livecopy.
  • cq:LiveRelationship mixin type
    Any livecopy page has such a mixin type on its jcr:content node.

    If not, the page has been at some point detached, or manually created via the authoring interface outside of a Livecopy action (create or rollout).

  • cq:LiveSyncCancelled mixin type
    Added on jcr:content nodes of Livecopy pages that were suspended.

    If the suspension if effective for child pages as well: a cq:isCancelledForChildren=true property is added on the same node.

The information present there should be reflected in the UI of course, however in abnormal situations you might encounter where you can question the UI or MSM Behavior, superusers can verify directly those nodes to understand the status of their MSM Pages.

Knowing those properties can be also useful in order to query your repository and find out sets of pages that are in particular states.

Example: select * from cq:LiveSync will return all Livecopy root pages.

Information to provide when raising a MSM Support ticket.

You might eventually require AEM Support assistance.

When raising a support ticket in the support portal, qualify the issue as best as possible following guidelines in the following KB article

For MSM issues those additional precisions should be added ideally:

  • Before attaching logs: enable DEBUG level for the logger in /system/console/slinglog, and repeat the problematic MSM Action.
  • Attach the output of config http://<host>:<port>/libs/wcm/msm/content/commands/rolloutconfigs.json
  • Communicate the rollout configurations attached to the Livecopies
  • If the problem seems to come from the UI (browser console error or UI error popup appears): Generate a HAR file to capture the complete flow from the user perspective when performing the problematic MSM action: see this link for details on HAR file generation

Reproducing the issue is the easiest way for support to quickly analyze and determine if the behavior is normal or not, and act accordingly.

For this purpose, try to:

  1. Reproduce your problem on a similar setup based on We-Retail Pages
  2. If not possible, try to build a content package that includes sample content of yours, in order for a support engineer to install it on a blank AEM instance with same patch level as yours, and reproduce the issue.