Logo: TechTrax...brought to you by MouseTrax Computing Solutions

Microsoft Word as a System Management Tool

by Greg Chapman, MVP (retired)
Skill rating level 7.

Word as a What?
A couple events occurred recently as a direct result of two personal characteristics. First, I have a big mouth. It's so big that I can comfortably fit both feet in it, disgusting as that may sound. Second, there's a touch of the curious contrarian in me. I'm often struck with the thought of "Why not?" closely followed by "Oh, yes you can!" when someone states a generalized, negative declarative sentence. Some would call it a defensive reaction…they'd probably be right. Still, it's a useful thing most of the time. It forces me to think, carefully, and then to re-examine the question.

Well, those two quirks got me into a little heat from two sources. One had asked a bunch of Microsoft MVPs what their favorite remote server management tools were. Answers came back in the form of PCAnywhere (bah!!), VNC (love it!) and Terminal Services (fantastic, but not so hot for working over Windows NT systems since they don't have a way to run the service, normally). My answer? An eclectic, enthusiastic "Oh. I use Microsoft Word!"

Of course, no one knew what I meant with that. Obviously, I can't run a remote console using Word and my favorite place is really within the comfortable confines of Windows Script Host. But I ask you to give this a moment's thought; you work as an administrator of systems including user desktops and laptops. Your boss is technically savvy but not likely to be a 0's and 1's geek. She's also interested in money and how much less of it you can be made to work with. She likes reports that people can read and process, not the dry output of a script's text stream.

What's the natural medium for producing readable reports? A word processor!! How do you get all that valuable data that justifies your paycheck into Word? Well, with VBA, you have access to almost everything available with Visual Basic and almost everything you can do with the Windows Script Host (WSH). If you've read any of my pieces before, you know that I advocate the use of WSH, regardless of language, for nearly all administrative tasks because of the need for consistency in output, speed in producing the results and an audit trail to confirm the work. Every one of those things can also be produced with MS Word if you need other people to see it.

And since Word has a much richer development environment than WSH, life for a newbie programmer can be simpler, too.

I'm not going to share my Word templates designed for the management of Active Directory and Windows NT domains in this forum. They are built fairly specifically for the environment and business rules in which they are run and customizing them requires that you, my reader, be at least as conversant with Active Directory Service Objects as I was forced to become…that segues nicely into the second event.

And You Decided Word Was a Good Backup Tool When..?
Last month, I described how my big mouth and contrary streak got me into showing how to use Word to output a formatted list of programs available from the Start Menu. In the same exchange of messages, I asserted that I could further prove Word's use as a system management tool to the average user and administrator by using it to back up your important files. To further prove the point and show the commonality between VB, VBScript and VBA, I decided that I would make this template a direct port of an existing WSH script I had already written to allow a hands-off backup of critical files.

Configuring WordBackup.dot and Logging Its Activities
Since the results are to be stored in a log file, this example template (a download to this article) does not create a resulting Word document. Instead, LogWordBackup.log is created in the same folder as the template so that you can have a record of the backup job to refer to.

It also uses a text file (the administrator's big buddy of convenience) called ConfigWordBackup.cfg in which the user can specify logging depth, folders to archive, the destination path and Special Folders to ignore. Don't worry, though, the template will work even if you don't have a configuration file since it does have operational defaults that it will work with if it can't find the configuration file. The downloadable zip file does include a sample configuration file with notes to help you along, though.

By default, the template attempts to archive the user specific Desktop, My Documents, Templates, Internet Explorer Favorites and the Windows Fonts folders. By the use of special keywords in the configuration file, the user can control this behavior and cause, say, the routine to ignore the Windows Fonts folder.

Additionally, users can use the template to back files up to a network share. All they need to do is configure the file using the altpath= parameter to specify a UNC path, i.e., \\server\sharepoint\archive.

The script is also as time friendly as possible. It's enthusiastically incremental in nature. If a file exists in the source directory but not the archive path, it copies the file. If the file is newer in the source directory, it copies it. If the file in the destination is newer or the same age, it doesn't get copied again.

To be friendly to real backup operations, the template ignores the archive bit so that those more enterprise minded applications can continue to catch files that have changed in some way, regardless of date. If you don't know about the Archive bit, here's a brief explanation. Any time a file is created or modified in some way and the results are saved to disk, the archive bit is set in the file system to reflect the fact that the file has changed. Backup programs use this bit when running an incremental backup to determine whether the file has been modified since the last time they looked at the file. Once the file has been backed up, this bit is cleared. The next time the backup operation runs, if the bit is still clear, the file won't be backed up. It really is an elegant way to operate and to have this template interfere with that quality process wouldn't be appropriate.

Finally, I mentioned variable logging depth. If you caught last month's article on a simple technique for controlling the size and growth rate of log files, you'll remember that I described 5 different logging levels, 0-4 and that, respectively, they reflected No Logging, Errors Only, Successes Only, Errors and Successes and, finally, complete Debug logging for chasing down bugs in your scripts. In this template, the logging depth can be controlled by specifying debug= and a number from 0-4 in the parameters section of ConfigWordBackup.cfg.

By now, many of you are wondering why this template uses a CFG file instead of the registry. Well, that's a great question and I think I have an equally good answer. The registry, even though it is simple enough to learn and understand, causes people to get nervous. They do things like restrict user privileges to it and won't go in there without a map or a program interface with which to manage it. And I understand the fear; if you know nothing about where the end of the world is, how do you work up the courage to sail your boat in that direction and know enough to turn back before you fall over the edge?

To accommodate those users who have had the privileges tightened down on the registry, using a text file for configuration information makes a great deal of sense. It's probably a safe assumption that wherever you have this template stored on your computer, you also have write privileges and that means you can write a change to the configuration file, save it and then the script will behave as desired! Well, heck! That's all we wanted in the first place!

The Question of Porting from WSH to Word…
A half hour. That's all it took to convert the script enough that it work cleanly as a Word Template. I'm not kidding! The sum total of porting for the barest of essentials in operating were:

  • Replace any reference to wscript.echo with Application.StatusBar=. This allowed anything that would normally be shown at the console prompt to be displayed in Word's status bar.

  • Get away from Late Binding as much as possible. While not absolutely necessary, it does help with speed and error control. Wherever you can avoid a "CreateObject" call by specifying a reference to the control/DLL, etc., do it!

As I mentioned earlier, a log file is generated instead of building a document. It would be easy enough to alter this operation by getting rid of references to log files within the logging routine…but this was supposed to be a quick port. Since the template's code is open, I'll leave that detail to you.

Performance
It's interesting. Many VB experts will guide you away from using the FileSystemObject. There are good reasons to avoid it. For instance, it is on the order of 8 times slower to parse a directory structure than a good ole complicated API call to Windows. But we're not parsing here. Is it equally inefficient at moving files from one place to another? Nope, it's only 1.5 times slower at this job. So the next obvious question is "Does it matter?"

Again, "Nope" is probably the best answer. In my tests, copying the files from one folder to another on the same drive delivered about 7.5 Gigs per hour of operation. That's much faster than your network will handle (Oh, yes it is! Do the math and measure it!) and it's easily proven that your removable media device cannot perform writes that quickly on today's technology.

My test systems were:

  • Dell Inspiron 8200 laptop, 1.13 GHz, 512 Meg RAM
  • Homebuilt AMD Athlon XP 2200+
  • My remote server for UNC testing is an Intel PIII at 896Mhz with SCSI Ultra 3

In no instances were any of these machines overloaded. The laptop, as the executor of the template, was the busiest with sustained processor levels of about 20% with occasional peaks to 70%. Most of this load, also, came from Word itself as the script version of this application moved slightly more than 8 Gigs per hour with 15% processor utilization.

What Liability?
I accept none! If you decide to use this tool, I advise you to test it to your satisfaction on data that has no real importance to you. I'm confident you won't experience a problem other than Word looking a little unresponsive during the backup, though.

And in that light, I hope you find this self-extracting download (WordBackup.exe) to be useful, easy to use and helpful!

 

 

Go up to the top of this page.
This site powered by the Logical Web Publisher™: Content management by Logical Expressions, Inc.