Share via

Windows Server 8: An Introduction

  • Article

Today at the Microsoft BUILD conference I had the pleasure of introducing the developer preview of the next release of Windows Server codenamed Windows Server 8, now available on MSDN.  In a room full of software developers and hardware partners I got to share some of our thinking behind the design of Windows Server 8 to help them prepare their new and existing applications, systems, and devices for the new release.  Now, on this blog, I want to share that same thinking more broadly with a series of posts from me and members of my team. 

Let me start with a reminder that this is a developer preview version, the purpose of which is to enable our development team to engage with the industry as we progress toward final release. This developer preview is not for deployments in enterprise environments. However we do welcome feedback from IT professionals doing early evaluations, and I would like to thank many of you for your help in getting us to this point. So far we have surveyed over 26,000 customers, had more than 200 customer meetings and documented over 6000 customer requirements during the course of planning and development. 

As the person who leads Windows Server and Windows Azure engineering, I have had the experience of building and operating a cloud platform. We have been able to apply many of our insights from Windows Azure to Windows Server 8, enabling us to deliver world class cloud capabilities to enterprises of all sizes. Windows Server 8 will be a big leap forward, especially in terms of helping IT organizations progress beyond virtualization to build private cloud services.  We innovated and worked with the industry on virtualizing network and storage infrastructures for multitenant support. Our goal is to give customers the choice and flexibility to build and deploy applications across their choice of private and public cloud environments, or a combination of both.

Another big area of focus is on manageability and serviceability of cloud infrastructure without service down time.  For example, one of the most common customer comments we have heard is that patching and updating servers is a costly and error prone process.  We are delivering new technologies, such as “cluster aware updating,” and the ability to script workflows with Powershell to make it an easier and repeatable process to patch multiple servers while maintaining continuous service availability. 

Continuous availability of services typically requires expensive hardware infrastructure, but not every IT organization can afford the necessary hardware.  So, with Windows Server 8 we are delivering high availability and disaster recovery at a much better price point, using software technologies and commodity networking, storage and servers.  For example, we are giving customers access to high-end storage capabilities that before required specialized hardware, such as device pooling, disk virtualization, and thin provisioning, in Windows Server 8. To evaluate how development is progressing I have a server in my office with 10 disk drives ranging in size from .5 to 3 terabytes. I find it very easy and quick to pool the disk drives, create volumes, and have them available for service within minutes using the new built in tools.    

This is just a taste of what’s coming in Windows Server 8.  There is much, much more to discuss over the coming weeks and months, so I’ve asked some of our engineering leaders to write posts on this blog to further explain some of the hundreds of new features.  Be on the lookout for those posts in the coming weeks and months. We look forward to engaging with you on the new technologies in Windows Server 8.   

Best,
Bill Laing
Corporate Vice President, Server and Cloud

Comments

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    January 01, 2003
    I wonder why the Windows Server 8 version is only available on MSDN and not on Technet. Future application and cloud developments will be deployed and  supported by system engineers and therefor this group needs to be included as soon as possible.

  • Anonymous
    January 01, 2003
    Excellent.

  • Anonymous
    January 01, 2003
    A small rant on improving the update features in Windows Server.  While  adding new "smarts", such as cluster aware logic to do rolling updates rather than simultaneous cluster downtime is a nice tweak, the biggest problems with the update rollout mechanism have been the same (competing server systems already fixed all this years ago, look at SUSE "YAST" and Ubuntu "apt" for inspiration, they are both willing to let MS see their design details):

  1. The interface and mechanisms change with every server release, making it hard to manage a network with multiple versions of Windows Server.
  2. Daily data feeds, such as fresh definitions for the desktop "windows defender" are mixed in with the software update mechanism, drowning out alerts about security updates (especially for WSUS admins and desktop deployments).
  3. The user interface makes it unduly hard to identify and select updates (For instance, the Server 2008 interface can either let you install updates, OR let you select updates, but not at the same time).
  4. WSUS should be replaced by letting the update system work with generic HTTP proxying (RFC2616) and mirroring ("genericrecursivedownload.exe http://somemsurl C:inetpubwwwrootoursus", schedule daily, point other servers to http://ourserver/oursus/). This could initially be based on the mechanism you currently use to deploy the updates to Akamai servers, but should eventually become "static content only, all code run client side".  This worked nicely with the "ftp.microsoft.com" updates subdirectory used before 1996.
  5. There needs to be much better support for environments where each update needs to be offline logged, archived and signed-off by multiple administrators for audit purposes. (This worked better in the manual processes used with NT 3.51 and older).
  6. The generic boilerplate update descriptions (which are localized but useless) need to be replaced by specific untranslated English descriptions plus structural tags for urgency, importance, reboot needed, KB number, security bulletin number, CVE number, etc.
  7. The metadata format needs to be documented again so 3rd party tools and large sites can apply their own detection and installation processes in place of the standard update agent.  This is far beyond "scripting" the standard update agent, but simpler for MS to make (just documentation, not new code to regression test).
  8. For recovery and forensic purposes there should be a tool to fully integrity check an offline read-only Windows Server disk without running any code from that disk, reporting changed files, missing updates, unsigned drivers etc. with great specificity.  A 3rd party could offer this if the formats were documented.
  9. The "hotpatching" mechanism for reboot-free updating of loaded system code needs to be much more widely used.  Where insufficient, the "during reboot" part of updating should be limited to the fast actions of MoveFileEx() delayed renames and a matching registry mechanism, with all other steps done by preparing complete replacement files and registry keys while the system is still fully operational, and deleting "moved away" old files when the system is fully up again.  (This reduces downtime of each server).

  • Anonymous
    January 01, 2003
    Thanks for the informational post !

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 14, 2011
    It will be interesting to see if Windows Server 8 will be a good replacement for some of the big/expensive hardware storage solutions out there and what that will mean for competition in that space.

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    Awesome!

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 15, 2011
    I woluld like the first download the system.

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 20, 2011
    Bro, this is so sweet

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    September 21, 2011
    I must say after reading this article I am extremely excited.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 21, 2011
    This is going to be an awesome server OS.

  • Anonymous
    October 29, 2011
    The comment has been removed

  • Anonymous
    October 29, 2011
    The comment has been removed

  • Anonymous
    October 29, 2011
    The comment has been removed

  • Anonymous
    October 29, 2011
    The comment has been removed

  • Anonymous
    October 29, 2011
    The comment has been removed

  • Anonymous
    October 29, 2011
    The comment has been removed