White Paper - Remotescope
Bringing Sanity to the Nightmare of Patches

Microsoft regularly releases security patches, sometimes as often as once or twice a week. It’s a good thing that Microsoft is being vigilant and quickly making patches to fix flaws found in their operating system. However, it can be such a burden to keep up with all those patches, especially when dealing with 22 servers and over 200 workstations ranging from Windows 98 all the way to XP Professional.

The problems with releasing patches with such regularity are, first, it interrupts the production of each user when they have to step away from their computer to allow the administrator to update it. Second, depending on the size of the network, by the time the administrator finishes the last machine another patch is released. It becomes almost a perpetual task that never ends. Therefore the Network Administrator cannot find time to deal with other projects besides patching each machine on their network. It’s probably more practical to hire one person whose job it is to solely do patch updates day in and day out. And with the rise of Internet security risks these days, it’s plain dangerous to ignore these updates.

I was introduced to RemoteScope software in its earlier version. RemoteScope has two parts, the console and the client side. The client is a very small program that acts as an agent on the end user’s machine. The client can be installed quickly, is easy to run, and the end user cannot uninstall it due to password protection. On the console side, RemoteScope has many functionalities including: keeping track of hardware and software inventory, remote control, file transfer that works similar to PCAnywhere, and remote deployment of software. I mainly used this product for the purpose of deploying security patches since my company already has PCAnywhere and inventory is very low on my priority list. So I can only speak for the functionality of pushing patches.

One of the good things about RemoteScope is that I can group all the computers by Operating Systems and by departments. This is important because security patches are OS specific. As well, some departments in the company work later than others and you can choose different times to push the patches to each group of computers. In a nut shell, here’s how I did it;

I organized the workstations and servers by Operating System and departments.

I downloaded the patches from the Microsoft website and put them in separate folders by Operating System.

I created a package for each Operating System.

Creating the packages was easy with the help of the wizard. The packages primarily consisted of a batch file that I wrote with a shutdown.exe file and, of course, all the patches associated with that OS.
By Install Shield,
By Windows Installer, and
By Other. (I used “Other” because the first two options were used for deploying software packages like Acrobat Reader and other programs.)
During this time, there were three methods of installation for this deployment. They were;

The batch file itself was simple. I listed each patch with a switch at the end to make them run in a silent mode and not to reboot after it each one finishes. Then, at the end of the batch, I told it to shutdown the boxes by executing the shutdown.exe, but waited for 60 seconds before doing so.

I would normally test the package on my test boxes for each OS just to make sure everything ran correctly. So on the day that I planned to push the patches, I notified the end-users not to turn off their CPUs at the end of the day. Then I would have the night operator connect to each particular group to make sure that each CPU was left on. After confirming that each CPU was on, they would click on a distribution button and select the proper group to push to.
In detail what RemoteScope did was copy the package to the hard drive of the client machine, ran the batch file, and if it was successful, deleted the package and sent a report back to the console. Once the patches completed successfully, the box was shutdown as the last step in the patching. If, for some reason, one of the boxes in the group was having a problem, the process would skip that one CPU and execute the next one on the list. At first, I spent a good amount of time trying and testing different ways of doing the procedure. Now, after I got the hang of it, it only takes minutes to put patches together and test them. RemoteScope has now evolved to its mature state, which makes it faster, more stable and more convenient with this feature. As for other features like Remote Control, Inventory and such, which are part of RemoteScope, I only briefly tested these features and they seemed to work well.

All in all, the RemoteScope program has been a lifesaver to me. Prior to having RemoteScope, every time I saw a notification regarding a new security patch, or patches, from Microsoft I would say to myself “Here we go again, my endless nightmare!”, but not any more. RemoteScope has been a major part of my Network Administration tools because of its convenience and simplicity. Not to mention, every time I called their tech support I would always get a knowledgeable and polite technician who knew what he was doing to help me immediately on my issues. I never had to wait for somebody to call me back or had someone treat me rudely, which I greatly appreciated.

I strongly recommend RemoteScope for any Network Administrator or Engineer who works with a medium to large scale Windows network environment. That is, if he or she wants to have a life and not spend multiple weekends trying to keep up with Windows updates and software upgrades. You should give it a try to see what RemoteScope can do to reduce time and effort of dealing with security patches.

Johnny Khum
Network Administrator
INSURESUITE, Inc.
Guardian General Insurance
Survival Insurance Brokerage