With the recent demise of Exchange Server 2003, so ends an era of GUI-oriented Exchange Server management.
Exchange Server 2007 and Exchange Server 2010 still allow admins to manage Exchange with a GUI, but Exchange Server 2007 was the first major server application to adopt PowerShell for automation through the Exchange Management Shell (EMS). This put the writing on the wall: PowerShell would become the de facto standard for command-line management and automation, and admins need to learn PowerShell scripting.
PowerShell has its roots in Monad (also known as MSH), Microsoft's original project for command line automation that started back in 2002. At that time, automation in the Windows world more or less revolved around Windows Script Host, which allowed admins to write scripts in JScript or VBScript as well as in specific purpose tools such as Netsh or WMIC. However, usability was limited, as scripting applications depended on the APIs exposed by those applications.
PowerShell 1.0, introduced in 2006, is built on top of the .NET Framework and is an extensible Windows Management Framework. This allowed Microsoft as well as other vendors to provide snap-ins that extended the shell's functionality, allowing for management of components or third-party applications using a single language -- PowerShell.
The language remains the same, so the learning curve is minimal. To learn PowerShell scripting, you only need to become familiar with the component or product-specific cmdlets. You can automate tasks by combining cmdlets with logic in Scripts. Scripts allow you to easily execute standardized tasks from the shell, making procedures repeatable and less prone to human error.
Getting hands-on PowerShell experience
What makes PowerShell unique is that it provides a so-called pipeline where the output of a cmdlet can be used as the input for another cmdlet, retaining all objects as they are passed on. If cmdlet A outputs a set of mailboxes, you still have access to all properties and methods of those mailboxes when piped to cmdlet B. This differs from Unix, where the piping mechanism is text-oriented. PowerShell 2.0 introduced PowerShell Remoting, which allows you to run scripts or cmdlets against one or more remote systems.
Starting with Exchange 2010, the importance of learning PowerShell scripting was emphasized as certain features and options were available or configurable only through the EMS. The Exchange Management Console and Exchange Administrative Console in Exchange Server 2013 only serve as an interface to construct and execute cmdlets. Office 365 offers basically the same set of cmdlets, allowing admins to use the same knowledge to run tasks in Office 365.
Exchange 2007 and 2010 were great for Exchange admins to familiarize themselves with Exchange cmdlets. They could display the constructed cmdlets; Exchange 2013 doesn't have such a feature. Exchange 2013 SP1 introduced the Show Command Logging option after demand from admins. When kept open, it displays the last 500 cmdlets executed on your behalf.
While this option is less ideal than having those cmdlets displayed before execution, it certainly is useful. You can learn PowerShell scripting by learning how to use cmdlets and looking at the Command Logging window as you click your way through the Exchange Administrative Console, or you can export the log for documentation purposes or as a basis for scripts.
Now is the time to learn the EMS
If you haven't looked into the EMS yet, I strongly urge you to familiarize yourself with it. Start with reading and understanding what's happening with the cmdlets and scripts. And while hands-on learning by example is great, some may still prefer the written word.
I also recommend two resources that offer many practical, real-world examples that can get you started with PowerShell -- Microsoft Exchange 2013 Cookbook by Michael van Horenbeeck (Exchange MVP/MCM) and Peter de Tender (MCT) as well as Microsoft Exchange Server 2013 PowerShell Cookbook by Mike Pfeiffer (Exchange MCM) and Jonas Andersson (MSFT).
So what are you waiting for? Open a PowerShell session and get going -- your PowerShell life starts with the get-help command.