By Tom Henderson

CHANGE. IT'S one of the only things you can count on in this business. In the latest round of changes, intranets are becoming de rigueur, Banyan has introduced a product to complement Microsoft's domain service and Windows NT-based phone systems are proliferating.

First, the Internet enabled users to communicate with the outside world. Now, intranets are improving communication within organizations. One of the beauties of internal Web site development is that it's automatically cross-platform; any Internet browser becomes a client to the in-house Web. No matter what operating system you're using, all you need is TCP/IP, and everyone can participate. On- and off-site workers and contractors can access an internal Web server as though they were dialing an Internet service provider.

An intranet can't reach out to specific workgroups the way groupware can, but it does enable companies to disseminate information quickly among all users. Electronic forms of all kinds are simple to deploy on intranet Web servers.

For most small companies, an in-house Web server may be nothing more than an overpriced memo pad. It's the large companies that will benefit most. For one thing, they'll no longer need to worry about lost sheets of paper or e-mail. Internal LAN users will also appreciate the speed advantage browsers provide over dial-up or T1-based (1.544Mb-per-second) Internet connections.

Most security experts demand that an organization's Internet and intranet platforms reside on separate servers. They also insist on the construction of an up-to-date firewall for the Internet server.

It's also a good idea to keep sensitive company information off the intranet. Online company address books, a blessing for employment recruiters, are a no-no. On the other hand, emergency information such as phone numbers for utility companies, fire and law enforcement agencies, medical groups, building maintenance, auto repair shops and towing companies can be useful.

An on-site Webmaster can speed Web updates, provided the content isn't graphics-laden. Appending a few pictures of the softball team is okay; you just have to be careful not to go overboard.

My company, Unitel, plans to digitize its main building to give users a tour of the facility from any of its seven branch sites using VRML (virtual reality modeling language)--that is, once it finds a way to amortize the dedicated-circuit costs necessary to bring the branches online. The Webmaster loves the idea, but loathes the lack of VRML standards. Because VRML is in its infancy, it'll be a while before sufficient bandwidth exists to support this standard.

It has taken a while, but there are now three ways to manage users and directories under Windows NT: the native NT Domains, the WINS/DNS Internet and intranet services, and the most recent addition, Banyan's StreetTalk Access for Windows NT File and Print. U.S. government agencies--major Banyan business clients--are turning handstands over this development because UNIX boxes are no longer required to run Vines and StreetTalk.

The fact that StreetTalk now runs as a native service under NT is significant. It's the first export Banyan has made to a non-UNIX foundation. Vines runs natively under a gaggle of UNIX platforms-its own (a modified Santa Cruz Operation XENIX kernel), Sun's Solaris, IBM's AIX on RS/6000 and a few others. Other systems, including Novell file servers, can connect to Vines and StreetTalk via StreetTalk agents through Banyan's Enterprise Network Services (ENS).

With Banyan's ENS, the ENS agents may reside on systems and act as brokers and communications vectors between Vines and the system. But that's not the model Banyan uses on NT. StreetTalk Access is native on NT, and it's the first port to a non-UNIX system that's a major improvement over StreetTalk agents running on NetWare servers. In order to make Banyan native to NT, the company has added TCP/IP support alongside Vines IP, its proprietary protocol. Novell's IPX protocol can talk to StreetTalk agents living in NetWare servers, but I haven't yet heard of a TCP/IP replacement for ENS NetWare's IPX transport. Banyan not only wants NT to live as a peer on Vines and StreetTalk networks; it needs the rapidly evolving NT server applications.

This is good news for Banyan users and those who find Microsoft's domain control dull and immature. It boosts Banyan's acquisition, BeyondMail, a favorite messaging system of several years ago that fell into relative obscurity with the advent of MS Mail, Lotus cc: Mail and Novell GroupWise. Banyan's Intelligent Messaging Agents, which fuel BeyondMail, now live on NT.

Client use of Banyan NT is similar to that of any other 32-bit network client. You install the client software from a CD-ROM or network download. You can use ten 32-bit network clients with Windows 95 architecture, provided no 16-bit client is present. If one is present, three's the limit.

The StreetTalk Access port to NT shows the shift in emphasis toward NT. Banyan has finally added a non-UNIX network platform with an NT price tag.

Also making a shift toward NT are phone systems. For years, voice-mail servers and automatic call distributors were based on IBM's OS/2, because of its multitasking and multithreading capabilities. Although NT isn't quite multithreaded yet, many vendors have ported voice-mail servers and Automatic Call Distributors (ACDs), which connect to the vast majority of key system units (KSUs) and small private branch exchanges (PBXes).

Mitel has unveiled a preliminary design that couples a phone system and a LAN file server with Windows NT. The server combines Microsoft Exchange with multi-port phone port boards to allow a networked NT server to function as a full-featured phone system and a network server. Exchange treats voice mail as just another received object for mail users. The final development work waits for MS Exchange and some fine-tuning.

Dialogic's Windows CT-Connect, an NT-based workgroup phone system, is available now. The system combines the usual set of phone system features under Windows NT. Dialogic DSP boards join the CT-Connect system either to the public telephone network or to Northern Telecom or AT&T digital PBXes, among others.

All of this phone development work is an important endorsement for NT as a stable applications server. If LAN components go down for a while, users are merely irked. But if phones are dead, users are cut off from the outside world. So, a more disciplined and preemptive service philosophy and culture has evolved around phone systems than around computer networks.

Because voice mail and other phone system features can now fit safely (in the minds of phone system vendors) into an NT server, universal mailboxes that couple these features with e-mail are just around the corner.

However, there are drawbacks to using NT as a phone server. Without virus protection, a server could shut down and crash-perhaps beyond recovery. High-reliability equipment and maximum uptime attitudes must prevail. Until we understand how telephony taxes NT, early adopters will use independent NT phone servers. In some ways, this defeats the purpose of having everything locally accessible-communication between a phone and data server now depends on a reliable network link.

Interoperability is another issue. TAPI NT, the Telephony API Microsoft is maturing for phone system hardware and software, has little meaning for NetWare users, where messaging surrounds Novell's Telephony Services API (TSAPI). Comdial just released a product that uses NetBIOS to transmit information from its phone system to Windows users running Comdial's version of Q.Sys or AnswerSoft desktop phone control software. None of the above talk to the others.

NT as a phone server platform is evolving rapidly. Novell isn't far behind, and the workgroup phone-system platform war is just getting started. Let the games begin.