MICROSOFT'S FIRST SLAP AT NDS
Dfs may be different, but Microsoft finally has a directory of its own
By WAYNE RASH Jr.
When you first hear about it, you're tempted to ask whether Dfs is really Microsoft's long-awaited directory service. Has Microsoft decided to move beyond support for Novell's NDS and Banyan's StreetTalk and deliver a directory service of its own? More important, is it a credible competitor to the other two packages?
The answer to the first question is yes. Microsoft has indeed finally delivered. As to whether it's better than the competition, well, that depends. This is one of those cases in which everything depends on what you're trying to do, and what you have to start with in the first place.
Microsoft's Distributed File System offers most of the features for which you would buy a directory service: You get a single login; you don't need to know what server a file or directory is on before you use it; the network administrator can move files and directories around without users knowing; and you can integrate multiple operating systems into a single management solution.
On the other hand, there are a couple of problems. The most important is that your entire directory tree, and therefore your entire network, is tied to the health of a single Windows NT server. If the server goes down, your directory service is dead. With Microsoft's current version, there's no support for redundancy.
As a basic directory service, Dfs has the components it needs. You can create a single network directory tree that contains items from a variety of places across your network. This means that you might have a graphics package on one server and images distributed across several servers. With Dfs, image files can be made to appear as though they are in handy directories, just below the one containing the graphics editing package.
Once Dfs is running and installed, users logging in to the Dfs-enabled server see the Dfs tree as simply another resource--as if it were a directory available on the server, for example. Although the data they're using may be based on another server in another directory, they never know that.
Instead, they only have to log in at one place, and the material they need is there. As a plus, it doesn't even matter whether the resource is a Microsoft server, as long as it's visible to the Windows NT server. In fact, we used Dfs with a Novell NetWare 4.1 server as a shared resource during testing.
The heart of Dfs and its potential for success lies in its flexibility and ease of administration. As should be the case with a directory service, users really can't tell it's there. Here, Microsoft faced a formidable challenge.
Both Novell's NDS and Banyan Systems Inc.'s StreetTalk already were deeply entrenched as powerful, enterprise-capable directory services, with a wealth of capabilities and solid administration tools. To be really useful, Dfs needed to be comparable, at least in major areas.
We believed it would be. But to test its limits, we went ahead and installed a beta version of it on a high-end NCR S40 server of the sort likely to be used in a corporate environment that would benefit from Dfs. This server was attached to a network containing other NT resources, including another server as well as three Novell NetWare servers and workstations running Windows NT and 95.
There was little to be done for the initial installation beyond choosing a name for the Dfs root directory. Dfs installs as a
Windows NT service and comes up and runs when the server runs.
Windows 95 Workstations, in contrast, need to have a new Microsoft Networking client installed and the drive mapping done, if that is desired.
Administering Dfs mostly consists of adding or deleting shared directories. You do this by telling the Dfs Administrator what you want to call the share in the Dfs tree and what you want it linked to.
Once you've added or deleted a share within the Dfs Administrator, clients attaching to the server will have access to the resource. You can change the ultimate destination of the attachment by moving the contents of one directory to another on a different server, for example, and once the change is made within Dfs, users will see the material just as they always have.
There's no question that Dfs is a real directory service. It's much more limited than either NDS or StreetTalk, but it's better
than nothing--which is what Windows NT Server users had before. On the other hand, administrators of large enterprises may be less than enthusiastic about its limited support for clients and about the relatively time-intensive means of managing the directory tree. Dfs does not hold a candle to Novell's well-designed object-oriented administrator, for example.
Administrators with networks that are even marginally mission-critical would do well to pair the product with some means of fault-tolerance, such as the Stand-by Server made by Vinca Corp., Orem, Utah. In addition, without careful attention to security with Dfs, it's possible to open up an otherwise well-designed server to viewing by anyone. We even made the entire directory structure of a NetWare server visible to an NT client that had no rights to log on to NetWare.
What we saw was clearly a test version of a product that may or may not be released in exactly this form. So, if you plan to use
Dfs, choose a test environment, not a production network.
Is Dfs, in the end, an important step forward? For administrators of Windows NT networks, the answer is definitely yes. Certainly for administrators of large enterprise networks, Dfs is a nice try. But it does little to ease their workload, and it adds concerns--concerns that make it a dubious achievement for now. |
