Install SUS on XPAre you sick and tired of installing a new system and having to download countless updates from Microsoft just to get your system up to date? Wouldn't it be nice if you could have a way to get all of those updates onto a CD and able to be installed in an automatic fashion? Sure, it would. The next logical step would be to take those updates and slipstream them into a bootable Windows CD, but that's not what this is about.
So how do you go about getting all of the updates without having to search Microsoft's site and download each one individually; SUS (Software Update Services). Yes, it's outdated and has been replaced by WSUS (Windows Server Update Services), but it has it's advantages. The advantage we're concerned with is using this service to extract the patches. With WSUS, the patches are stored in their "database" and are not easily extractable (READ: I haven't found a way yet). With SUS, they're stored in a "cabs" folder for all to take.
I'm assuming you've already gone to Microsoft's site and downloaded SUS (most likely with SP1). If you're running a non-server OS, you'll soon find that you can't install it, no matter what you do. SUS does a check to make sure it's being installed on either Windows 2000 Server or Windows Server 2003. How do you circumvent that? Elementary, my dear Watson; elementary.
The first step in our venture is to understand that even though the SUS download is an EXE, it's really not. It's a wrapper EXE, which means that there are files inside of it. Use any ZIP program to extract those files. You'll end up with two, Sus10Sp1.vbs and SUSSetup.msi. Disregard the VBScript, we don't need it. All we care about is the MSI. First, and foremost, make a copy of the MSI just incase we break it (we wouldn't want to re-download that 48MB file, would we?).
By opening the MSI, we still get the error, so we can assume that the "server check" is not in the wrapper EXE, but the MSI itself. Somehow we need to edit the MSI. It is at this point that you need to realize that MSI files are pretty much mini-databases. They have tables and rows. But they also have the real data too. As with all databases, you need a special utility to edit them. Enter Orca. Microsoft has made life harder on us and started only offering Orca through their SDK, which needs .NET 2.0 to run (even though the tools in the SDK don't need .NET 2.0). To save you the trouble, I have provided Orca for you [DOWNLOAD].
Open Orca, and then open SUSSetup.msi with it (make sure you made that backup!). On the left side you'll see all of the tables. Scroll down to the LaunchCondition table. On the right you'll see the conditions that have to be met for this MSI to install. One of them says:
... which is the error we were getting. We've now found the condition! So, let's look at the condition:
From the beginning; REMOVE="ALL". That will be true if you are attempting an uninstall of SUS. Installed; this will be true if SUS is already installed. In this case, you'll get the standard window to Change or Uninstall the package. (ServerNT AND ((VersionNT > 500) OR (VersionNT = 500 AND ServicePackLevel >= 2))); this will be true if you are running a server OS equal or greater than Windows 2000 Server SP2. If any one of those 3 conditions fail, the whole condition fails, and the MSI will produce the above error message.
So, how do we get around that? Easy, all we need to do is make that condition evaluate to "true." We could try editing our system settings to appear like a server OS, but why? Why not just enter our own expression that will _always_ be true. 1=1. That's it! It's so simple, you'd never think of it. Delete that whole long triple condition statement and replace it with "1=1" (without the quotes, of course). Save the MSI (do NOT do a save as, you must save overtop). Close Orca and open the MSI. Voila!
NOTE: You need to have IIS installed first. Don't try the above trick for the IIS condition, it is ACTUALLY needed ;)
Great, we've installed SUS, we've synchronized with the Microsoft servers, and all of the hotfixes are stored in %somepath%\cabs (you specify %somepath% during the install). The first thing we notice is that they're all there. All, as in 2000, XP, 2003, etc. Sort them by name and pull out the ones pertaining to whatever system you need to patch and put them in a new folder. Now we need some way to automate their install so you don't have to click Next a thousand times. Don't worry, I got you covered. Save the following as install.vbs in the same folder as your "extracted" cabs:
On Error Resume Next ' Create our shell object so that we can run commands and stuff Set wshShell = WScript.CreateObject ("WSCript.shell") ' Set an environment variable to temporarily disable the security warnings Set wshEnv = wshShell.Environment("PROCESS") wshEnv("SEE_MASK_NOZONECHECKS") = 1 ' Create our filesystem object so we can do folder listings Set objFileScripting = CreateObject("Scripting.FileSystemObject") Set objFolder = objFileScripting.GetFolder(".") Set filecollection = objFolder.Files For Each filename In filecollection ' We only want exe's if instr(filename, ".exe") then ' Since filename contains the whole path, extract just the filename filename=right(filename,len(filename)-InStrRev(filename, "\")) ' Run the file, visible, and wait til it's done before moving on wshshell.run filename & " /q /z", 1, True end if Next ' Re-enable security warnings wshEnv.Remove("SEE_MASK_NOZONECHECKS") ' Tell me when you're done Wscript.echo "Finished applying patches" ' Free memory set wshshell = nothingThe above code will disable the stupid "are you sure you want to execute this" warnings first introduced in XP SP2 (but are also found in Server 2003), pick out the EXE's from the current working directory, execute them with the options to install quietly and not need a reboot, turn the security warnings back on, then give you a message saying it's done. Simple, huh?