Active Directory In light of NT 5.0's beta status, we didn't compare the performance or features of its AD to NDS. Nevertheless, we can make some general comparisons. Microsoft's implementation of AD introduces the concept of the "forest," which is a collection of AD trees. Though seemingly more powerful than Novell's single-tree construct, it really is much the same thing. An NDS tree with multiple Organization root objects is essentially akin to a forest with many trees. In either case, there must be a uniform schema. If you need a different schema when using NT 5.0, you'll need to create a new AD 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 AD 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 NT 5.0 supports these RFCs, and we used it in our tests. Subsequent implementations of the popular Bind DNS server will also work (Microsoft has tested Bind version 8.1.2.)
A Simple Forest We set out to create a simple forest directory structure, as diagrammed on page 57. We attempted to install two AD trees into the same forest, with one tree in the Madison lab and the other in San Mateo.
The first tree was installed in Madison under the DNS domain nt5.uw.nwc.com. We began with a stock NT 4.0 Server running as a primary domain controller (PDC). We created various users and groups in the domain and then let the NT 5.0 installation perform the upgrade on the server. The upgrade was successful, although it took about an hour to complete the basic install. Once the upgrade was finished on our Compaq ProLiant 6500, we ran the DCPROMO program to upgrade our server to the first machine in our AD tree. DCPROMO promotes servers to domain controller (DC) status, and demotes them to standalone server status if you no longer want them to be DCs; this option was not available with NT 4.0.
 We're happy to report that NT 4.0's limitation to a single PDC no longer applies. Under NT 4.0, other NT servers can participate in the domain only as backup domain controllers (BDCs). When changes are made, the PDC updates the BDC servers. NT 5.0 uses a multiple-master replication scheme, so updates made to any of the domain controllers will automatically be replicated to other DCs as needed. Each tree has its own set of DCs.
The second AD server was installed in our San Mateo lab with a root DNS domain of nt5.sm. nwc.com. Although we ostensibly were able to add the new tree to the forest, we ran into many problems--so many that we ended up scrapping our initial design and starting over. For instance, we found that it took several days for a few changes made in Madison to show up in San Mateo. When discussions with Microsoft brought no relief, we changed our directory.
An Even Simpler Forest We decided to try a configuration that might be more typically deployed in a corporation's network. We created a root domain in Madison at nt5.nwc.com. Once this domain was up and running, we created a child domain in San Mateo at sm.nt5.nwc.com. We added a third machine and made it a second DC for the nt5.nwc.com domain (see page 57). We had much better luck with this configuration.
We suspect that our problems with the first forest scenario stem from AD'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 our machines to the same WINS server eliminated many problems; this gave all AD servers access to the same WINS information, which normally isn't possible due to WINS' incompatibility with large routed internetworks. Microsoft claims that these dependencies have already been removed in NT 5.0's post-Beta-2 builds. We hope so.
|
REPORTS
ANALYTICS
Follow 
