As I reported in May, the 1999 Microsoft Exchange Conference (MEC) will convene October 4-7, 1999, at the Georgia World Congress Center (GWCC) in Atlanta. The GWCC is a great venue, so I expect the logistical problems of MEC '98 to be a distant memory this year. See http://www.events.microsoft.com/ events/mec99 for registration information. For the first time, Microsoft will offer a European version of MEC on October 11-14 in Hamburg, Germany, and will repeat many of the sessions from Atlanta.
Why don't the changes I make to mailbox permissions take effect immediately?
In Exchange Server releases earlier than version 5.5, changes to mailbox permissions took effect immediately. Microsoft modified Exchange Server 5.5 to speed up mailbox access. With the pre-5.5 scheme, the Information Store (IS) had to look up permissions in the Directory Service (DS) and the domain SAM database every time a user attempted to access a mailbox. This process slowed mailbox access; therefore, the IS in Exchange Server 5.5 caches permissions for 2 hours after it retrieves them from the DS. This caching eliminates the need to contact a domain controller and look up the account credentials, but it causes the wait you've noticed.
To avoid the delay, add a new REG_DWORD entry called Mailbox Cache Age Limit to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIS\ ParametersSystem Registry key, then give the entry a value equal to the number of minutes you want to cache the account credentials for. Restart the IS. The value must be in hexadecimal notation; for example, to change the limit to 60 minutes instead of 120, you must enter a value of 3C.
Can I obtain by email the store.exe hotfix you mentioned last month?
No, you must call Microsoft's Product Support Services (PSS) group for the hotfix; Microsoft won't send it by email. Although you might be able to get a hotfix from someone else on the Internet, I generally advise against it for two reasons. First, Microsoft might not have thoroughly tested hotfixes on a wide range of configurations; therefore, Microsoft prefers to give hotfixes only to people who call in to report the same problem the hotfix solves. Second, different problems might cause identical symptoms, and often you need to call PSS to determine whether the hotfix will fix the problem in your situation.
What is the best way to change our Exchange Server organization's name?
If you're running Exchange Server 5.5 with Service Pack 2 (SP2), Microsoft's Move Server Wizard is the best way to change an Exchange Server organization's name. As Tony Redmond's Windows NT Magazine article "How to Rebuild Your Exchange Organization" (January 1999) points out, the Move Server Wizard can move a server into an existing or new organization. For example, the wizard could move a server from Tele-Communications Inc. (TCI) into the AT&T organization (when those two companies merge), or it could move servers from Chrysler and Daimler-Benz into the new DaimlerChrysler organization.
The Open Relay Behaviour-modification System (ORBS) organization informed me by email that my company's Internet Mail Service (IMS) is an open relay. Is ORBS a legitimate organization?
ORBS is semilegitimate. The company's Web site (http://www.orbs.org) says ORBS's purpose is to keep a central registry of machines that act as open SMTP relays. An open relay is an SMTP server that lets anyone on the Internet connect to it and send email to anyone else on the Internet. Unscrupulous users who find open relays typically use them to blast out zillions of get-rich-quick letters, ads for porno sites, and other delicacies.
John R. Levine, author of The Internet For Dummies and a noted fighter of unsolicited commercial email (UCE), tells me that no backbones or major ISPs use the ORBS blacklist, because it blocks vast numbers of hosts that have never sent any UCE. ORBS doesn't block UCE sources; it lists computers that fail a simple mechanical relay test that's only distantly related to UCE relaying. Levine says the man in New Zealand who runs ORBS doesn't have evil intent, but the overall result is counterproductive. Levine believes the only responsibly run network blocking list is Paul Vixie's Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL) at http://maps.vix.com/rbl; MAPS uses a variety of tests to check for improper relaying and provides a realtime list of suspect systems that you can use as a filter.
You received the email from ORBS because someone entered your mail server's IP address into a Web form on the ORBS Web site. Your server might not have relayed UCE, but it's probably open for relay unless you've already relay-proofed it in a way that ORBS doesn't understand. Now that you're on the list, you'll stay on it until you've reconfigured your IMS not to be an open relay and you've notified ORBS through its Web site that you've fixed your relay.
Being on the ORBS list has few repercussions. However, some ISPs configure their servers to refuse traffic from servers on the ORBS list, which might make exchanging mail with other hosts on the Internet more difficult for you.
On the MSExchangeIS object in Performance Monitor, what do the Push Notifications Generated/sec and Push Notifications Skipped/sec counters measure?
A push notification is what the Exchange Server IS sends to a connected Messaging API (MAPI) client to let it know that new mail has arrived for one of its mailboxes. The Push Notifications Generated/sec counter measures the average number of push notifications the IS has generated every second. Because the IS can process several messages for one client concurrently, the IS caches push notifications for a short time. If the IS sees multiple notifications queued for one client, it skips all but one of them to avoid submerging clients in a tide of redundant notifications.
The Push Notifications Skipped/sec counter tells you how many notifications the IS skipped because they were redundant. Microsoft says these two counters should never have equal values; however, on a healthy server, the skipped notification counter can be a large fraction of the total number of notifications.
How can I find out how many inbound and outbound replication messages pass between my site and the sites I replicate with?
Microsoft added two new counters in a post-SP2 hotfix for Exchange Server 5.5: Incoming Inter-Site Replication Updates/sec and Outgoing Inter-Site Replication Messages/sec. When you use these counters on replication bridgehead servers, the counters count the number of incoming and outgoing messages exactly as you want. The catch is that you must upgrade your bridgeheads to SP2, get the hotfix with the new counters from Microsoft PSS, and follow the instructions in the Microsoft article "XADM: New Intersite Replication Counters Added" (http://support.microsoft.com/ support/kb/articles/q222/1/91.asp) to install the counters.
My company has several very large archive mailboxes, ranging in size from a few hundred megabytes to several gigabytes. When I use Microsoft Exchange Administrator to look at the Mailbox Resources view, why are the biggest mailboxes listed as 2GB, even though I know they're bigger?
The Exchange Server IS incorrectly reports that mailboxes larger than 2GB are actually 2GB. However, the total item count you see in Exchange Administrator is correct, and Outlook reports the right mailbox size. If this inaccuracy bothers you, contact PSS and get the hotfix described in the Microsoft article "XADM: Exchange Administrator Program Is Inaccurate When Mailbox Exceeds 2GB" (http://support.microsoft.com/support/ kb/articles/q224/1/74.asp). If you can live with the quirk, wait until the next Exchange Server 5.5 service pack provides a fix.
My company's fraud department asked for the ability to monitor certain mailboxes undetected. I made the fraud buster an alternate recipient; however, when someone sends a message with delivery receipt requested, the reply includes the alternate recipient's name. How can I prevent Exchange from identifying the monitor?
I can think of three ways to prevent Exchange from revealing this person.
- Designate the fraud buster as an alternate recipient, then have that person use a client (e.g., Netscape Messenger and Eudora Pro) that doesn't support delivery receipts or lets you suppress them.
- Give the fraud buster Mailbox Owner permissions on the suspect mailboxes, then have the person use the preview pane in Outlook (set so Outlook never marks messages as read).
- Use an automated scanning tool such as Content Technologies' MIMEsweeper to scan suspect mailboxes' traffic and store any suspicious items.
Where can I obtain step-by-step information about installing and setting up a Help desk system based on Microsoft's HelpDesk example code?
Microsoft provides some documentation with the example code; however, as the Web site clearly states, HelpDesk is just an example—it's not necessarily intended for use in a production environment. If you're looking for a comprehensive overview of how to create, use, and integrate Outlook forms with your Exchange server, look at Programming Microsoft Outlook and Microsoft Exchange by Microsoft's Thomas Rizzo. The book explains how to use Outlook and Exchange Server technologies, including forms and Exchange scripting, to build applications. The book also will help you understand how to build a Help desk application from Microsoft's example code. (For a more detailed review, see http://www.robichaux.net/writing/books.html.)
How do I use the Exchange Administrator's directory export tool to export the entire Global Address List (GAL)? I tried writing an export options file that specifies the home server and container, but the file exports only the contents of that container.
The following file looks as though it would export the container, but it yields only one container's worth of data:
\[Export\] HomeServer=HQ Container=Recipients Information=Full ExportObject=Mailbox
This file is syntactically correct, but it doesn't specify where to start exporting from. You must include two key export file options to get the entire GAL in your output file: the Basepoint and Subcontainer flags. Compare the previous file with this example, which includes the flags:
\[Export\] Basepoint=/o=ReallyBigCompany ExportObject=Mailbox Informationlevel=Full Subcontainers=yes
The Basepoint flag tells Exchange Administrator what to use as the base point for the export. By including your complete organization name and by using the Subcontainers flag to signify that you want the contents of all containers inside that organization, you can get the data you want.
A user somehow renamed his Inbox icon in his Outlook 97 mailbox on a Windows 95 platform, and I couldn't rename the icon back to Inbox. Microsoft suggests two ways to rename the Inbox: Run Outlook with the /resetfolders switch, or create a new profile and move all the old mail to it. However, these solutions didn't work. How did this problem come about?
The original Exchange Server 4.0 and 5.0 clients let users rename their folders—including the Inbox. The easiest solution is just to run that old client (exchng32.exe will do the trick) and rename the inbox. Then remove that executable from your user's machine so he or she won't do it again.
My company is juggling its server configuration, and I have to move some connectors from their existing home to a new server. What's the best way to do this?
You want to move a connector in a way that causes the least disruption to mail that has to flow over that connector. Exchange Server dynamically recalculates its routing rules when someone adds or removes connectors. You can take advantage of this behavior by changing the cost on the connectors to suit your needs with these steps.
- Create the new connector on the new server (and a corresponding one on the other end, if you're using a 2-way connector).
- Raise the cost of the old connector higher than the new one on both ends. This action will cause Exchange to prefer the new connector to the old one after you recalculate routing.
- Force Exchange to recalculate its routing table using the Recalculate Routing key on the General tab of the server's MTA Properties page. After Exchange has rebuilt its routing table, new messages will flow over the new connector instead of the old one.
- When no messages are in the queue for the old connector, delete the connector on both ends.
- Force Exchange to recalculate the routing table again to remove references to the old connector.
Thanks to reader Ed Crowley for suggesting this technique on the msexchange mailing list.
