For several reasons, the decision to support StreetTalk for Windows NT (ST4NT) in your new Windows NT network is more compelling than a complete migration from VINES to NT's domain architecture. One of the most compelling reasons for supporting ST4NT on your NT network is that you can continue using the true enterprisewide directory services that you are accustomed to. You can leverage your existing StreetTalk architecture and proven services on the open NT platform. Another reason is the ability to migrate from VINES at any pace that suits your business computing and staffing requirements without dramatically affecting interoperability or end-user training. By properly staging your migration to NT and running ST4NT, you can often perform the most complex and time-consuming tasks in the server room, without ever touching your clients. Just think about that idea: You can move hundreds of servers to NT and never touch your VINES clients.
Even if you have already decided to abandon StreetTalk, consider leveraging its services during your migration. First, you can often recoup the cost of ST4NT because it can prevent major obstacles from getting in the way of your migration.
Second, with StreetTalk, you have hadand would missthe luxury of a three-part namespace for users and services (e.g., User@Group@Org). Because most VINES networks consist of thousands of users and hundreds of servers, you must have a directory that lets administrators and users quickly and accurately determine the location and name of any resource in the network. StreetTalk's location-independent architecture lets users locate and use resources without knowing the location or what server the resources are on.
In contrast, NT 4.0 domains classify users and services within a two-part name space (User@Domain) that is incredibly flat and nearly impossible to arrange to represent most organizational structures. In addition, NT's structure requires users to know the location (domain) and the server name on which any resource is located. And, NT doesn't provide an enterprisewide directory service that reduces administrator workload. As a result, domain-based networks require administrators to maintain multiple namespaces for NT domains, Exchange-based mailboxes, and any other traditional NT domain-based applications.
Equally important to realize is that ST4NT's interoperability lets you build large-scale NT networks without designing and supporting NT domain trusts, file replication, and account and security database propagation in the enterprise. ST4NT lets you manage your network directory in much the same way as you have always done, seamlessly integrating your directory service between user accounts, services, and StreetTalk's Intelligent Messaging (IM).
|
When planning your migration and determining what role ST4NT will play in your network, you need to determine how you will map your directory namespace on your NT network. Banyan's promise to deliver a Lightweight Directory Access Protocol (LDAP)-enabled version of StreetTalk is likely to beat Microsoft to market. This version will let you further extend StreetTalk's directory space into a large array of LDAP-enabled applications. LDAP will virtually hide the proprietary nature of StreetTalk and allow StreetTalk's convergence with any desktop-based application.
You can use ST4NT to ease your migration and provide enterprise directory services for your network for the next few years, and when NT 5.0's Active Directory (AD) is proven, you can then decide whether to abandon StreetTalk. By using ST4NT today, you get the best of both worlds, with NT's proven open platform and StreetTalk's enterprise-based directory services.
I have to say that Microsoft gives enterprise networks one significant servicefault resiliencethat StreetTalk doesn't. The potential failure of a server can have an enormous effect in an enterprise network. One way of reducing your potential exposure is to design a network that can continue to function even if one server on the network fails.
StreetTalk's major drawback is that although its services and namespace are logically dispersed throughout a network, each logical entity is tied to a specific server. This arrangement increases your exposure during a server failure. A server failure somewhere on the network can affect the rest of your network and users because access rights lists, user accounts, and mailboxes are physically stored on one server. If a user's account belongs to a StreetTalk group that is on a failed server, the user will probably be unable to access any network resource.
You can reduce your exposure with StreetTalk by shadowing your StreetTalk groups. Shadowing lets you put read-only versions of StreetTalk groups on up to two additional servers on the network. If a StreetTalk group's primary server fails, account and access rights lookups can automatically switch to the shadowed server.
NT provides a slightly more elegant process of fault resilience. Because user accounts for an NT domain are automatically distributed between the Primary Domain Controller (PDC) and all Backup Domain Controllers (BDCs), you have a larger distributed database that's easier to manage.
Although three StreetTalk servers are unlikely to fail at one time and cause StreetTalk lookup failures, I still like Microsoft's distributed name architecture better. If I could recommend one thing to improve StreetTalk, I would ask to have its database automatically distributed among all the servers in the enterprise. We wouldn't have to wait for those long access rights lookups from server to server over the network. The entire StreetTalk database would be right there. Although I appreciate Microsoft's approach to fault resilience, it's not enough to prevent me from running StreetTalk in any enterprise network.
