Final Deadline for a Rickety Old Console is September 1, 2022
The September 8 announcement (MC283874) that Microsoft will retire the old Exchange Admin Center (EAC) on September 1, 2022, didn’t come as much of a surprise. The old EAC has been on life support for the last few years and Microsoft confirmed the signs of an impending exit when the new EAC reached general availability in April 2021. They subsequently followed up with a blog post listing six reasons why it’s time to move (without mentioning the general state of decrepitude in the old EAC. I’m unconvinced about the assertion that the new EAC will be an intelligent dashboard (it seems pretty static to me), but the tenant switcher, support for delegated admins and Azure AD Privileged Identity Management, and delivering a console suitable for GCC/GCC-High tenants are all good goals to attain.
Overall, the only surprise in the story is how long it has taken Microsoft to develop the new EAC. First disclosed at the Ignite conference in November 2019 and then launched into public preview in July 2020, development has progressed at a snail’s pace. And a slow (but determined) snail at that.
Feature Parity Claimed but Not Attained
In September 2020, Microsoft said that the new EAC had reached feature parity with the old console when it clearly had not, except in the minds of the marketing community. Many items of functionality available in the old EAC were not in the new portal then and the same is true now.
A quick check of the two portals today identified several features that are not yet available in the new EAC, including:
- User role assignment policies. Admin policies are available in the new EAC, but the RBAC policies to control user access to features are not. These policies are useful for doing things like stopping users adding personal retention tags or creating new distribution lists.
- OWA mailbox policies. OWA mailbox policies control the features available to users in the browser client (or the type of browser client they can use). For example, you can stop OWA users creating autosignatures for messages or prevent people updating their user photo.
- Exchange Data Loss Prevention. Microsoft 365 Data Loss Prevention (DLP) policies are now as functional for messaging as the old Exchange DLP policies, so it’s understandable that Microsoft should remove Exchange DLP (from the GUI) at this point.
- Mailbox records management (MRM). Microsoft would like organizations to use Microsoft 365 retention policies (especially auto-label policies as that’s a nice opportunity to upsell Office 365 E5 licenses). However, sometimes the processing of mailbox contents is better done using Exchange MRM, especially when archive mailboxes are involved.
- Journal rules. These are special transport rules which direct copies of messages to journal recipients outside Exchange Online (usually third-party journal and archive systems). Microsoft has never liked journaling within Exchange Online, so it’s unsurprising that these rules are not exposed by the new EAC.
- Mailbox auditing. Exchange admin and mailbox audit events now flow into the Office 365 audit log. The functionality available in the EAC was always poorly executed and lacked depth. Its demise is welcome, but I would expect a link to the Microsoft 365 compliance center to bring administrators to the audit log search feature.
- Mobile device policies (Exchange ActiveSync – EAS). At one time, EAS was the best method to connect mobile devices to Exchange (on-premises and online) and Microsoft included device access rules and device mailbox policies to help control the kinds of devices the organization allowed to connect to mailboxes. Now, EAS is the lowest common denominator and the functionality available to EAS clients are far behind what’s available to Outlook mobile clients. That’s still no reason to remove the mobile device management features from EAC as not every organization wants to use Intune or Microsoft Endpoint Manager.
Although it’s true that administrators can manage all the missing features with PowerShell, the point remains that the new EAC has obviously not reached feature parity with the old EAC. Unless your definition of parity extends to excluding bits and pieces we don’t really want to include in our shiny new console.
A Complete Rewrite for Exchange Online
In defense of the new EAC, it is a complete rewrite and Microsoft intends it to reflect the new world of Exchange Online rather than the old world of Exchange 2013. Once the transition is complete, I expect new features to show up in the new EAC, just like the ability for administrators to recover deleted items for users.
Inside Microsoft 365, other admin interfaces have responsibility for areas covered in the old EAC. For instance, the Microsoft 365 admin center deals with accepted email domains and DNS records while protection is in the Microsoft 365 Defender portal. There’s also no need for functionality like Exchange Unified Messaging, an area now handled by Teams. Even so, Microsoft could handle some of the depreciation a little more elegantly than it does for Unified Messaging (Figure 1), like pointing the user to a page describing current voice solutions.
![Selecting Unified Messaging in the old EAC delivers a 404 error](https://s40823.pcdn.co/wp-content/uploads/2021/09/EAC-Old-UM-1024x686.jpg)
The hybrid section of the old EAC could also do with a refresh (if only to point to the Exchange Online management PowerShell module), but I understand the reluctance to invest any further effort in outdated code.
A New Exchange Management Graph API?
The now-decrepit older EAC is based on the PowerShell cmdlets created for Exchange management dating back to Exchange 2007. The new EAC uses Graph APIs. At least, I assume that Graph APIs underpin the new EAC as in the Microsoft 365 and Teams admin center. Microsoft doesn’t have a public API for Exchange Online management at present, so the new EAC might be a forerunner of a new Graph API to come.
More Work to Do
Underlining the need for further improvement in the new EAC before the old version disappears next September, the portal deals with some areas of functionality by calling the UI from the old EAC. For example, the entire public folders section uses the old interface (Figure 2). The only new contribution is to mislabel the Public Folders mailboxes section.
![The Public Folders section in the new EAC displays the old GUI](https://s40823.pcdn.co/wp-content/uploads/2021/09/EAC-Old-PF-1024x658.jpg)
End of an Era
I’m not sad at the demise of the old EAC. The transition to a purpose-build administrative console for Exchange Online should have happened years ago. I am a tad dismayed that the transition is taking so long, and that Microsoft has overlooked or chosen to ignore several features available in the old portal. But I shall wait for the final outcome. After all, it’s only another 50-odd weeks until the old EAC bites the dust.
Even looking for things such as retention policies/retention tags in the new EAC are really hard to find (where we would set email retention policies insofar as move to archive after set period of time).
In the new EAC under Policies/Data/Retention there seems to be the ability to add retention polices, but not tags. Seems very unintuitive and will make more work for admins if these features are not returned into the UI.
We can set many of these things via cmdlet easily enough, but what I don’t like is they are regressing features and making us access them via scripting. If so, they should link to a comprehensive wiki of cmdlets in the new EAC.
Hi Tony,
would you mind giving practical examples of creating a Journal rule in the new version of the EAC, please?
I read that it could be done only by using PowerShell which is not so convenient for most people.
Thank you.
The Real Person!
The Real Person!
I just checked the new EAC and there’s no way to create a journal rule in it (still). You therefore need to run the New-JournalRule cmdlet in PowerShell (https://docs.microsoft.com/en-us/powershell/module/exchange/new-journalrule?view=exchange-ps). Is the example in that page unclear?