The IT industry has a habit of refreshing itself by reusing ideas from the past. The recent news that Windows Server 8 will boast a much-enhanced array of PowerShell cmdlets and the ability to log onto servers via the web with PowerShell Web Access brought a number of thoughts to mind (read my WindowsITPro.com blog for more on this topic).

First, Windows is becoming more and more like great mainframe and minicomputer operating systems such as OpenVMS (my personal favorite, but I acknowledge my bias) by discarding the PC-like requirement for administrators to physically log onto servers to perform management tasks through a GUI. I include RDP access in this comment because RDP is just a remote GUI session to a server.

Second, it’s taken a while for Windows to fully embrace PowerShell but it now seems that we’re getting there with Windows Server 8. PowerShell has been around since 2006 or thereabouts but Windows seemed reluctant to generate the modules and cmdlets that administrators needed to perform basic management. For example, it took several years before basic Active Directory management could be done through PowerShell. Exchange 2007 was the first major server product to support PowerShell. Some queried the wisdom of this decision but its sagacity has been proven many times since.

Exchange 2010 went further with the implementation of Role-Based Access Control (RBAC) to determine what cmdlets and cmdlet parameters are available to users according to their membership of role groups. RBAC is linked to channeling PowerShell sessions via IIS in the implementation of Remote PowerShell to remove the need to log-on to a physical server. This is huge both in terms of enabling management of tenant domains in Office 365 and setting out work that Windows has built on in Windows Server 8.

Third, even after two versions and some five years of PowerShell support in Exchange, it seems that some administrators still don’t consider PowerShell (or more correctly, the Exchange Management Shell) to be worthy of their time. Perhaps it’s because they think that the GUI tools are sufficient for the task; perhaps it’s because they don’t have the time to get to know PowerShell; or maybe it’s just because they don’t care to get to grips with a command-line language whose syntax smacks suspiciously of Linux or UNIX.

The good news for those folks is that while PowerShell’s syntax is a little quirky at times, it’s relatively easy to get to know. Anyone who can write BASIC (showing my age, VAX BASIC and VAX COBOL were the two programming languages that I used most) can write PowerShell scripts, even ones that work. And casting back to my remark at the start of this piece, anyone who thinks that fantastic things can’t be done with scripting languages has obviously never looked at some of the incredible scripts that folks are writing today. But this has always been so as UNIX and Linux servers were always managed with scripts and OpenVMS had DCL, the Digital Command Language.

The highlight of DCL was VMSINSTAL.COM, the standard product installer for OpenVMS systems. VMSINSTAL was huge, complicated, and worked very well. Its major developer was Paul Anagnostopoulos, who wrote a great book called Writing Real Programs in DCL. If you ever explored the depths of VMSINSTAL or read Paul’s book, you quickly understood the amazing things that could be done with a scripting language.

Things haven’t changed much since I first encountered VMSINSTAL in 1985 or thereabouts. We have new technology of course and that technology is more complicated and complex than its predecessors. But the need for system administrators to automate common tasks through scripts (or equivalents) still exists and that’s why I am so glad to hear that Windows Server 8 will, at last, fully embrace its own scripting language.

– Tony