At the CAE (Computer-Aided Engineering) Center at the University of Wisconsin-Madison, we have been using Novell NetWare and Microsoft Corp. Windows NT for years and have made great strides integrating the two. We now support more than 200 Windows NT 4.0 workstations in a NetWare 4.11 environment.

Taking the plunge into integrating Windows NT and NetWare is a worthwhile undertaking. With it, you get the best of both worlds--a solid desktop operating system as well as a powerful network back end. And integrating the two has gotten easier, with Novell picking up much of the administrative and management overhead. In particular, the emergence of Z.E.N.works (Zero Effort Networks) for users has made integrating NetWare and NT a snap.

Where the Rubber Hits the Road One of the first problems we had to contend with was what to do about Windows NT's need to have some form of authentication at the local workstation or domain. Though this problem can be solved in many different ways, the most obvious choice is to create all needed user accounts on each NT workstation. Even simpler, a Windows NT domain could be created to let users be authenticated against a single server, but this scenario requires that an NT server be present in the network. We didn't consider this option due to the fact that we have a continuously changing user base of 5,000+ students who are already using an NDS tree.

Another solution to this dilemma is to use a single, generic NT account for all users. This would require the creation of a single user object on all NT workstations (or one object in a domain). In this model, your users would not need to know of this account's existence--the Auto Admin Logon option could be set in the registry of each workstation. Of course, this has the drawback of the password for the account being present in clear text in the registry for prying eyes to find. It also makes it a bit more difficult to track who's using the NT workstation with NT's built-in auditing tools. When we first deployed NT in our labs, this was the solution we implemented, as the options we now use (and will discuss shortly) were not available. With this method, people would use the NetWare client to log in to their NetWare accounts, and the generic account specified in the Auto Admin Logon registry options would be used to authenticate to the local NT workstation.

With an upgrade to Novell's NT client software, IntranetWare Client for NT--and specifically the inclusion of Workstation Manager--we were able to consider a third option. Workstation Manager offers the ability to have the Novell client dynamically create user accounts on each workstation as they are needed. Now accounts can be created using NetWare credentials (login name and password), or a generic NT account can be created, eliminating the need to manually create and set up blind accounts on all your workstations.

Workstation Manager also can remove accounts from the workstations after users log out. But one question remains: With dynamic account creation and removal, won't you run out of unique IDs on the NT machine? The short answer is no. Even if you were to log in and out of the workstations 100 times a day, you wouldn't run out of SIDs for at least 100 years. A SID is the unique ID given to each user account on an NT workstation. And NT does not reuse SIDs after an account has been removed. In our environment, we have many users that come and go and may never use the same machine twice. Because of this, we choose to have Workstation Manager make the accounts temporarily and remove them after they are used. This also helps keep the "C:\WINNT\Profiles" directory clean, as this is where NT stores information about local accounts.