Network Computing Long Ago

Before joining Microsoft, I worked in small companies that generally employed less than a hundred people and usually didn't have a full-time information technology (IT) staff. As is the norm at many small companies, the people who liked to muck around with computers got to manage the network. The term "manage" is probably too strong—back then, network management involved connecting printers and keeping them running and performing tasks like making sure that new group assistants could access the files of the people they were assisting. Although all the computers were linked together, for the most part people worked as islands, using the network only for printing and occasionally for accessing shared files.

I started working at Microsoft in 1994 as a Program Manager for a component in Microsoft Bob. (Anyone remember that product?) At the time, I was tremendously excited at the possibility of working with more sophisticated systems. I assumed that Microsoft would have an extensive networking setup and use it to its maximum capabilities. Upon arriving, I was given four passwords—two Microsoft Windows passwords to log on to the two computers I had, a password for my Microsoft corporate network account, and, finally, a password for my Microsoft e-mail account. Each day, just to read my e-mail, I had to enter at least three different passwords. This was during the days of Microsoft Mail and Microsoft LAN Manager, so if I wanted to send e-mail to a coworker, I couldn't just type in the person's name; I had to know the "short name"—the eight characters or less that appear to the left of the @ sign in an e-mail address. If I didn't know the person's e-mail name, I could call him or her, but there was no simple way to find the phone number. My need for this information usually resulted in a call to one of the phone operators or a walk to the supply room, where I would flip through a large book called the Microsoft Company Directory. This printed directory was published each month and contained the full name, e-mail name, phone number, and office location of each person in the company. Figure 1-1 shows a setup in which a user needs multiple passwords to access different resources.

Figure 1-1 One user and many network resources and accounts.

Those hassles soon gave way to online versions of the company directory. Recognizing how personal information was being used, the group responsible for electronic mail started adding directory features to Microsoft Mail and then to Microsoft Exchange Server. The idea seemed logical: store the full name of everyone in the company, along with their e-mail name, office location, and telephone number in a special directory that was a part of Microsoft e-mail products. The directory also included the name of an employee's manager, in case the person I e-mailed didn't reply to my queries. But even with this electronic version of the company directory, I still had separate passwords for my computer and my network and e-mail accounts. With Windows NT, the security model was improved to the point where users' network accounts validated them to access both computer and network resources, but there were still separate accounts—one for the network and one for the e-mail system.

In addition, as in any company, the human resources department had large databases that stored details about each employee's salary, sick leave, performance reports, and benefit programs. So while I only needed to enter my network account information to log on and read e-mail, I had to provide a separate password to access information about my health care plan or to find out how many vacation days I had accrued. Even though Exchange provided simple hierarchical information about employees and their managers, this information couldn't be used for the official company organization chart or other purposes, usually because some necessary data was not included in the e-mail directory. Relying on the information in the e-mail directory also assumed that each employee had an e-mail account; not a problem at Microsoft, where everyone had an e-mail account, but certainly an issue for many companies at the time.

Another hassle in those days was the simple task of printing a document. If you didn't have a printer connected directly to your computer, you had to use a network printer. Some network printers offered color and duplex printing and collating, but not all of them. I would wander the halls looking at the printers stashed away in the supply rooms, make a note of the type of printer and whether it had the option I needed, and scribble down the Universal Naming Convention (UNC) name of the printer (something similar to \\prnsrv05\hpoffjet). Then I'd run back to the office, put in the name of the printer, and hope everything worked well. It rarely did, of course, and the 150-page specification output in PostScript would result in 300 pages of unreadable gobbly-gook by a printer that didn't understand PostScript.

These examples illustrate the challenges faced by the end-user. Network administrators had an even tougher job. They managed hundreds of print and file servers and tried to fit some sort of description into an 8.3-character name. They were continually called upon to make even trivial changes to user's accounts. Developers of line-of-business applications such as a human resources benefit tracking system would have to create their own databases to hold user information. Of course, whenever employees left or joined the company, moved to a new location, or changed their name, dozens of databases and directories needed to be updated. The potential for error and security violations were huge, not to mention the labor costs of maintaining all that information.

One solution to such issues is a single enterprise directory. Instead of maintaining dozens of databases on employees, a single hierarchical directory centralizes the information. The directory is available for searching from each connection point on the network. Similar to how the paper directory was printed and distributed each month, a network directory can be replicated in a matter of minutes and distributed to servers at the farthest points of the network.

Microsoft didn't invent network directories, but they have advanced the state of the art with the introduction of Active Directory, the directory and set of services included in Microsoft Windows 2000 Server. Active Directory builds on years of experience with network computing and collaboration with Windows NT, Exchange Server, and other products. To better understand Active Directory, let's further describe directories and their use in distributed computing.