MICROSOFT NT ENTERPRISE DESIGN Conclusions Designing an NT enterprise can be accomplished successfully provided you take all issues into account. Understanding Domain communications, WINS, Browsing, and DHCP can result in an effective implementation. At the same time you must also accept the shortcomings of these technologies. The lack of tools to effectively manage trust relationships, WINS failures and database corruption, and disappearances of Browser entries, can make the maintenance of NT harder and more expensive than expected. Finally, the lack of mature server management and LAN administration tools also hinder a cost-effective NT enterprise. At the same time, tools in all the above mentioned areas are fast reaching maturity, and coming into the marketplace in great numbers. The return on investment with NT server should not be underestimated. Corporations are quickly realizing that most mid-range client-server applications a re being ported from UNIX to NT, and once the learning curve is conquered, NT can be a very effective enterprise platform. Databases, mail, mission-critical applications, remote access, connectivity to older systems, and the use of TCP/IP as it's basic communications pipe make NT an easy choice for entry into the corporate world. On the other hand, the roles of directory services and NT is less clearer. Directory services can make an enterprise system more manageable, cost-effective, and easier to use. Microsoft has been criticized for lacking a directory service, and promptly labeled it's Domains, a directory service. While that did not convince industry analysts, Microsoft has put forth a X.500-compliant directory in its Exchange mail software, and an API called ODSI (Open Directory Services Interface). Most sites implementing Exchange are not considering it as an enterprise directory for anything more than mail. This, we believe, is a mistake. Exchange design must be done as if the directory were meant for all resources. Cairo technologies, include a directory component. This component is expected to be modeled after the Exchange code, with extensions to make it more adaptive to a variety of information. The directory service is expected to be released in mid to late 1997. ODSI, initially a stop-gap strategy by Microsoft to quell lack of directory interoperability, is expected to have code that will let applications and software access information from any directory service, be it Lightweight Directory Access Protocol (LDAP)-compliant (Netscape implementations etc.), X.500-compliant (NDS, Streettalk, Exchange), or Distributed Computing Environment (DCE) (IBM implementations etc.). While ODSI expected each directory service vendor to code the connector to their service, Microsoft has announced it will write the code for LDAP-based and Novell's Novell Directory Services (NDS) directories. Currently, DCE may be the closest we have to a cross-platform directory (DCE software ex ists for mainframes, UNIX, NetWare and NT), but lack of applications leveraging this technology has slowed down it's implementation. The directory services area is now in flux on the impact of LDAP-compliant directories vs X.500 vs OSF/DCE. Championed by the major companies with Internet product lines, LDAP may be the most talked about way to access directories. Countering this, Microsoft and Banyan tout X.500, while Novell attempts to port it's NDS to various platforms. The resultant effect will be that every directory service vendor will write code to talk to every other directory. There may be duplication of information, but with an API such as ODSI and LDAP-compliance, we may yet see a universal store of users and computers and data. Next Updated August 15, 1996 Print This Page E-mail this URL