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 PolicyRelated 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.
End of Article
)
—Darren Reed
Anonymous User June 21, 2005 (Article Rating: