CQ 5.5 Update 1: Service unavailable – AuthenticationSupport service missing. Cannot authenticate request.


CQ 5.5 Update 1 is now available on PackageShare.  If you have installed CQ 5.5 Update 1 you may encounter the following error in the error.log after restarting the CQ instance:

*ERROR* [0:0:0:0:0:0:0:1%0 [1340016598398] GET / HTTP/1.1] org.apache.sling.engine.impl.SlingHttpContext handleSecurity: AuthenticationSupport service missing. Cannot authenticate request.


After installing the Update 1 package, an info dialog appears which advises to “restart the instance”.  If you restart the instance immediately after the dialog appears, you will run into this problem.  Even after the dialog appears, the package keeps on installing behind the scenes.  This process is interrupted if the instance is restarted at this point.

You should wait until the installation has completed before restarting CQ5, checking the activity in error.log.  Once the error.log becomes quiet (after approx. 5 mins) it is safe to restart the instance.


After installing Update 1 check that all OSGi bundles have the status “ACTIVE” in the OSGi console.  Start any bundles that do not have the “ACTIVE” status and this should resolve the issue.

If the issue persists, you may have to reinstall CQ5 from a fresh copy, install the update 1 package, restart (wait until error.log shows no more activity) and finally reinstall your installed packages manually.

reference: (CQ5-18534)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 4.9/10 (14 votes cast)

LiveCycle ES3: Authentication failed for user (Scheme – Username/Password) Reason: Username or password is incorrect


If you are accessing any LiveCycle services and have problems getting a response, you may notice the following warning in the server logs:

WARN  [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-21) 
Authentication failed for user [user] (Scheme - Username/Password) Reason: Username or password is incorrect. 
Refer to debug level logs for category com.adobe.idp.um.businesslogic.authentication for further details


If you enable DEBUG level logging you will see the following DEBUG information in the log:

DEBUG [com.adobe.idp.common.errors.exception.IDPLoggedException] (Thread-21)
UserM:: [Thread Hashcode: 1796127844] com.adobe.idp.common.errors.exception.IDPLoggedException|
[com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] errorCode:12803 errorCodeHEX:0x3203 message:
Authentication failed for user [user] (Scheme - Username/Password) Reason: Username or password is incorrect
 =========== Authentication failure detail report ================== 
 Scheme Type : Username/Password 
 UserId : user 
 Current Thread : ajp- 
 Following are the response details from various authProviders.  
 1 - com.adobe.idp.um.provider.authentication.LocalAuthProviderImpl - 
 Authentication Failed : Exception stacktraces are avialable at TRACE level 
 Messages collected for this AuthProvider are provided below
      - No local user found with UserId [user] in Domain [DefaultDom]
      - No local user found with UserId [user] in Domain [EDC_SPECIAL]

These warnings in the log may also be accompanied by an Error 500 if you are attempting to call the LC services through a browser/web application.


This issue can occur when you are attempting to access the services with a user account that does not exist in the LiveCycle database, especially when you are migrating applications from one LiveCycle environment to another (e.g. ES2 to ES3).  User accounts that were used by applications in the 1st environment will also need to be available in the 2nd environment.


Try whichever of the following solutions is applicable to your environment:  (contact your LiveCycle administrator if you do not have sufficient privileges)

1. Synchronize your LDAP server with LiveCycle (AdminUI > Settings > User Management > Domain Management > (Select LDAP Domain) > Sync Now)

2. Create the user manually in a local LiveCycle domain (AdminUI > Settings > User Management > Users and Groups > New User)

reference: (183300170)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 1.0/10 (2 votes cast)

CQ5.5: Upgrade recommendations and information

This information will be useful if you are planning to upgrade your CQ environment to CQ5.5. This information is intended as a supplement to the official upgrade documentation:  http://dev.day.com/docs/en/cq/current/deploying/upgrading.html

You should read these recommendations, and then follow the steps in the upgrading documentation, applying the added suggestions here as required.

Trial migration

It’s better to first run a dry-run migration on a clone of UAT (author & publish instances) to ensure that there are no major issues in the upgrade process. Check if there are any changes needed for your code to work on the upgraded version. In this case, change the code and ensure you have a consistent process for applying those changes. Identify any high risk areas in the code and plan for extended testing time on these areas following the upgrade.  Repeat the steps from scratch on the UAT clone so that you’ll be sure to have a consistent end-to-end process for the upgrade. Then proceed to upgrade all the environments: DEV, UAT & PROD.


  • Create a clone of the instance to upgrade.  You’ll perform the upgrade on the clone. It will be easier to rollback in case of problems.
  • Perform a full consistency check on the repository early.  Fix any problems before attempting the upgrade/migration.
  • Read the extensive list of “Tips and Troubleshooting” in the upgrade documentation and apply the recommended changes to avoid these common problems.
  • The code-base has to be frozen before the upgrade process and all the existing bugs closed. In case it’s not possible to close all bugs, keep a detailed list of them and double check them on the upgraded version.
  • Only do 1:1 migrations. Only introduce new product features for editors/business later. This will let you focus on the migration itself and any regressions.
  • Try to get dedicated hardware for all environments (PROD + staging), this gives you much more flexibility.
  • Involve Adobe consulting if required.  This will ensure a smooth migration process adhering to best practices.
  • Compile a list of all connected systems and involve those teams in the migration planning.  Ensure they have a short turn-around time in case of issues.
  • Purge workflow history (this speeds up the update process).
  • Make sure all workflow tasks are finished (none are running).
  • Make sure you have at least 1024MB Heap configured during update.
  • Clean all the logs to make it easier to isolate upgrade issues.
    • crx-quickstart/logs/*
    • crx-quickstart/server/logs/*


Tests should cover complete authoring workflows and not just the correct rendering of templates.

Check ACLs and permissions (especially when updating from 5.2.1).

Check Workflow models – check if any customizations were overwritten.

Check all forms and form actions (especially when updating from 5.3 or older).

Production upgrade

After performing the upgrade process on a UAT instance, once you are ready to upgrade the production instances, there shouldn’t be any major/unexpected issues. The code-base should already be frozen and in a good state, and you should freeze out content changes also. Only urgent changes should be applied to the content and the author team will need to keep track of all updated pages. These can then be moved later with a package.

1. Follow all the steps documented in the upgrade docs.

2. Sign-off the environments.

3. Migrate the latest content changes (if needed).

4. Switch the instances.

5. Delete all the dispatcher(s) cache.

It’s better to keep the old instances available for a while in case of problems not encountered during all the documented steps.  You should plan enough time for bug fixing following the production upgrade.

reference: (35335)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 6.3/10 (4 votes cast)