INTERVIEW While the fundamental changes to Windows' core architecture were first seen by the general public last January with the release of Vista, the impact those changes will make to how businesses work will be felt later this year, with the release of Windows Server 2008.

The way time slices for processes are allocated, the way errors and exceptions are handled, the way the system recovers from faults - the situations that may benefit Vista users on occasion, could make a tremendous positive impact on servers that handle skyrocketing IP traffic, especially with voice and video becoming more commonplace.

Technically, they're in many cases the same fundamental changes, which Microsoft touted for consumers as groundbreaking - as reasons to ditch their old computers and trade up to dual-core, 64-bit processors with DirectX 10-compliant graphics cards. And in Windows Server, the effects of those changes may be more directly felt in the enterprise. Nonetheless, the mood at Microsoft's server division is much lower-key, with the move from Windows Server 2003 to 2008 being portrayed as a more incremental shift.

As BetaNews learned from speaking face-to-face with Microsoft's Ward Ralston, senior technical product manager in the Windows Server division, even the most obvious changes in the operating system must be portrayed as evolutionary rather than revolutionary, if business customers are to have an easier time accepting them.

We began our discussion by focusing on perhaps the most obvious strategy shift in the server division: the move back toward a less burdened kernel and command-line-driven operation, with the provision of the new Server Core option.

Although Server Core runs within a window, it's essentially a promoted version of the CMD.EXE command-line shell in Windows Server 2003. New utilities have been written for Server Core, in the classic style of the best MS-DOS 6 executables. As we learned last week at WinHEC, there's considerable support for making PowerShell the official WS2K8 command prompt, including for Server Core.

But the reasons why that can't happen yet are technological, not political: PowerShell relies on the .NET Framework, which is currently bound to the graphical environment that Server Core relies upon. That might change, and soon, Ward Ralston told BetaNews, though even the nature of that change may just be evolutionary.

Ward Ralston, Microsoft: With Server Core, it's important to remember this is Version 1 of the product. What we did when we started development on this is, we looked at the top, key workloads within an organization, and at that time it was File, Print, Active Directory, and DNS. And we said, how can we take those four workloads and put them in their absolute, most reliable configuration? And that was the basis for Server Core.

We removed the GUI, the .NET Framework, any DLLs or libraries that were not needed to perform those four particular roles. At Beta 2, we felt we did a really good job with those roles, and now we're moving Server Core forward. You may have noticed, at Beta 3, we now support eight roles instead of four. And I guess that's a testament to what our development plans are going to be.

"It actually sounds kind of exciting...to kind of get back to this world where everyone has a community-driven effort to create the tools to get the job done." Ward Ralston, senior technical product manager, Microsoft

We absolutely hear that customer feedback loud and clear, about allowing any potential role to be installed on Server Core. So we definitely are looking at the next version of the .NET Framework, which is more componentized, so we'll have the ability to put in just the core components of the .NET Framework into the product to potentially support products like PowerShell. No commitment on that yet, but we are absolutely looking at new, expanded roles for Server Core.

Scott Fulton, BetaNews: So once that .NET Framework becomes more componentized...then I would imagine you're going to see more scripting languages besides PowerShell emerge on the scene. IronPython would be ported over at some point. The possibility exists that admins could build a whole new wealth of little development tools, the way you used to have in the '80s...

Ward Ralston: It's interesting that you brought up Python and the whole notion of Perl, because PowerShell can completely leverage any existing [scripting language], because it's based on the .NET Framework, it can consume any other type of language or scripts that you've traditionally written in. I think PowerShell will complement people who choose to install or use other scripting options. By no means are we attempting to restrict, or anything like that, on Server Core - it actually sounds kind of exciting.

Now, to kind of get back to this world where everyone has a community-driven effort to create the tools to get the job done: I think our Scripting Center on MSDN is a testament to that, too. We're seeing tons of cmdlets ["command-lets"] that people are uploading and contributing to the larger community effort of using PowerShell to do IT administration.

You think the same thing's going to happen around Server Core?

Scott Fulton: I see Server Core starting maybe a little revolution of its own, in that a lot of people who set up blades and servers designed to be remote, they don't need a graphical environment. They just need a way to get to the core of the system.

Ward Ralston: And I think it's important to point out too that, even though you do install Server Core and it just has the command line interface, we have scripts that you can install that enable [TCP] port 3389, so you can administer it with Terminal Services. If I'm sitting at a full install version, and let's say I bring up the DNS, I can connect to a Server Core running DNS, and I can administer it from another machine using the GUI on this one.

You're not just roped into the command line for all administration. We see the majority of IT pros using existing GUIs or using PowerShell that leverages WMI running on Server Core, to perform administration.

Scott Fulton: But either way, you're not into a situation where you're running a remote graphical environment on the remote server.

Ward Ralston: And that's where we want to be.

Next: How long will it take for WS2K8 to get big customers on board?