AEM 6.5 – New Features Guide for Platform Architects & Ops

AEM 6.5 – New Features Guide for Platform Architects & Ops

April 16, 2019 0 By Tad Reeves

Most articles you’ll find on the new Adobe Experience Manager 6.5 will focus on the great new features that AEM Sites and AEM Assets now provide, which are – truth be told – quite compelling. But from the people who will be executing an upgrade to AEM 6.5 from an platform architecture and operational standpoint, I wanted to call out a few changes from earlier versions that you may or may not be aware of.

Connected Remote AEM Assets Instances

This was going to be my new favorite feature of AEM 6.5, as I’ve been trying to make this topology a “thing” for a number of different clients. What this feature is meant to bring is to allow authors working on an AEM 6.5 Sites Author server to discover, browse and embed Assets from a separate AEM Assets instance. Why would you want to do this? The main problem in designing AEM infrastructure is that the AEM Author has always been notoriously difficult to scale. It has never taken well to horizontal clustering, so in many cases your only hope to scale up an AEM installation that has (a) a lot of content authors and (b) a lot of assets is to make two separate Authors – one for site authoring, the other for a DAM.

The only problem though, is that if you stick your Assets instance on another server, you have to go onto that server separately from your Sites author, find the asset you want, download it, and then upload it to your AEM Sites instance to use it. This Connected Remote Assets feature is, then, just what the doctor ordered to solve this.

Simplified diagram of AEM 6.5 Connected Assets feature, showing that to use this feature, you need to be entirely in Adobe Managed Services, or at least have your connected Assets Author instance be hosted in Adobe Managed Services.

Or is it? If you notice the big red detail on the diagram above, the Connected Assets feature has one catch – it will only work with an AEM 6.5 Assets instance that is hosted at Adobe Managed services.

I checked with various contacts at Adobe on this after reading the documentation, and my fears were correct. One source said that there are no plans to enable this feature for non-AMS builds, and another source said that it was possibly planned for Service Pack 1 (AEM 6.5.1). Either way, it wasn’t mentioned at Adobe Summit as an AMS-only feature, just a “feature” but there you go.

Evidently, the reason for it not working on a self-hosted build (i.e. at your own datacenter or AWS/Azure/Google Cloud/etc) is that the Sites Author <-> Assets Author authentication depends on the Adobe IMS (Identity Management Service) auth service which is a protocol only used by Adobe Managed Services for remote auth.

So there you go. If using a Connected Assets server is something you were looking forward to doing on your own AEM instance, and you don’t run at AMS, please do give your Adobe rep a ring and let him know it’s a feature you want.

Edit: As a further note, if you’re dead-set on running this now without Adobe Managed Services support, check out Brett Birschbach’s Remote Assets plugin that he made, and then presented at AEM Rockstar 2018. That may get you where you’re trying to go. Brett just submitted this into ACS AEM Commons, and it has quite a few more use cases than just the “remote DAM” case, like pulling assets remotely from PRD to use on lower envs, such that you don’t then have to sync the ENTIRE environment down to lower envs.

So, if Adobe doesn’t come through with making this work with non-AMS environments, give ACS AEM Commons a whirl.

AEM Now Supports JDK 11

Previously, the only Java version that was supported for AEM 6.4 was JDK 8, but now AEM 6.5 is officially supported on JDK 11 as well. I haven’t set up a test environment on AEM 6.5 with JDK 11 as yet, so no data if there are any differences in stability or performance. However, if you’ve run any tests on such, please let me know in the comments!

Java Updates will be Supplied by Adobe

Last year, Oracle dropped the big bombshell news that it would be charging for Java. There were varying numbers being thrown around for how much Oracle was going to charge per JVM, but the cost of these was going to be considerable.

However, Adobe decided handle this with AEM customers by directly providing JDK updates for any new Java releases as the come out, to be downloaded directly from Adobe, rather than from Oracle.

I’m still waiting for details on how exactly this is going to work, as there is installation automation many companies use to install Java when provisioning new AEM servers. I’ll update this as it becomes more clear.

Admin User Password Expiry

Image result for idiot luggage

OK, show of hands: how many of you guys have been rolling with the same admin password since your AEM instances were first installed?

Actually, never mind, I really don’t want to know.

Jackrabbit Oak has supported password expiration for some time, and now supports expiring or force-change password on the “admin” user as well.

New Permissions Management UI

Slowly but surely, the AEM Product Team has been working to phase out old ExtJS-based Classic UI pages we all know and love for new TouchUI-based interfaces that look like they were created this decade. The latest to get that treatment in AEM 6.5 is the new Permissions Management UI.

The new TouchUI-based AEM permissions management interface in EM 6.5

This allows one to modify permissions on objects without having to dive into /crx/de like one’s had to do these past 10 years or so.

There are a number of other great core features, but these were the ones that most impacted me. I’d love to hear from any of you out there if you’ve got anything to add, or have had experience implementing these new features!