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
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
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
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
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
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.
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
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.
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
And in that light, I hope you find this self-extracting
download (WordBackup.exe) to be useful, easy to use and helpful!