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:
Depending on the specific configuration these changes can be made by using either the:
Adobe CQ Web Console
This is a standard location for configuring OSGi bundles and services.
See Configuring OSGi for further details and recommended practices.
Repository
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:
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 https://[ab12::34c5:6d7:8e90:1234]:4502
an IPv4 address
for example https://123.1.1.4:4502
a server name
for example, https://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.
See Version Purging for full details, in particular Version Manager for details of how to configure AEM to purge older versions when a new version is created.
AEM offers you the possibility to configure:
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:
/content
so that the internal structure is hidden from the visitors to your website./content/en/gateway
page of your website are redirected to https://gbiv.com/
.See Resource Mapping for further details.
Replication agents are central to AEM as the mechanism used to:
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 Experience Manager’s caching and/or load balancing tool that can be used in conjunction with an enterprise-class web server.
See Dispatcher for full details, in particular Configuring the Dispatcher for further configuration details.
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.
Performance is key to your project. Certain aspects of AEM (and/or the underlying repository) can be configured to optimize performance.
See Configuring for Performance for further details.
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.
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:
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.
The Rich Text Editor (RTE) provides authors with a wide range of functionality for editing their textual content; providing them with icons, selection boxes and menus for a WYSIWYG experience.
See Configuring the Rich Text Editor for further details.
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.
The Video component allows you to place a predefined, out-of-the-box video element on your page.
For proper transcoding to occur, your adminstrator must Install FFmpeg separately. They can also Configure your Video Profiles for use with html5 elements.
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:
See Configuring Email Notification for further details.
Page impressions are displayed in the Impressions column of the classic UI siteadmin console. To enable the capture of page impressions you need to configure:
On the publish instance:
On the author instance:
The configuration of Adobe Page Impressions Tracker on the author environment will allow anonymous requests to the tracking service.