 |

|
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 |
|
 |
|