I just got back from a week-long Caribbean cruise. It was the first time in nearly 15 years of marriage that I went on a vacation with no computer. For the first day or two, it was tough, but I adapted quickly to not having access to email, the Internet, or voicemail, and to be honest, I spent no time whatsoever thinking about Exchange. Now that I'm back, though, I'm back to my normal work routine, and I learned something interesting that I wanted to share.
Exchange implements a permission called "View Information Store Status." I first came across it when working on the Exchange Server 2003 version of "Secure Messaging with Microsoft Exchange" ( http://www.e2ksecurity.com ), but I never could find a good explanation of what it is and what it does. Now, courtesy of the Microsoft article "Event ID 9646 is logged in the application event log of your Exchange Server 2003 computer when a client opens many MAPI sessions" (http://support.microsoft.com/?kbid=842022 ) and a little digging, I know what it's for.
Messaging API (MAPI) is the primary connection method used by Exchange clients, so you should see MAPI connections for each connected user. The number of open connections will vary according to the client software and what the user's doing at a given point in time. If you launch Microsoft Office Outlook 2003 and press the Ctrl key while you right-click its taskbar icon, you can use the Connection Status command to get a continuously updated view of all the connections in use at a time--and you'll probably see more than you expect. It's not uncommon to have five or more concurrent MAPI connections per Outlook user, which is one reason why the ExMon tool (http://www.windowsitpro.com/Windows/Article/ArticleID/46338/46338.html) is so useful.
Ordinarily, these multiple connections aren't a problem, but other MAPI client applications might open up too many connections. For example, some archival and backup products open MAPI sessions to retrieve messages and process them. In Exchange Server 2003 SP1, Microsoft started limiting each user to a maximum of 32 concurrent MAPI sessions. Most users never noticed this limit, but a few applications that were legitimately using more than 32 sessions broke; accordingly, Microsoft released the aforementioned knowledgebase article. The article talks about three ways to work around the error: Get a version of the application that doesn't use so many connections, increase the connection limit by applying the "Maximum Allowed Sessions Per User" registry key described in the article, or grant the View Information Store Status permission to the account in question.
This last workaround is what got me interested in the permission--after all, granting that permission to an account obviously exempts the account from the resource usage checks in SP1. I couldn't think of a good reason why you might want to do that; however, it appears that the permission allows an account to see the status of the Information Store (IS) and its subordinate objects even when the account doesn't have Exchange-specific permissions. This is obviously useful for programs such as the Microsoft Operations Manager (MOM) suite, but it turns out to be required even for Exchange System Manager (ESM)--if you deny "View Information Store Status" to an account that otherwise has valid Exchange permissions (say, Exchange Administrator), that account won't be able to see the list of mailboxes normally visible in ESM. The Microsoft article "XGEN: Exchange 2000 Role Permissions" ( http://support.microsoft.com/?kbid=289811 ) states that this permission is normally assigned as part of the Exchange Administrator, Exchange Full Administrator, and Exchange View-Only Administrator role grants; you probably shouldn't manually remove it unless you have a good reason to do so. (In fact, there's at least one MOM troubleshooting guide that tells you to put it back if you're having trouble with MOM resource monitoring of Exchange servers).
There's good news and bad news. The bad news is that there are still tons of semi-documented settings like this one in Exchange. As time passes, and we get more such settings, it's increasingly difficult to know about all of them. The good news is that the product team is getting better at documenting special-purpose settings like this one, but it takes time to do so.
