We all now know that there are issues with SP2. There are no showstoppers, however, if you’re careful about getting your customers’ systems up to speed.

First things first. Check to see if your users have any of the known “problem child” applications.

Chances are you’re not going to care that “Need for Speed Hot Pursuit 2” doesn’t run. Indeed, your client may be much more interested in knowing what that one was doing on a business machine in the first place than in how to get it to run.

But, you are going to care, and care a lot, if your customer dives into SP2 and then finds out that Autodesk Inc.’s AutoCAD 2000, 2002 and 2004 releases; Computer Associates Inc.’s ARCserve and eTrust 7.0 releases; Macromedia Inc.’s ColdFusion MX Server Edition 6; Symantec Corp.’s AntiVirus Corporate Edition 8.0 and Ghost Server Corporate Edition 7.5; and Veritas Software Corp.’s Backup Exec version 9 and Volume Manager 3.1 won’t run without tweaking. (For the full list of problem applications, check out Microsoft’s Knowledge Base.)

That’s only the start, however, of your application checking. You should also pay close attention to any applications that use FTP, including most Web authoring tools, or require the PC to act as a server, such as remote desktop or file-sharing applications.

You should also be wary of any browser-based application that opens pop-up windows. For example, I’ve found issues with some older versions of On24 Inc.’s Webcasts and Vignette Corp.’s Vignette Web content management system.

Now, at this point, it appears that many of these problems can be fixed by correctly setting up the new SP2 Windows Firewall and pop-up blocker. Unfortunately, setting it up right won’t always be that easy.

For example, Microsoft’s Outlook inboxes and outboxes may not update as quickly as users are used to. That’s because the Outlook 2000 and 2002 e-mail clients try to set up a dynamic UDP (User Datagram Protocol) port to use with their assigned Exchange mail server for mail status updates.

The firewall blocks UDP ports and since there’s no good way to predict what the port is going to be, you can’t simply set up a port or a range of ports for it to open up for Outlook. The default is that Outlook will fall back to polling the server every 60 seconds; if users are used to more sprightly inbox and outbox updates, they’ll see the patch as having slowed down their systems.

There are a variety of solutions—I favor setting a static RPC (remote procedure call) port for Outlook RPC access to the Exchange Server—but the point is that in some situations you won’t be able to solve a firewall or pop-up problem with a simple fix. (For more details on dealing with this particular Outlook problem, see NTBugtraq.)

The uber-answer to these problems is to first run SP2 on a test network that corresponds to the real network. Your customer doesn’t have one? As my colleague Larry Seltzer suggests, you should then, at the least, set aside a “small sample of typical systems.”

While you’re doing this, check with your software vendors to see if there are any known issues with your customer’s applications. It’s far better to know about a problem beforehand than to face a customer with the news that their heart-of-the-company program won’t be working quite right for a few days.

Don’t assume that any program will work out of the box with SP2. After all, even Microsoft’s own Systems Management Server 2003 won’t run unless you manually open TCP port 2701.

Next page: Getting Your XP Boxes Ready for the SP2 Jump.