Ready or Not, Here SP2 ComesBy Steven Vaughan-Nichols | Posted 2005-03-01 Email Print
In a few weeks, Microsoft is going to start pushing SP2 to XP systems with Automatic Update enabled whether you want it or not, so it's time to get serious about checking about compatibility.
Yes, Windows XP Service Pack 2 is a major step forward in Windows XP functionality and security. Yes, anyone who programmed their applications by the book shouldn't have too much trouble with SP2. Yes, almost all SP2-unfriendly applications now have updates that make them work and play well with SP2.
And yes, you're going to have trouble when your XP systems start updating themselves in a few weeks to SP2.
On April 12, Microsoft Corp. will no longer block the delivery of SP2 via Automatic Update and Windows Update. That means that you, and many of your customers, will have to deal with SP2 whether you're ready or not.
Just to make life even a bit more interesting for the guys at the trouble desk, this is also a patch-update Tuesday. So, you may have the pleasure of determining whether any problems that pop up that day are coming from SP2 or from the latest round of patches.
Life is nothing but fun, fun, fun at the help desk.
Now, if you'd like to avoid that kind of fun now—not tomorrow—now is the time to address SP2 compatibility issues. While most XP applications work just fine with SP2, you don't want to find yourself stuck in a situation where a vital application goes down because of SP2 incompatibilities in the middle of the work week.
You can start by setting up some XP SP2 test bed systems. On these guinea-pig machines, which should be representative of your company's or customers' PCs, you need to run all of the company's applications.
Further, you can't run those applications in isolation. You need to run typical workloads on a test network to make sure that a particular blend of software doesn't give XP SP2 the fits.
While you're setting up your test network, you also should be checking for known incompatibilities. Your first stop should be Microsoft's own list of applications that may break with SP2 and programs that may have some functionality issues with SP2.
You should keep in mind that neither of these are complete lists. Check with your application vendors' technical-support resources to make certain that they don't know of any issues with their software working with SP2.
You're likely to find that many applications will work with SP2—if you tweak them.
If you're stuck with an older version of an application that won't work, you'll need to find a workaround. For example, I know of at least one business that's stuck on an older edition of Vignette Corp.'s Vignette content management system, and some of its functionality simply will not work with SP2.
You also should pay close attention to any applications that require network access. I'm not talking primarily about Web browsers or e-mail programs, although amusingly enough, Microsoft's own Outlook Web Access won't work properly with SP2 default settings.
No, I mean programs that use FTP—such as many Web authoring tools—or that require the PC to act as a server, as is the case with most remote-desktop or file-sharing applications.
It's been said that 90 percent of all SP2 problems are firewall permissions problems. I wouldn't go quite that far; I'd say it's 70 percent firewall settings, 20 percent pop-up blocking, and 10 percent everything else in the kitchen sink.
For the firewall settings, you simply need to carefully go over the application's network requirements and make sure that the firewalls' permissions are set up properly.
It's not enough to go read the manual. You need to actually test the applications and make sure that all of the network ports it really needs are open.
While a network sniffer or the like can be helpful with this, you often don't need to get that high-tech. Microsoft's good old command-line programs netstat and tasklist may be all you need.
First, you run the applications that you're testing. Then, you get a list of all of the ports that these programs have which are open and listening. You do this by running:
netstat –ano > netstat.txt
This gives you a text file with all of the active connections.
Next, you run:
tasklist > tasklist.txt
This gives you a list of all of the non-service processes. To get the service processes as well, run:
tasklist /svc > tasklist.txt
at the command line.
Armed with this information, you then match the application or service with its ports by matching their PIDs (Process IDs). These are the ports that you'll need to take care of in the Windows firewall.
To address these, you need to run the SP2 Security Center.
Once there, click on Windows Firewall. Then, under the Exceptions tab, click Add Port. Next, in the Add a Port dialog box, type the number of the port that you want to open, then click either TCP or UDP.
You'll then be prompted to give this port a name and set the scope for the port exception. You can set the scope to any computer, your subnet, or a custom list of IP addresses. Once done, you need to enable your new application port by clicking OK on its checkbox.
That's the basics on how to manually open a port, but if you run into something that's not so simple as merely opening a single port, and many applications will require just that, check out Microsoft's excellent SP2 Firewall troubleshooting guide.
When pop-ups are necessary
Most of us hate pop-ups in general, but I suspect it was only after SP2 arrived that we realized how many important Web-based applications, such as PeopleSoft Financials 8.x, rely on pop-ups.
To fix Web-based programs that run into trouble with SP2's pop-up blocker, you should open Internet Explorer, click on the Tools menu and select Internet Options. Next, click on the Privacy tab and click on the Pop-up Blocker Settings button. Then, enter the appropriate URL— without the "http://"—in the "Address of Web site to allow" field, click the Add button and save.
There are also programs, such as the Outlook 2000, 2002 and 2003 e-mail clients, which use their network connections in unexpected ways.
These e-mail clients set up a dynamic UDP (User Datagram Protocol) port to use with their assigned Exchange mail server for mail status updates. The SP2 firewall blocks UDP ports by default.
The usual solution for this kind of problem, opening up a port or a range of ports in the firewall, won't work this time because you can't predict what the port is going to be and you can't tell these versions to use a particular port. Outlook will default to polling Exchange every 60 seconds, but users may see SP2 upgrade as slowing down their e-mail.
There are several solutions. The lazy person's answer is to simply turn off the SP2 firewall. Of course, that rather defeats the purpose of installing SP2 in the first place.
It's a pain, but I like setting a static RPC (remote procedure call) port for Outlook access to the Exchange Server and forcing the client to use that port. It's safer, and it works.
A related problem, which affects Outlook 2000 and 2002, is that their find and new mail notification features won't work properly. This again boils down to a UDP problem, and the fix in this case is to make some registry changes. As always, when you're working with the Windows registry, back it up and be very, very careful about the changes you make.
If this sounds like a lot of work, well, yes, it is.
For some reason, a lot of folks have been talking about how easy it is to move to SP2 and how the only problems most people will face is with home-brew applications that don't comply with Windows programming guidelines.
As we've seen, even Microsoft's own programs can require some pretty extensive tweaking to work correctly with SP2. You can be sure other programs have similar issues.
In particular, any program that requires network access, whether it was written by Microsoft or by a temp six year ago, needs to be tested and verified on SP2 today. Now.
After all, with Microsoft pushing SP2, it's not like you have any real choice in the matter. You can either fix potential problems today or wait until you have real problems tomorrow. I know which way I'm going!
eWEEK.com Senior Editor Steven J. Vaughan-Nichols has been working and writing about technology and business since the late '80s and thinks he may just have learned something about them along the way.
Check out eWEEK.com's for Microsoft and Windows news, views and analysis.