continued...page 3 of 5 Migration From NDS
Windows 2000 includes a tool for administrators who want to migrate from NetWare Directory Services to Active Directory. The Directory Service Migration tool will scan an NDS tree, or just a portion of it, into an offline database, allowing the information to be manipulated before being exported into Active Directory.
We started the migration tool and let it scan the production NDS tree for the Engineering College at the University of Wisconsin. All told, the Production Engineering NDS tree contains about 10,000 objects. These are mostly user objects, with a few groups, NetWare Servers, and application objects also thrown into the mix. After working on the tree for hours, the migration tool eventually failed, spitting out an error message announcing that it was out of resources. So we tried scanning a portion of the tree instead. We selected a branch that contained about 100 objects. This scan was completed in a reasonably short time, although we ran into some trouble with a few objects when attempting to export the information into Active Directory. Deleting the objects allowed the program to continue. Microsoft acknowledges that not all NDS objects can be converted to Active Directory.
Passwords are always a problem when migrating objects between directories, and this is true when moving to Active Directory. Active Directory's migration tool handles passwords in one of three ways: It lets the administrator choose "no password" for the account, select a random password (logged to a file), or make the password be the same as the logon name.
New Management Technique
Microsoft has changed server administration for the better. The Microsoft Management Console was introduced through a service pack for NT 4. MMC provides a single, coherent interface for all management consoles. In fact, since it's also available for third-party vendors to use, it can accommodate virtually all the management applications an administrator might need.
Instead of having a dozen or more programs to manage various parts of the system, Microsoft combines all administration tools under the MMC. The MMC lets administrators and users customize the interface so that it shows only the administration options they care about. Administrators can also assign groups of management tools to system operators with fewer privileges.
With MMC, administrators can manage Active Directory, DNS, and Dynamic Host Configuration Protocol, as well as local and remote workstations and servers. This is a huge step forward from Microsoft's previous management system.
Managing policies under Beta 2 has gotten a bit easier--or more complex, depending on which of several new options an administrator chooses. For example, Beta 2's MMC lets an administrator work with Group Policies, which are applied to a user or computer on the network and which replace the POLEDIT program in NT 4. Instead of having to distribute .POL files around the network, the administrator can store user policy information in Active Directory. With Group Policies, the administrator can restrict rights, such as disabling the registry editing tools or limiting access to the control panel.
The Group Policy editor lets the administrator assign applications that should be available to specific users or groups. The catch is that the applications must provide a new Microsoft Installer file. Fortunately, the popular third-party InstallShield package already has a beta version for Windows 2000 available for companies that develop apps to create the new file. Also, Beta 2 includes a "lite" version of Seagate Software's WinInstall program that will create the Installer file for older packages.
To test the Group Policies feature, we assigned two sample applications to all users of the domain. One app was set to always be distributed, while the other was intended to be published. The first distributed application showed up on the user's start menu after logon. When the application was selected, the application installer kicked into gear, and the application started. Since the app was fairly small, it didn't take long.
The second app, which we published to everyone in our Active Directory tree, didn't show up on the start menu. However, when we selected the Add/Remove Programs option on the control panel, we found it listed under the applications published by the corporation. We really liked this new way to very easily distribute new applications out to user desktops. We did run into a problem, though: If the user does not have rights to the local file system in which the installer needs to place files, the install process will fail. When a failure occurs, the installer will back out any changes that were made to the system.
Fortunately, there's a way to let applications install themselves, regardless of whether the user running the application has the right to do so: A Group Policy management option will let the application installer run if it has been given "higher privileges." This option is not enabled by default, but it's easily turned on.