How to automatically update Windows XP clients without MS Automatic Updates
Last modified on:
11-18-2006 - HTML changes.
By: Max Hetrick
Printer friendly: http://www2.maxsworld.org/howtos/winxp_updates.html”
If you’re like me, you would rather have an automated patch process. Windows doesn’t give you many options though. You can either turn on Automatic Updates, releasing your patch control over to Microsoft (very dumb in my opinion), or if you’re running an environment in Active Directory, you can patch that way. I don’t know about you, but I prefer to test the patches on a test box prior to releasing them into a network. I’m writing this because I finally found a very easy way to automatically release the patches on a network, without expensive software I might add. I was sick and tired of running updates manually from the GUI all the time.
If you’re a true geek, you wouldn’t be caught dead running AD, so this how-to is geared to those that have Windows XP desktop machines with a Linux/non-Microsoft server backup. Therefor there’s no AD to patch with. It’s a very simple process actually. All you need is one simple tool called BeyondExec, which is a free utility written by Craig Peacock, and a domain to play with. It’s easiest if you have a Linux Samba share set up, but it’s not necessary. Setting up Samba is out of scope of this how-to, so I’ll show you how to do so with a Samba network share, but all you should need is a simple network share from any source. As long as you can map a network drive to the share, you’re good to go.
Download BeyondExec
The first thing to do is download the utility from above. It’s a very small utility, only about 47k actually, so it’s easy to throw on a USB drive. BeyondExec works by copying a small service file onto the remote machine from your host box. It uses this service to talk back and forth and then launch whatever commands you want. It’s great for launching application installers, patches, service packs, also it’s great to reboot machines remotely. Ok, get the file and unzip it somewhere. From the command line (Start -> Run -> CMD), now launch the utility to see the help. You’ll get the following output as displayed in the image below.
Authentication with accounts
BeyondExec has a few different ways of authentication that you have to deal with. It is totally capable of authenticating using a local administrator account, but it’s easier to use a domain admin account on your network. This way you can pass along the credentials and authentication automatically occurs. Also, it’s possible that you can different local administrator users and passwords which will make this hard to automate, as you’ll see later. The basic idea of how this works is this: It will attempt to authenticate with the remote machine as the account you are logged in as. If it can’t figure out who you are, a box pops up asking for credentials. If it successfully authenticates, it goes to the remote machine and processes whatever set of commands you have passed. Simple!
Seeing is believing
Just to give you a small idea of how it works, let do a simple reboot of a remote machine. This way you can see what occurs and get a better understanding of what I said above. Navigate back to your command line and directory where you stored the utility, and launch the command with the parameters as this image shows:
What this does is launch the remote process to the machine you have specified in \\yourmachine using the username and password of the account you inserted. After that, it launches the restart process on the remote machine with a message and a 20 second countdown. If you specify -l 0sec with no message, then the machine shuts down immediately without prompting the user. Hint: Come back to this section later to easily script a reboot procedure nightly for your clients!
Ok, go ahead and launch the command and if you have a remote viewer you can see what actually happens. If you’ve specified atime and a message, you’ll get this:
Pretty cool, huh! Ok, now that you have a good understanding of seeing it in action, let’s move along to other things.
Network shares, batch files, command scripts…Oh my!
If you’re running some Linux servers on your backend, then most likely you’ll have Samba running as your domain controller. If so, I’ll assume you already have some network shares set up that you use to store software, files, or whatever it is thatyou share. Here you can dump the patches that need to be applied to your clients. This makes it perfect for the utility to map a network drive to from WinXP, copy the files over, and then install the patches. Again, it’s out of scope for this to explain Samba, so Google Samba if you’re clueless as to what I’m even talking about. BeyondExec has several different ways of reading in the commands that you wish to execute remotely, but I’ve found it easiest to do so with a simple batch file. This way, you can script it and when the batch file needs changed each month, you only have to change a few parameters within the file. This also is what gives you the power to launch one line from the command line, and have it patch all of your clients in one shot. So instead of having to sit on your couch at home and manually browse to Microsoft’s update site a hundred times, you can launch one command and voila! Furthermore, you can even schedule the command to run at a specified time through the WinXP Scheduled Tasks utility (for the really lazy like me).
The last piece of the puzzle is a simple command script that houses all the cool stuff you want to do. This is what initially launches the utility to do it’s thing. Here’s the process: the command file is launched, it copies the batch file over to the remote machine to execute, the batch file is executed remotely on the machine, the machine does it’s command set, the batch file is removed from the remote machine, and the command file moves along to the next remote client. Slick as slick can be!
Get your updates
This is mainly my way, so you may have a different means to obtaining the actual update files to install. The next thing you need to do is determine what patches you want to actually load. I do this by launching IE directly to Microsoft’s web update site. From here I choose the custom selection and determine which updates I want to download. I write down the patches that I want from the KB12345 numbering reference. Then I head over to their download section and search for each update. They usually have the most current released patches on the main download page, but I find it easier to search for the ones I want.
After you’ve determined the updates you want, go ahead and download them. Place these files in your shared network folder. This is where the batch file will go to copy the patches onto the remote machine before it installs them. After the initial set up of this process, this is the only section that will require work down the road. Every month you’ll have to get the new updates, and change the paths in your batch and command files. Moving along…
Setting up the batch file
The next step is to now set up a batch file to use. I personally use my Linux machines and Vim to create what I need, but you can also use Notepad or Wordpad…any text editor will do. I’ll show you with Vim. To create a batch file just open a text file and make sure you save it with the .bat extension. WinXP will then recognize it as the appropriate file. I name the file with the month that I want to run, and then each month simply rename the file to the appropriate month, so you’ll always be using the same file. If you’d like to keep the history of everything, then every new month create the file with the current month. I’ve created a directory in my shared path on the network as may_2006. I create a new folder to house the current month of updates. My directory would look like this:
[me@mypdc updates]# ll total 12 drwxr-xr-x 2 root root 4096 May 2 11:06 april_2006 drwxr-xr-x 2 root root 4096 May 10 09:38 may_2006
I then open up a new text file and enter the commands I want executed:
[me@mymachine updates]# vim may.bat net use u: \\path\to\my\updates\may_2006 /USER:DOMAIN\user password /PERSISTENT:NO u:\Windows-KB890830-V1.16.exe /quiet /norestart u:\WindowsXP-KB913580-x86-ENU.exe /quiet /norestart u:\Windows-KB913433-x86-ENU.exe /Q
I’ll explain what this all means in case you don’t already know. If you do know, then just skip ahead and ignore.
When you launch the command file that we’ll create later, it will copy the batch file to the remote machine to execute. It then maps a network drive letter of u (you can pick whatever you want, I picked u for “updates”). It uses the domain you specify in DOMAIN and the domain user account and password you specify in user and password.
Next it simply executes the patches to install. Note: not all patches have the same switches. Most use the same format, but if you notice the /Q is different, it’s because the quiet switch is different for that particular patch than the other two. You’ll have to run each patch separately to determine the switches it accepts. When you’re through, just save the file and we’ll go on to create the command script file.
Another note: use the /PERSISTENT:NO switch to make Windows not remember that mapped drive. You’ll run into problems later with trying to change the map point if WinXP has that connection saved. After you reboot, the mapped drive u: will be removed from the client.
Setting up the command script file
Now we have to set up the command script file as I mentioned earlier. Again, I’ll be using Vim on Linux to actually create the file, but any text editor will do. The file extension to be used for a WinXP command script file is .cmd.
[me@mymachine updates]# vim launch_updates_group1.cmd echo off set directory=C:\wherever\ set command=beyondexecv2.exe set args=-u domainadmin -p domainadminpass -cs C:\updates\may.bat %directory%\%command% \\client1 %args% %directory%\%command% \\client2 %args% %directory%\%command% \\client3 %args% %directory%\%command% \\client4 %args%
Again, I’ll explain this section and if you already know then skip ahead. I’m including this for completeness.
If you read the documentation from the BeyondExec utility, then you can find a switch that it accepts -g. This allows you to create a simple text file with a list of machines it’s to use. I’ve not had very good luck with it, so I actually launch BeyondExec individually on each machine. This allows the process to execute, run it’s command set on the remote machine, and then return back with a success or failure. The reason I do it this way is because if the thing bombs when reading in a list of machines from a text file, you’re updates won’t run. This way, it’s on a one-to-one basis. If one machine fails to execute it’s command, it complains about that particular host and moves along to do the next. If you find it works well for you the other way, then by all means use the group switch BeyondExec provides.
What’s happening with the command script file is this: You want to set the exact directory where BeyondExec is found with set directory, you then set the actual .exe command with set command, you set the command arguments as you would on the command line with set args, and finally you insert all the clients you want this to run on as a simple list of client1, client2, client3, client4, and so on. The switch -cs means copy the file to the remote computer and set the security. Again, refer to the documentation for a complete list of switches. Save your file and move along. It’s pretty straight forward.
You’ll notice that I’ve created this file as launch_updates_group1.cmd. If you only have one set of machines to do, then you can use one file. I have different groups of machines located in different buildings and so I simply split them into groups. My second group would then be a file called launch_updates_group2.cmd. A third could be launch_updates_group3.cmd with the machines you want to include in this group. I use it to simply split out the updates for organizational purposes. Ok, that’s it you’re done with the command script file. Next.
Launching the process
You’re now ready to actually start the update process. Navigate to where your .cmd files are located, and from the command line execute the command. It will now complete the process as described earlier: command script file executes, copies the batch file to the remote machine, the remote machine maps a network drive share, copies the patches to the remote machine, installs the packages quietly without rebooting, results in a successful execution, removes the batch from from the remote machine, and moves on to the next in line.
I’ve blurred my real parameters out, but yours will be whatever you have supplied. Your output should look something like this:
From here, you can either do what I do each month and run this manually from the command line to ensure it’s success, or schedule a job to run it at night. I run it from the command line that way I can come back later to check on it’s status and see what it’s actually doing. Either way, you’ve cut down tremendously on the amount of time spent to patch your WinXP desktop clients. In case you don’t believe the patches are actually installed, take the machine in question and launch IE directly to Microsoft’s Updates. You’ll see that no updates are available.
What else?
I’m glad you asked. As you can see, this utility opens things up a bit for many tasks. Remote shutdowns are very easy to script. Just twist some of the examples around a bit that I’ve provided, and you’ll be able to manage reboots. It’s also great for simple tasks like scheduling defragmentation cycles. Other odd ball things I’ve used this for was to change a printer name on clients in one shot. I’ll give you a hint for this command:
beyondexec2.exe \\machinename -u user -p password C:\WINDOWS\system32\rundll32.exe printui.dll,PrintUIEntry /Xs /n “printername” PrinterName “newprintername”
