In-Depth
Building the New Server
Microsoft's Windows Server 2008 has been radically redesigned. Here's how it was done.
- By Mary Jo Foley
- 06/01/2007
If the road to Windows Vista was a bumpy, winding dirt trail, the route to Windows Server 2008 (formerly code-named "Longhorn Server") has been a paved, four-lane highway.
Over the past two years, beta testers have been giving Microsoft a thumbs up for its progress with Windows Server 2008, the first major upgrade to Windows Server since 2003. Microsoft has stuck pretty close to schedule with its stated plans for the new OS, commencing with the first beta issued back in July 2005 and most recently with beta 3, released just five weeks ago. The Windows Server team actually has added a fairly major feature -- the PowerShell scripting environment -- to the product midway through the testing process (see ".NET Developers Taking to PowerShell," May 15, 2007).
That's a far cry from the well-documented travails of Vista, which suffered from slipped schedules, axed features, changes in direction, lack of compatible drivers and apps and a less-than-positive reception when the product shipped in January.
Given their intertwined histories, the differences between the two "Longhorn" products might seem surprising. After all, Longhorn client (Vista) and Longhorn Server (Windows Server 2008) were developed in lockstep up until Microsoft released Vista to manufacturing in early November 2006. Windows Server 2008 and Vista share the same kernel. Microsoft designed both client and server with modularity in mind, and spent lots of time and energy to reduce dependencies across shared Windows subsystems.
So what is it that's made Windows Server 2008 gel so well? A recent visit to Redmond with the development team provides insight into what developers can expect from the next release of Windows Server. Just as important are lessons developers can apply from the dual development paths.
Taking a Cue (or Two) from Vista
In spite of Microsoft's emphasis on how Vista and Windows Server 2008 work "better together," the two products are designed for different users and markets. Building a product that will be tested and used by consumers versus one for enterprises is, by its nature, a very different process. Because Vista was designed to be used by vastly more people in conjunction with a greater variety of hardware and software, it was under much more scrutiny by a greater number of testers than Windows Server 2008.
The Server OS team, predictably, shies away from comparisons with Vista. When pressed, managers will cite the server team's collective years of experience and its ability to build on top of -- and take cues from -- Vista as big reasons why Windows Server 2008 has proceeded, relatively problem-free, down the design/ development/test path.
Windows Server General Manager Bill Laing says being able to take advantage of the Vista base gave the server team a leg up. The server team also learned what to do -- and what not to do -- in terms of driver readiness from the Vista team.
For example: "We've been working hard with the driver partners to make sure [they'll be available]," Laing says. "It's a little bit less challenging, because most people don't add stuff [to a server] after they've bought it. They usually buy it from Dell or IBM or HP or whoever, and order all the pieces from them, so there's a driver available."
Directions on Microsoft analyst Michael Cherry says he sees some additional factors at work. Both the client and server teams "suffer from trying to create too many versions, which have to be differentiated by arbitrary packing of features or processor support," Cherry says. However, "the strange thing is that the code base is passed between the two teams, and yet the server feels more polished, stable, powerful and easier to work with than the client built from the same base."
In fact, about three-quarters of the Windows client and server code is shared these days, says Iain McDonald, director of project management with Windows Server. He says the Core Operating System Division (COSD) "makes the bits down at the bottom" of the stack, while the client team provides many of the user interface elements that are unique to Vista. The server team is left to focus on code unique to Windows Server 2008, such as the clustering functionality. The goal for the client, server and COSD teams is "don't change as many of the shared bits" as we have in the past, McDonald says.
That said, there are obvious dichotomies between the client and server teams' focuses. "I think that the client team's trying to put too many features -- many of which are not even OS features -- into the product," Cherry says. "The obvious example is Movie Maker, but the list is actually quite long. In addition, too many of the [client] changes that they make appear to be changes for the sake of change -- for example, why did they have to make it so hard to find the map [for] a network drive command?"
In contrast, "it appears that the server team focuses on making incremental improvements that are continual refinements," Cherry continues. The server team "seems to be more reluctant to mess with the key features unless there's a really good reason to do so, such as the need to integrate IPv6." By comparison, he points out, the client development team "is always ripping the whole thing apart and moving components around."
Assembly Required
Delivering Windows Server releases in a more predictable fashion -- alternating between "major" and "minor" builds every two years -- has been a top priority for the server team as well, says Laing.
The Lessons of Windows Server 2008 |
Build on proven ground
The Windows Server 2008 (formerly code-named "Longhorn Server") team benefited from working with the core OS code initially matured by the Vista OS team. It also "outsourced" component code to other key Microsoft units.
Refine and increment
Vista suffered because the team reinvented existing features and added major new ones. The Windows Server team refined, improved and advanced the existing bits, while staying tightly focused on the mission of their server OS.
Stay predictable
From Muglia's 4-to-2 schedule for major and minor server OS releases, to the steady march of betas and community technology previews, the Windows Server crew has set a schedule and committed to it.
Focus on the mission, not the brand
Once the Windows Server team came to terms with the fact that IT looked at servers by role (file and print, mail, etc.), the idea of modularizing functionality emerged.
Stay tough
The Windows Server team didn't allow the feature creep that hampered Vista. They under-promised and over-delivered (by adding PowerShell), and seemed to more tightly control what the team was allowed to add and when.
|
Server and Tools chief Bob Muglia pushed for a periodic release schedule back in 2003. Customers would see a major new release of Windows Server every four years, and an incremental update would occur two years after each major release.
The planning under the new regime fell to Laing. "My team kind of drove this structural thing," Laing says. "We wanted to restructure. We said to the identity management guys, 'You go do your plan.' And the IIS [Internet Information Services Web server team] went and did their [own] plan."
The Server team realized customers talked about servers by role (mail, Web, print) rather than by platform. That understanding prompted the idea of delivering Windows Server 2008 in pieced parts -- via "roles" and optionally user-installable features. (For more, read the Q&A with Bill Laing on p. 27.) Instead of uninstalling functionality, customers would work with a stripped-down core and layer on specific roles and features. In fact, only 25 percent of the bits in Windows Server 2008 are installed as part of "Server Core" -- the rest are add-ons.
When developing new server releases, the Windows Server team takes ideas and code from other parts of Microsoft's server and tools business, the COSD team, the networking team, the Vista team and the Microsoft business division (the team that's behind Microsoft Office), and integrates them into a cohesive whole. But with Windows Server 2008, Microsoft's Server team relied much more heavily on its own code, rather than code written by COSD -- the group that was created in 2003 with the goal of improving Windows' quality and processes -- according to Laing.
Still, the OS is crammed with new features, including a small-footprint installation (Server Core), Terminal Services gateway, improved failover clustering, a network-access protection quarantine capability, the aforementioned PowerShell, a reworked IIS Web server and a read-only domain controller configuration.
Whiskey and Doughnuts
The Windows Server 2008 team delivered three betas in three years. In between these drops, the team delivered several interim community technology preview (CTP) builds. The Windows Server 2008 release is due to go to manufacturing by the end of calendar year 2007 -- just a few months later than officials were predicting a year ago.
The man who sets the milestones for the Windows Server development team is Program Manager Alex Hinrichs. He oversees what's known as the Windows Server ship room in Building 26 on the Redmond campus. There are seven different development branches that feed into the Windows Server organization, and each of these (platform, networking, other server features, etc.) also runs its own "leaf room" ship room.
"I set the schedule and the milestones," says Hinrichs. "I set the priorities, principles and processes for how we'll build this thing. I drive the leadership teams. I break the ties. I am Bill [Laing's] and Iain [McDonald's] guy to make sure we ship the right product at the right time."
There have been challenges, Hinrichs concedes. In spite of having "some very, very senior leadership," not only at the management, but also at the dev, test and product-unit-manager levels, getting everyone on the role-based train was "rough" at the beginning, he says.
 |
"We're building our product on last week's code. We beat the heck out of it. ... We push really hard Monday through Friday. ... We want to do things without having to rely on heroes." |
Alex Hinrichs, Program Manager,
Windows Server
Development Team, Microsoft |
Hinrich says that his team benefited from building on top of the solid code base provided by Vista, which had matured significantly by the time Windows Server 2008 reached beta stage. He also says his team had to closely manage the timing of new features, ensuring that late-arriving functionality wasn't allowed to derail progress.
Because Microsoft says Vista is a solid operating system, that should carry over to the server OS as well. Aspects of Vista that critics say aren't ready for prime time -- features such as power management and User Account Control (UAC) settings -- aren't part of Windows Server 2008.
Says Hinrichs: "The nature of Server is we need to stabilize earlier." This means:
-
Deploying servers earlier and often, in order to discover problems earlier;
- Getting domains running on builds as early as possible;
- Building Windows Server 2008 on Windows Server. ("We're building our product on last week's code. We beat the heck out of it," Hinrichs says.)
Does Hinrichs rely on carrots or sticks to motivate his team? Actually, Hinrichs jokes that he prefers Krispy Kremes and Jack Daniels. (To motivate the team for the April CTP, Hinrichs promised to bring doughnuts and whiskey as a reward. The day the code was complete, team members received from Hinrichs an e-mail that had a picture of a doughnut and a bottle of Jack.)
"We push really hard Monday through Friday," with many team members putting in extra hours from 9 p.m. to midnight from home to get things done, he says. But Hinrichs isn't a sleep-under-your-desk kind of manager.
"We want to do things without having to rely on heroes," Hinrichs says.
And that -- as much as any design, development or testing decision -- has contributed to the Windows Server team's success to date.
Lining Up Developers for
Windows Server 2008 |
Microsoft is still five or so months away from releasing Windows Server 2008 (formerly code-named "Longhorn Server") to manufacture, with the official launch not likely until sometime in the spring of 2008. But that doesn't mean the Redmondians are sitting on their laurels, waiting for developers to magically line up behind the new OS.
As reported, Microsoft is hustling to deliver Visual Studio "Orcas," the next release of its development-tool suite, which will be optimized for developing Windows Vista and Windows Server 2008 apps. (The final version of Orcas will be released to manufacture either late in 2007 or early in 2008, similar to the anticipated release of the new server OS, according to Microsoft officials.
At the same time, Microsoft has engaged in extensive partner and customer handholding to minimize unpleasant surprises when Windows Server 2008 finally ships.
Microsoft started building out the Technology Adoption Partner (TAP) program for its "elite" beta testers in 2005, says Neil Hutson, director and manager of Windows Server Developer Evangelism.
Starting with a small handful of software partners and customers, the evangelism team began bringing "TAPers" into Building 20 on the Redmond campus for "Deep Dive Labs," where they sit with Microsoft developers to work through their specific Windows Server 2008 issues, Hutson says. Last April, the team held a software design review (SDR) for 300 partners to make sure they were on board with the product's direction.
With the final beta 3 just out the door -- and deployed on more than 750 TAP customer machines (under Microsoft's GoLive licenses) -- the focus of the evangelism team is moving from product feedback to marketing readiness and application compatibility.
On the marketing side, Microsoft is working to get as many software, hardware and services vendors as possible to certify their applications as being Windows Server 2008-compatible via the "Certified for Windows Server" program (innovateonwindowsserver.com/). Once products run the "Winqual" test gamut, they're eligible for inclusion in Microsoft's online Windows Server Catalog of Tested Products and Windows Server Marketplace showcase (windowsservercatalog.com).
"We want to make sure there's a good suite of [Windows Server 2008] applications" once the product launches, Hutson says.
With Windows Vista, there were several feature changes and additions that have created compatibility hiccups for certain hardware, software and services. Some of these changes -- specifically the addition of more restrictive User Account Control (UAC) permissions, protected-mode default for Internet Explorer and new sleep/hibernate power-management -- are less likely to wreak havoc on Longhorn Server apps than they did on Vista ones. As Microsoft notes in its client and server OS compatibility "Cookbook," Windows Server 2008 "does not, by default, install applications and accessories that are considered to be part of a user's desktop experience."
A dearth of compatible drivers isn't likely to be the same sore spot for Windows Server 2008 as it has been for Vista, given that the server OS needs to support a smaller set of products than the consumer client OS.
As Hutson acknowledges, "Vista took some of the driver pain for us. We use the same core device-driver model [Vista does]. We started earlier and learned lessons from [it]."
Microsoft installs the top independent software vendors' applications on every daily build of Longhorn Server, Hutson says. As was true with Vista, Windows Server 2008 applications that directly touch the kernel, such as security products, backup tools and the like, are the ones most likely to encounter potential compatibility issues, he says. Microsoft is providing compatibility guidance around versioning, Internet Information Services (IIS) 7.0 and a host of other features in its recently updated developer Cookbook for Vista and Windows Server 2008, which is downloadable for free from Microsoft's Dev Readiness Web site (http://devreadiness.org/blogs/ app_compat_generic/attachment/204.ashx).
Beyond the kinds of apps that directly touch the kernel, the Longhorn Server wares most likely to hit compatibility stumbling blocks are those that check for OS version numbers before installing, and those that make heavy use of IIS, Microsoft's built-in Web server, according to Microsoft's early feedback.
A number of software applications check for an OS version number (which is "6" for both Vista and Windows Server 2008) before attempting to install. Because some existing apps, especially older legacy ones, won't install if they find a new, unsupported version number, Microsoft has provided a compatibility mode workaround (known also as a "shimming layer") to allow partners and customers to get around this initial check. Windows Server 2008 doesn't allow for shimming, but partners and customers can still fudge the version number to get around the initial check, company execs acknowledge.
On the IIS front, Microsoft has made a number of deep and substantial changes to the 7.0 version of its Web server, which is built into Vista and Windows Server 2008. Change isn't necessarily bad, in this case. Windows client and server tester Robert McLaws, who is president of Interscape Technologies Inc., calls IIS 7.0 "the most exciting part of Longhorn Server."
"Having a really robust and modular architecture built on .NET allows developers to do things that just weren't possible with ASP.NET on IIS 6. Because Microsoft has finally caught up to Apache in terms of the modular design and ease of building plug-ins, I think you're going to see a huge spurt in the add-on market," McLaws says. "A lot of ASP.NET developers will take their existing modules and add cool functionality to them that can be leveraged across technologies like PHP."
That said, Microsoft basically rewrote IIS with version 7.0. Like the rest of Windows Server 2008, IIS 7.0 is componentized and setup is granular, meaning not all components are installed automatically. (The NT LAN Manger [NTLM] authentication protocol, for example, is not installed by default.)
With IIS 7.0, Microsoft made numerous changes in the Internet Server Application Programming Interface (ISAPI), as well as the metabase, or metadata database, in the backup/restore and import/export areas. Microsoft Management Console snap-in extensions won't work with IIS 7.0. And a number of older IIS features, including support for the Network News Transport Protocol (NNTP), clustering user interface and built-in Passport authentication, are no longer supported with the 7.0 release. The result: Web sites using missing components may fail to run and sites using deprecated components won't run without modification.
Microsoft's bottom line message to current and potential Windows Server 2008 developers: Typical line-of-business apps shouldn't create compatibility headaches. If your application doesn't go deep into the kernel, and/or make use of clustering, your existing Windows Server app will probably work with few or no modifications on Windows Server 2008. As always, the "your mileage may vary" caveat applies.
-- M.J.F.
|