My company uses WINS to attach clients to its Microsoft Exchange servers. Exchange Server is the only application for which we use WINS. Can we convert to DNS instead?
You can convert to DNS, but you must heed some important considerations. Above all, your DNS implementation must be functional—a hurdle that is often difficult to surmount. If you're using a DNS authority at an ISP, the DNS authority might not have your Exchange server listings. You need to ensure that the DNS authority correctly lists the servers. Also, to start the delivery chain that lets DNS find your Exchange server, at least one pointing address external to your network must exist. The Exchange Server DNS address is typically located at the nearest ISP DNS server.
As a process, DNS isn't intensive in a local network server, except in large installations (e.g., more than 500 active Internet users). You can add DNS to an Exchange server, but I prefer to put the DNS service into the PDC when possible—and run nothing else on that server. Some organizations also forget to update LAN or WAN DNS listings. The DNS authority must correctly list Exchange servers, unless you want users to remember IP addresses.
As a last resort, you can have a HOSTS file on each machine—an alternative that requires a massive update cycle. Remote users, vacationers, and other users who can't get an automatically distributed update also complicate this solution. To work around the HOSTS file's file-synchronization problems, you can send email messages with Windows Scripting Host (WSH) batches to update users' HOSTS file. Scripting tools such as WinBatch can also perform the distribution job.
I have two Exchange Server sites that a Site Connector and an ISDN connection link. Occasionally, enormous activity between the sites seems to cause delivery failures. Any suggestions?
Although many administrators fear the X.400 connector because they don't understand it, it's often a better choice as a site connector through a VPN or a direct-connect full-time link. When bandwidth is plentiful and latency isn't a problem, the X.400 has several advantages, not least of which is that you can limit message size without using the Message Transfer Agent (MTA). If you limit message size at the MTA or store level, you do so for all messages. An increasing headache is fat messages on large distribution lists (DLs)—remember the dancing-baby AVI file? These messages clog email servers to a point at which some administrators dub the messages Denial of Service (DoS) bombs.
The Site Connector pipe can't usefully limit message size. By contrast, the X.400 connector can limit message size and be as invisible as the Site Connector method for users at the remote site. The X.400 can also connect to non-Exchange Server email systems, such as those based on older, host-based mail systems.
Another advantage is that you can use selectable, scheduled delivery-time options, including remote initiation (i.e., nothing happens until a remote host initiates contact). The X.400 method isn't only less restrictive in options but more flexible in administrative control.
You can also use the Internet Mail Service (IMS) as a site connector. The advantage to using the IMS is that Microsoft Exchange 2000 Server (formerly code-named Platinum) will use the IMS connector primarily for intrasite communication. Getting the IMS in place now is a good head start.
My company's Asian subsidiaries complain that Unicode email displays nonsense when they use Outlook Web Access (OWA). When they're in the office, everything is fine, but when they access mail through an ISP and OWA, the message is gibberish. What's going on?
A strange thing happens on an Exchange server if you've installed OWA with IIS 3.x. If you install the Microsoft Internet Explorer (IE) 4.0 browser after you install Exchange Server, the IE 4.0 installation routine destroys the server's MIME Registry database. As a result, Unicode, double-byte, and international MIME viewing or attachment reassembly doesn't work. However, direct access is undisturbed. Fortunately, you can easily restore the settings. Insert the Exchange Server CD-ROM, copy the \server\support\mimedb\reset.inf file to a temporary directory, then right-click the file and choose Install. This procedure immediately restores the correct settings to IIS and OWA (i.e., without requiring a reboot or service restart). OWA suddenly works again. Unfortunately, this fix doesn't work with a post-Exchange Server IE 5.0 installation.
My company has approximately 400 employees actively using Exchange Server 5.5. As the number of users increases, we experience slowdowns in message delivery and overall responsiveness. What can we do at the platform level to keep mail flowing without spending too much money?
Several factors have a direct bearing on responsiveness, and a few of these factors have an indirect bearing on mail delivery. The factors are network speed, platform optimization, user access speed and client type, and hardware infrastructure.
The application that you might turn to for help—the Microsoft Exchange Performance Optimizer—has a limited effect on performance. You probably need to use it only when you change platform hardware, the location of message stores, or the Exchange server's role in the site. Running Performance Optimizer is free and causes no harm, but its tuning features are minimal.
Of course, a fast server that is well connected with a fast link is your best start. Exchange Server needs ample memory. I recommend a minimum of 128MB, but your server will perform more effectively at 256MB, if you can afford it. Server performance can also depend on the speed of your disk subsystem. Although many smaller servers come with the ATA or UltraATA disk interface, neither interface works as well as any of the new breed of advanced PCI bus-based SCSI controllers, such as Adaptec's Ultra160 interfaces, or caching controllers from Mylex (now an IBM division). Coupled to a fast drive, these controllers can increase throughput dramatically. However, these controllers also require you to add a UPS to the Exchange Server machine because they might have a few milliseconds of uncommitted cache life that dies on powerdown. The majority of midrange and high-end controllers on the market have some sort of cache protection, but you're better safe than sorry.
Another potential solution might be more expensive. If your network is an older 10Base-T Ethernet, consider adding another Ethernet card into the server and using load-balancing software (e.g., third-party solutions, Microsoft's free Windows NT Load Balancing Service—WLBS) to plug the server into an Ethernet Switch cloud. Organizations that frequently access public folders containing documents or graphics files can add extra capacity to an Exchange server by adding a network card (to a practical maximum of four cards). In such an organization, additional network channels can create higher throughput rates. See a network specialist for recommended designs. Converting to 100Base-T Ethernet can also increase performance but requires a forklift upgrade.
Because mail is an I/O activity, the Exchange server's CPU speed doesn't have a huge bearing on performance. Increased disk performance, memory, and network connectivity produce the most dramatic performance improvements. A balanced configuration is more important than a fast CPU. If you can't get data to the CPU, the processor will spin idly while messages queue to the databases and transaction logs.
