This issue is nicely avoided in a Windows NT domain. "One account, one password" is the method for domain security - if a user can log on, they can get their mail (or rather, they aren't likely to be denied mail access due to password discrepancies). NT domain user accounts have only one network password for authentication, network browsing, email, etc. Occam's Razor dictates that we avoid the unnecessary complexity of the potential Linux solution for this.

Another concern is the fact that I have about a dozen users at a remote facility. Windows NT's domain model allows me to drop a Backup Domain Controller at this site. This will allow me to locate the users' home directories on this server, as well as allow this server to handle domain logon authentication; both of which help minimize WAN traffic across the connecting T-1 link.

Linux requires that I either set up NIS/NIS+, or duplicate the /etc/passwd file somehow in an effort to ensure that users from both facilities can log on from either and still access the network resources they need. Again, this is comparatively more complex than the Windows NT solution.

MESSAGING
I'd been running sendmail on my personal mail server for some time. It's complex, cumbersome, and sometimes just plain weird. Recently I replaced sendmail with Postfix, which is far easier to configure and supposedly less vulnerable. I have very little experience with Microsoft Exchange, so any messaging system I choose to implement will require a fair bit of effort on my part.

My first matter of business was to decide whether or not I wanted to be responsible for client email. Should it be backed up? If so, what makes the most sense - keeping all mail on the server, or configuring a backup system to include workstations? I'd rather have the workstations be fairly modular: all user data should be kept in their network home drive, so a desktop failure can be quickly remedied by dropping a spare machine on the user's desk. Local email presents a hurdle to this.

So I planned on configuring my client workstations to use IMAP. Again, a lot of research followed as I familiarized myself with IMAP. I'd previously only ever used POP3. Outlook 2000 doesn't support IMAP, but Outlook Express does. So I began fiddling around. It was about this time that the password issues discussed above began to surface. It then came to my attention that Outlook Express was caching the IMAP folders and messages locally on the workstation. While this wasn't an issue in regards to my backup strategy, it did present some security concerns. If one user were to use someone else's desktop just to check their email (not an unlikely thing to happen at all), the possibility exists that an enterprising (and malicious) individual could read their email from the locally cached copy of the IMAP information.

I haven't found any evidence that Outlook 2000 caches the information stored on an Exchange server (as long as you're _not_ using personal folders). So again, Microsoft comes out on top.

Exchange also provides me with Public Folder support. This allows me to easily store (and make available) departmental communications, memos, etc. I'm sure this same functionality is available from a Linux solution, but I'm not aware of it; nor am I aware of whether or not it is compatible with Outlook 2000 as the client component.

SUMMARY
I had quite hoped that I would be able to implement a Linux solution for our information technology needs. Linux has a lot of things going for it: stability, customization, low-cost. It's more secure, and requires less hardware to function. I will almost certainly have a Linux box in my office, to run an internal web server, use nmap, and generally just fiddle.

I've been detailing why Microsoft Windows NT is earning my business. But I have many complaints against it. I don't _want_ to have an internet browser> installing NT.

I don't like the security vulnerabilities in NT. I don't like how inflexible it is in regards to its function. I don't like having to navigate what feels like countless nested windows in order to close down my open TCP and UDP ports, only to be told that I need to reboot. I don't like the Blue Screen of Death.

But the proof is in the pudding. We're not software developers, so development tools aren't important to us. We're not running an e-commerce site, so uptimes and internet security aren't key concerns. We have modest requirements, and Windows NT fulfills them quite well. Better, in fact, than Linux.

Linux is a great operating system, with a lot of power, and potential. I truly regret the fact that I am not more skilled in it. But I don't regret using a tried and true network operating system that will fulfill my needs, and the needs of my users.