Serving up Windows on the network

Compared to NetWare and VINES, Windows NT Server version 3.51 is the new kid on the network operating system (NOS) block, but it's that overly bright new kid who grows up to be Bill Gates.

We found NT's domain services to be quite comparable to the directory services of NetWare and VINES, contrary to what Novell, Inc. and Banyan Systems, Inc. may say. While Microsoft Mail has some deficiencies, the beta version of Exchange Server we looked at holds the promise of some exciting new group collaboration and scheduling functionality. And Systems Management Server (SMS) is a terrific tool for managing user desktops, even though its lack of Simple Network Management Protocol management capabilities leaves it without Banyan DeMarc's greatest strength.

A domain directory

The directory services in Microsoft Corp.'s Windows NT Server and IBM's LAN Server 4.0 show these products' common roots in Microsoft's LAN Manager 1.0. They share a basic domain-based naming architecture, so we've compared the two below.

In both systems, a domain is a group of servers that share a common database of users, groups and security restrictions. One server is declared at installation time to be the domain's primary controller and holds the master copy of the domain database. This server is also where you make changes to the domain database, such as adding a new user or changing a current user's access rights.

This design by itself works fine for a small network, but a naming system that relies on a single server to handle all access to the name database would quickly bog down as the network grew. Therefore, both LAN Server and Windows NT Server allow you to declare one or more of the other servers in a domain to be a backup or secondary domain controller. Each secondary has a copy of the domain database and can validate user logons. When the administrator makes changes to the domain database, the primary domain controller replicates the changes to the backups.

Both systems provide robust replication services between primary and backup domain controllers, including facilities that keep track of what domain database updates have been sent to each backup controller. If a WAN link to a backup controller, or the controller itself, goes down, these systems know what information to send to bring themselves back in sync. On our test network, an NT Server that was down during a block of user adds was resynced in seconds.

Thanks to the backup domain servers, users can still log on to the domain and have access to all file, print and other resources - except, of course, those that are on the primary controller itself - should the primary domain controller go down. While the primary controller is down, administrators cannot update the domain database and therefore have to either repair the domain controller or promote a backup domain controller to take over.

Promoting a Windows NT Server backup domain controller to become the primary controller takes just a few seconds and a few mouse clicks. Making the promotion under LAN Server is a bit more difficult, requiring a command-line utility. LAN Server's documentation also lists under administrative duties manually backing up of the domain database. This could mean that IBM believes the restorations are needed regularly or simply that the company's mainframe "suspenders and belt" attitude is showing through. We can't say for sure since we were unable to corrupt the database on either system.

Placing multiple servers in a domain lets both LAN Server and Windows NT Server provide a single point of logon to all file and print resources on the servers in the domain. It also provides a single point of admin- istration, allowing you to grant any users in the domain acces to any domain resource.

Windows NT Server allows you to configure the frequency and size of domain database replication packets so replication traffic won't swamp your network's low-bandwidth links. We were unable to find an equivalent feature in LAN Server.

LAN Server allows servers to be part of a domain but not act as a domain controller. These additional servers have no logon database and rely on the domain controllers to provide validation. You can still grant access to these servers to users in the domain just as you do to a primary or backup domain controller.

The Windows NT Server model places these additional file and print or application servers outside all domains. The network administrator must grant access to the resources on this server by specifying both the user's ID and home domain.

While both NOSes offer domain naming services, they are nevertheless true directory services in our opinion. The fact that they are domain-based means they have either multiple independent (in the case of LAN Server) or interdependent (Windows NT) databases instead of a more flexible, single, partitioned database such as NetWare Directory Services (NDS) or StreetTalk. This flexibility is apparent in the case of a server in a field office where the sales staff for four divisions share space on a single server. With a directory service, the server can have the partition data for all four divisions. In a domain structured system, the server can be in only one domain.

Microsoft has extended the domain concept in Windows NT Server by providing network administrators with the ability to create trust relationships be- tween domains. Microsoft borrowed this concept from the Open Software Foundation, Inc.'s Distributed Computing Environment (DCE): Trust relationships allow a user logged on to one domain to access resources in others. For example, to let users from the accounting domain access resources that are part of the manufacturing domain, you would create a relationship where the manufacturing domain trusted the accounting domain.

Once this relationship is established, administrators in the trusting domain, manufacturing, can grant access to resources in their domain to users and global groups in the trusted domain. Servers in the trusting domain validate guest users with the domain controller in the trusted domain, then grant access to resources if the user has the right permissions.

Members of both local and global groups can be granted access permissions. Global groups are visible outside the domain they are in, so they can be used to grant access to resources in trusting domains. Local groups are only useful within the domain, but they can include global groups as members. So, for example, if all the domains in your network trust the MIS domain, you can make the global group administrator from MIS a member of the local group of administrators for all the other domains. That would make the MIS group's administrators masters of all domains.

Trust relationships are unidirectional; just because Domain A trusts Domain B doesn't imply that Domain B trusts Domain A. Trust relationships also only extend to the explicitly trusted domain; if Domain A trusts Domain B, which in turn trusts Domain C, that doesn't mean that Domain A trusts Domain C.

LAN Server doesn't currently support trust relationships, but IBM is promising support as part of a future LAN Server extension that fully implements DCE. With the current version of LAN Server, IBM solves the problem of allowing a single point of logon for a user by allowing a workstation to log on to multiple servers in different domains simultaneously as long as the user employs the same ID and password on all the servers.

But LAN Server doesn't really address the additional administrative overhead of maintaining a user account on all those servers. About all it lets you do is administer several domains without logging back on, as the administration utility allows you simply to select the domain you want to administer from the displayed icons.

If you're planning a new network, you can think of domains - especially in Windows NT Server - as being similar to NDS partitions. Both include groups of file servers and their associated objects in a replicated database. A partition is a section of the database starting at a container object and extending down the tree. Partitions allow administrators to control the parts of the database that are replicated to different servers for load-balancing or to limit replications across the WAN. Like a domain, a partition usually contains several file servers.

Windows NT Server does a better job than LAN Server of providing a single point of logon and a single point of administration. This is made even more evident by limitations in LAN Server's graphical user interface (GUI) tools. You need to use command-line utilities much more often with LAN Server than with Windows NT Server. The most significant example of this is LAN Server's User Profile Manager, the GUI tool used to manage user accounts. It can handle only about 1,800 users per domain. Microsoft's User Manager for Domains has no such limitation. A command-line tool supports higher numbers of users, but it lacks even a menu interface.

LAN Server does provide a few properties for user objects that Windows NT Server doesn't, allowing you to define drive and printer assignments and the applications that appear in the public applications folder on OS/2 desktops.

Windows NT Server has no provisions for providing location-independent access to data. Data resources are addressed by the Universal Naming Convention that includes the server name and the name of the shared resource. By contrast, NDS and StreetTalk allow a user to access a resource by name without specifying the server it is on. This allows you to relocate resources without any change to the way users access it.

LAN Server allows you to use aliases, which define a file or print resource in a location-independent way. Once an alias is defined, a user can assign a drive or printer port to the alias without referring to a server. Administrators can move the resources from server to server and just redefine the alias to let all the users access the resource.

Both Microsoft and IBM are beginning to address unifying file and print service directories, as well as the directories for other application services on the network. The LAN Server user database is shared by OS/2 Database Manager, while Windows NT directory services are also used by the Microsoft BackOffice applications, including SQL Server and SMS.

Microsoft has made three recent announcements about the future direction of Windows NT directory services. The first, Directory Service Manager for NetWare, a Windows NT Server add-on, allows you to copy user accounts from NetWare 2.X and 3.X file servers' binderies to Windows NT Server's directory service. It also lets you manage those user accounts on both NetWare and Windows NT Server from Windows NT Server's User Manager for Domains.

The second announcement, Open Directory Service Interface, defines a series of Windows APIs that allow application developers to use and manage multiple heterogeneous directory services through a common API, and eventually through a common user interface.

Finally, Microsoft has announced that the directory service in Cairo, a future version of Windows NT Server, will integrate with the file system, providing a single object-oriented directory for access to files and directory objects.

Messaging is Mail

While domains are a comparatively recent innovation, Microsoft Mail has been around even longer than Windows NT itself. Despite a new name - Microsoft Mail Server 3.5 - and the fact that it ships with a multitasking message transfer agent (MTA), Microsoft's messaging service is still the same old Mail. Mail does not currently support any integration with the domain-based services of Microsoft Windows NT Server. And, although it is billed as a component of Microsoft BackOffice, Mail is more accurately described as compatible with BackOffice because it's not an integrated component of the server suite.

Messaging systems are composed of three basic components: clients, message storage and an MTA. The MTA is a program running on a server or workstation that is responsible for moving messages from one place to another. Microsoft Mail has two types of message transports: a DOS transport that runs on a stand-alone workstation and an NT transport that can run on a workstation or server.

The message store in Microsoft Mail, called a post office, remains a shared-file and -directory structure that resides on any DOS-compatible server.

Installing Mail is a matter of determining where to install post offices, setting up MTAs to transfer messages between post offices, installing Mail clients on workstations and setting up user mailboxes.

However, you might have a little trouble trying to figure this out from the documentation - it's terrible. Other than a setup card that attempts to convey the steps simply, the documentation appears written with the assumption that you will read it from cover to cover. There are no road maps or hints.

While the Microsoft Mail documentation is complete, it's tedious because it's organized feature by feature rather than task by task, the way someone would actually use the product.

You administer Mail with the ADMIN program, a DOS-based utility that can be run on any client workstation that controls mailboxes, definitions for external post offices, directory synchronization, gateways, remote users and message queues. The ADMIN program manages a single post office at a time, though if you have access to the administrator's mailbox and shared directories where other post offices are stored, you can use ADMIN to manage them, as well. There is currently no Windows-based administration tool.

With ADMIN, you can set options on user mailboxes for user, user access, group and folder privileges, and whether to include the user in directory syn- chronization. User privileges determine whether the user is an administrator of the post office. User access privileges determine what rights users have for manipulating messages, including the right to delete, retrieve, send, send urgent and external messages, which are messages sent to other post offices. Folder privileges determine the level of control the user has over private, group or shared folders.

Microsoft Mail supports directory synchronization between post offices for a global address book. Mail directory synchronization can be either manual, where an administrator exports the address list and sends it to other post offices, or automatic, where updates are sent out according to a schedule defined by an administrator. Schedules must be set individually for each server.

If you plan to use automatic directory synchronization, you must use ADMIN to define the external post offices with which information will be shared. One post office must serve as the "home" or primary post office, while the others are "requesters" of the update information. When directory synchronization is set up and the MTAs are running, updates to address books on participating post offices are automatic.

Mail clients

Microsoft Mail currently has clients for DOS, 16-bit Windows, OS/2 and Macintosh desktops. Windows NT Workstation and Windows for Workgroups automatically install a Mail client. All users need to access a post office are the user name and password for their mailbox, as well as the necessary file access permissions in the post office directory (\MAILDATA by default). The client asks if the user wants to connect to an existing post office when the client starts.

Presentation Manager and Windows 3.1 clients must run PMSETUP or SETUP from the executable mail files directory on the server. One caveat: Make sure you edit the MSMAIL.INI file in that directory to point to the shared drive that all clients use for accessing the post office. Otherwise, the Mail client gives an error stating that it can't find the post office when executed. If users are going to use different shared drives to access the post office, they must modify the ServerPath= line under the [Microsoft Mail] section of MSMAIL.INI.

While Windows NT's current messaging system may be old hat, the same cannot be said of its management component. SMS Version 1.1 provides powerful features for managing workstations and servers. One huge plus for SMS is that its functionality is not limited to the Microsoft universe. SMS can effectively manage and support DOS, Windows, Windows for Workgroups, OS/2, OS/2 Warp and Macintosh clients, as well as NetWare 3.X (and 4.X in bindery emulation mode), LAN Server and LAN Manager servers.

SMS gives you lots of help in hardware and software inventory and management, software distribution, software metering, client help desk functions (remote control and troubleshooting) and some rudimentary traffic monitoring.

On the down side, SMS currently does not support SNMP management, as Banyan's DeMarc does. A recent acquisition of Network Managers, Ltd. by Microsoft, providers of SNMP enabling technology, should fix this problem in future releases. SMS also seems to require a lot of hardware and software resources, which may be overkill for smaller networks.

Finally, SMS' hierarchical structure does not consider the network as a single entity. SMS divides the network into geographical groupings called sites, which provides flexibility for installing network management but still leaves several points of administration.

To install SMS, you must have an SMS server license and user licenses equal to the number of nodes managed, as well as at least one 20-user copy of SQL Server 6.0 for storing all of the data that SMS tracks. At a bare minimum, you need one Windows NT Server 3.5X server with more than 100M bytes of disk space and 20M bytes of RAM. The RAM recommendation expands to 28M bytes if SQL Server is run on the same machine.

Building the hierarchy

An SMS site can contain one or more Windows NT Server domains. In a multiple-domain setting, you must set your interdomain trust relationships so the SMSAdmin account (or a similar account created in one of the domains) has full control of all resources in all domains.

A primary site under SMS is a site that supports a SQL Server database. A secondary site must send information to a parent primary site. The secondary site and its parent do not share information; they have separate databases running on the parents SQL Server.

A primary site can also have another primary site as a child. The child writes its information to its own SQL Server database, then passes the information up to the parent for storage on the parent's SQL Server database. Information is passed up in this manner to the top of the hierarchy to a central site. This special primary site contains all of the SMS data for the entire network.

Each site has to contain several components for SMS to do its job. Among them is a site server, a computer running both Windows NT Server and SMS. It generally serves as the console for that site.

Each site must also have its own SQL database, but only primary sites need the SQL Server to support those site databases. The SQL Server databases can be run on the site server or a helper server.

One of the key features of SMS is automated software distribution. When SMS sends software to a site to be installed by the clients of that site, the software package is sent to a distribution server. In this way, only one copy is sent to the site, keeping network traffic to a minimum.

Similarly, a logon server authenticates user logons for the domain and serves as a transfer point between client information and the site server. When an SMS-enabled client logs on to a logon server, programs run from the logon script and upload the information that SMS tracks for inventory purposes from the client to the logon server. This is where it is gathered by the site server at a later time. Interestingly enough, a logon server or a distribution server can be a NetWare, LAN Server or LAN Manager server in addition to a Windows NT Server.

Larger networks have more information to track and software to distribute. Judicious use of helper servers for each site can improve SMS' performance. However, the site server can perform all of these functions when separate servers are scarce.

Tracking the elusive details

Assuming you successfully weave through the maze of site and domain permissions and trust relationships, you should have a pretty effective tool for managing your networks. SMS keeps track of the hardware and software configuration of all the SMS-enabled nodes. This information includes client identification information (such as name and domain), workstation status (such as date of last scan or software not installed), processor type, operating system, network addressing, network card settings, hard- disk information, total memory, mouse hardware installed, active services and DOS environment variables.

All of this information is easily accessible via the SQL database using simple customizable queries. This information can be invaluable when planning to upgrade your network or troubleshooting individual machines.

SMS lets you install new software packages on workstations or servers automatically without having to visit each computer. SMS creates a package containing the software to be installed, a program to begin the process and a job to deliver the package to the proper recipients.

You can control exactly who gets the software installation - down to the individual workstation or server level and up to a blanket upgrade of all workstations capable of supporting the software - according to any user-defined parameters. You can even control when the distribution takes place and how often the job is repeated.

SMS helps prevent applications running on NT servers from being accessed by more users than you care to permit. You can limit the number of concurrent clients allowed to access shared resources through Windows NT security functions. You can also let a client search for a shared resource that contains a copy of an application that has available connections.

SMS has a service for monitoring network traffic, called Network Monitor, that copies network packets from the network interface card for analysis. Not all frames are useful, so Network Monitor allows you to filter the sample down by frame type. Frames can be edited and retransmitted to test remote devices or reproduce network problems.

One of the more useful troubleshooting functions in SMS is remote control. When a user complains of a network problem, the administrator can take control of the computer, view exactly what is happening and try to determine a solution.

The database of hardware and software information can be invaluable at this point to see exactly how the client is set up. SMS even allows a split-window chat mode for communication between the user and the administrator. If the client happens to be running Windows NT, the administrator can run NT's remote diagnostic programs.

We liked SMS' tools for software distribution and metering, as well as its remote control features. Where SMS needs help, and where Novell's ManageWise and Banyan's DeMarc excel, is in the area of network infrastructure management. SMS' lack of ability to serve as an SNMP console is a hindrance.

Microsoft appears to know this and seems to be taking steps to fix it in future versions of SMS.

Looking ahead

Windows NT Server is the most up-to-date of the NOSes we looked at. Its architects learned from the mistakes of NetWare 2.X and 3.X, as well as Microsoft's own LAN Manager.

Windows NT Server provides not only an enterprise-scale domain service and good management tools, but also a stable architecture for server-based applications and competitive file and print services for organizations of various sizes.

Its homegrown messaging system is a weak spot, but the upcoming Exchange Server should help change that.

If you haven't already done so, this might be a good time to bring in at least one Windows NT Server for evaluation.