Subscribe to Windows IT Pro
October 01, 1996 12:00 AM

Email for the Small Business

Windows IT Pro
InstantDoc ID #2774
Rating: (0)
Avoid pitfalls in Windows NT and Windows 95

In the real world, few people run Windows NT alone. With it, they run Macintoshes, DOS, Windows 3.x, UNIX, and others, and need for these operating systems to communicate with each other. Nowhere is that fact so evident as in small businesses, which often have PCs running three or four versions of Windows (3.1, Workgroups, 95, and NT) and don't have the money or management talents to standardize. Such a business can have NT on its server and one or more NT workstations or on a single workstation that doubles as a server.

Pity such a shop's poor systems administrator who's learning NT between getting the everyday job done and dealing with screaming users. They want email so they can communicate with each other and with the outside world. And the boss doesn't want to spend any money.

So what can the harried systems administrator do? With nothing but what Microsoft provides, you and your users can communicate inside your mixed network. This substitute may not work as well as the expensive spread, but what you have may be good enough. Just be aware of potential problems.

Free Internal Email
Ahh, email. How did we live without it? Well, most people don't live without it. People often have two or three personal addresses through America Online (AOL), CompuServe, and a local Internet Service Provider (ISP).

Email provides an inexpensive, fast, and efficient way to conduct business. However, many small companies don't have internal email or a corporate Internet connection.

Internal email is a good first step toward connecting small companies to the Internet. NT 3.51 comes with a mail system, MSMAIL32, that is functionally identical to the mail client in Windows 3.11. Be warned: MSMAIL32 is cantankerous, crotchety, and high maintenance. It's not well documented, either online or in the big Administering NT books. MSMAIL32 is not secure: The data files live in a shared directory that anyone can mess with. (MSMAIL32 does offer simple encryption, but no protection against someone, say, deleting all the mail files.) But the price is right, and as a step toward getting your company on the Net, MSMAIL32 can do the job.

Setting up MSMAIL in NT 3.51 isn't hard, but you'll run into enough pitfalls that working through the prescribed steps is worthwhile. The first step is to log in to your NT server and find MSMAIL; by default, it's in the Main group. Run the MSMAIL program, and create your post office on a machine that remains on your server, for example. Put the post office in a directory you plan to share, a top-level directory (e.g., d:\wgpo) to avoid confusion. Then use the Administration function to create accounts that include the names of the users, their account names, and their passwords. Nope. Sorry. You can't copy accounts from the NT user list; you have to administer mail accounts separately. (In such management matters, NetWare Directory Services--NDS--still has it all over NT: NDS allows centralized management of most network functions, which saves time, and has only one tree of usernames, which NDS-savvy programs such as GroupWise can access.)

Be careful when you choose passwords. MSMAIL's rules are different from NT's. MSMAIL considers characters such as apostrophes illegal in passwords, but these characters are fine in NT passwords. This difference means that MSMAIL's administrator will let you type won'ttell as a password but will silently throw out the apostrophe. Then when you try to enter the password you typed, instead of ignoring the apostrophe, MSMAIL will reject it. And because you can't see what a password is--only type in a new one--you end up starting over in frustration. This misfeature perplexed me for an hour.

This password caveat goes double for the administrator's password. You have to be utterly sure you keep it in mind or on paper--as with NT, an MSMAIL password appears as asterisks. If you forget it, you can't retrieve it--yep, I forgot the admin password. Worse, MSMAIL gives you no easy way to nuke the existing post office directory and start over. I'm not sure where the pointer to the directory lives, and I can't find anybody who knows. It's not in an .ini file, and it doesn't seem to be in the Registry. I finally started over by deleting everything that seemed connected to MSMAIL and restarting the computer.

Related Content:

ARTICLE TOOLS

Comments
  • Dan Nelson
    13 years ago
    Aug 12, 1999

    I just finished Alex Pournelle’s October 1996 column, “Email for the Small Business.” It is slanted, biased, and flawed. After working with NT, Microsoft Mail and Exchange for more than three years, I can address some items he mentioned.

    I agree that little MS Mail documentation comes with NT, but you need only two resources: TechNet and Microsoft Windows NT Resource Kit for NT 3.51. TechNet articles describe the mail system’s architecture and troubleshooting steps. The NT Resource Kit devotes Chapter 8 (Volume 1: Windows NT Resource Guide) to the use of Mail with NT.

    MS Mail’s security certainly is not C2 like NT’s. Unfortunately, only so much security can be built into a shared file system. You can, however, implement some security with MS Mail. Instead of simply stating it has none, why not offer the readers the option of sharing the postoffice (PO) directory by appending a dollar sign (e.g., WGPO$) to the filename. This step prevents the share point from appearing in any browse list. Users can then configure the clients with a universal naming convention (UNC) path for Serverpath= in the msmail.ini or Registry (depending on the OS). No permanent drive mapping is necessary. What users can’t see, they can’t delete. This capability is further enhanced in the FPP with the addition of a utility that will encrypt the path to the PO in a file, so it will be unreadable to the user.

    Pournelle mentions that there is no way to create accounts from the NT User Accounts Database. Although that statement is true, he needs to point out that if the network administrator upgrades, the full packaged product (FPP) will not only allow import from the NT User Account Database, but also from a NetWare bindery.

    Pournelle then begins to sell NetWare and NetWare Directory Services (NDS) because of its centralized management. NDS does offer many advantages compared to NT’s administration capabilities and domain model, but finger pointing is off target. Exchange Server provides this integration with network logon. Because Exchange relies on NT’s built-in security, the user’s password allows access to the network and the mailbox. In addition, through an extension that Exchange Server installs to User Manager, the creation and deletion of mailboxes is linked to the action taken on the user’s NT account. Note that this process also works in reverse with the Exchange Administrator program. Because of MS Mail’s older architecture, this capability was not a programmable option. I don’t believe NDS was available in the late 1980s and wasn’t well developed until 1995.

    The postoffice pointer is in the Registry under HKEY_CURRENT_USER\\SoftwareMicrosoft\\Mail\\Microsoft Mail. ServerPath : REG_SZ : C:\\WGPO. Because each user can create a PO, the option is stored under each user’s Security ID (SID) rather than HKEY_LOCAL_MACHINE. The only difference between connecting to an existing PO and creating a new one is the ability to run Postoffice Manager.

    As for removing the WGPO, the process is published in Microsoft’s Knowledge Base as Q104021. You just have to delete the directory from the hard disk and the reference in the Registry noted in the previous paragraph. You can find this article on the Web at http://www.microsoft.com/
    kb/articles/q104/0/21.htm.

    Yes, the client gives the option of an offline address book (OAB), but it can use the global address list (GAL) on the server. The client gives you an OAB to use when you can’t connect to the server; this offering is a bonus, not a drawback. Some of us need this functionality. In fact, I’m taking full advantage of it right now on a flight from Houston to Boston. As a side note, the file downloaded for the OAB is the same as that for the MS Mail Remote client, rnetwork.glb. Care to complain about that client, too?

    Pournelle next comments on the fact that the client must poll the server to check for new messages rather than using a remote procedure call (RPC) from server to client when new mail arrives, as in Exchange Server. It’s the Microsoft Mail information service within the client that has this limitation. This service acts the same as the MS Mail client does. How can a passive shared file system contact an active client? Again, it all goes back to the architecture.

    I’m sorry Pournelle doesn’t like the interface of the Windows Messaging (WM)/Exchange clients, but he may be happy to know that Outlook (in Office 97) has a completely different UI.

    Pournelle seems to expect features that are not possible with MS Mail’s architecture. Rather than complain that they don’t exist, he could help the readers to understand what the environment does provide, explain workarounds, and inform about alternatives that are strong in the areas where MS Mail is weak.

    Please share this information with readers. The magazine is one of the best I’ve read, and I hate to see it damaged by articles like this one.

    --Dan Nelson, MCSE, MCT, CNE

    NT/Exchange Consultant



    Thank you very much for your informative and helpful corrections. We’re always grateful when readers keep us on our toes!

    --Karen Forster

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.