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.
Getting Your XP Boxes Ready for the SP2 Jump
While you’re working out application compatibility on the test systems, you should take the following steps on your customer’s production systems.
First, as much of a pain as it is, it’s time to make backups of the workstations if there’s anything of value actually resident on them. Value, by the way, means more than just corporate data files. If you and your customers have misplaced the installation CDs for locally resident programs, do you really want to spend hours looking for, say, Lotus Organizer 6.0?
I mention that one not just because it’s my own favorite scheduling program, even if it is five years old; we all know that our customers’ machines tend to be full of old, reliable, and—for our purposes—hard-to-replace programs.
After that, it’s time to make sure that those workstations are in tip-top shape. For me, that means running a threefold checkup.
First, are the machines already up-to-date with patches? I use Shavlik Technologies LLC’s HFNetChkPro to keep machines up-to-date. It works well and Shavlik also has a useful version of the program for Red Hat Linux.
Next, run an anti-virus check with the latest updates on each PC. I tend to be ultraparanoid on my own systems so I haven’t seen a virus in ages, but when I run virus checks on other networks I’m seldom surprised to find at least one or two old viruses hiding out in some remote nook or cranny of the network.
Finally, run a spyware detection program. My particular favorite (and a favorite of many others) is Patrick M. Kolla’s Spybot-S&D. It’s freeware, but it works better than any of its commercial cousins. Unfortunately, you must run it manually on each workstation, but given the problems caused lately from spyware, it’s more than worth the effort.
Once you’ve got your customers’ systems cleaned up, and you’ve finally worked out workarounds for any application incompatibilities, now, and only now, are you finally ready to start deploying SP2.
I’ve said before than installing SP2 isn’t that much different from installing a new operating system. It’s worth repeating.
eWEEK.com Senior Editor Steven J. Vaughan-Nichols has been using and writing about operating systems since the late ’80s and thinks he may just have learned something about them along the way.
Check out eWEEK.com’s Windows Center at http://windows.eweek.comfor Microsoft and Windows news, views and analysis.
Be sure to add our eWEEK.com Windows news feed to your RSS newsreader or My Yahoo page