InformationWeek
Defining The Business Value Of Technology
November 2, 1998
NT5: Miles TO Go Before Win2000
 Print this story |
In either case, there must be a uniform schema. When using Windows 2000, if you need a different schema, you'll need to create a new Active Directory forest, just as you would need to create a new tree under NetWare to achieve the same end.
If you aren't accustomed to depending on DNS for your network, get used to it. For Active Directory to function properly, DNS must be working, and the DNS server in use must support both the Dynamic Update protocol (RFC 2136) and the Service Location resource record (DNS SRV, described in RFC 2052). The DNS server that comes with Beta 2 supports these RFCs, and this is the server we used in our testing. Later implementations of the popular Bind DNS server will also work (Microsoft has tested Bind version 8.1.2).
We set out to create a simple forest directory structure. We tried to install two Active Directory trees into the same forest, with one tree in the Wisconsin lab and the other in California.
The first tree was installed in the Wisconsin lab. We started with a stock NT 4 Server running as a primary domain controller (PDC). We created various users and groups in the domain and let the operating system's installation perform the upgrade on the server. The upgrade was successful, but it took about an hour for the basic install to complete. Once the upgrade was completed on our Compaq ProLiant 6500, it was time to run the DCPROMO program to upgrade our server to the first machine in our Active Directory tree. DCPROMO promotes servers to domain controller status, and demotes them to standalone server status if you no longer want them to be domain controllers--an option not available with NT 4.
Master Of Its Domain
Happily missing from Windows 2000 is NT 4's limitation of a single PDC. Under NT 4, other NT servers can participate in the domain only as backup domain controllers. When changes are made, the PDC updates the BDC servers. The new version of the operating system uses a multiple master-replication scheme so updates made to any of the domain controllers will automatically be replicated to other domain controllers as needed. Each tree has its own set of domain controllers.
Although we were able to add a new tree to the forest, we ran into many problems--so many that we ended up scrapping our initial design and starting again. Among the problems we unearthed was the fact that it took several days for a few changes made in Wisconsin to finally show up in in California. When discussions with Microsoft brought no relief, we changed our directory.
We decided to try a configuration that might be more typically deployed in a business. We created a root domain in Wisconsin; once this domain was up and running, we created a child domain in San Mateo. We added a third machine and made it a second domain controller. We had much better luck with this configuration.
We suspect that our problems with the first forest scenario were caused by Active Directory's reliance on WINS. Although DNS is used most frequently in cases where the directory service needs to use a name resolution service, we found lingering dependencies on WINS in Active Directory. Pointing all of our machines to the same WINS server made many problems disappear, because all Active Directory servers then had access to the same WINS info, which isn't normally possible since WINS isn't compatible with large routed internetworks. Microsoft claims these dependencies have already been removed in the post-Beta 2 builds. We hope so.
Security and administration of a tree with new child domains was confusing and fell far short of what we expected. We think its confused nature points up the immaturity of Active Directory. When adding a child domain to the tree, an administrator from the parent context needs to be present to let the child system join the tree. This makes sense, so not just anyone can link into the tree.
However, once it's joined, that administrator does not have any administrative rights to the child domain by default. The administrator of the child domain could grant the parent administrator privileges to the child domain, if desired. This could be useful if local administrators don't want the administrators who control the root of the tree to be mucking with their child domain. But on the other hand, it means a bit more setup work for anyone who wants to be able to administer the entire tree from a single account at the root.
If a parent domain administrator wants to supervise the parent domain from a child domain machine (which could happen if an administrator from headquarters were to visit a remote site, for example), it's possible to add users from the parent domain to the group of users permitted to log in locally to the child domain machine. We experienced browsing problems between domains in the snap-in, however, and couldn't select members of the parent domain. We had to add the parent domain administrator to the group from a command-line tool to make it work.
Logons presented another stumbling block. Active Directory lets administrators create Organizational Units to organize the tree logically. However, if in the same portion of our test tree, we tried to create two users with the same logon name but in two different Organizational Units, the addition of the second user would fail. This is where backward compatibility with NT 4 rears its ugly head. An administrator can create more than one user with the same logon name, but only if they exist in separate child sections of the Active Directory tree.
continued...page 3, 4, 5
return to page 1
Read sidebar story, "NDS Offers Stability And Maturity."
Back to Labs
Send Us Your Feedback
Top of the Page
Featured Microsite
