Baker's Byroad: "When you are over the hill, you pick up speed."

In the Trenches with LAROKE

Konsultant's Log, Cyberdate 05.28.1998 (Building Johnny Mnemonic Part III)

SITREP: In the last "In the Trenches" log entry, we finished setting up a basic Windows 95 OSR2 operating system environment on the new server "Johnny Mnemonic". In this installment the network operating system software will be installed and configured as well as the intranet Web server software. The data now residing on the old server "Old Blue" will be transferred to Johnny and be reorganized in the process.

TACAMO:

Step 1: Configure the network software

1:00 P.M. 4/19/98 The Invisible LAN installation files were copied across the network from the server "Old Blue" to a temporary directory on Johnny's hard drive. The Invisible LAN "protocol", "client" and "server" components were installed in a manner simular to installing Microsoft Networking components (see LAROKE Step-by-Step 004 "Installing Windows 95 Network Components"). The components were configured using other machines in the system as a guide. The Microsoft networking components were removed at the same time. Then the TCP/IP protocol was added for company Intranet operations.

When I first setup the intranet, I didn't have much knowhow regarding IP addresses. I still don't but between then and now I've read that addresses between "192.168.0.0" and "192.168.255.255" have been set aside for private use. I resolved to reset the IP addresses on the company machines to comply with this usage. I would have to reconfigure each machine on the company intranet. This is as good a time as any.

After I changed the IP address for the current intranet server, Old Blue, I had to reconfigure the Web server software to reflect this change. I opened the Quarterdeck WebSTAR Web server "Control Center" to change the IP address for each of the six current "Document Trees". I had a lot of typing ahead, so I was pleasantly surprised that as I clicked on the 'Properties" button for each Document Tree in turn, I was presented with a message "The host name in the Registry is different from the local host name", then (after clicking the "OK" button") the "Document Tree Management" Dialog would appear with the "Host address" field already corrected. All I had to do was click the "OK" button to make to change take effect. Every once in a while you get Artifical Intelligence software features where the emphasis is on "Intelligence" instead of "Artifical".

Step 2: Transfer Files from Old Blue to Johnny

9:58 A.M. 4/22/98 I've spent the last two days copying files and directory structures from the server "Old Blue" to the new server "Johnny". This is not quite as easy as it sounds. Keep in mind that the files that reside on five hard drive volumes on Old Blue will be placed on a single drive volume on Johnny.

This move has also provided an opportunity to separate company data into workgroup data (e.g.: project data required by the CADD group will now be in different subdirectory hierarchies than company data used by the administrative group). Another reason for reorganization is future expansion flexibility. Eventually, the growing mountain of data in the various groups will begin to crowd each other, even on this large 9.1GB drive. The next time I have to move things around, it will be easier. I can move whole groups to new additional drives with much less disruption than I'm having this time.

The problem with this current "shell game" is that thousands of our intranet URL addresses will now point to non-existent directory and file structures. They will be broken links, but we will cross that bridge when we get there. Network disk drive mappings on other network workstations will have to be upgraded to point to the new server Johnny instead of Old Blue. Also the files will still exist on Old Blue (and be accessible there) until everything is transferred, accessible, backed up and otherwise "hunky-dory" on Johnny. This situation means that extra work is required (and care must be taken) to avoid file synchronization calamities until the successfully transferred data can be erased from Old Blue.

Step 3: Setup the WebSTAR Web server software

12:30 P.M. 4/23/98 Most of the files have been copied to Johnny's drive D: and reorganized. I'm now ready to install the WebSTAR Web server software. I began trashing the Krash Lab in search of the WebSTAR installation CD. The Krash Lab is a bit better organized than usual and I found the CD in less than a half hour of scrambling around. WebSTAR was installed on Johnny's drive C: in a few minutes. The meat of the operation, however, was in the configuration. WebSTAR was originally developed for the Apple Macintosh operating system and enjoys a big following in that environment. The Windows 95/NT version I'm using was published by Quarterdeck, but no longer supported by that company. It has performed well as a Web server for our small company intranet and I've been happy with it.

There were three basic areas of configuration that had to be addressed now that the basic WebSTAR installation was in place: "Document Trees", "Mime Types" and "File Type Display Options".

1. Document Trees: In general, all your files for the intranet are placed under a single "document tree". In my case the document tree is called "Company Server" and all the files (and subdirectories) for Company Server are located at "D:\VPAWEB". The IP host address is "192.168.0.21:83" which is "port" 83 at Johnny's "IP address". When users on the company network type the URL address "http://192.168.0.21:83/index.htm" into their browser, it retrieves the file "D:\VPAWEB\INDEX.HTM" on Johnny's hard drive (actually, they don't have to type it since I've set it up as the "start page" on all the browsers).

This works well as long as all the documents for the Web site are in subdirectories under "D:\VPAWEB". During reorganization, I separated "company" data from "project" data and project data is located under "D:\JOB". This is good for keeping workgroups out of each other's way, but since "D:\JOB" is outside of the "Company Server" document tree, project files cannot be accessed through the intranet. The way around this restriction is to setup additional document trees and use an "alias" name to access them. The next task then was to set up another document tree "Jobs" for the files (and subdirectories) that located under "D:\JOB". The IP host address for this document tree is "192.168.0.21:84" which is "port" 84 at Johnny's "IP address".

Under the Company Server document tree, an alias name "/job" was set up. Conversely, under the Job document tree, an alias name "/server" was configured. Now files could be accessed from both document trees transparently. Here's an example:

Say a user is on a job list Web page and s/he clicks a link that retrieves the web page
 
http://192.168.0.21:83/job/job_five.htm
 
When WebSTAR gets this request and sees
 
/job/job_five.htm",
 
it will actually retrieve
 
http://192.168.0.21:84/job_five.htm"
 
and the user will get the file
 
"D:\JOB\JOB_FIVE.HTM".

Similarly, If that page has a link to the company home page
 
http://192.168.0.21:84/server/index.htm
 
When WebSTAR gets this request and sees
 
/server/index.htm",
 
it will actually retrieve
 
http://192.168.0.21:83/index.htm"
 
and the user will get the file
 
"D:\VPAWEB\INDEX.HTM".

After the basic document trees were set up and alias' established, I moved on to MIME types.

2. MIME Types: MIME types were developed for e-mail, but Web browsers also use them to determine whether they can display a particular file type. In this office, for example, I use Envoy documents to display company documents, faxes, etc. with their original formatting intact. To allow envoy documents to be displayed in a user's browser, both the WebSTAR server and the browser have to be made aware of what an Envoy file is. The browser additionally has to know what to do with an Envoy file when it encounters one. For WebSTAR, a MIME file type is added. An entry is added that tells WebSTAR that files with the extension ".EVY" are MIME Type "application/x-envoy" and that's it. The browsers on the company intranet machines have to be configured to open the Envoy files with the Envoy viewer applet when they encounter one.

The problem I had is that I have added quite a few MIME types to the WebSTAR server on Old Blue and I did not want to have to re-key them all into the new WebSTAR installation on Johnny.

I examined the files in the main WebSTAR directories on both Old Blue and the newly setup WebSTAR installation on Johnny. They both had a "MIME.TYP" file and the file on Old Blue was larger and had a newer date than the other WebSTAR installation files. The MIME.TYP file on Johnny had the same date as the other installed files. This indicated to me that the MIME.TYP file was a data file and that the file on Johnny was a "default" MIME types file whereas the MIME types file on Old Blue was larger with a different date because it had the additional MIME types I had added over time.

Acting on this hunch, the Old Blue MIME.TYP file was copied to Johnny's WebSTAR directory. I opened up the "WebSTAR Manager" Dialog on Johnny and clicked the "MIME" Tab to check my hunch . . . Good. I was right. All the MIME types I had added to Old Blue previously were now registered on Johnny's WebSTAR installation as well.

3. File Type Display Options: When a HTML directory listing is displayed from a WebSTAR server in a browser, WebSTAR will display icons and descriptions for files based on file extension. The icon graphic file name and locations and well as the file description has to be entered for each extension type so WebSTAR knows how to display them. This is further complicated by the fact that file types can be different for each Document Tree, multiplying the amount of data that must be entered by keyboard.

Unlike the MIME Types data file, similar data files for file type display options did not exist. After a bit of sleuthing, I discovered this information was kept in the Windows 95 Registry. Editing the Registry by hand would not be any faster than keyboarding into the WebSTAR Dialog for entering this same information. It would also be much more dangerous - one slip could corrupt the Registry. The REGEDIT.EXE utility is unforgiving. As an American General once observed: "Stupidity is always punished more swiftly than evil."

I noticed that each "Document Tree" had its own "sub-branch" Keys in the Registry. Each document tree key was a number rather than the document tree's name. Now, one of the nice features of REGEDIT.EXE is that a sub-branch key and the data below it can be exported and imported as a file. When imported, the key will be placed in exactly the same location, even if imported into a different Registry on another machine. This is a limited safety feature that tends to keep one from really screwing up.

My problem was that the Document Tree keys in Johnny's Registry were numbered differently than those on Old Blue. For example, the file type display options keys I wanted to use for Document Tree "4" on Johnny were under Document Tree "6" on Old Blue. Because of this mismatch, some sleight-of-hand was required to import the file type display options keys from Old Blue to where I wanted them in Johnny's Registry.

First, I found the "Key" for file type display options under Document Tree "6" on Old Blue. This Key, "<DirListProps>" and its sub-branches were exported to a temp file, "TEMP.REG" and copied to Johnny's Desktop.

If I just imported this file into Johnny's Registry, which doesn't have a Document Tree "6", a Document Tree 6 would be created with the <DirListProps> Key under it. To avoid this and get the <DirListProps> Key under Document Tree "4" where I wanted it is where the sleight-of-hand came in. I exported the Document Tree 4 Key and subbranches to a "BACKUP.REG" file for safety in case things went seriously wrong. Then, Document Tree 4 in Johnny's Registry was renamed Document Tree "6". The <DirListProps> Key under the renamed Document Tree Key was deleted to make way for the yet-to-be imported TEMP.REG file. The TEMP.REG file was imported and it arrived right where it was supposed to under the renamed Document Tree "6" Key. Finally, the Document Tree 6 Key was given back it's original name, Document Tree "4". Voila! I had my long list of file type display options without having to rekey them into the WebSTAR interface on Johnny. Only three more Document Trees to import and I'll have the WebSTAR configuration "up-to-snuff" on Johnny.

Step 4: Fix broken URL Links

Because of the separation of "Project" data and "Administrative" data when files were moved from Old Blue to Johnny, and the establishment of differently named and aliased Document Trees on Johnny's WebSTAR installation, thousands of URL address links in existing company intranet HTML documents were now broken. Fixing them by hand would be a daunting and time-consuming task.

Lucky for me, I had HomeSite v2.5. This wonderful HTML editor has "Extended Find and Replace" capabilities. You can instruct it to find a specified text string and replace it with another text string in "batch" mode. That is, search and make replacements in all the files in a subdirectory or project.

After pondering the various replacements that would be necessary by studying the differences in typical broken URLs and fixed URLs and deciding the exact "find" and "replace" text strings required to fix broken addresses (and not inadvertently break good addresses), I let HomeSite loose to do the changes. Over 2,000 HTML pages were scanned and corrected this way, and all the changes were done in less than a day. I felt pretty good with that chore behind me.

MISREP: Johnny Mnemonic was now ready for "Sea Trials". He would be run twenty-four hours a day on the workbench in the Krash Lab for the time being. After I redirected the drive mappings for the other PCs on the network from Old Blue to Johnny, Old Blue would be taken off-line for his refit as a communications server. Old Blue's dockyard experiences will be the subject of the next couple of installments. Old Blue's refit starts badly but ends well. After a gut-wrenching meltdown, he ends up running more reliably than in the past, but I'm getting ahead of myself here. See ya all next time.

LAROKE Microcomputer Consultants
155 East Boca Raton Road
Boca Raton, Florida 33432
(561)368-0659 (Tel & Fax)

Issued Thursday May 28, 1998

copyright © 1996-1998 LAROKE Microcomputer Consultants all rights reserved