Skip to main content


AEM Infrastructure Series: Making the Case for Consistency

Oreo CookieThe Adobe Deploying and Maintaining AEM documents are an invaluable reference for the new or experienced systems administrator installing and configuring Adobe Experience Manager on premise. Despite the wealth of references, I all too often see installations that were not well thought through and result in maintenance headaches that would have been easy to avoid, but can be challenging to remedy after-the-fact. Common problems include:

  • Inconsistent installation paths, permissions, and ownership;
  • Inconsistent startup settings and overall configuration;
  • No planning or forethought for disaster recovery and expansion;
  • Little or no monitoring of AEM instances;
  • Poorly documented release processes and inconsistent access restrictions;
  • Lack of, or not adhering to a standardized maintenance plan;

These are just a few of the challenges customers face; employee turnover and juggling multiple vendors only aggravates the problem. Deploying AEM for the long-term involves careful planning, clear and repeatable documentation, and a maintenance plan that follows established best practices not just from Adobe, but from your internal IT team.
It seems obvious, right?
Not always. For organizations that are new to AEM, getting up and running initially on the platform in a way that adheres best practices and promotes long-term maintainability is often overlooked. This task is sometimes given to an experienced AEM developer, but with little or no actual system skills, or an experienced system administrator, but with no AEM experience.
If you are embarking on a new project to stand-up your AEM foundation, here are some tips:
Pre-Installation Tips

  • Understand best practices from your internal IT organization around separation of systems (e.g. dispatcher zones vs. author/publish instance zones, firewalls, load balancers, etc.).
  • Create a detailed topology diagram for all environments showing each server and device along with detailed port maps. This visually communicates infrastructure needs, shows how internal and external system interact with one another, as well as what firewall ports and load balancer pools, etc. need to be created.
  • Obtain the necessary approvals and get started on build sheets early.
  • Understand Disaster Recovery requirements, AEM Cold Standby’s, clustering, Jackrabbit Oak Document Store configuration options, and physical sizing requirements. All of these decisions will affect infrastructure topology and build.

Installation Tips

  • mkdir /opt/aemCompletely read Adobe’s Deploying and Maintaining AEM.
  • I encourage anyone that will be deploying and maintenance AEM in an enterprise environment to attend the Adobe AEM System Administration. This training can be invaluable and offers a well-rounded view of how to deploy AEM.
  • Draft and fully test detailed step-by-step installation documentation locally or on test servers before finalizing.
  • Establish a set of configuration parameters that can be used both during the initial system stand-up and as a health check guide for the future.
  • Read through the Adobe Security Hardening Checklist, and maintain a list of your own hardening instructions.
  • Don’t always go for the latest version, unless there is a compelling feature you can’t live without. Our general rule is to wait until the first service pack is released.
  • Implement a change management process that includes updating all relevant documentation, including disaster recovery, service packs, hotfixes, health check and hardening guides, etc.

Development, Build and Release Processes Tips

  • It’s likely your organization has standardized release process guidelines that can be adopted for AEM, and if not you’ll need to develop them.
  • Make sure the guidelines include necessary security and code scans, release notes templates, rollback procedures, and any other checkpoints required before moving between environments.  
  • Establish source control and document a branching structure early on, before the first line of code is developed.
  • A developer Standard Operating Procedures document should be created to accelerate developer onboarding and again provide consistency.

And if you are choosing an AEM vendor for the first time, you are now armed with knowledge to quiz their maturity level around AEM on premise deployments.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Greg Dawson

More from this Author

Follow Us