Adobe Experience Manager (AEM) is installed with default settings for all parameters which allows it to run "out of the box." However, you can configure AEM for your own specific requirements.
There are many aspects of AEM that can be configured:
- Some are commonly configured for every project installation and must be reviewed to confirm whether or not they are applicable to your project.
- Further configurations may be common though not imperative; related to features, or system performance and stability.
- Others are only required for certain optional features of AEM (these are documented together with the appropriate feature).
- Adobe CQ Web Console
This is a standard location for configuring OSGi bundles and services.
See Configuring OSGi for further details and recommended practices.
A sub-set of OSGi configurations are available in the repository. This ensures that copying, or replicating, repository contents recreates identical configurations. You can also add your own configurations, dependent on run-mode, to the repository.
See OSGi Configuration in the Repository and in particular Adding a New Configuration to the Repository for further details.
- File system
A few configuration files reside within the file system.
- AEM WCM
Various aspects can be configured within AEM WCM itself, many using the Tools console; for example, replication agents.
When working with Adobe Experience Manager, there are several methods of managing the configuration settings for OSGi services (console or repository nodes).
See Configuring OSGi for full details.
Configuring AEM is straightforward, but you must be aware that:
Certain changes can have a major impact on the application(s). For this reason, ensure you have the necessary experience and knowledge before you start to configure AEM, and make only the changes which you know are required. Any changes made via the OSGi console are immediately applied to the running system (no restart is required).
This list details the primary areas that are commonly configured for every new project. Not all are needed, but the list must be read and reviewed to see what is applicable to your project.
The list gives a short overview of each configuration aspect, together with links to the pages that provide full details.
Several key configuration issues are listed in the Security Checklist. Please ensure that you read this and take any action necessary for your installation.
There are two UIs available for use in AEM:
- The Touch-optimized UI
- The Classic UI
You can configure the UI you require using Root Mapping.
Further information about selecting the UI is available under Selecting your UI.
All elements of AEM (e.g. the repository, the Dispatcher, etc) can be installed in both IPv4 and IPv6 networks.
Operation is seamless as no special configuration is required, when needed you can simply specify an IP address using the format that is appropriate to your network type.
This means that when an IP address needs to be specified you can select (as required) from:
- an IPv6 address
for example http://[ab12::34c5:6d7:8e90:1234]:4502
- an IPv4 address
for example http://126.96.36.199:4502
- a server name
for example, http://www.yourserver.com:4502
- the default case of localhost will be interpreted for both IPv4 and IPv6 network installations
for example, http://localhost:4502
In a standard installation AEM creates a new version of a page or node whenever you activate a page (after updating the content).You can also create additional versions on request using the Versioning tab of the sidekick. All these versions are stored in the repository and can be restored if required.
These versions are never purged, so the repository size will grow over time and therefore need to be managed.
AEM offers you the possibility to configure:
- global parameters for the central logging service
- request data logging; a specialized logging configuration for request information
- specific settings for the individual services; for example, an individual log file and format for the log messages
See Logging for full details.
Run modes allow you to tune your AEM instance for a specific purpose; for example author or publish, test, development or intranet, etc.
This is done by defining collections of configuration parameters for each run mode. A basic set of configuration parameters is applied for all run modes, you can then tune additional sets to the purpose of your specific environment. These are then applied as required.
All configuration settings are stored in the one repository and activated by setting the Run Mode.
See Run Modes for full details.
Single Sign On (SSO) allows a user to access multiple systems after providing authentication credentials (such as a user name and password) once. A separate system (known as the trusted authenticator) performs the authentication and provides Experience Manager with the user credentials. Experience Manager checks and enforces the access permissions for the user (i.e. determines which resources the user is allowed to access).
See Single Sign On for further details.
Resource mapping is used to define redirects, vanity URLs and virtual hosts for AEM.
For example, you can use these mappings to:
- Prefix all requests with /content so that the internal structure is hidden from the visitors to your website.
- Define a redirect so that all requests to the /content/en/gateway page of your website are redirected to http://gbiv.com/.
See Resource Mapping for further details.
Replication agents are central to AEM as the mechanism used to:
- Publish (activate) content from an author to a publish environment.
- Explicitly flush content from the Dispatcher cache.
- Return user input (for example, form input) from the publish environment to the author environment (under control of the author environment).
For further details see Replication.
OSGi is a fundamental element in the technology stack of AEM. It is used to control the composite bundles of AEM and their configuration.
See OSGi configuration settings for a list of the various bundles that are relevant to project implementation (listed according to bundle). Not all the listed settings need adjusting, some are mentioned to help you understand how AEM operates.
When working with AEM there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.
LDAP authentication is required to authenticate users stored in a (central) LDAP directory such as Active Directory. This helps reduce the effort required to manage user accounts.
LDAP authentication occurs at the repository level, so it is handled directly by the repository. For further details, see Configuring LDAP with AEM.
For user management within AEM (including assignment of access rights) see User Administration and Security.
Dispatcher is Adobe's caching and/or load balancing tool. Using the Dispatcher also helps to protect your AEM server from attack. Therefore, you can increase the security of your AEM instance by using the Dispatcher in conjunction with an enterprise-class web server.
With the release of the AEM Doc Services and AEM Doc Security, we now have the capability to invoke the LiveCycle doc services to render an XFA form, convert a document to PDF and policy protect a document. Please read AEM LiveCycle Connector for more details.
Offloading distributes processing tasks amoung Experience Manager instances in a topology. With offloading, you can use specific Experience Manager instances for performing specific types of processing. Specialized processing enables you to maximize the usage of available server resources.
Topologies are loosely-coupled Experience Manager clusters that are participating in offloading. A cluster consists of one or more Experience Manager server instances (a single instance is considered as a cluster).
For more information on how to view or modify topology membership, consult the Administering Topologies section.
The Welcome console of the classic UI provides a list of links to the various consoles and functionality within AEM.
It is possible to configure the links that are visible, see Configuring the Welcome Console for further details.
Scaling a CQ installation correctly depends greatly on the details of your particular use case. A detailed discussion of solution patterns for various situations can be found in Scaling CQ.
The repository data store is used to offload the storage of large binaries from the repository proper to a separate area, so that multiple instances of the same binary (an image, for example) within the repository tree are stored only once.
This "store-once, reference-many-times" feature can be extended to serve not just a single repository tree but entirely separate repositories, by configuring the data store of each to refer to the same shared file system location.
Such a data store can be shared between different nodes in the same cluster, different publish and/or author instances in the same installation, or even entirely separate instances in different installations.
For more information, see Configuring Data Stores and Node Stores.
You can enable HTTP over SSL to employ more secure connections to your servers.
See Enabling HTTP over SSL for further details.
A portal is a web application that provides personalization, single sign on, content integration from different sources, and hosts the presentation layer of information systems. The portlet component also lets you embed a portlet on the page. To access content provided by CQ5 WCM, the portal server can to be fitted with the CQ5 Portal Director Portlet. You can do this by installing, configuring, and adding the portlet to the portal page.
See Portal and Portlets for further details, in particular Using CQ as a Portal and Installing, Configuring, and Using CQ in a Portlet.
Static objects (for example, icons) do not change. Therefore the system should be configured so that they do not expire (for a reasonable period of time) and so reduce unnecessary traffic.
See Expiration of Static Objects for further details.
Each java process may access files - this requires system resources. For this reason an upper limit is defined as to how many files each process is allowed to access concurrently. If this is exceeded an exception error can occur.
If the AEM process exceeds this maximum, then the message "too many open files" will be seen in error.log.
To avoid such exceptions you need to:
- Check how many open files your AEM process is using.
How you make this check will depend on the platform your instance is running on. Utilities such as lsof (Unix) or Process Explorer (Windows) can be used.
This value should be monitored during development and testing to:
- confirm that files are being closed as required
- to determine the maximum value needed (under various circumstances)
- confirm that files are being closed as required
- Set the maximum allowed.
The new value should cater for both the current needs and any future peaks, so it is advisable to to double the current needs.
By default, serverctl configures CQ_MAX_OPEN_FILES to 8192; this should be sufficient for most scenarios.
There are several properties that control the behavior of the undo and redo commands for editing pages. These can be configured, see Configuring Undo for Page Editing for further details.
To help you monitor and analyze the state of your instance, CQ provides a selection of default reports, which can be configured for your individual requirements:
See the Basics of Report Customization for further details.
CQ sends email notifications to users who:
- Have subscribed to page events, for example modification or replication.
- Have subscribed to forum events.
- Have to perform a step in a workflow.
See Configuring Email Notification for further details.
The configuration of Adobe Page Impressions Tracker on the author environment will allow anonymous requests to the tracking service.