|
|
|
by Tom Henderson
Not long ago, you were eager to migrate to new and exciting platforms-it was a challenge. All too soon, though, anticipation was replaced by a migraine when you discovered all the "gotchas" that came bundled with a new operating system. Whether it's incompatible registries or directory services, you know what I'm talking about if you've deployed Windows 95, Windows NT 4.0 or NetWare 4.x.
I offer Windows 95's Registry as exhibit number one. When Win95 arrived, I fondly hoped that it would cure my Windows 3.1x initialization blues. Like many of you, I had a PC filled with both used and orphaned Win3.1x .INI files. Each time I uninstalled a software program, a trail of .INI files was always left behind. The answer, Microsoft said, was upgrading to Windows 95. After all, Win95 included a Registry-a type of database that tracked, among other things, software settings, applications and their associated .INI files. With Win95, a PC would no longer crash like a house of cards because an .INI file or setting was deleted or moved by a fiddling user.
More than a year after Win95's arrival, it's clear that the Registry is hardly a cure for my .INI blues.
The data in the .INI files has been mapped to the Win95 Registry, but the Registry itself suffers from a new problem called UBFWI (user's been foolin' with it). In other words, the Registry is not secure, and users can change its settings easily.
When first deploying Windows 95 at my company, I tried to set and enforce certain system and user policies across our wide area network. The settings didn't last long. In the last year, department users have installed purchasing, sales and marketing software, a package to figure tariffs and tolls, and incremental revisions to Microsoft Office (and now Corel Office 7). Many of these new packages and upgrades alter the Registry. Product installation, after all, means Registry changes. Fortunately, most applications won't interfere with settings for other applications residing on the same PC.
Still, I get nervous when users are involved in the upgrade process. If there's a field with a number in it during installation, users are curious to know what it means. If they change one of those field numbers, that means a change to the Registry. Electronic software distribution is one way to shield a user from the installation process-and remove their temptation to make Registry changes-but post-installation reconfiguration options are still widely available to them.
For example, when a user right-clicks Network Neighborhood on Windows 95 or NT 4.0, he can drill down to the setting level. Before you know it, I get e-mail asking why certain values are set in the property sheets. My users aren't trying to make me justify my keep with these questions-instead, they just want to be sure that things are set properly.
To secure the Registry, I suggest it become a fully encrypted file (it's already somewhat encrypted) or distributed COM (DCOM) object for which Win95 software developers have the key. On networks, only approved administrators should have the key. I say keep the key out of users' hands. That does not mean I don't want users to install software. They could continue doing so by using Wizards and property sheets that decrypt the Registry, but keep the Registry's minutiae out of sight and mind.
Currently, most property sheets show far too much Registry information. Not even a system administrator can tell you what each entry on a property sheet means. To illustrate my point, I'll use Novell's Client32 Properties sheet from the Windows 95 Network.
I'm not trying to take Novell to task more than any other vendor, but this properties sheet is a handy example of software that offers too many options. Each of the settings on this sheet has a correlating Registry entry. Almost none of them really need be exposed to users-the defaults are great! Also, the passwords that are exposed need to be password-protected, even if the password is a version-wide one. There's no safety latch on the Registry trigger.
I've got at least two suggestions that would exercise further control over settings and Registry changes. Microsoft should allow Windows Explorer to view a system's architecture directly. Of course, this approach should employ password protection. By right-clicking on a box-plus sign, you would be able to drill down to the hardware resources underlying the services-way down to the chipset if desired. Another option: Perhaps PC configurations could be stored and downloaded from a secured directory services server (more on directory services in a moment).
As if a network running Win95 and NetWare didn't invite enough potential Registry problems, the situation becomes even more problematic when Windows NT is tossed into the mix. NT 4.0's Registry schema is so gee-whiz (techno-babble for "advanced") that it's not compatible with Win95's Registry schema. The differences are dramatic enough to make upgrades from Win95 to NT 4.0 a matter of reinstalling nearly all your software. By the time you read this, tools will likely be available to ease and remap settings during upgrades from Win95 to NT Workstation. Still, it seems stunning for Microsoft to release NT Workstation 4.0 without an easy migration path from Win95.
Imagine the anger when those upgrading from Win95 to NT 4.0 read the migration guide and discover that Microsoft couldn't write a routine that enters the Windows 95 Registry, plucks out the settings for MS Word, WordPerfect, Notes or another application, then maps them to the new NT 4.0 schema. You'll have to suffer because a parser didn't make it into NT 4.0. Will we face the same schema madness when Cairo arrives sometime in 1997 or '98?
Novell users have also suffered from schema changes. Novell took four releases (and 11 patch levels) to get the NDS services inside NetWare 4.x optimized. Those who wrestled with the incremental iterations have some scars from destroyed directory services databases and faulty backup products from vendors that weren't paying attention to the NDS changes. Though the just-released NetWare 4.11 (also available with bundled Web software under the IntranetWare name) has a directory services schema that differs from the four prior major releases of NDS, don't lose hope-migration tools are included in the box. Also, check out the new administrative tools, such as the Novell Requester for Windows NT, which can manage NetWare NDS servers. With luck, you won't have to debug the new schema, utilities or backup software.
Novell finally learned to smooth its upgrade paths after suffering earlier migration goofs. Upgrading to NetWare 2.1x required as many as 105 diskette swaps in the pre-CD-ROM days. Fortunately, migration tools rapidly evolved during the NetWare 3.x era in the early 1990s. Both NetWare 2.x and 3.x versions had a fairly simple user and resource database that constituted a bindery, so upgrading from the former to the latter wasn't too painful. The pre- and early releases of NetWare 4.x had very weak migration tools. Upgrading from 3.x was difficult because administrators had to master NetWare 4.x's new directory services. Novell realized that without tools to convert prior releases to NetWare 4.x, its upgrade business was going to be soft. Those tools matured rapidly-even for Novell.
Rather than constantly shipping upgrades, vendors should slow the release pace and raise prices by 50 percent (so that Wall Street won't be offended by the changing cycle times). The curative costs of maintaining networks is skyrocketing because of the expense of managing "gotchas"-such as directory and registry issues-in interim upgrades that are released merely to drive sales volume. We'd all rather pay preventative dollars than curative, which have a cost far higher in real money and real problems. Until vendors understand this, upgrades will remain a problem.
Contributing Editor Tom Henderson is vice president of engineering for Indianapolis-based Unitel. Contact Tom in the "Enterprise Administrator" topic of WINDOWS Magazine's areas on America Online and CompuServe, or care of the Features and Columns Editors.
|
|
|