I’ve spent a fair amount of time recently trying to get to know PowerShell. I’ve never been a developer, but I did write a fair amount of Windows Script Host (WSH) both at Microsoft and since then – much to the chagrin of some of the developers I worked with. The more time I’ve spent with PowerShell, Windows Server 2012, and Windows 8, the more I’ve realized that we’re at the beginning of something pretty unusual – in a way, a bifurcation of the Windows server and consumer client conjoined twins that have existed since Windows XP.

Prior to Windows XP, the consumer versions of Windows were the “9x” variants (Windows 95-Windows Millennium) and earlier versions back to Windows 1.0 (which all in turn traced their roots back to DOS/QDOS. The enterprise variants of Windows began with Windows NT 3.1 – designed from the ground up. These two family trees merged after Windows 2000 and Windows Millennium, with the release of Windows XP .

If you stop for a second and think about it, Windows XP was pretty amazing (not just saying that because I was on the team). It was the first fully 32-bit, NT-based version of Windows that offered full plug and play, significant application and device compatibility, and a consumer-ready user interface. I still remember Windows 2000 – I loved it. The day it shipped, I installed it on my Toshiba laptop. I hibernated at the end of the day and undocked. When I went home, it immediately blue-screened. Hibernate in Windows 2000 was never designed or tested to support a “surprise undock” during hibernation. A great example of not quite being ready for consumers (or some of the enterprise).

A key goal in combining the Windows 9x and Windows NT codebases was engineering efficiency. It’s much better to have one team working on a project than have two teams working on two projects that are – at the user interface level, incredibly similar. Since Windows 95 and Windows NT 4, every version of Windows had featured a Start menu, whether it was 9x or NT-based. Windows internals aside, you could sit a typical Windows 9x-using home consumer down at Windows NT or Windows 2000 and expect them to be able to find their way around relatively easily.

During my time in Windows setup and deployment, I worked with a team in the Windows Server group. Somehow we had come up with the idea of making the server more immediately usable for server administrators. Given that Windows XP had “pinned” some things to the Start menu (IE and Outlook Express) by default, we thought, how can we do something similar for admins? I offered the suggestion of pinning cmd.exe (remember, no PowerShell yet!), Notepad, and Server Manager to the Start Menu – since the role of a server administrator is so different from the role of a home consumer. Little did I know what the next 10 years would bring.

As I look at Windows Server 2012 and Windows 8, I see a fork in the road. While Windows 8 largely eschews the legacy Win32 desktop in favor of the tablet and touch-centric Metro user interface, and Microsoft largely emphasizes that the WinRT API framework underneath Metro is their direction forward, Windows Server 2012 goes in a completely different direction. While Windows 8 (and perhaps Windows RT – we’ll see) include PowerShell support, it’s predominantly for their own management or for administrators wanting to remotely manage one or more other remote systems. If we were ranking their importance as user interfaces, WinRT would be number 1 on Windows 8/RT, then Win32, and following up far, far behind, is PowerShell. Windows 8, like previous Windows client versions, exposes no entrypoint into the command prompt – let alone the PowerShell command shell.

Yet, if you log on to Windows Server 2012, the new Start page is really the only user interface element shared with Windows 8. Windows Server 2012 does not include Metro or WinRT – just the Start page (which is an odd experience, frankly). While Windows Server 2012 still includes Win32 as well, the pinned PowerShell icon in the Taskbar is your first bold notification that things are quite different here. Windows Server 2012, in both full installation mode and the “Server Core”  installation mode feature PowerShell and .NET support, and PowerShell 3.0 now includes over 2,300 cmdlets in it. It’s really no longer a question of what tasks can be completed with PowerShell, but what tasks cannot. Not much, I’d bet.  For an administrator of a handful of servers, Server Manager (which uses PowerShell underneath) will suffice. Bit as Windows Server 2012 focuses on deployment and manageability en masse as a core tenet, PowerShell is key. For a typical administrator of Windows Server from now forward, you probably want to get familiar with PowerShell if you haven’t – it’s the path forward.

So as Windows 8 focuses more on it’s new role of touch-and-tablet savvy, delivering a consumer-ready experience that Microsoft hopes will push the iPad aside, Windows Server 2012 focuses more on manageability across numbers of servers – the products are evolving to suit the needs of the customer bases that Microsoft wants them to appeal to. Client focusing on the user scenarios, while server focuses on the enterprise scenarios. I don’t think this is a bad thing. But as I looked back at Windows 2003, I found it an interesting transition.

This doesn’t mean – and shouldn’t mean – that the kernels will fork – that would be rather illogical and inefficient. But in particular, the user interfaces will likely continue to fork, and we could in the future again see split shipping times. Windows consumer operating systems generally have historically been RTM’d in time to hit the back to school market (August) or holiday market (Black Friday, in November). Server releases generally have no dependency date like this – and as a result have shipped later than the client to focus on more intense quality or to add features necessary just for them. It’s an interesting time in the evolution of Windows, and it’ll be interesting to see what happens down the road.

Update: One other thing I recalled as I drove in to work… When we consider how Terminal Services (now always called Remote Desktop Services) began, by remoting the Win32 user logon so more than one user could have an interactive logon, my point becomes even more clear. PowerShell 2.0 added remoting, so an administrator could connect from one server to any other. With PowerShell 3.0, the robust session behavior and the addition of PowerShell Web Access provide an administrative equivalent to SSH, whereby an administrator can connect from one server to any other from the command-line, perform any management task as if they were there, and log off – without ever launching Remote Desktop. This is a further branching of the behavior between the two operating systems – where Remote Desktop on server will be largely relegated to providing actual Remote Desktop services functionality to desktop users, and administrators who are either new, or more comfortable with a GUI than a CLI – and a growing percentage of server administration will likely be done directly through PowerShell, not through a GUI.