By Ram Tackett
Network World, 1/20/97

To fill the directory service void Microsoft Corp. left in Windows NT, Banyan Systems, Inc. released StreetTalk for Windows NT a few months ago. We set out to answer the question, Does it fit the bill? Answer: Not unless you already have a significant investment in VINES.

If you're currently running Banyan's VINES network operating system and want to host some of your user accounts on Windows NT, StreetTalk for Windows NT might be a good fit. However, if you're outside of the Banyan customer camp, wait for revisions to clean up problems with installation and administration, or hold off and see what Microsoft delivers in its forthcoming Windows NT 5.0 directory services.

A directory service is supposed to help users and administrators get to information without having to maintain separate logons for services and applications. But to use most NT applications, including those in Microsoft's BackOffice suite, users still need Windows NT accounts, accounts for individual applications such as Exchange or SQL Server, or both. The only applications we found integrated with StreetTalk for Windows NT were Attachmate Corp.'s NetWizard, and LANshark Systems, Inc.'s StreetLegal.

If you have to maintain user accounts in NT domains anyway, what value does StreetTalk bring to an NT-only shop? We had a hard time finding any, unless all you're looking for are rudimentary file and print sharing, and basic E-mail services.

In the box

You can manage several types of objects using StreetTalk, including users, groups and lists of objects, in addition to services such as mail, print, file, gateway and calendaring. You can also maintain nicknames or aliases for any of these StreetTalk objects.

Each StreetTalk object can theoretically maintain as many as four billion attributes such as business addresses or telephone numbers. StreetTalk uses a dozen of these internally. Third-party software vendors can also store data into these attributes by registering with Banyan.

If you plan to kick StreetTalk's tires, make sure you have an NT File System (NTFS) partition on the targeted servers. StreetTalk won't install without one. After installation, you can configure file sharing services on any type of NT partition, including File Allocation Table, NTFS, OS/2's High Performance File System or CD-ROM drives.

Banyan was kind enough to send system consultant Allen Moffett to aid in our tests. Good thing, as we needed him to work through a plethora of problems including buggy installation and administration.

According to Moffett, the Compaq Computer Corp. ProLiant we used should support between 200 and 300 StreetTalk users without difficulty. But we had several problems with network scalability.

This version of StreetTalk will only bind to a single network interface card in a server, which throttles back performance in larger shops. In addition, server shadowing - the ability to duplicate user and group information across servers for redundancy - is not supported unless you use a pure VINES server (not NT) as your shadow.

The product package includes StreetTalk for Windows NT, the Client Components Suite, on-line documentation and an evaluation version of the Admin ToolBox Lite from NetPro Computing, Inc. (www.netpro.com). The server-side installation was straightforward and went off without a hitch. After we rebooted the server,there was little to show that StreetTalk was even around. At a minimum, we looked for the presence of StreetTalk administration tools. None were installed. But we could tell that the StreetTalk service was running through the services applet in NT's control panel. In addition, StreetTalk created a Banyan program manager group with icons for logon, log-out and send (for chat purposes).

StreetTalk uses VINES IP, which is similar to TCP/IP, as a core communications protocol. VINES IP is configured through the standard network applet in the Windows control panel, and errors are logged to the NT event viewer, which is nice for remote administration purposes.

To connect to StreetTalk for Windows NT, you need to install the Banyan VINES client for your operating system. DOS; Windows 3.1, 95, NT; and OS/2 are all supported.

For Windows 95, by default, the VINES client installs the VINES IP protocol stack. If you use the Microsoft TCP/IP stack, you can configure the VINES client to use the Microsoft stack via the User Datagram Protocol (UDP).

In the lab

StreetTalk Explorer version 1.0, which ships in the box, allows you to configure only file and print services. For tasks such as creating users or groups, you must use Banyan's kludgy character-mode utilities. But Banyan released Version 1.5 of the graphical user interface on the World-Wide Web, so we decided to try it out.

Bad idea. We ran into several glitches during 1.5 installation and finally removed it to go back to the original version. However, this produced a barrage of general protection faults in Windows Dynamic Link Libraries. We had to scrap that machine.

We installed StreetTalk Explorer Version 1.0 on the new client, but also tried version 1.5 on a third machine, where it finally worked somewhat successfully. The product administered the StreetTalk services correctly, but the buttons on the toolbar were blackened out. Occasionally, Explorer went south on that machine with general protection faults. Banyan's tech support suspected we'd gotten a corrupted installation file; we suspect the company rushed out Version 1.5 before it had been thoroughly tested.

We created a StreetTalk print service that tied back to a Windows NT print queue, which in turn was routing data to a print queue on a Novell, Inc. NetWare server. We had hoped Banyan would transparently hand data off to the NT print queue, which would then hand off to the NetWare print queue.

Not so fast. Our StreetTalk client's Windows 95 print manager told us the printer was off-line. However, we could print successfully from the NT console.

Trying to dig up troubleshooting information through the one working copy of StreetTalk Explorer we had was fruitless. It reported that the print service was stopped for the new StreetTalk queue. Clicking the button to start the service displayed the message, ''Service already running.'' We felt trapped in a bad Abbott and Costello routine.

We tried adding users to the Banyan print service through StreetTalk Explorer, to no avail. ''Maximum users reached'' was the only message we got. StreetTalk Explorer had defaulted to displaying only one user, ''st@corporate@servers'' - the name of the general StreetTalk service itself. According to Moffett, this security privilege setting should have defaulted to ''*@*@*'' - Banyan nomenclature for all StreetTalk users. We deleted and re-created the print service, with the same results.

Turns out the problems were twofold. First, when a print service is defined in StreetTalk, by default it neither accepts queued print jobs nor releases any jobs to the printer. You must explicitly enable this functionality through StreetTalk Explorer for every print service you create. While experienced StreetTalk administrators would be familiar with this, it's likely to throw NT administrators for a loop. Why would an administrator create a print queue that doesn't accept or submit print jobs? Again, we were at a loss.

Second, the print service we configured to pass jobs from Banyan to NT to NetWare gave StreetTalk a mid-flight lobotomy. The NT event log showed no anomalies with the print queue process in setup, handoff or printing. Even though the Windows 95 client printed successfully directly to the NT queue, we couldn't perform the same operation through StreetTalk, and we couldn't discover why. When we reconfigured the NT print queue to communicate directly to the Hewlett-Packard Co. LaserJet 5Si, eliminating the NetWare server hop from the picture, most of our problems were solved.

Remote administration remotely possible

To administer over RAS, we had to change the StreetTalk communication protocol on one of our servers to use UDP, supposedly for security and encapsulation purposes.

To safeguard against packet fragmentation, we also had to lower the size of the Sequenced Packet Protocol Maximum Transfer Unit (SPP MTU) option, which controls the size of the VINES IP data frames within IP packets.

According to the documentation, the maximum size of data that StreetTalk for Windows NT sends in a frame (1,500 bytes) allows for 50 bytes of packet headers when the SPP MTU size is 1,450 bytes. Since the frame size can't be increased, adding these UDP headers reduces the number of bytes available for data. If we didn't reserve more space for the headers, a single frame could no longer carry all the original VINES IP packet data, leading to packet fragmentation.

When we installed our Banyan Windows NT servers, we configured them to use Dynamic Host Configuration Protocol (DHCP), which transparently manages IP addresses on a network. For StreetTalk, this works fine on a small subnet as long as you're not using RAS.

To administer StreetTalk servers over RAS, Moffett recommended we give the StreetTalk Home Server a static IP address and configure the RAS Banyan client to point to this address. That's because StreetTalk for Windows NT doesn't understand DHCP when you're not using it on a routed network.

We also had to change the 95 client to point to the StreetTalk server's static IP address instead of falling back on dynamic addressing when administering via RAS. Our dial-up adapter on the client could use DHCP, but the Banyan client software had to know the static IP address of the StreetTalk server. That's because the client broadcasts to find the StreetTalk server, but the client broadcast will work only if the StreetTalk server is present on the same physical network as the client.

Once we had our remote client configured, we were able to see and administer both StreetTalk servers, even though the second wasn't configured for UDP.

The moral of the story