I'm trying to set up a Post Office Protocol 3 (POP3) client to see the company Global Address List (GAL). However, I can't make it work, even when I dial in with Remote Access Service (RAS) and copy the address from an Exchange client. What's the problem?
The root of your problem is that all addresses aren't created equal. Standard addresses (not custom recipients) in the GAL use Exchange Server's internal format, which non-Messaging API (non-MAPI) clients can't handle. When you copy an Exchange Server address and paste it into a POP3 or Internet Message Access Protocol (IMAP) client, all you get is the display name. (For my address, you'd get Paul Robichaux instead of firstname.lastname@example.org; mail sent to the former would bounce.)
You can try several solutions. One solution is to use a POP3 client that supports Lightweight Directory Access Protocol (LDAP) and enable LDAP on your Exchange servers. That way, your POP3 users can see the GAL, albeit not in the format they expect. Another approach is to let your users use Outlook Web Access (OWA) as a mail client. A third option is to use Address Magic, a new utility from Connected Software (http://www.empire.net/~level/AddressMagic.html). Address Magic lets you convert Simple Mail Transfer Protocol (SMTP) addresses in the GAL into different formats that POP3 clients can use.
A fourth route is more work, but is invaluable when you can't change client software. Use Microsoft Exchange Administrator's File, Directory Export command to export the contents of the GAL, and then write a short Visual Basic Script (VBScript) or Perl script to convert the GAL into a format that your POP3 clients can read or import. Sue Mosher explains this method in detail in "Outlook Tips and Techniques," page 7.
One of my users lost the password to a password-protected .pst file. How can I remove the password?
The official Microsoft answer is succinct: Microsoft doesn't support any method of removing, changing, or cracking a .pst file's password. That statement doesn't mean you can't do it, just that Microsoft understandably doesn't want to get involved with the messy legal overhead of deciding whose personal folders it will help open (although I understand that Microsoft responds to requests from law enforcement agencies).
The unofficial solution is to use the pst19upg.exe utility, which is on the TechNet CD-ROMs and available from a variety of online sources (try doing a Web search and you'll see what I mean). This utility strips the existing password from a .pst file, effectively removing password protection. This tactic works because .pst files use passwords only for access control—the passwords aren't encrypted to protect confidentiality.
My company recently upgraded its Exchange Server 5.5 servers from the Standard Edition to the Enterprise Edition, but I still can't create X.400 connectors. Doesn't the Enterprise package include that capability?
Exchange Server Enterprise Edition includes the X.400 connector. However, because the Standard Edition doesn't include the connector, when you upgrade a Standard server, the setup tool doesn't install the X.400 connector; you have to add it manually. To do so, run Setup from your Enterprise Edition CD-ROM, and choose Complete/Custom as the installation type. When you get to the options list, select Microsoft Exchange Server, click Options, and select the X.400 connector from the list. Turn off all the other options, and Setup will install the X.400 connector alone. Now, you'll see the X.400 connector in Exchange Administrator.
I used the Move Server Wizard to move one of my servers, but now users on that server can't see the Offline Address Book (OAB) anymore. What happened?
When you move a server, Exchange Server might not automatically regenerate the OAB and Address Book Views (ABVs) to reflect the changes made to the server, site, and organization objects in the directory. The cure is simple: After Exchange Server has completed replicating directories in the server's new site, force Exchange Server to rebuild the OABs. To do this, open the DS Site Configuration Properties dialog box, switch to the Offline Address Book tab, and select a server name from the Offline Address Book server drop-down menu. Click Generate All, and Exchange Server will regenerate the OAB and ABVs. When the process completes, your users will have OAB access again.
After I used Exchange Administrator to grant some accounts Search permission on the GAL, none of the other accounts could see items in the GAL. What did I do wrong?
When I was in college, Gus Baird—a legend among Georgia Tech students—taught us the Principle of Least Astonishment: When you're writing software and you have to provide some default action or behavior, make the action do whatever will surprise the user the least. Exchange Server violates this principle, because assigning Search permission to one account does the opposite of what you'd expect. When you assign Search permission on an object to an account, you remove Search permission for everyone else.
Microsoft designed Exchange Server 5.5 that way intentionally, because with that release, Exchange Server included access control with the Search permission. In at least one case, this feature stopped a hacker, who accidentally exposed his presence by granting himself Search permission. As a result, all other accounts were unable to see the GAL. When users complained, the administrator got suspicious, started checking the event logs, and found evidence of the break-in.
If you want to restrict user access to the GAL, you can assign Search permission to only certain accounts. You can also use this capability to set up multiple departments or organizations that share an Exchange server but can't see each others' GALs. The Microsoft article "XADM: How to Setup Container Level Search Control" (http://support.microsoft.com/support/kb/ articles/q182/9/02.asp) describes in detail how to set up this configuration. If you assign the Search permission and your GAL breaks, remove the permission you assigned, and everything will return to normal.
I want to monitor client connections to the directory. Performance Monitor shows me how many clients are connecting, but how do I see which users connect and when?
Once again, diagnostic logging comes to the rescue. You can turn on diagnostic logging on the Directory Service (DS) to see who connects to it and when. Use Exchange Administrator to find the server you want to start logging connections on, select the Directory object, open its properties page, and go to the Diagnostic Logging tab. Then, turn the logging level for MAPI Interface to maximum.
With this setting, Exchange Server logs events from the MSExchangeDS source that have a category of MAPI Interface. The two most common events are 1136 (which signals that a user attempted a bind) and 1170 (which denotes a successful connection). The User column in Event Viewer tells you which account made the connection attempt. Maximum diagnostic logging can fill your event log quickly, so don't turn it on unless you really need it.
What RAID chunk size do you recommend for Exchange Server?
First, let's define chunk size. When you build a striped RAID array, the chunk size governs how the controller distributes data across disks. For example, a 64KB chunk size means that the controller can place any write request for a chunk of data smaller than 64KB on one disk; the system breaks up larger amounts of data into smaller chunks and stores them across multiple disks. If you pick a chunk size that's too small, you'll end up with lots of split I/O requests. Split I/O requests are undesirable, because when you distribute one write across multiple disks, the controller has to wait for the slowest disk to finish before it can complete the request. If you pick a chunk size that's too large, you'll waste space and time, reducing the benefit of having a RAID array.
The sweet spot for chunk size seems to be 10 to 20 times the average I/O request size. Exchange Server always does database I/O to and from the Information Store (IS) and the DS in 4KB chunks, so a 40KB to 80KB chunk size is about right. Most manufacturers configure RAID controllers with a chunk size in this range (64KB is the most common), but if the manufacturer has set your controller to another size, you might consider using the vendor's configuration utility to change it.
I installed Exchange Server 5.5 Service Pack 1 (SP1). I want to enable custom message filtering to help filter out unsolicited commercial email (UCE). However, I can't find the Message Filtering option mentioned in the SP1 release notes. Why can't I see this option?
When you install SP1 on your server, you get several capabilities, including Message Filtering. However, if you're following the good practice of running Exchange Administrator on an administrative workstation, you won't see the SP1 changes, because the workstation contains all the original Exchange Server 5.5 Exchange Administrator code. You need to use the SP1 CD-ROM to upgrade your administrative workstation, so that the code knows about SP1's new features.
I created a new replica of a public folder. The replica appears in the hierarchy, but the replica has no data in it. What's happening?
This behavior occurs by design. Every item in the directory has a replication priority. Exchange Server replicates high-priority items first. The public folder hierarchy has a higher priority than that of the folders and contents to ensure that Exchange Server always propagates changes to the hierarchy (e.g., new or deleted folders) before changes to the data in those folders. However, that design leads to the problem you noticed—folders show up, but they're empty. This problem is most common if you have large folders or a slow replication link. You have to wait for replication to finish for your folder contents to be available.