Primary Configuration Considerations
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.
IPv4 and IPv6
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 addressfor example https://[ab12::34c5:6d7:8e90:1234]:4502
- an IPv4 addressfor example https://126.96.36.199:4502
- a server namefor example, https://www.yourserver.com:4502
- the default case of localhost will be interpreted for both IPv4 and IPv6 network installationsfor 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
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 https://gbiv.com/ .
See Resource Mapping for further details.
Replication, Reverse Replication and Replication Agents
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 Configuration Settings
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 .
Configuring AEM LiveCycle Connector
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.
Job Offloading and Topology Administration
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.
Configuring the Welcome Console
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.