Windows Server is, without a doubt, a comprehensive and complete platform, composed of hundreds of components supporting a wide array of roles. As we continued to develop the Windows feature set, we saw the need to streamline the footprint of Windows Server by enabling the removal of components that are not always necessary for all Server installations. We refactored the previously “monolithic” features of Windows Server into smaller components which allow us to offer system administrators more granular control of what components and features are installed. The introduction of Server Core as a common base component across all Windows Server editions and installation modes allows us to address many of the previous limitations of Server Core.
In Windows Server 8, users can transition between Server Core and Server Graphical Shell at any time, with a single command and a single reboot. Accordingly, we enabled the installation and removal of server GUI components from the command line, PowerShell, and within Server Manager. In addition, we created over 2,300 PowerShell cmdlets to enable command-line and remote management of all server roles. We also introduced enhancements to Server Core itself to increase application compatibility; for example, the full .NET Framework 4.5 is now available out of the box on Server Core.
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
In addition to Server Core and Server Graphical Shell, we are introducing a new experience in Windows Server 8 called the Minimal Server Interface. The Minimal Server Interface enables most local GUI management tasks without requiring the full GUI Shell or Internet Explorer to be installed. It is an intermediate state that is installed by enabling the Graphical Management Tools and Infrastructure Windows feature and not enabling the Server Graphical Shell feature.
Technically, the Minimal Server Interface is a full Windows Server install excluding Internet Explorer, Windows shell components such as the desktop, Windows Explorer, Metro-style application support, multimedia support, and the Desktop Experience. It provides many of the benefits of Server Core (reduced footprint, attack service and serviceability) for those applications that can be made to work without IE or the Shell. We refactored all of the GUI management tools and frameworks (such as MMC.exe) into separate installable packages, and removed extra fonts and graphical resources.
In previous versions of Windows, developers could rely on a relatively large set of dependencies (usually the Windows Foundation) always being available. Because it is now possible to transition between Server Core and Server Graphical Shell, this is no longer the case.
For example, any applications with a dependency on Internet Explorer, the WebBrowser control, or the Microsoft HTML (MSHTML) Engine, can no longer assume those dependencies are available at all times. Furthermore, it is not sufficient to check for these dependencies at installation time, because they can be installed or removed at any time.
In many cases, the limitations of what is not installed (Minimal Server Interface or Server Graphical Shell) inherently prevent access to the parts of your application that are not supported. For example, MMC is not available on Server Core; thus, users wishing to use a snap-in associated with your service would be unable to do so because the *.msc extension is unregistered and MMC.exe itself is not installed. If the Minimal Server Interface or Full Server were later installed, MMC would be installed and registered and your snap-in would be immediately available for use, with no work required on the part of your application.
In other cases, some work is required on the part of the application developer to ensure a great experience on all Server Installation Levels. For example, a MMC snap-in that embeds a WebBrowser control will not work on the Minimal Server Interface, even though MMC is installed and available for use. The same snap-in, however, will work if Server Graphical Shell were installed. In this case, the snap-in should detect that Internet Explorer is not available and display an error message informing the user that a required component is missing. The error message could also provide the user with a hint that the dependency requirement may be met by installing the Server Graphical Shell. The same concept applies to components such as HTML Help and actions that launch URLs using ShellExecute.
When the graphical user interface is not available, command line installation and administration is the preferred solution for management. Consider deploying PowerShell cmdlets to enable the configuration and control of your application’s services. PowerShell cmdlets inherently support remote invocation, which makes it possible for administrators to configure services remotely and in bulk; this scenario is ideal in private cloud deployments.
The Minimal Server Interface fulfills two major purposes. It is a compatibility option for applications that are not ready to support our recommended application model but still want to benefit from some of the benefits of Server Core. Additionally, administrators who are not yet ready to move to remote or command-line based management can install the graphical management tools (the same ones they would otherwise install on a Windows client PC) alongside the Minimal Server Interface or Server Graphical Shell.
The best way to determine if your application is ready for the Minimal Server Interface is to test it. Try installing your application and check that all functionalities work as expected. Many applications will “just work” without any changes required on your part. Other times, adjustments may be required. Keep in mind that it is also possible for a user to install and configure your server application under the Server Graphical Shell, and then scale back to Server Core in production.
Windows Server 8 empowers administrators to deploy servers with “just enough” of content and capabilities to fulfill their server’s desired function. By increasing deployment agility and refactoring monolithic components – such as the Windows Foundation – into smaller, installable packages, we’re putting more power in the hands of system administrators than ever before.
Please keep in mind that this blog article is not meant to be a definitive – or even complete – guide to developing for Windows Server 8. For example, we are still in the process of drafting the official logo requirements and developer best practices. With that said, we wanted to give developers a sneak peek of what is already available in the Windows Server Developer Preview and empower developers to make design decisions now that will enable their applications to work seamlessly on all installation states of Windows Server.
David B. Cross
Director of Program Management
Why Powershell? Windows Services for UNIX should be part of the Windows server core / minimal installation, and they should include a decent software management subsystem, like SVR4 packaging, as well as a decent selection of freeware applications, so that there are enough dependencies available to build and package other freeware.
We're a small business. A full time / fully qualified IT /admin/ is beyond our means. But headless Windows Server would actually be very appealing for several of our applications we currently serve from under Linux; however - we specifically chose Windows Server for our administrative machines precisely *because* of the GUI. Two words: Active Domain.
I suspect our team would choose Bash & Gnome over unknown-Windows-command-line and Powershell.
But if you could package all of the administrative components into a VM, so that it *can* be run from the server itself or an administrative client ... so that small businesses like ourselves can have both the lean, mean, serving machine that is Windows Server Platform without losing the elegant administrative interface you've spent the last 10 years finally achieving...
Will Windows Installer technology still be supported? I have server apps that are installed via setup programs that use Windows Installer technology. Some parts of the installers use MSXML, will MSXML be available in Server Core or Minimal Server?
And the windowites have all been so proudly pronouncing the CLI Dead and Burried Ha ! right for sure welcome back CLI your place in histort will never be GUI'ed out
Talk about a step backwards! As if a server admin's job wasn't busy enough, Ms now wants us to right 3 lines of power shell command code to do what could be done with a simple click. Ridiculous.
One of our biggest pain points on our development team is the fact that when some part of a build crashes on our Windows build machines, the entire build gets stuck because Windows is sitting around waiting for a human to come along and dismiss the "MSBuild.exe or vc.exe or some other process crashed for some strange reason" dialog box. Being able to have a headless continuous integration server that wouldn't get stuck on such things would be wonderful. When you guys are testing the GUI-less servers, please take the build farm use case into account.
This is great but.....
How do you remote in? Telnet? Now that's secure!
I think it is time for you all to but a ssh licenses for Windows server and install it by default/
When a Server is installed in 'minimal server interface' mode does Powershell still have have access to XAML, and can we run XAML windows from Powershell?!
Does application developer must test their programs in all three environment (core/minimal/full) ?
Now atlast we hope to install MS Exchange or other server install on windows server 8 and scale back to minimal core after that.
In 2008 R2 Sp1. Limitation comes around RPC_HTTPS component which is not available on server core edition but now with this model of switching back and forth, things seems really to ignite the ideas !!!
Really appreciate the decision makers for this !
Q: Does application developer must test their programs in all three environment (core/minimal/full) ?
A: Hi there – great question.
Each of the environments is a superset of the level below it. Everything in Server Core is included in Minimal Server Interface and everything in Minimal Server Interface is included in Server with a GUI. Because of this, if your application has the same functionality across all three you only need to test your installer and application in the lowest supported configuration. For example if your application has two pieces:
1. A server service that is supported on Server Core, Minimal Server Interface, and Server with a GUI
2. A GUI admin tool that is supported on the Minimal Server Interface and Server with a GUI
We would recommend:
• Installer/Setup – run your full test pass on Server Core and regression test on Minimal Server Interface and Server with a GUI
• Server service – run your full test pass on Server Core and regression test on Minimal Server Interface and Server with a GUI
• GUI Admin tool – run your full test pass on the Minimal Server Interface and regression test on Server with a GUI.
As part of your regression testing on the higher levels you should move from Server Core to Minimal Server Interface to Server with a GUI and verify everything continues to work post the change.
If your application enables additional functionality at a higher level, then yes you would need to test in any levels where there is a change in functionality. For example if your app detected it was running on Server with a GUI and that then allowed the user to use some additional functionality not available when running in the Minimal Server Interface you would have to test in both.
Andrew Mason (Microsoft)
Q: When a Server is installed in 'minimal server interface' mode does Powershell still have have access to XAML, and can we run XAML windows from Powershell?!
A: Yes PowerShell will run XAML workflows in all Server configurations.
Jeffrey Snover (Microsoft)
Q: This is great but..... How do you remote in? Telnet? Now that's secure! I think it is time for you all to but a ssh licenses for Windows server and install it by default/
A: The recommended methods for remote access are remote PowerShell (Enter-PSSession –ComputerName x) and Remote Desktop (RDP). Enter-PSSession gives you an interactive PowerShell environment over an encrypted connection that is similar to the TTY shell you are used to with SSH. Remote Desktop Connection uses an encrypted connection that allows you to interact with Windows graphically.
Q: One of our biggest pain points on our development team is the fact that when some part of a build crashes on our Windows build machines, the entire build gets stuck because Windows is sitting around waiting for a human to come along and dismiss the "MSBuild.exe or vc.exe or some other process crashed for some strange reason" dialog box. Being able to have a headless continuous integration server that wouldn't get stuck on such things would be wonderful. When you guys are testing the GUI-less servers, please take the build farm use case into account.
A: We hear you Jason. These are exactly the type of scenarios and issues we are addressing with this effort.
Q: Talk about a step backwards! As if a server admin's job wasn't busy enough, Ms now wants us to right 3 lines of power shell command code to do what could be done with a simple click. Ridiculous.
A: We do not view this as a CLI vs. GUI issue. Microsoft is, and always has been, committed to simplifying the administrative experience through rich GUIs. The only changes here are that we have dramatically improved our PowerShell coverage and the strong recommendation to run those rich GUIs on client machines and remotely manage the server. All of the GUI management tools included in Windows Server are available for installation on the Windows Client.
That said, PowerShell does have some value to offer in exchange for its learning curve. PowerShell enables administrators to more easily automate their management operations. For example, it is much easier to use PowerShell to configure 100 servers than to perform the same operation 100 times using GUI tools. PowerShell also works very well over slower connections, which can come in handy when dealing with servers located in multiple datacenters around the world, or when performing management operations across a metered connection such as a cellular broadband wireless card.
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud