Memo on XP SP3 Upgrade

November 5, 2011  

This addresses the common scenario of upgrading very old XP stations from SP2 to SP3. It is not to be installed in a haphazard manner, as it is potentially disruptive in a typical production system, at this juncture. Especially, when so many sensible alternatives are available. My analysis:

• hardware resource requirements
  • SP3 code is significantly bulkier, thus consumes more memory& disk space
  • during upgrade process, 2G of hard disk space is required for temp files, etc.
  • after installation, it takes up 1.2G ~ 1.8G of additional disk space, half of which is due by backup version of system files, the remainder belong to uninstalling mechanism, and newly expanded executables.
  • system partition would grow by 1.2G ~ 1.8G, making GHOSTing more difficult
• compatibility issues
  • very old XP systems typically harbor numerous minor corruption, which likely would prevent the upgrade script from patching up executables to the new version
  • some applications have no SP3 compatible version, other would support fresh install onto SP3 platform, but not survive an in-place upgrade.
  • some device drivers have no SP3 support, or work only as a fresh install, but cannot be migrated over to SP3 by Microsoft's patching
• logistical process considerations
  • during the upgrade process, remote IT will lose connection
  • upon first reboot, Microsoft resets many system settings to default, prompt corresponding reaction from IT
  • upon first reboot, Windows built-in firewall would be activated, preventing all remote access, requiring local intervention, via verbal instructions.
  • all these mean it'd have to be performed during business hours, with all the implied downtime and distraction to staff
• risk assessment based on my empirical data
  • typical scenario:
    • 6- to 10-year old system
    • 256M to 512M memory
    • 30G to 120G hard drive
    • lots of legacy applications, often from defunct vendors
    • some legacy peripherals (scanner/printer/wifi), without up-to-date driver availability, due to EOL policy
  • 25% risk of minor glitches, mostly sidestep-able, or possible to live with them
  • 10% risk of major glitches, enough to be considered operationally unacceptable
  • 2% risk of catastrophic melt-down: runaway costs + time drain + stress
• necessity and justifications
  • when vendors proclaim SP3 is "required," 90% of the time, it reflects only their arbitrary administrative policy, not a technical decision/assessment
    • it is entirely understandable and fair, for vendors to demand certain baselines, so as to reduce their workload & risks.
  • in most cases, such "requirements" can be skipped, and the program would work, and it is commonplace practice by IT dept. everywhere, per their internal priorities and risks assessment.
  • majority of the time, the real reason things don't work lie elsewhere, and it has to be addressed even after SP3 upgrade is performed.
  • of course, it's possible for some software vendor to implement a check, and lock out program functions, or refuse to install, upon detecting non-compliance. In which case, you must make a decision.
• strategic decisions/directions/alternatives
  • definitely will not casually perform to all XP stations at once
  • at minimum, start with one pilot station, allow reasonable wait period to evaluate & validate, then consider rolling out to remainder
  • it is oft acceptable to forgo certain apps which prompted such upgrade: entirely or at selected stations
  • it might be sensible to designate a single (or subset of) station(s) for such apps
  • consider virtualization for off-loading such apps
  • consider drastic alternatives, such as: pushing up workstation upgrade schedule
  • Bottomline: Avg. $40~$75/station in best case scenario, when nothing went wrong, just spending time taking care of all the basic tasks. $150+/station is not uncommon; and in nightmare scenarios, the sky is the limit.