Microsoft Talks About Windows Server 2003 SP1

In response to every survey I field for my Hey Microsoft! column, readers always ask Microsoft to address security and to provide a roadmap for products. With the release of Windows Server 2003 Service Pack 1 (SP1), the company is tackling both concerns. SP1 is positioned as the Windows Server security release similar to Windows XP SP2. And coinciding with SP1, Microsoft is taking the opportunity to mark out a path of predictable releases every 2 years. I talked with Microsoft's Clyde Rodriguez (group program manager and the project manager responsible for the SP1 and 64-bit Windows releases); Samm DiStasio (director of marketing, Windows Server Division); and Jeff Price (senior director of marketing, Windows Server Division) about SP1, how SP1 fits in with the new roadmap and the impending Windows 2003 Release 2 (R2), SP1 features and fixes, and the role of customer feedback. For a more in-depth discussion with Clyde about delivering SP1, see the Web-exclusive sidebar "The Drive to Deliver SP1: Clyde Rodriguez Explains the Focus on Security, Reliability, and Performance," available to Windows IT Pro subscribers at http://www.windowsitpro.com, InstantDoc ID 45900.

Release Roadmap
Microsoft has always released server fixes, features, and new versions, but the timing and packaging of these various offerings have been erratic. Customers, especially those in the Software Assurance (SA) program, have been pleading for clarity about what to expect and when to expect it.

To answer that plea, Microsoft has announced that it will issue a server OS release every 2 years: first a completely new version (e.g., Windows 2003 or Longhorn), then 2 years later an update that rolls up new features and introduces improved functionality targeted at specific areas. For example, Windows 2003 R2 will include features that have been released as downloads (i.e., out-of-band—OOB—releases), such as Active Directory Application Mode (ADAM). In addition, R2 will focus on enhancements for branch-office scenarios, Active Directory (AD) federation, and storage.

Unlike service packs, which Microsoft will continue to release as necessary to provide fixes, the update releases won't be free. SP1, which is free, will be a prerequisite for R2. Clearly, Microsoft views the update releases as a much-needed way to provide value for its SA customers. I asked Samm DiStasio to explain the new approach.

Samm: I think it's important for customers to see us being very structured about our business so that they know that every 2 years there will be something they should at least consider. Now you can expect a release of the entire OS every 2 years. Previously, we kept throwing downloadable components out there. The R2 version will bring together the latest innovations into one release.

KF: Were you concerned that customers wouldn't know that the downloadable OOB features even existed?

Samm: Yes. We couldn't really tell people enough about each new piece. If features come out in dribble form, you can't do a big marketing campaign for something like ADAM. \[The new release structure\] allows us to be louder about it, so customers know to pay attention.

So how does SP1 fit in this new picture? I asked Jeff Price for his perspective.

Jeff: SP1 is an update that will augment Windows 2003 and constitutes a shift in the server-security paradigm. With R2, we're focused on providing a better consumption model for the feature packs that otherwise would be released to Web. Our customers told us that they felt we were providing too many separate updates or OOB releases. R2 helps us make the release of new features more predictable in terms of timeframe and simplifies deployment for our customers.

Windows 2003 R2 is the next version of Windows Server and will build on SP1 technology. R2 will deliver on our philosophy of increasing consistency and predictability for customers and will bring forward SP1's security and reliability enhancements. It will also provide new functionality around simplified branch server management, access management across security boundaries, and more efficient storage.

SP1 Features and Fixes
Since the Windows NT days, Microsoft has wrestled with how to position service packs with regard to adding new features. When Paul Thurrott interviewed Microsoft Vice President Dave Thompson at the launch of Windows 2003, Dave explained, "It used to be that \[service packs\] were flexible, a way that we could deliver features as well as fixes. But customers made it clear that they wanted bug fixes only \[in service packs\]. That leads to an interesting question, though: What, exactly, is a bug? Is a missing feature a bug? Customers often have different views themselves. But \[Windows\] NT 4 SP3 was the end \[of major new features in services packs\]." (For Paul's story, "Windows Server 2003: The Road To Gold; Part Two: Developing Windows," see http://www.winsupersite.com/reviews/winserver2k3_gold2.asp.)

Well, maybe not quite the end. SP1 includes both fixes and some security enhancements that qualify as missing features. Jeff explained, "Service packs are traditionally a group of existing updates for a product. SP1 is more than that. In addition to the latest updates for Windows 2003, SP1 adds new enhancements designed to improve security and reliability."

I asked Clyde, Samm, and Jeff to look at some of the security enhancements that Jeff mentioned. Then we moved on to discussing the fixes in SP1.

Security Configuration Wizard
KF: The SP1 security feature that has received the most attention is the Security Configuration Wizard (SCW). As the project manager and technical driver of SP1 and the Windows 2003 x64 editions, Clyde, can you give a quick overview?

Clyde: Like other wizards that help configure your server properly (e.g., Configure Your System and Manage Your System), SCW provides a guided attack-surface reduction for your server. When you run SCW, it asks you questions to determine the functional requirements of your server according to its role.

Jeff: By shifting security into a role-based paradigm, SP1 lets customers run no more additional services than they need, eliminating potential toeholds for hackers and malicious code. Moreover, role-based security eases the deployment of future updates, reducing the time it takes for IT professionals to prepare for new security holes.

Clyde: To accomplish this, SCW's roles-based metaphor is driven by an extensible XML knowledge base that defines the services, ports, and other functional requirements for more than 50 different server roles, including roles for Windows Server System applications such as Microsoft Exchange Server and Microsoft SQL Server. SCW disables any functionality that the server doesn't require for the roles it's performing.

SCW can perform role discovery, solicit user input, and author security policies that disable services, block ports, modify registry values, and configure audit settings according to the server role. Even ports that are left open can be restricted to specific populations or secured by using IP Security (IPsec).

KF: You've said SCW is extensible. How does that work?

Clyde: Since the format is XML, users can create an XML template for a unique server role at their organization. They can then use this template to secure other computers with the same configuration needs. Exporting the templates is possible, but not necessary, because an administrator can select any computer in the organization to apply the template to—provided you have admin rights to the computer. SCW also lets you roll back previously applied policy settings. It includes a command-line tool with which you use administrative scripts and other administrative utilities to apply a security configuration, and you can do compliance analysis for groups of servers in your organization. SCW also integrates with AD to support deployment of SCW-generated policy settings through Group Policy.

KF: Why did you put this new feature into a service pack instead of waiting for the R2 version?

Clyde: The decision was customer focused. It's great to have a dialog about how customer interaction influenced the design of a feature. We wanted to simplify the process for securing a machine against external attack, based on feedback about Windows 2003 and previous releases. SCW came about through general customer feedback about security improvements. Then we refined it further by deciding not to impose it on every user and striking a balance. We hope the solution we've offered gives all camps access to what they want.

KF: What do you mean when you say you didn't want to impose it on every user?

Clyde: Customers want service packs to focus on improving the OS without dramatically changing the product's functionality. There has been a long debate over bug fixes versus new features. Some customers say they want only fixes. Others look for improvements. Some people on our development teams wanted to give SCW to everyone. Another camp here at Microsoft cited customers who didn't want SCW forced on them. We had to strike a delicate balance between delivering what one set of customers needed and also meeting the requirements of others that don't want the tool. Customer analysis convinced us that making SCW an option as opposed to a default offered the best of all worlds.

KF: So your compromise was to have users install SCW via the Add or Remove Programs applet. Are you worried that some people might not find it?

Clyde: We placed an SCW icon on the desktop so that users immediately see a link to additional information. When they click that icon, it doesn't automatically start installing SCW. It provides a link to information on our Web sites about what the feature is and its benefits. Then if customers want to install SCW, the process points them to Add or Remove Programs, and SCW automatically installs from there.

Post-Setup Security Updates (PSSU)
KF: Another security feature in SP1 is PSSU. Can you explain its function?

Clyde: PSSU was designed to protect the server from risk of infection between the time when you first install and start the server and when you apply the most recent security updates from Windows Update. To protect the server, we've enabled Windows Firewall during new installation of any version of Windows 2003 that includes the service pack. If Windows Firewall is enabled and the administrator didn't explicitly enable it by using an unattended-setup script or Group Policy, PSSU appears the first time an administrator logs on. Inbound connections to the server are blocked until the administrator has clicked the Finish button in the PSSU dialog box. If the administrator set exceptions to the firewall through Group Policy or by enabling Remote Desktop during installation, inbound connections assigned to these exceptions remain open.

KF: Some people look for PSSU from the Start menu and can't find it.

Clyde: PSSU is not available from the Start menu and is available only under the specific conditions I described. If PSSU appears, Manage Your System opens after PSSU is closed (unless a policy setting has suppressed Manage Your System).

KF: You mentioned that Windows Firewall is enabled during a new installation of Windows 2003 that includes SP1. I think some people are confused by this and think that Windows Firewall is enabled by default on the server, as it is in XP SP2.

Jeff: In SP1, Windows Firewall is installed but disabled in all scenarios except one—when a customer does a new installation of Windows 2003 that has SP1 built into the installation CD-ROM. This scenario allows a "shields-up" approach until the server has a chance to be updated and configured for its role.

Samm: We've tried to be crystal clear about the differences between the client world and the server world. The reason it's off with the server is that customer feedback early on told us not to add another step. IT pros said, "Please don't give me predetermined stuff that I can't control."

Application Compatibility
KF: When XP SP2 came out, the stricter security defaults resulted in some application-compatibility problems. Will application compatibility be a concern with SP1?

Jeff: With SP1, we've focused on ensuring application compatibility for our customers and continuing to communicate with our Independent Software Vendor (ISV) partners about development protocols for SP1. Customers should check applications that are remote procedure call (RPC) and DCOM dependent, but overall app compatibility is as good as or better than the shipping Windows 2003 code was compared to Windows 2000 Server.

Clyde: We definitely want customers to look at their applications and do some testing. We've done a lot of external beta testing, and overall the compatibility regressions we see are very minimal. There are some "corner cases" (as we call them) where security requires us to make a change that necessitates an update from an application vendor, for example.

It's a difficult balance to strike. We want compatibility to remain unchanged. When users install SP1, all their applications should work, and that will be the case for the large majority of users. In certain instances, we had to make a security change that did impact applications, much as XP SP2 did. The impact will be less dramatic on the server side because a lot of the changes that went into XP SP2 were the result of a very broad security push that we did when we shipped Windows 2003. XP didn't go through that at the same time but definitely went through security review at XP SP2. So a lot of the security changes that XP SP2 went through already were in place by the time Windows 2003 shipped. With SP1, we don't expect to see a huge change in application compatibility.

KF: Have you seen any application-compatibility issues that surprised you?

Clyde: The other day we had a bug that I was surprised to see on the server product. It involved something about a Winnie the Pooh application not being able to run. Somebody said, "Nobody will ever run this in a server scenario, but it points to a real bug." We have an application-compatibility team that researched this issue, and in fact there was a bug in the Windows 2003 SP1 code base. I asked them, "How in the world did you ever think of running such a product on server?" They said, "We wanted to see if it would work just for the fun of it." And they found a bug.

SP1 Fixes: Customer Feedback and GPE
KF: We've talked about some of the new security features in SP1, but we haven't discussed the ordinary service pack fixes. How did you determine which fixes to include?

Jeff: This is again based on what we're hearing from our customers. SP1 is focused on providing security-relevant updates along with the standard patch and fix rollups.

KF: Where did your customer data come from?

Clyde: When we first started the service pack, we looked at data about Windows 2003 from Customer Support Services (formerly Microsoft Product Support Services—PSS) and Watson reports. (We get Watson data when users report problems to Microsoft.) Then we released an SP1 beta in fall 2003 to thousands of customers in our technical beta program to get their feedback. In addition, Microsoft IT is one of our customers that has to sign off. We also invest heavily in high-touch programs like the Technology Adoption Program (TAP), and we live and breathe their feedback.

KF: I noticed that SP1 includes an interesting change to Group Policy Editor (GPE) that addresses a problem that Darren Mar-Elia covered in our February issue: unintentional consequences of some Group Policy settings (see "Troubleshooting Group Policy­Related Problems," InstantDoc ID 44983). Was that a customer-driven fix?

Clyde: Customer feedback told us that many customers use GPE to modify user-right assignments and security settings in Group Policy in ways that could break services and applications. In response to that feedback, we updated the GPE tool to inform users of potential undesirable side effects when they make known risky changes to some settings. A new cautionary note points users to additional information about the specific setting and the types of services that could be impacted if they make that setting incorrectly.

WSUS: Neither SP1 nor R2
KF: You've said that you want service packs to roll up fixes and update releases to roll up things that you used to ship OOB as feature packs. So how does the release of Windows Server Update Services (WSUS), as well as Microsoft Update (MU, which will replace Windows Update), fit in this scheme?

Jeff: WSUS and MU consolidate security and feature upgrades for a range of Microsoft products including XP, Win2K (Server and Professional), Windows 2003, and security updates for Microsoft Office, Exchange, and SQL Server. Eventually all Windows Server System products will be updateable through WSUS and MU. Additionally, because WSUS can be installed on both Win2K and Windows 2003, it really doesn't make sense for it to be in Windows 2003 SP1.

Samm: The philosophy of feature packs going forward is that we will do them—but according to urgency in the customer environment. WSUS qualifies there easily.

SP1 Now and R2 Later?
KF: What's your advice for an IT person considering whether to deploy SP1 now or wait a few months for R2?

Samm: Given the preventive nature of SP1 security enhancements, you should get SP1 now. Later, you won't be able to install R2 without SP1 because it's a prerequisite.

KF: SP1 is free, but R2 will have a cost. Is cost an issue?

Samm: If you don't value the specific additions made in R2, the free, downloadable SP1 is absolutely what you want. Obviously the folks that have SA don't worry about making the choice. They just pick what's better for their business. Certainly the whole reason service packs are free is we want them broadly adopted—\[more so for\] the last two service packs (XP SP2 and Windows 2003 SP1) than any we've released.