Time to Move to a New EAC
Among the Exchange announcements made at the virtual Ignite 2020 conference was the assertion that the new Exchange admin center (EAC) is ready for prime time. Microsoft said: “We’ve recently reached parity with the legacy admin interface and are now adding new features such as personalized dashboards, cross tenant migration and providing actionable insights. We have also invested in a better mobile experience for admins on the go.”
I don’t buy the statement around parity in functionality because the new EAC links back to the old EAC for some functions, like management user role assignment policies. Understanding that these are marketing words and that the developers will close the gaps over time, let’s consider what the new EAC brings.
Anyone taking the invitation to opt-in from the old EAC or by going direct to the new EAC might be underwhelmed at first look. The home screen is under inspiring and the new console (Figure 1) is just another bland Microsoft 365 portal, even if it’s regained some functionality (like Mail Flow from the Security and Compliance Center), some new tricks (like administrator recovery of deleted items), and is the go-forward target for investment in new functionality.
The new EAC also inherits some smarts from the Microsoft 365 admin center, like how groups are processed, but there’s no magic present to convince you to set the toggle to default to the new portal (sometime in the future, the toggle will be disabled and using the new EAC will be the only choice).
PowerShell Created Portal Magic
I know you’re going to think me crazy that magic can exist in an administrative tools, but this has been the case in the two previous generations of Exchange administrative portals and it’s all to do with PowerShell.
When Microsoft came to design Exchange 2007, they took the brave decision to base all the administrative tools on PowerShell. EMC, the Exchange management console became a wrapper around PowerShell cmdlets, as did the later web-based Exchange Control Panel (ECP) and EAC. The great thing about this approach was that the consoles exposed the PowerShell code they used to perform actions through a feature called command logging. Figure 2 shows how the EMC displayed the code used to create a new mailbox. You could copy the code and reuse it in your own scripts.
Given that PowerShell was very new (Exchange was the first major Microsoft server to embrace PowerShell), this was a fantastic way for administrators to learn how to interact with Exchange and manage objects through PowerShell. In a nutshell, it was the best learning tool available at the time. I haven’t seen much to beat it since.
The unfortunate thing is that following the transition to Exchange Online, Microsoft proved adept at breaking PowerShell command logging. I’m sure this wasn’t deliberate; the developers probably didn’t put as much value on the feature as its fans did. And to be fair, fewer people needed to use command logging as experience of PowerShell grew and more information was available online.
The Graph is the Strategy
The truth is that the new EAC doesn’t use PowerShell. Like the other modern administrative consoles used across Microsoft 365, the new EAC is based on the Microsoft Graph. This is in line with Microsoft’s strategy to use the Graph whenever possible as the basis for Microsoft 365 management. It’s an understandable and reasonable approach to build everything on a common foundation, even if it loses some magic. And no, the new EAC never tells you anything about the Graph code it uses. Some secrets must be kept.
The folks who subscribe to the Office 365 for IT Pros eBook seem to know their way around PowerShell, so we have never covered command logging in depth. It’s sad to see it go, but we dedicate our pages to new stuff and not the past.