Windows XP SP2 is shipping in August. Microsoft has been pre-briefing the operator community for weeks; the technical changes are public; the release timeline is firm. This is the time to plan deployment, not to react to deployment.
This is a planning post. Specific deployment guidance based on what I have learned from the pre-release information and from beta testing.
What is shipping
The structural changes are substantial. Brief summary:
- Windows Firewall on by default, replacing the off-by-default Internet Connection Firewall.
- Data Execution Prevention — software DEP for all systems, hardware DEP where the CPU supports the NX bit.
- Internet Explorer hardening — pop-up blocking, restricted file downloads, the Information Bar, conservative Local Intranet Zone defaults.
- Outlook Express attachment blocking for dangerous file types.
- Windows Security Center dashboard for awareness.
- RPC service restrictions that reduce default attack surface.
- Wireless networking improvements with more conservative defaults.
The cumulative effect is the largest single change in default Windows security posture in any release I have observed. The deployment will reshape how XP machines behave on networks.
What operators should be doing now
Three categories of preparation.
Application-compatibility testing. Some applications will break under SP2's tighter defaults. The friction surfaces are predictable:
- Applications that require inbound connections will be blocked by the firewall until exceptions are configured.
- Applications using legacy buffer-overflow patterns (probably accidentally) may trigger DEP exceptions.
- Web applications that rely on automatic downloads or pop-ups will be visibly broken under SP2's IE.
- Applications using older RPC patterns may fail.
The audit work is bounded but real. A representative sample of the application portfolio tested against SP2 in advance produces a list of issues to address; addressing them before deployment avoids surfacing them during deployment.
Deployment-mechanism planning. SP2 will be offered through Windows Update. Operators with managed estates need to decide:
- Allow Windows Update to deploy automatically? The simplest path; provides the least control over timing.
- Use Windows Server Update Services to stage deployment? More control; requires WSUS infrastructure.
- Use Group Policy to defer or block automatic deployment until controlled rollout? Most control; requires explicit administrative effort.
The right choice depends on the estate's size, the application-compatibility risk profile, and the maturity of the deployment infrastructure. There is no universal answer.
Communication planning. Users will see different behaviours. The user-visible changes — pop-up blocking, the Information Bar, file-download restrictions — will produce support requests. Communication ahead of deployment, with screenshots and explanations, reduces the support load substantially.
What can wait until after release
A few things that some operators feel pressured to address before release but that can wait:
Custom policy templates. SP2 introduces new Group Policy options. The templates ship with the release; configuring them before release is wasted effort.
Deep firewall-exception planning. The application-compatibility testing will reveal which applications need firewall exceptions; the exceptions can be configured during testing rather than predicted in advance.
Detailed user training material. The user-visible changes are simple enough that brief communication suffices for most users. Detailed training material can wait until specific issues surface.
The pre-release planning should focus on the things that take time and that benefit from advance preparation. The reactive work can wait for the actual deployment.
My own deployment plan
For the test machine: SP2 deploys automatically when offered. The test machine is for surfacing issues; surfacing them quickly is the point.
For the production hosts I run personally: SP2 deploys after I have run it on the test machine for a week. The phased approach catches per-host issues before they affect everything.
For client deployments where I have advisory roles: phased deployment over 6-8 weeks. Less critical hosts first; more critical hosts later. The cumulative experience informs the more critical deployments.
What this teaches operationally
Three observations from the planning process.
Major service-pack deployments benefit from explicit planning. Reactive deployment produces more friction than planned deployment. The investment in planning is bounded; the avoided friction is substantial.
The Trustworthy Computing trajectory is producing operationally significant change. SP2 is concrete evidence that the memo from January 2002 is producing structural change. The trajectory is real; the operational implications are substantial.
Application-compatibility testing infrastructure is now operationally valuable. Organisations with mature testing pipelines benefit from this kind of release; organisations without are exposed to surprises. The investment in testing infrastructure pays back across multiple service-pack deployments.
What I will write about post-release
Several posts likely over the coming weeks:
- First impressions from deploying SP2 on real machines.
- Specific application-compatibility issues that surface.
- The deployment cadence across the operator community.
- The cumulative effect on worm-propagation patterns.
The structural impact will be visible across many subsequent posts.
For now: plan now, deploy in phases, communicate with users. The release is firm; the operational discipline is what matters.
More after the release ships.