The future of Exchange administration

David Cross is the Microsoft’s Director of Program Management in the Windows division. Recently, he wrote in the Server and Cloud Platform Blog on the topic of  “Windows Server 8: Server Applications and the Minimal Server Interface”. I found the text fascinating because it provides both a glimpse of the future as well as some indications of how far Exchange 2010 is ahead of the game when it comes to remote management of server applications.

The key points that resonated with me are encapsulated in one segment of the post:

“In Windows Server 8, the recommended application model is to run on Server Core using PowerShell for local management tasks and then deliver a rich GUI administration tool capable of running remotely on a Windows client. Server applications using this model would:

1. Be capable of running in the Minimal Server Interface configuration to take advantage of the reduced resource utilization and servicing footprint.

2. Detect presence of available components and adapt the application behavior accordingly

3. Fail gracefully when required dependencies are not available

4. Support command line installation which does not require UI interaction

5. Support centralized or remote administration, where appropriate”

This sounds a lot like Exchange 2010 to me. After all, you can deploy and manage an Exchange 2010 server remotely using a mixture of web-based administrative utilities and PowerShell. The full vision of where Microsoft wants to go isn't completely enabled yet in Exchange, but a good start has been made.

During his keynote at Windows Connections in Las Vegas last November, Jeffrey Snover, the lead architect for Windows Server, described how Windows Server 8 includes some 2,300 PowerShell cmdlets to enable automation of all the normal administrative operations that people have logged onto servers to perform in previous versions. He pointed out that we’ve essentially been following the same administrative model with Windows since the release of Windows NT 3.1 in 1993 and that it’s time to change, if only because the growing number of servers cannot be managed if people have to logon to each and every one to perform administrative tasks through a GUI.

Of course, Microsoft is hugely interested in automated operations because they need Windows to run as smoothly and as cheaply as possible in the datacenters that support their cloud offerings such as Azure and Office 365 in order to be able to deliver profitable services. Even though they are an impossibly rich company, Microsoft can’t afford to have an army of administrators running around to maintain servers. The work has to be done centrally with as few administrators as possible – and that means using PowerShell and scripting to enable remote management. In the future, it should become the exception rather than the rule for anyone to make a physical connection with a computer once it has been deployed in a datacenter.

Exchange 2010 is the application that I think is closest in many respects to the model for administration towards which Microsoft is working. The decision to invest heavily in PowerShell as the basis for management in Exchange 2007 enabled this situation. Today, every management operation on an Exchange 2010 server goes through a remote PowerShell session and although we still have a GUI-heavy Exchange Management Console (EMC), the introduction of the web-friendly Exchange Management Console and its deployment as the de facto standard for management operations in Office 365 is a powerful pointer to the future. I expect that as Microsoft rolls out new versions of Exchange, they will move further away from the kind of GUI consoles that have been in the product since the ADMIN console of Exchange 4.0 to a point where all administration is done through the web or via PowerShell commands. Of course, the web-based administration tools are built on top of PowerShell cmdlets to ensure that all commands flow through a common code base. You should never have to make physical contact with a computer running Exchange unless you want to. And some might still harken back to the days of yore when knights were bold and CDs were used to install software on computers…

Some will continue to bury their heads in the sand and believe that Microsoft will not move away from consoles and other GUI tools. It will take time for the transition to occur but the writing is on the wall. In fact, it’s been on the wall since Exchange 2007 appeared and the message was underlined in strong terms with the introduction of Remote PowerShell in Exchange 2010. If you want to continue to run GUI-based administration, I guess you can stay with Exchange 2010 and run it on Windows 2008 R2 servers until the cows come home. The rest of us with move on and embrace change with all the challenges that change brings. Hopefully, we’ll get to a point where automation gives us back a little more time to spend on more interesting activities because we don’t have to execute repetitive tasks on multiple servers through a GUI.