Skip navigation

Moving On: Valentine Talks About Windows Server 2003

Microsoft's newest server product signals a shift in the company's focus

In this special focus section, Windows & .NET Magazine targets Microsoft's latest server OS: Windows Server 2003. Find out what Brian Valentine, Senior Vice President of Microsoft's Windows Division, and others have to say about developing the new OS. Then, drill down into how to establish multiple-forest trusts, and discover how to minimize administrative overhead with the Volume Shadow Copy Service (VSS) backup utility. Learn how to write simple scripts that take advantage of new and improved command-line tools, and find out how to configure and manage terminal servers with Group Policy Objects (GPOs). Finally, investigate Microsoft IIS 6.0's new architecture and learn how to install this server.

With Windows Server 2003 development coming to a close earlier this year, I had the chance to sit down with Brian Valentine, Senior Vice President of Microsoft's Windows Division, and discuss the company's most complex and customer-driven Windows Server version to date. Here's what Valentine had to say about Windows Server 2003's development, process changes at Microsoft, and the future of Windows.

Paul Thurrott (PT): How did Windows Server 2003's development compare with the development of previous Windows versions? As the product gets more complex, do you see an increase in the development time line with each release or simply an increase in the number of developers devoted to Windows?

Brian Valentine (BV): Windows 2000 was built with a lot of sweat, energy, and passion, but we didn't have a good process. For efficiency, tools, and productivity, I'd give us a fairly low score. We built a great product, but the energy required was tremendous.

Now, we have a much better process that lets us do more complex things and do better things faster. What we've concentrated on most since Windows 2000 was completed is how to move the company from technology-centric thinking into customer scenario—based thinking.

If Microsoft walked in on one of our key enterprise customers 10 years ago, the customer would have explained its business problem and we would have offered Windows and Microsoft Office as the solution. But customers aren't looking for products— they're trying to solve specific business problems, and they need end-to-end solutions. Just offering them Windows and Office won't work today; we've learned that over time. We've taken customer scenarios, feedback, and experience and mapped them directly to the development process.

One example is the Watson technology and the customer-feedback loop that it enables. It's a direct connection to the customer, and we can pull feedback into the product immediately. You get a dialog box when an application or the system crashes, and you can use that dialog box to send a report back to Microsoft. We track these problems all around the world. If we've seen the bug before, we can say, "Here's the fix." You can subscribe to Auto Update and get the fix automatically. This process is just a small component of the overall feedback loop, but it's what we needed to do to address customers' needs.

We've also got a good core set of customers—the Joint Development Program \[JDP\] partners and others—whom we interact with daily. They sit down with us at design time and help us make priority decisions about which features and fixes need to be in the product. At end-of-process—where we are now with Windows Server 2003—they deploy the product early and make sure it's tested in a production environment, as if it were already shipping. All this maps directly back to the development process and affects how we deliver the products.

PT: It sounds as though Microsoft has really changed the way it develops products.

BV: Yeah, it's been a key shift in the way Microsoft thinks about these things. We used to just say, "If you build it, they will come." But that's changed, and we have to engage customers, make sure we're delivering a high-quality platform, and give them a road map for growing that platform. We need to be there when rapid change occurs. This encompasses a lot of things: the best manageability that we can supply, the best quality (obviously with regard to security issues), rapid deployment, and so on.

A few years ago, there was a wall between the development team and customer feedback because of our technology focus. Now, our people are customer-satisfaction focused. We're all absolutely held accountable. If there is a customer-satisfaction issue, it's me that gets beat up, not the sales force. I tell my people that they have five priorities. First are customers. Customers take priority over everything else. Second is the company. That means no egos. If we need to take people off your project and move them to something more important to the company, then we're going to do that. Third is the product. To get a product completed, you must first satisfy the first two goals. Fourth is the people. As a manager, you have to make sure your people are taken care of from a health, pay, or benefits standpoint; in the overall environment, you might ask, "Is morale high?" Your last priority is yourself. If you think of yourself last, then your success will come out of the other four things. If you're not last, you're not doing your job.

Also, I tell my people to think about this every day when they get out of bed: When I look at my group, do I have the best group in the world doing what I do? Do I have the best people to deal with our customers? And compare the answer to other groups at Microsoft as well as to other companies in the industry. If the answer is yes, how do we retain these people? If the answer is no, how do we build that group?

PT: Can you give us a little information about your background? Which products have you worked on, and what was your role during the development of Windows Server 2003?

BV: I joined Microsoft in August 1987 as a test manager for OS/2 \[LAN Manager\], then moved to the Workgroup Application Group, which became the Exchange Server group over time. In late 1998, I was asked to run Windows 2000 development. After Windows 2000, I picked up all of Windows, so I now own anything with the Windows name on it. I'm basically the ultimate decision-maker on the Windows Server 2003 team. \[Corporate Vice President\] Dave Thompson is the day-to-day executive driving the project. He's the engineering manager across the board and works for Bill \[Veghte, Corporate Vice President of the Windows Server Group; see the sidebar "That Was Then ... NT's Early Days," page 63, for an interview with Thompson and Microsoft Distinguished Engineer Mark Lucovsky\]. If someone doesn't know the answer, it stops at my desk, and I handle any big debates. I meet with \[Group Program Manager\] Iain McDonald and \[Research and Development Manager\] Todd Wanke every other day after the War Team meetings to get the status of the project. \[The War Team consists of a broad set of people within the Windows team, all of whom are responsible for different areas of the project. This team meets several times each day to perform triage on bugs that have been found in the upcoming release.\] In essence, I'm the executive Godfather. \[Laughs\]

My history and passion have revolved around managing complex software projects. How do you build a complete environment? I tell the Windows group, "It isn't just a product, it's a lifestyle." Everyone should feel that they're part of that. The product should be fun, because we're building things that other people don't have the opportunity to build. So I'm more than project manager—I have to keep people honest and be the ultimate decision maker. Steve \[Ballmer, CEO\], Bill \[Gates, Chairman of the Board and Chief Software Architect\], and Jim \[Allchin, Group Vice President of the Platforms Group\] look to me as the guy that is ultimately responsible for Windows Server 2003.

PT: Looking ahead, how do you see .NET managed code becoming more integrated with the core OS? Will you rewrite large parts of future Windows versions in managed code?

BV: The long-term goal is that the majority of Windows will be managed code—when that makes sense. So we won't rewrite device drivers and kernel code in managed code, but we will do so for anything above that, including the shell, services, and any applets that come as part of Windows. In the long term, it should all be managed code.

PT: When does 64-bit technology become viable, both on the server and on the desktop?

BV: We have native Intel Itanium support in Windows Server 2003, and that will help 64-bit computing go mainstream. Moving forward, the 64-bit architectures that we've committed to support include Itanium and AMD's AMD-64. These architectures are native parts of the build process now, and every day we build them as well as the 32-bit products.

With Longhorn \[the next Windows release\], our goal is that everything that's native to Windows will be 64-bit native across those platforms. In Windows Server 2003, we've come a long way in that direction, but a complete solution needs all the ecosystem support: We need Independent Software Vendor \[ISV\] support, and all our key server and desktop applications need to be there too. Windows Server 2003 won't have all the device support that's available on the 32-bit versions.

So far, the focus in 64-bit has been the server space, in which most of these machines (such as huge, headless data center boxes) are deployed. For high-end workstations, some of the client features available in the 64-bit version of Windows XP didn't make it, but there's less risk of security exposure. Users of high-end workstations asked for a common environment that they could integrate seamlessly into their infrastructure so that the 64-bit workstations weren't separate from the 32-bit versions. We've delivered that common environment.

PT: Is Microsoft doing any work to abstract the types of storage devices on which Windows can run? For example, when will Tablet PCs and other devices support solid state storage?

BV: Machines that don't have moving parts are basically an interesting research project at this time, unfortunately. Solid state needs a longer life cycle before it can replace a hard disk. Solid state supports about 1 million updates before a failure, and that sounds like a lot, but it doesn't take much time to rack up 1 million reads and writes. The hardware technology needs to advance, but we're very excited about the capabilities in solid state systems. These systems will give us truly instant-on capabilities and much better battery life, whereas today the hard disk is what brings that down. Solid state systems will offer better performance as well. As soon as the hardware is there, we'll be right there with it.

PT: You once told a funny story about using wireless networking to set off car alarms in the Oracle parking lot. Do you have any good enterprise stories?

BV: \[Laughing\] Well, the client products are always about experiences, fun things, and cool entertainment stuff. Servers are a whole different world. When I was on the Exchange team, my son wanted to bring in his Cub Scouts troop to see what Microsoft was all about and see what dad did at work. All I could show them was this rack of servers. "See that green light?" I asked them. "I have to keep that light green."

With servers, it isn't so much about fun as it is about satisfaction. You must plumb the depths of the data center before you can have fun. In Windows Server 2003, the things we're most proud of are the sheer number of downloads we've had—by far, this is the most broadly used server we've ever shipped in beta release—and the feedback we've gotten from customers. What we're achieving around security and quality has been tremendous. We're very excited about what our customers are already doing with Windows Server 2003 before we ship. And really, that's where it's at if you're a server guy. You have to keep the light green.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish