Bob Muglia delivers the Windows Server roadmap

Microsoft senior vice president Bob Muglia is responsible for the development of Windows Server and communicating the company's Windows Server roadmap. I recently had dinner with Muglia and Windows Server Senior Director Jeff Price at Boston's historic Union Oyster House, where we discussed that roadmap and the features Microsoft hopes to include in the next several Windows Server versions. Here's what Muglia and Price had to say about the future of Windows Server.

Windows Server and DSI

Bob Muglia [BM]: It's been just over a year since we released Windows Server 2003, so I thought we'd give you some updates on that. You were at the launch last year, right?

Paul: Oh yeah.

BM: With this release, we started to talk about what Windows Server does for the cost of IT operations, and for IT infrastructure. That's when we rolled out the "Do more with less" concept. Ideally we can help IT administrators save time and money while they're helping end users. We're seeing, a little over a year into it, in our last quarter, we had about 30 percent growth, year-over-year. It's just a huge success, especially Small Business Server, which is very strong. So we're going to continue a theme over the next few years of trying to innovate along three major initiatives--Dynamic Systems Initiative (DSI), Trustworthy Computing, and .NET--all to drive a set of benefits for users that are pretty consistent. So we'd like to discuss how we're going to drive those initiatives over major and minor [Server] releases.

Paul: DSI comes up again and again these days, but I'm not quite sure that I understand what it is.

BM: The whole concept behind DSI is how we can improve the manageability of systems. The approach that we have is to look at the different types of people who are involved in the application lifecycle and systematically build ways for information--knowledge--to transfer between those people, so that everyone in the whole chain can be more effective. When a developer creates an application, there is a lot they know about that application. They have an idea of the runtime environment that it should exist in. That knowledge isn't transferred to the operations staff. Maybe some email is sent, maybe there are some diagrams, but there's so systematic transfer to the operations staff. The operations guys deploy the application, and then they learn things [about that application] that the developers don't know, and they never tell the developers. Meanwhile, end users have the real scoop about what that application is doing on a day-to-day basis. And being able to get that data, about the way they use the application, again, there's no systematic mechanism.

So what DSI is all about is the transfer of knowledge between all of those people in a programmatic way. So that for the first time, when you deploy an application on top of a series of computers, the knowledge of the runtime environment that application expects is actually encoded into the system in some way. The way that we do that is, in Visual Studio, the developer creates the application using something called the System Definition Model, or SDM, which is an XML document that describes the application runtime environment. And that gets sent over to the operations staff, and then they can use it to run and monitor the application in a specific configuration. And as they learn things about the configuration, they can transmit that back to the developers, again using the SDM.

The other part of this is the experience that end users have running the application. Today we do things with Watson, when we get an error, that information can be transmitted back to Microsoft. Well, we also have something called Corporate Error Reporting, where that same information can go back to the IT administrator instead. We're expanding on the kinds of information Watson collects, and we'll hit other areas of information transfer, like, for example, help information. And as we move that to an online state, we can really find out what documents are useful to end users, what they use, what they don't use, and then let them comment on the usefulness of those documents. So again, we're taking information that the end users have, and programmatically sending it back into the development process.

Paul: So if a business rolls out Corporate Error Reporting, when they get a crash...

BM: ...it goes back to the corporation's IT staff. It could be a business app that they created, and not a commercial app. The fascinating thing about these error reports is that its led to one of the most substantive changes in our development process ever. It is clearly the 80/20 rule .. in fact, it's more like the 90/10 rule, where 10 percent of the bugs cause 90 percent of the crashes. So if you can fix those bugs, you have a dramatically improved user experience.

Paul: Is this successful? Are a lot of customers actually using the Error reporting tool?

BM: We get millions a day.

Paul: Millions a day? Really?

BM: We have a lot of users. The thing that's great about it is that we can actually debug their problems. It's more than just finding out that a problem exists. We can actually instrument it and know more about the errors.

BM: So that's DSI. The other two major initiatives are Trustworthy Computing, which is all about security, and .NET, which is our application development platform. All of this, together, is about how we can reduce the cost for IT and give them unique advantages. That's the core focus of these major initiatives, and they're very long term. We're going to be working on these initiatives for a long time.

Paul: I was surprised to read recently reports that Microsoft was scaling back Trustworthy Computing. At the [Windows Hardware Engineering (WinHEC) 2003 show] recently, there were reports that Microsoft was deemphasizing Trustworthy Computing. But that doesn't seem to be the case at all.

BM: It's not deemphasized. People seem to pick up on certain things. People may try to intuit things.

Server workload focus

BM: This is sort of the overall way that I think about the server business. In some ways, it's very straightforward, but in others it's important to understand the ways in which customers use our products. We look at the different audiences--the different personas--of IT staff that use Windows Server, and we've actually codified that into 32-32 different personas. These are different roles, like IT administrators, database administrators, desktop support administrators, help desk administrators, security administrators, storage administrators, and so on. We think about those different audiences and the ways they look at technology.

Windows Server compared to Linux

BM: The second piece is that we look at Windows Server. People deploy Windows Server for one or more workloads within their environment and its often Windows Server together with a server application. It might be Windows Server, a database server, and an application on top of that. So you have this series of things that are all put together to create a solution. Thinking about the server across all these workloads helps us to think about how we can build, in one dimension, a best-of-breed system for each of these workloads, and it also lets us think about how we can innovate in an integrated fashion across all workloads to create a differentiated advantage relative to the competition. And in thinking about the competition, this approach really lets me frame how we run this business and how we can get advantage and do better things for our customers than our competitors can do using technologies like Linux.

The thing that I've come to realize is that Linux has changed in the last couple of years, or at least in the last 12-18 months. It's moved from this purely amorphous open source movement into a commercial technology that is brought to market by commercial companies. So when a customer buys a Linux-based solution, they turn to a vendor like IBM and they buy a set of products from that vendor, often with consulting services attached to it. The interesting thing about that is that the myth that Linux is free is still really broad. I think that all of our customers understand that Linux has costs associated with it, and in fact if you look at a comparative solution, a Windows-based solution and a Linux-based solution, I think the initial price tags on those things will be pretty comparable.

So how do we do on that networking workload, relative to Red Hat Linux? It's the point where we can look at commercial implementations of Linux and do a comparison of that product and technology relative to our product. And that's very important for us, to be able to differentiate our products in the market. In many ways, Linux is not our competition. Instead, Linux is a technology that is used by our competitors to build competitive products. And those products are our competition.

So that's sort of the high-level way that we're thinking about this problem-space. We think about how organizations can manage themselves to build best-of-breed solutions that span one of these workloads, and at the same time ensure that we provide integration across the workloads to provide the best all-around solution that's clearly a differentiator relative to any of our competitors.

Paul: It just seems to me that Linux is a competitor for what I call "infrastructure," things like network services, Web serving, and so forth.

BM: Yup. That's correct.

Paul: But they don't have anything like Small Business Server, it's not even close.

BM: Nope, they do not. They do not.

Paul: They're years away from having a product like that.

BM: The categories where we're seeing Linux [succeed] are in exactly what you described, network services. And then the other place we see it is in proprietary UNIX solutions migrating down to [Intel] x86 hardware. We have a solution there called Services for UNIX, but certainly Linux is a solution that some customers prefer. But I think you hit it right on the head: Looking at this, I can sit back and say, where do we see Linux? We certainly see it in networking, we see it in UNIX application migration, and we see it in high performance computing. And we see it to some extent in application/Web server, but not as much there. We don't see it that much in database, we see it only moderately in storage, email and collaboration--not at all, identity management--almost not at all, and so on, you can go down through the different workloads, and see it to different degrees in different places.

But this workload focus gives us an all-around way of looking at the problem-space and understanding how Microsoft can build the best products for our customers.

Where Windows falls short

Paul: This [chart] begs a question. Obviously, Microsoft addresses all of the workloads you've listed here. Are there any workloads Microsoft doesn't address that should be on this list?

BM: One workload I think we've historically done poorest in is high-performance computing. But that's an area where we're making some ongoing investments too. Looking at this list, I think you can say that we have either best-of-breed solutions--like Small Business Server--or others where we have very strong offerings, like application/Web server. And then there's those workloads that are commodity in nature, like networking, where customers can choose whatever is convenient.

Paul: Clearly that's not going to be a huge business anyway, customers buying Linux machines to be DNS servers isn't going to harm Microsoft's core business.

BM: That's absolutely correct. It will be interesting to see if the networking workload changes over time. We'll take a bit about anywhere access in a little while, and some of the new opportunities that exist in gateways. Like anything else, there is some innovation that's possible but in its current form, you're absolutely right. Those things are pretty much commodities.

Jeff Price [JP]: Quarantine is another place where we've decommoditized.

BM: Absolutely. We'll talk about that in a bit too.

Windows Server release cycle

BM: One thing we're trying to do is move to a world where we have much more predictability associated with our software release schedules. And as we made this shift, around Christmas [2003] time, we reorganized around three basic organizations for Windows product line development. We went from a monolithic organization run by Brian [Valentine] to a Windows Server group that I run, a Windows Client group that Will Poole runs, and then the core [Windows kernel] team that Brian [Valentine] runs. We're moving into a world where the core team really provides a pulse for Windows Server. And you can think of that group doing a major release about every four years. So Longhorn is the next major release. And Longhorn will be release in both client and server versions, with a bit more bake time for the server.

But we're also trying to build on top of those [major release] kernels and ship update releases that are about two years after each major release. So we can take features and functionality and add them on top of the [then-current Windows Server] kernel--not change the kernel in any way, keep things consistent for the customers and don't break compatibility--and build functionality on top that they can utilize. [Windows Server] R2 will be the first of these update releases.

Paul: So this is a way to undercut the current churn cycle, where product releases are getting so far out that it's getting a little hard for corporations to plan.

BM: It's a recognition that, to do something major, when you open up the hood and do something major to the core of the operating system, that it really takes 3-4 years to do that, and that's a long time to go between major releases, especially when there's all this innovation we're building in between. How do we get that package together and out there, and do it in a consistent, predictable fashion?

Paul: I know this isn't your area, but do you see the client going the same way?

BM: The client does not have as much clarity about these update releases. But they'll certainly synchronize [with Windows Server] on the major releases. There's no question about that. [Windows Client] might do more targeted individual market releases, like they've done with Media Center and Tablet PC. Things like that. But it's a somewhat different environment than [servers].

Paul: One of the big issues that's come up recently is that people who opted for the Software Assurance (SA) licensing program feel that they were promised a release of some sort and there's been a lot of grumbling, with SQL Server [Yukon] being delayed again. Is there any talk going on at Microsoft about doing right for these customers.

BM: Sure! Sure, we want to create consistency so customers can know what to expect. It's common sense that if you have a Software Assurance cycle that's three years, that four years between product releases is going to be problematic for your customers. By doing releases on a more regular basis, we have an ability to deliver value on an ongoing basis.

JP: The one thing to add there is that most customers aren't buying a license just to get the next version. They're getting other benefits and might have a number of different servers rolling out at different times. Customers on enterprise agreements know they're getting the value. In the specific case where there's one SQL Server version ...

Paul: Well, this is obvious a big issue for some people. I've gotten a lot of email about this issue. I'm sure you're right, but it seems like there are a lot of people who expected to get the next version as well.

JP: No, it's a real issue.

Paul: Does R2 address the need to have another Server release?

BM: I think it does. It's a new Server release that customers will have to pay for, unless they're on Software Assurance. If you're on Software Assurance, you just get it.

Windows Server release roadmap

BM: Ok, let's look at the actual roadmap. Obviously, we shipped Windows Server 2003 last year. In 2005, we'll do R2, the first update release. In 2006, we'll start the beta process for Longhorn, and probably do a second service pack for Windows Server 2003. We're targeting 2007 to ship Longhorn Server, or about 6 to 12 months after the Longhorn client. It's a ways after the client.

Paul: OK, so the schedule hasn't changed all that much. Someone described the Longhorn Server schedule to me one time as being "one milestone" later than the release of the Longhorn client.

BM: Yeah, that's pretty much what it is. In 2009, probably, we'll do an update release of Longhorn Server. So we're actually thinking that far ahead, and even to Blackcomb, about how we can continue to drive innovation.

That said, what we're doing this year is a little more than just a service pack, and I'll talk a little bit more about that. But the key thing that's coming this year is that, in addition to Windows Server 2003 Service Pack 1 (SP1), we're also doing a whole new platform, which adds 64-bit support. It's a pretty major release, but it's an example of how the industry can have a major platform shift and we have to respond to that. Does this make sense?

Future Feature Packs?

Paul: Yes, I'm up on this product [Windows Server 2003 for 64-Bit Extended Systems, which targets AMD-64 Opteron and Intel x86-64 EM64T]. But a few questions come to mind. The first is that there have been a bunch of [out of band] Feature Packs released for Windows Server 2003. Are there going to be other Feature Packs moving forward? Is this going to be a tradition for Windows Server releases?

BM: To some extent. If you only do major releases every four years, you have to do lots of Feature Packs. If your releases are two years apart, you can do less of them. Where possible, I will roll features into update releases, rather than have them be released separately as Feature Packs. But there will always be reasons to do certain Feature Packs. Here's what's worrying about Feature Packs: Customers have a hard time absorbing Feature Packs. They're not discoverable, they have to download them, OEMs don't ship them. There's a lot of convenience that comes from having a single release, and it just provides a lot more value to the customer.

I would never say that we're not going to do another Feature Pack, because we will do Feature Packs. An example of one we'll always do is SharePoint, which ships when Office ships, because the alignment [of that product] is predominantly with Office. We'll make sure we do the right thing, which in this case means that Feature Pack will ship when the next version of Office ships, and then we'll roll it into the next Server version. If you look at Office 2003, it will be 18- to 20 months before that [SharePoint] product is rolled into R2.

Windows 2000 Service Pack 5 (SP5)

Paul: The other question is about Windows 2000. Are there any Windows 2000 update releases planned? One of the things I get asked about a lot is whether Windows 2003 Service Pack 5 (SP5) will include any of the "Springboard" security updates from XP SP2 and Windows Server 2003 SP1.

BM: We're taking the core fixes that we find we need to bring back to Windows 2000 and putting them back there. But no, there's nothing like Springboard at this point for Windows 2000. We won't do the very broad pass that we did for XP.

Paul: Can you clarify a bit what that will be? Are you talking about the low-level improvements in XP SP2? Or just hot-fixes and so forth?

BM: Just those things that we feel are the really significant security vulnerabilities we've identified. Those are the only things that we're taking. You have to understand that with Springboard, we made hundreds and hundreds of changes to the operating system. We've done a lot of clean-up-type work that no one's really done any exploits on [in XP SP2], and yet we want to make sure there's no chance of that happening, so we're doing a ton of that sort of work. That's not all going back to Windows 2000.

Paul: OK, so ... Windows 2000 Service Pack 5 will be more like a traditional service pack and less like XP SP2.

BM: Absolutely. Even XP SP2 doesn't look like a service pack.

Paul: No, not at all.

BM: Any other questions on the Feature Packs?

Paul: What is the Server Performance Advisor?

BM: It's a tool that makes it straightforward to look at different performance configurations and determine what sort of performance you're going to get. It lets you understand the more in-depth underlying performance characteristics of your system.

Paul: OK, and Windows Update Services is still on track for release this year?

JP: Yes, actually late this year.

BM: And Virtual Server 2005 is on track for this summer.

Paul: OK.

Windows Server 2003 Service Pack 1 (SP1)

BM: OK, next is SP1. Windows Server 2003 SP1 has three predominant things. First is a base level improvements to the system in terms of hot-fixes. We haven't seen a tremendous number of problems with Windows Server 2003, but it's still there. There are security enhancements in there too, but a lot of the security enhancements we added to Windows XP SP2 were already in Windows Server 2003. Some of the vulnerabilities we had in XP weren't present in Windows Server 2003. Sasser, for example, doesn't affect [Windows Server] 2003. Also, we've increased performance in SP1. We believe SP1 will bring some slight performance improvements across the board. There's also an availability improvement with this release too. The other major thing is [AMD-64/Intel EM64T] 64-bit support. And the Security Configuration Wizard (SCW) is going to be big.

Paul: Yeah, clearly that is the big UI piece in this release.

JP: So have you ever used the Security Configuration Editor (SCE) in Windows 2000 and 2003? It lets you take a template of settings you want to apply and tell you, one, when a machine is out of compliance with those settings and, two, why. The SCW is a natural evolution of that [feature]. Its more roles based. It's unfortunate that more people don't know about the SCE, because there are a lot of people suffering through individual policy settings, even Registry settings.

Paul: The biggest problem you folks have is, and this is true of the Configure Your Server stuff that you're already shipping, is that administrators see the graphical stuff and they just turn it off. You're going to have the same problem with the SCW. And it's too bad, because it's just beautiful. It's one of the coolest Server tools I've ever seen.

JP: If they are hard core admins that don't want to use anything called a wizard, then we can debate whether that's the right name to use or not. But you can script it, so there's a programmability aspect to it as well.

Paul: Yeah, that will make a big difference. "Don't forget, guys, you can make an XML template file with this thing..."

JP: [Laughs] Yeah, exactly. You can make it really hard on yourself if you want to. You can use Notepad.

BM: OK, so that's SP1.

Paul: So what's the schedule on this? Are we waiting for XP SP2 to wind down, and then thing starts cranking up?

BM: Absolutely. We're all waiting.

Windows Server 2003 64-Bit Extended Systems release

BM: So we think 64-bit is a big deal.

Paul: I haven't kept up on the Itanium stuff as much as I could have, I guess, but I did go to the first 64-bit Windows reviewer's workshop that you had in Mountain View, probably four years ago or so [LINK], and I recall that the big problem, aside from performance, was that the versions of Windows you were coming out with for Itanium weren't complete, didn't include all of the features from the 32-bit versions. And then of course the performance of 32-bit applications was garbage.

JP: Both of those problems are fixed with the new 64-bit platform. If you look at the numbers today on AMD64, and then flash forward 12 months...

Paul: Sure. I mean, you can buy laptops today with an Athlon-64.

BM: You can, you can. It's not Opteron, but it's based on the same technology.

JP: It's only a matter of time before we get to the point where it doesn't make sense for a server vendor to ship anything but 64-bit machines based on AMD64 or Itanium.

Paul: So you think this platform will be bigger on the server at first?

BM: I think we'll start on the server, but it's going to move to the client very quickly.

Paul: So what are these machines looking like today? How many processors can you get in a single box on AMD64?

BM: Four-ways look great. And we'll see a lot of that over the next 12 to 15 months. It will take longer for 8-way to come out. But I think AMD64/Intel EM64T is going to be the volume platform of the future.

Paul: Oh I think so too. I think it's going to happen very quickly. Before Christmas 2005, all [mainstream] PC systems will be 64-bits.

BM: They'll all be enabled by next year. I think it will be huge on the client.

Paul: Absolutely.

BM: One thing we've found is that 32-bit applications run better on the 64-bit OS than they do on 32-bits. Just adding a 64-bit processor and the 64-bit OS changes everything.

Paul: Now what are you comparing there? Are these machines running the same clock speed...

BM: Same everything. Same chips, same everything. We run apps on 32-bit Windows, and then take those same apps and run them on 64-bit Windows, and you'll get about an 8 percent performance improvement on average.

Intel EM64T vs. AMD64

Paul: Are you seeing any difference between AMD's [64-bit] stuff and Intel's stuff?

BM: Yes. [Smiles]

Paul: Would you care to clarify that? [Laughs]

BM: Well, AMD has done a good job ...

[Laughter]

Paul: OK, I realize these companies are both important partners...

BM: I think both have invested very heavily... and I'm sure that customers will be happy with either solution.

Paul: All righty.

[Laughter]

BM: Are there differences? Yes, there are differences.

Paul: OK, so how do these companies differentiate their 64-bit products?

BM: So there are some things that AMD's done that Intel hasn't done, and I'm sure Intel will continue to invest here, and will do a really good job. AMD led the way on this one. There's no doubt they led the way on this one.

Paul: Right, I thought [AMD64] was going to be the orphaned [microprocessor] of the decade, the next Alpha...

BM: Oh I didn't think so. But do you know why I knew? Because of Dave.

Paul: Dave Cutler.

BM: Yeah, Dave's been all over this. Dave worked really closely with to design the chip. He was trying to get something that was really compatible and the problem that we have is that we want to support all of our applications totally. And these chips are just fantastic for that.

Paul: It's almost like applying the Microsoft model to [chip design]. The Itanium, for all its advantages, just couldn't run the installed base very well.

BM: No, not very well.

Paul: And it never will.

BM: No.

Paul: So back to the core OS benefits, again, where do these figures come from?

BM: This is our own internal testing. It's pretty remarkable what we're seeing, actually.

JP: There are a bunch of address space limitations to 32-bit, and for certain functions, you just can't get enough memory. And with a certain amount of memory, all of those limitations go away.

BM: We tested a whole series of workloads. Some workloads just don't benefit that much from 64-bits, but having a 64-bit OS on there gives you certain advantages. Other workloads--even if the app is 32-bit--you get a huge benefit by running on a 64-bit OS. The most extreme example of that is Terminal Services, because it's limited by the amount of physical memory in the box, in terms of capacity. So even though it's a 32-bit application, you can now run a lot more users simultaneously on the same computer. And these four-ways are blazingly fast.

Paul: These machines we're talking about. Are they out now, or are they coming out next year?

BM: They're out now. They're AMD Opteron systems.

Paul: Physically, what is the limit on RAM in today's Opteron machines?

BM: It's a physical limit based on the number of slots in the machine. I'm not sure what that number is. I'm sure you're going to see 32 GB systems today.

Paul: Compared to 4 GB on 32-bit.

BM: Well, three really. Though we can do more with address extensions. It's funky. Kind of like the old school memory extender stuff.

Paul: Ah yes, the good old days. But wow, 32 GB of RAM this year.

BM: Sure. I mean, we've actually built Itanium systems [at Microsoft], these really big systems, with a terabyte of RAM in them.

SQL Server 2005 for 64-Bit Extended Systems

Paul: As far as software support goes... presumably, you'll have a 64-bit version of SQL Server that will run on this new 64-bit platform?

BM: We'll have a native 64-bit SQL Server when the new version [SQL Server 2005] ships next year.

Paul: What about other products?

BM: Most of them don't need to go to 64-bits, at least for the near term.

Paul: And this [Windows Server 2003 for 64-Bit Extended Systems] will ship concurrently with SP1?

BM: Absolutely. And then shortly thereafter, we'll ship a client release [Windows XP for 64-Bit Extended Systems] that's actually based on the same code base. It's interesting to ask how quickly the industry will switch over to 64-bits. We're pretty bullish about it turning over pretty rapidly.

Paul: Obviously, driver support is going to be the big problem.

BM: You know, the thing you have to realize is that, yes, that is the key issue, but there are over 10,000 drivers now running on this new operating system. So there are a lot of drivers out there.

Paul: This is like the "printing of the HCL [Hardware Compatibility List]" days from NT 4, when you'd want to have the list with you when you went to the store to see which hardware you could actually buy.

BM: Yeah, but it's not that bad, there are already 10,000 drivers converted to 64-bits. So we should have a ton of driver support eventually. And of course, there's more [drivers] than that that exist. Some drivers will never get converted, too. That four year old printer might not work.

Paul: Sure, but hopefully new hardware will be generally supported.

BM: Right.

Windows Server R2

BM: OK, R2. The first update release [for Windows Server]. The most important point is that it's based on Windows Server 2003 SP1.

Paul: So you're finally going public now, right?

BM: As of [May 13, 2004].

Paul: This was the release that never existed.

BM: Yeah, it's been weird, we know that.

Paul: Hey, that's OK.

[Laughter]

BM: We just needed to get our act together, so we could talk about it publicly. The first and most important thing about R2 is that its based on Windows Server 2003 SP1, so customers who deploy Windows Server 2003 don't need to worry about deploying R2, it's compatible with all those applications, we're not changing the binaries that ship in 2003.

Windows Server 2003 SP2

Paul: So this will be pre-SP2?

BM: Yes.

Paul: So ... Will there be an SP2 release that addresses only the original Windows Server 2003 release, or will SP2 be only for R2?

BM: Great question. No one's asked that question yet. When Windows Server 2003 SP2 ships, it will apply to both the original Windows Server 2003 as well as R2. It will apply updates to R2 binaries if that they're present.

Paul: OK, so R2 doesn't mark the abandonment of the original version [of Windows Server 2003].

BM: Nope, not at all.

SMB file sharing and Terminal Services over HTTPS

BM: Our first focus in R2 is on accessing information. One of the most important things we have is remote access from the Internet into the corporate intranet for things like SMB [file sharing] and Terminal Services. Are you familiar today with the way Outlook 2003 and Exchange Server 2003 work where, you know, if your portable here was connected to a Wi-Fi network, and you were on the Internet, you could just pull your email down...

Paul: You're talking about Exchange over HTTPS.

BM: Exactly. We're taking that same technology and extending it to SMB file shares and Terminal Services.

Paul: Really? Now what about firewall-type issues?

BM: We'll use HTTPS ...

Paul: Right, but I remember when Exchange 2003 was still in development, the Exchange guys talked up HTTPS access, and it sounds very exciting, especially if you're ever tried to set up a VPN connection, but if you talk to the ISA Server guys, and they have a new version of that server that's coming out this year that will handle that, but with their existing product, their advice is, whoa, hold on, that's scary because ISA doesn't do any kind of HTTPS filtering for Exchange traffic.

BM: We're going to do that filtering right in the OS for SMB and Terminal Services. So, for example, we will not allow named pipes access over HTTPS because ... it's too scary. So we're just going to allow file access.

Paul: OK, let me just make sure I have this right. This version of the server [R2] will support SMB file shares and Terminal Services over HTTPS. OK.

Other R2 features

BM: The second big feature [of R2] is identity federation across corporations.

Paul: This is Trustbridge, right?

BM: This is Trustbridge, yes.

Paul: So this is cross-domain identity federation?

BM: Across forests. This allows a company to work with their business partners, share information, and not have to worry about setting up unique Active Directory accounts.

The third feature is network defense, or quarantine. And this is an area where we're going to invest in a bunch, in terms of how to allow and ensure that a portable that gets on the network through VPN or within a corporate LAN in fact has the correct level of security patches and accreditation.

Paul: Now when does that happen? If I'm here and I VPN into the network...

BM: It happens when you VPN in. We'll check with SMS [Systems Management Server] or the virus vendor to see if the machine is up to date before we let it access the network.

Paul: So basically, this is a way of enforcing updates.

BM: Exactly. Jeff was talking last night about the stages of evolution of software, and he mentioned that we start by making things possible, we continue by making it practical, and then eventually we make it seamless for the end user. I think that taking and creating HTTPS access and transitioning from VPN moves that technology into the seamless category. VPN makes it possible, in Windows 2000, we made it practical, but now it will be seamless. Quarantine is still at that "possible" stage. I think it's going to be hard for companies to deploy this at first. But it's pretty important, in the long run.

JP: We use it today at Microsoft.

BM: Right. Our IT guys had to write all these custom solutions to make it work. It's clearly still in the "possible" stage. It's not practical yet.

The next thing, and it's not on this slide, is the application infrastructure. So we're taking the Whidbey .NET Framework and CLR [Common Language Runtime] and putting that in R2.

Paul: OK, so that will be the .NET Framework ... what? 2.0?

BM: Yeah. 2.0. And that enables people building Whidbey applications to run them directly on Windows Server 2003 R2.

Another area of focus in R2 is in branch offices. There's been a whole new investment stream [at Microsoft], similar to what we've done with Small Business Server, and our focus is to focus on how we can enable branch offices as remote caches, so that they're accelerators for people that exist in branch offices. So even if they don't have an IT staff, they can be managed remotely from a central location. The key feature here is file replication, making it easy to replicate files between the central office and the branch office, and to do so with compression algorithms that reduce the amount of WAN traffic that they require. We're pretty excited about this, though I will say that we're still in the early stage of investment for our branch office offering. Overall, from a long-term investment perspective, I'm pretty excited about this space.

[R2] is a new release of the Server, as I said, so Software Assurance customers will get it, but other people will have to buy it as a new release of Windows Server. We do expect the channel to move to this product very rapidly.

Small Business Server R2

Paul: Will there be a Small Business Server R2 release?

BM: Yes. There will be a Small Business Server SP1 as well, although we don't have plans to do a 64-bit Small Business Server in the short term. Hey, it will happen. There are a lot of markets where we're selling all kinds of Small Business Servers to our enterprise customers. A lot of them are buying SBS to do branch offices. It's great for branch offices.

Paul: Have you looked at putting any of the great management tools from SBS in the base Windows Server products?

BM: We always look at the things we've done in Small Business Server and think about how we can incorporate it back. But you have to understand, with Small Business Server, there are a lot of assumptions we can make. It's the first major server being installed, which won't be true in a lot of enterprises. But one of the things we're looking at--I talked about these different roles or personas for different IT people--one of the things we're looking at very closely is that one persona, which is the IT generalist, a person who is literally a mile wide and an inch deep, and seeing how we can apply Small Business Server to all those different workloads for this person. It's amazing how hard it is to set up a medium business with a half dozen servers. It's much harder than it should be. So if we can make that a lot easier, we think there's a huge opportunity to grow that market.

Paul: Right.

BM: One of the things I did was, for my house, set up half a dozen different servers. I didn't want to use Small Business Server because I knew those guys had done a lot of optimization, and I wanted to see what it would be like for a medium business. So I set up DNS and DHCP, I set up an 802.1x wireless network. It's not easy to do that. And I can tell you about starting a Certs server (Certificate Services), starting a RADIUS server, getting the Certs server into the RADIUS server, establishing that with a CISCO Airnet wireless access point, I can tell you how awful that is.

Paul: Meanwhile, you're wife's sitting there saying, "I just want to get online..."

BM: It's always on a trip like this that something goes wrong, and I get that phone call.

Paul: I can't even tell you how many support calls I take from my wife when I'm on the road.

BM: The TV is usually the first problem.

Paul: Oh, it's always the Media Center, exactly. "So, I recorded this show, but it recorded a cartoon instead. What do I do?" Well, you watch the cartoon, honey.

[Laughter]

BM: Looking at this, there's just such a huge opportunity for us to make these things better. And that's a big focus for us. It's fun, because now that I've done all this work, I can talk to these guys, the ones who actually built these things, and say, why did you do this? What were you thinking? Why can't we do this differently? Sometimes they have a good reason.

Paul: Oh, there's always a good reason. I did something similar [but less adventurous] with servers and just switched it over to Small Business Server.

BM: It's the totally rational thing to do.

JP: The remote access stuff is just incredible.

BM: Right. I don't have that. I wish I had that. But I'll get that in R2 now, won't I?

JP: Yes you will.

Longhorn Server

BM: So there's not a lot of change in Longhorn [Server]. We're building the Longhorn client and server together. Our areas of focus in Longhorn are, first, we have a whole updated generation of the application development platform, with a new version of IIS [Internet Information Services], and of course Indigo [Web services platform] comes into play in this timeframe, so we'll focus on Web services and WS protocols. There's a lot of work on manageability going into Longhorn Server, really an extension of what we're doing on DSI. We're focused on a number of improvements to the command line shell and scripting, so we're continuing down the path of working on Monad [the Microsoft Script Host environment, currently in beta] to think about how we do command scripting. We've got a new eventing subsystem, a number of things to make end-node manageability better in this environment.

Looking at DSI, we have some components in place today with DSI in MOM and SMS 2003, and coming soon in MOM 2005. Next year, we ship Whidbey [Visual Studio 2005 and .NET 2.0], which is the toolset that creates the SDM. In 2006, we'll build a version of System Center that consumes the SDM, and move it from a cross-system management perspective to allow it to do things like desired state management. And then in this [Longhorn Server] release, we'll do more focus on the end-node management, to make it easier to manage the end nodes associated with the overall DSI model. So they all build on each other. It's a long term effort, but you'll see progress at every step along the way.

Other things here, in the fundamentals space, this [Longhorn Server] is where we get IPv6 support and we're already focused on application compatibility with Windows Server 2003, although because it is a major release, my certainty of perfect [regarding app compatibility] is less certain than it is with R2. It's also time for a whole new generation of hardware support.

Dynamic partitioning

BM: We'll have support for dynamic partitioning, which is appropriate in mainframe-class systems, such as those we have on the Itanium today. So if a processor fails, you can swap out the processor without bringing down the application.

Paul: So I've confused partitioning with virtualization. Is partitioning more about redundancy?

BM: The two technologies are actually quite complementary. Partitioning is about being able to allocate resources within a single operating system environment, to different tasks, and being able to change those resources over time. So, for example, you have a server application that's running. Today, if you have Windows Server running on a box, and you put SQL Server on it, that will grab whatever processors that the server has. With dynamic partitioning, you can say, this SQL Server only gets four processors, but maybe later on you decide you want to add a couple of processors, so SQL can take advantage of that. And then, if a processor fails, you can automatically switch over. You can literally pull the board out, replace the board, and then have the processor available once again.

Paul: I don't do that kind of thing anymore, but I never did get used to Hot Swap.

BM: They do it. People have this thing about rebooting: They just don't want to do it.

Paul: So dynamic partitioning could actually work with Virtual Server environments.

BM: Yeah, it's interesting with Virtual Server, because Virtual Server lets you subdivide these [physical] machines to different virtual machines, and then perhaps you do dynamic partitioning on top of that.

Diskless blade support and a storage snafu

BM: Also, we're supporting diskless blades [in Longhorn Server]. Today, blades have backup hard disks, but hard disks can fail, so they're a pain in the butt. You want to be able to both boot and page off of a SAN [Storage Area Network], and that's what this support will provide. You can create images that can be booted and run completely off of a SAN environment, and not require hard disks on the blades themselves. This will reduce the failure rate dramatically. I love this stuff. This is my favorite stuff. That and storage. I love storage.

Paul: Really? Wow. I don't even know what to say to that.

[Laughter]

Paul: A friend of mine writes about storage, and it's always kind of a joke between us. You know, I'll be having a tough day, and he'll say, "Hey, at least you don't write about storage." It always cheers me up.

BM: Ooh. I find that almost insulting. [Laughs] I'm almost insulted by that statement.

Paul: I'm sorry. From our perspective, it's not the most dynamic ...

BM: You know, the interesting thing is that the storage industry continues to grow greater than Moore's Law, and the implications of that are so astounding, when you think about how we'll have multiple terabyte stores on a portable, which is not that far away. It's just astounding, the implications.

Paul: Sure, my Pocket PC has 32 times the storage of my first PC.

BM: Absolutely, at least. You could get one of the first PCs with just 64 KB of RAM. My first PC had 256 KB of RAM. And the floppy drives were just 384 KB.

So that's pretty much it.

Paul: This is all your doing?

[Laughter]

BM: We could talk about storage more if you want.

Paul: And a can of worms has been opened. But seriously, I'm just glad you folks are finally talking about this stuff.

BM: I am too. All the marketing guys are too. They've said that, "Bob has had a piece of duct tape on my mouth for the past four months."

Back to Linux...

Paul: You know, I just remembered something. You've been to a few Linux events recently, haven't you?

BM: Not too much. The Linux community is an interesting place, with an interesting set of focuses. Sometimes they're not very in sync with what we're trying to do.

Paul: [Laughs] Right.

JP: That said, it's a lot more pragmatic today than it was.

BM: I think so.

JP: A lot less emotional and religious.

Paul: Well, you can make a lot of money off emotion.

JP: Yeah, it's a wonderful model.

But both Linux and Windows are taking share from everyone else. Looking forward, a lot of companies are going to be running both.

Blackcomb Server

BM: One of the great things about this space, and this job, is that it's not like any of my customers are saying, "I don't want any new features." They're saying, "How come this is screwed up," or "how come that is screwed up?" "How come you're not doing this?" or "how come you're not doing that?" So that's why we look at this new roadmap, and we try to have a regular release cycle, with a regular innovation plan. We can drive these things out in regular, consistent ways to customers. I didn't list it on here, but I'm thinking about Blackcomb [the next major Windows release after Longhorn, currently due in 2011] too. And I can think about the feature-set of Blackcomb. I know what features are going in R2, I know what features are going into Longhorn Server, and I'm getting a pretty good idea what features are going into the Longhorn Server Update, and I have an idea of what might go into Blackcomb.

Paul: Blackcomb being the next major release.

BM: Right, the next major release, four years after Longhorn Server. You may think that Longhorn is a long time away, but you'd be shocked by how fast that much time goes by. Think about something like Indigo, which has been in development for almost four years now. And you realize that some of these major innovations take a long time to bring to market. Especially in an enterprise environment where customers really have an expectation in terms of maturity and availability.

Wrapping up

Paul: I get a lot of questions from people who want to know what's going on, and I know that you're being very secretive about a lot of the client stuff for various reasons, But on the business side, especially, there are some good reasons to what to know what the roadmap is. It's nice to have it clearly spelled out like this.

BM: Good, I'm glad to hear that. I think that's what our customers really need. The reality is, our average customer today is starting their deployment of Windows Server 2003. They've had some introductions, but by no means have they entirely switched over. They're in the middle of that transition. They still might have a few NT 4 machines, though they seem to be retiring very rapidly. [Windows] 2000 is still being deployed by a fair number of customers, though we're starting to see a tremendous uptake with Windows Server 2003. It takes about two years after a release ships for us to peak in our upgrade rate. So the cycle of how long it takes customers to move forward with technology is quite long, and yet they want to look forward and know when things are coming for a long-term basis.