Understanding Exoledb default folders
EXOLEDB creates a number of system folders under the NON_IPM_SUBTREE during the Accept Clients phase of MDB initialization. Some of the folders remain for historic reasons, but most have real purposes and impact on the server should they be deleted. None of these folders should ever be replicated. The folders that are created are: \NON_IPM_SUBTREE\schema-root\ \NON_IPM_SUBTREE\schema-root\Default \NON_IPM_SUBTREE\schema-root\Microsoft\ \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1 \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views \NON_IPM_SUBTREE\StoreEvents\ \NON_IPM_SUBTREE\StoreEvents\GlobalEvents \NON_IPM_SUBTREE\StoreEvents\Internal \NON_IPM_SUBTREE\OWAScratchPad In all cases, Subfolders named with the GUID correspond to the MDB object with the same guid. The first folders created are the Schema folders: Schema-Root \NON_IPM_SUBTREE\schema-root\ - introduced in Exchange 2000 RTM. \NON_IPM_SUBTREE\schema-root\Default - introduced in Exchange 2000 SP1 \NON_IPM_SUBTREE\schema-root\Microsoft\ - introduced in Exchange 2000 SP1 \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1 - introduced in Exchange 2000 SP1 The typical schema path for a public mdb looks like: File://.BackOfficeStorage/<domain>/<TLHName>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1 The private MDB schema path is under the system attendant mailbox. EXOLEDB supports multiple schemas, or property type definitions. This was part of support for the "never fully implemented" exchange web store development platform. The idea was that Folder items could reference various versions of the schema and live happily alongside of each other. At one point (Exchange 2000 RTM) schema files lived in the schema root folder, and changes to the schema effectively propagated to all items. This lead to problems in the application development workspace where each item needed to be touched to remove or add props as appropriate, so we adopted a versioning method. Under schemaroot, we create subfolders with application and version elements to allow effectively seamless upgrades. EXOLEDB watches the schema folders for changes so that it can propagate the entries, dump the schema cache, and repopulate on the fly. The \schemaroot\default folder is where normal folder items pull their schema from, and the schema root folder is flagged as pointing to the ExchangeV1 folder. EXOLEDB populates the schema entries from the .xml files, which are processed by an event sink - EXSCHEMA.EXE. The schema event sink binding cannot be deleted or removed, as it does not have an entry in the EventBindings folder like most events. EXCHWEB, Views, IMG, Controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views Introduced in Exchange 2000 SP1, no longer populated in Exchange 2000 Post SP3 hotfixes and Exchange 2003. For the Local Store to open items that referenced OWA control functionality the files had to be in a sync-able folder. These folders once contained copies of the web data for OWA to allow LIS stored items to open, but have never actually been used outside of LIS. Next, EXOLEDB starts the event binding system, which creates StoreEvents All store event folders have been present since Exchange 2000 RTM. \NON_IPM_SUBTREE\StoreEvents\ \NON_IPM_SUBTREE\StoreEvents\GlobalEvents \NON_IPM_SUBTREE\StoreEvents\Internal This is the event binding folder, where EXOLEDB stores information on events build to a given MDB. At startup EXOLEDB must enumerate the events here, which can lead to long store startup times with large event sink numbers. Titanium performance in this area is greatly improved, but time to mount an MDB is still affected by number of rows. Each binding is validated for class, having a valid event method (onsave, ontimer, ect), valid clsid, and sink parameters. Events with a match class of ANY can only be registered in the GlobalEvents subfolder. After creating the Schema folders and starting the event bindings system, EXOLEDB creates the OWA scratch pad OWAScratchPad \NON_IPM_SUBTREE\OWAScratchPad - Introduced in Exchange 2000 SP1 Posts have to start out somewhere in order to have attachments, and for public store logons, that place is the OWA scratch pad. Because DAV doesn’t do cross mdb operations, we need a point on every mailbox where we can always write posts to, so that we can support adding attachments. The Posts are "Staged" in the OWAScratchPad until all attachments are added (or they are saved). The size limit on the OWA scratch pad controls the size of attachments that can be added via OWA. Attempts to post larger messages should result in an error: "This item exceeds the maximum size defined for this folder and cannot be saved. Contact your administrator to have the folder limits increased." The size of OWAScratchPad is always reset to 1mb at EXOLEDB initialization if the registry key "HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA", a REG_DWORD value "Message Size Limit" is not set. This is required for Sharepoint, because EXOLEDB has no idea of we are running in magma mode or not. OWA posts to the scratch pad are done in flat url format, meaning they directly reference the folder and message. This is to support deep vroots where the friendly URL might be too long. What causes duplicate system folders? This question really falls into two categories. AD Objects -Because when a store is deleted (disaster recovery & friends) we have no way to tell the AD the PF objects went away, then when folders are re-created they do not get "attached" to the corresponding DS objects. New ones are created. Actual Folders - If the folders are set to replicate, and the store in question is deleted, EXOLEDB will recreate the folders on startup, and replication can then create a second, duplicate of any such folders. This wreaks havoc with event bindings. Deleting said folder via friendly URL is dangerous, as the two will often have duplicate friendly URLs.. Why do they get strange names? When the number of system folders with the same number grows, we append a random number to the DS proxy to make it unique, resulting in names like "controls12345678". Why can I not delete them? First off, if you were to delete the folders, EXOLEDB would put them back. Secondly, most of these folders have real uses that will adversely affect the operation of the server if not present. - Jason NelsonSo how does this Deferred Delivery thing work?
There are actually 2 different types of delayed message delivery... I believe stemming form the quaintness of X400. The following applies to Exchange2000/Exchange2003. They have somewhat different behaviors, but both result in getting the message delivered to the intended recipients at some time after the specified time. The first type is delayed send. This is the typical functionality you see when using Outlook to send email. This functionality is controlled by the MAPI property PR_DEFERRED_SEND_TIME. When this property is set, the the message is kept in the MSExchangeIS SendQ. To end users, this means that their messages are visible in their Outbox. They can still double-click on them to open them, and will need to click "Send" for them to resubmitted for delivery. For an administrator, they will need to log into the users mailbox to see the message in that users Outbox. Unless the mailbox is deleted and purged The second type is deferred delivery (controlled by the MAPI property PR_DEFERRED_DELIVERY_TIME). The key difference is that the delay happens on the "delivery" side once transport "owns" the message. While the phrase "deferred delivery" might make you think that message is held on the destination server, it is in fact held in the queues on the source server. From the end-users perspective, the message immediately disappears from their mailbox and they cannot modify it if something occurs to them later. This is somewhat moot, as the past several versions of Outlook do not use this feature. For the email administrator, the message is queued up in the MDB temp tables along with all of the other mail. In Exchange2003, these messages are also exposed through the queues node of the Exchange System Manager. Deleting and purging the mailbox have no effect on these messages, but deleting the MDB they are queued on will make the messages disappear. - Michael SwaffordRemoving Reply All Functionality for Outlook Users in Reply-All Storms, via Group Policy
Just recently I was speaking to a Microsoft Premier Field Engineer (PFE) who had just returned home from a rather arduous onsite dispatch. While onsite he was tasked with unwinding a phenomenon commonly referred to as a "Reply-All" storm (defined below). This task had been so tedious that he half-jokingly mentioned that he was thinking about submitting a formal Design Change Request to the Exchange/Outlook Product Groups with a proposal to remove Reply-All functionality from within Outlook. Well this got me thinking... "could the removal of Reply-All functionality actually be done with the tools at an Administrator's immediate disposal today"? Eventually curiosity got the best of me and I started performing some basic research on the issue. Throughout the course of this research I found a jumbled set of different articles and blog posts that appeared rather half baked in scope to me. That being said, what did become abundantly clear was that there were a significant number of administrators (as well as standard users) who have expressed interest in this functionality and have actually been looking for it for some time. Presto: Blog idea. To be clear there are a number of different approaches for achieving the goal of disabling Reply-All in Outlook. The most common technique would appear to be the creation and deployment of custom Outlook toolbars. Far more infrequent are macros in Outlook as well as custom Group Policy Objects (the primary topic of this post). Additionally, while future versions of Exchange will include features to deal with this problem much better (read about Exchange 2010 Conversation View here) - I wanted something that people can use now, with versions of software they currently have. As previously noted, this post is going to focus on the use and deployment of a custom Group Policy to disable the Reply-All functionality in Outlook. This post will not focus on disabling Reply-All in OWA (which would require modifications to the ASP Pages) and will also not cover disabling this functionality in Windows/Outlook Mobile. My hope is that you will find this post interesting; that it helps clear up some of the confusion on the subject; and that you learn some new skills along the way. Should and when you choose to deploy a scenario like this, I hope this document serves to aid you in increasing the stability of your messaging environments and networks as a whole. As you will soon see, this post has a little bit of everything, Exchange, Active Directory, Group Policies, Outlook and even some "old/new school" VBA. I hope you enjoy it and learn something new in the process! Back Story: Nearly every user within a corporate messaging environment has at one time or another been the unfortunate chance victim of a "Reply-All Storm". It starts out innocently enough: Typically a formal communication it sent out to a large internal distribution list. A member of the distribution list strays off course or asks to be "taken off the distribution list". A series of people start replying "ME TOO" via a Reply-All. Another member of the list, "Replies All" to the request, and asks everyone to "PLEASE DO NOT REPLY ALL !!!!@!!@!!!". Cycle perpetuates itself over and over. Users come into the office and notice literally hundreds of emails all with the same subject sitting in their inbox. They read the most recent thread, whisper to themselves (geez...not this again), then proceed to delete the entire thread and possibly miss the actual intention of why the original mail was sent out in the first place. Not only is this extremely annoying, but obviously has larger corporate and financial implications as well: Loss of productivity for client base. Potential service interruptions for a variety of different reasons. Storage implications on the Exchange Back-End. Puts unnecessary strain on Exchange, Active Directory and network links. A host of Administrative implications ranging from increased backup times, etc. Loss of credibility (if say an external contact was a member of the list or even your immediate manager or "higher ups", etc.) Upon first read this may seem funny but it is actually a very serious problem. For a blow by blow of the infamous "BEDLAM DL3" issue that occurred internally here at Microsoft several years ago I suggest a review of the following post: http://msexchangeteam.com/archive/2004/04/08/109626.aspx. The issue is definitely real and varying degrees of the problem are most likely occurring somewhere in the world at this very second. Before Getting Started: I want to stress that the steps outlined below are not going to resolve an immediate Reply-All storm. However, it is very possible that they may help reduce or mitigate a future problem from occurring once your user base learns (either by word of mouth or "the hard way") that there are potential consequences for perpetuating one. Again, I'm talking about helping to bring about positive educational change in your user base over time. The steps outlined below will effectively remove a user's ability to use the Reply-All functionality in Outlook via creation and deployment of a custom Group Policy Object (GPO). The examples presented below will target a dedicated Active Directory Organizational Unit. This OU will ultimately become the target for the deployment of the GPO as well as the container where user objects that have Reply-All removed will be homed in the Active Directory. That being said, the techniques presented here could be adapted to a broader environmental context based upon the discretion/desire of the administrator. Thus to perform the steps here you will need at your immediate disposal: Access to the Active Directory. The ability to create a dedicated Organizational Unit. The rights to move members of your user base to said Organizational Unit. The ability to modify and/or create a new custom GPO. The ability to link/deploy said GPO. Hypothetical Scenario and Steps: You come into the office and your immediate manager mentions that the messaging group has been tasked with removing Reply-All ability for all users who participated in a recent Reply-All storm that impacted a large internal distribution list. Upper management has made a decision to not implement bulk message restrictions to the Distribution List itself (e.g. limiting who can send or reply to messages on the DL), but to simply remove Reply-All ability for all users who played a part in perpetuating the storm. The removal of this functionality will be accomplished via deployment of a GPO as opposed to leveraging other potential options. Step-1: Obtain and review the most recent thread in the Reply-All sto rm and build a list of all individual user accounts that either caused or played a part in perpetuating the storm. Build a master list of these users and denote the current location of their user objects within the Active Directory. Once done, receive "buy-off" from management that these users can and will eventually be moved into a dedicated Organizational Unit that will have a GPO applied that prevents the Reply-All button from being active within Outlook. Step-2: Once you have obtained buy-off, build a new Organizational Unit with an obvious clear name. To do so, go into Active Directory Users and Computers, right-click a user container, then select New, Organizational Unit, then provide it with a clear name. In the examples to follow my OU will be titled: "Users who have Reply All Removed" Step-3: Move the users into the new" Users who have Reply All Removed" organizational unit via Active Directory Users and Computers (or your favorite LDAP tool) created in Step-2. Step-4: If not already available proceed to download the appropriate Office Administrative Template files. In my scenario all my users can be assumed to be using Outlook 2007 Service Pack 2. The template files can be downloaded here: http://www.microsoft.com/downloads/details.aspx?FamilyId=73d955c0-da87-4bc2-bbf6-260e700519a8&displaylang=en Legacy Office Administrative Template Files can be downloaded from Office Online. So if your client base is running Outlook 2003, go here: http://www.microsoft.com/office/orkarchive/2003ddl.htm Step-5: Extract the Administrative Template files by running AdminTemplates.exe. Once extracted you should have 3 folders created (ADM, ADMIN, and ADMX): Step-6: Build a new Group Policy that links users of the "Users who have Reply All Removed" organizational unit. To do so: In Active Directory Users and Computers get Properties of the "Users who have Reply All Removed" organizational unit. Select the Group Policy Tab. On the Group Policy Tab, select New and give the policy a clear and applicable name such as "Remove Reply-All Ability" Once named, select Edit. The Group Policy Editor (GPE) opens. Step-7: Add the Office/Outlook Administrative Templates In Group Policy Editor: Navigate to User Configuration\Administrative Templates. Right-Click Administrative Templates and select Add/Remove Templates. On the Add/Remove Templates page select: Add Browse to the Outlook Administrative Template and Select Open (in my case I uncompressed the file to my desktop so the path was: c:\Documents and Settings\ericnor\Desktop\OLK2K7 Admin Templates\ADM\en-us\outlk12.adm): If performed successfully you should now see that the Microsoft Office Outlook 2007 Administrative Template files have been added in Group Policy Editor: Step-8: Once you have successfully added the Outlook Administrative Template, you need to properly define and enable the necessary policies. To successfully block "Reply All" functionality we need to enable and define two specific policies in the Administrative Template: A policy to disable the actual command button as well as the menu option. A policy to disable the keyboard shortcut. To accomplish: In Group Policy Editor navigate to the following path: User Configuration\Administrative Templates\Microsoft Office Outlook 2007\Disable Items in User Interface\Custom. Once here you will notice 2 policies that will currently show as "Not Configured": Disable Command Bar Buttons and Menu Items. Disable ShortCut Keys. To disable the Command Bar Reply-All button we need to select the Disable Command Bar Buttons and Menu Items Policy. Once the policy is open set the State of the policy to Enabled then select the "Show..." button. Any and all Outlook Command Bar Buttons that are currently disabled will be present here in a numerical context (although presumably this would be the first time working with the template so you would not see any numerical values present). Click Add, and in the "Enter the Item to Be Added" field, type 355. Once done click OK. You will be returned to the Show Contents page which should now resemble the following. Click OK: (It's worth making a note here: All command buttons and menu options are referenced by their numerical Command IDs. I will show you how to determine these values in a follow-up post, so that you can apply what you have learned to other command buttons and short-cuts should you desire). Back on the Disable Command Bar Buttons and Menu Items policy page, select Apply and OK. The "state" of the policy should now show as Enabled. Now we need to disable the keyboard shortcut for Reply All. To do so, we need to open the Disable Shortcut Keys policy, configure our settings and enable it. To do so: Select and open the"Disable Shortcut Keys" policy. Select Enable, and then click the "Show..." button. This will bring up the Show Contents page. Select Add. In the Add Item Window type the following: 82,12 Click OK which will shift the focus back to the Show Contents pane. Your value should look like this: (Short-cut keys are always distinguished via the decimal representation of their ASCII character value. In addition the keyboard modifier (e.g. the keyboard combination used to activate the short-cut) needs to be converted to decimal notation and referenced here. As previously noted, I will detail how these values are calculated and converted in a follow-up post). Back on the Disable Shortcut Keys property pages, select Apply and OK. Back in Group Policy Editor, both policies should now show as Enabled: At this point both of your policies are enabled and configured. Close Group Policy Editor. You will be returned to the Group Policy tab for the "Users who have Reply All Removed" Organizational Unit. Click Apply then Close. Step-9: Provide "The List" to Help Desk. You should inform the Help Desk that there is a very high probability that users on "the list" will be calling in to complain that their Reply-All functionality no longer works. Your Help-Desk personnel should know why. Step-10: Create a Distribution List then and add all members of "the List". Send an informational to all users informing them that their "Reply-All" functionality has been removed due to misuse and for "x" amount of time. Once the GPO has been applied to the user workstation, these users will notice that the "Reply to All" button is disabled. If one of these users were to hover their mouse over the disabled button they will be presented with the following information: They will also notice that the menu option for Reply-All is now disabled: If the user attempts to issue the keyboard shortcut for Reply-All (CTRL + SHIFT + R), nothing will happen. I will cover additional related "Techy stuff" on this process in a follow-up post! Happy Trails! - Eric NorbergRemoving Reply All Functionality for Outlook Users Who Cause Reply-All Storms, via Group Policy
This is a part 2 of blog posts on this subject, you can read part 1 here. Within the first part of this post, I showed you had to remove the Reply-All functionality via GPO. At its core the process is relatively straight forward (obtain Outlook ADM templates, define policies, link and deploy it). However you have to take some things within this article at "face value". Specifically, the values I provided for the Command Bar ID as well as the values for disabling the keyboard shortcuts within the respective policies. At this point I wanted to take some time to show you how to verify these for yourself. The benefit being that you would be able to leverage a number of the techniques presented here to successfully disable other shortcuts and/or command buttons should and when you so desire. Prior to getting started it is worth noting that two separate approaches need to be utilized to obtain the appropriate command and shortcut IDs. Out on the Internet there seems to be a lot of confusion on how to best determine the Command Bar IDs, so I'm going to start with that first as it seems to be giving the most people difficulty. Determining Command Bar IDs: In retrospect there are a number of different techniques that could be utilized to obtain the valid Command Bar IDs in Outlook. MSKB 1736004 ((http://support.microsoft.com/kb/173604), actually has a complete list for Outlook 97. I don't know about you... but that is a bit old for my taste, although obviously most of the Command-IDs will stay the same for backwards compatibility, etc. Nevertheless a simple review of that document will show that the Command ID for "Reply All" is = 355. CommandBar Control ID ------------------------------------------ Compose Reply to All 355 You could also use a tool like Outlook SPY. Once you become proficient with it the Command IDs will be easily ascertained. How I did it: A very easy way to do this is to use Outlook Visual Basic Editor. So the first thing you need to do is enable the VBA Editor if you are not already doing so (most people don't). To Enable: Open Outlook. Select the Tools menu, and then select Options. Select the "Other" tab. Select Advanced Options. Under "In all Microsoft Office Programs" section select "Show Developer tab in the Ribbon". Select OK. Then Apply and OK on the Options page. Restart Outlook. Once Outlook has been restarted, you can now use Visual Basic for Applications to determine the Command Button ID for Reply-All. The code to follow is loosely based on the sample provided in MSKB 173604 with some subtle changes. First this code when executed will create a file on the root of the d:\ named OLIDS.txt. So, if you don't have a d:\ you will need to adjust the code as appropriate to reflect a valid path. However once properly executed you will have an output file in text format with all the valid Command IDs for Outlook. Steps: Open Visual Basic in Outlook. Add a reference to the Microsoft Scripting Runtime Library (From the Tools menu in the VBA Editor, select References, and then add the Microsoft Scripting Runtime). Once located, select OK to return to the VBA Editor: Paste the following code into your project: Sub GetIDsForInspector() ' The Outlook object library must be referenced. Dim objOL As New Outlook.Application Dim objCommand As Object Set cb = objOL.ActiveExplorer.CommandBars ' We will Create a new Text document. Dim objtxt Dim txtfile Set objtxt = CreateObject("Scripting.FileSystemObject") Set txtfile = objtxt.CreateTextFile("D:\OLIDs.txt", 8) ' 3500 is the maximum # of Controls Outlook has defined. For I = 1 To 3500 Set lbl = cb.FindControl(, I) If lbl Is Nothing Then ' Do nothing. Else ' Insert CommandBar name, Command name, and ID. txtfile.WriteLine (lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I) End If Next End Sub Run the Form. Once done you will notice a text file has been created on the d:\ named OLIDS.txt. Open this file in notepad. You will notice that the Standard Menu Bar has a Command ID of 355 for Reply to All: Standard Reply to A&ll 355 Note: If you didn't care about compiling an entire list of al l Command IDs but only wanted to get the value for Reply All, you could substitute the above code with what I have below. This script will simply throw the value into a message box: Sub GetIDsForInspector() ' The Outlook object library must be referenced. Dim objOL As New Outlook.Application Dim objCommand As Object Set cb = objOL.ActiveExplorer.CommandBars ' Create a new Text Document. Dim objtxt Dim txtfile Set objtxt = CreateObject("Scripting.FileSystemObject") Set txtfile = objtxt.CreateTextFile("D:\ \OLIDs.txt", 8) ' 3500 is the maximum # of Controls Outlook has defined. For I = 1 To 3500 Set lbl = cb.FindControl(, I) If lbl Is Nothing Then ' Do nothing. Else ' Insert CommandBar name, Command name, and ID. 'Uncomment next 2 lines if you want all Outlook CMD Ids 'txtfile.WriteLine (lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I) If (InStr(lbl.Caption, "Reply to A&ll")) Then MsgBox lbl.Parent.Name & Chr(9) & lbl.Caption & Chr(9) & I Exit For End If End If Next End Sub So this is where the value of "355" came from in the "Disable Command Bar Buttons and Menu Items Policy" (from Part 1 of this post). Screenshot again: Determining the Short Cut Key IDs and Modifiers: As evident from above, the shortcut key consists of two independent numbers separated by a ",". The first number is the actual shortcut key (R in this scenario). To get the proper value you need to convert the ASCII character to a decimal value. This is easy enough to do by simply looking it up in an ASCII table (http://www.asciitable.com/). As you can see the capital "R" character equates to 82 in Decimal Notation: So this is how the first number set is defined for the shortcut pair. The second set of numbers (in this case 12) is determined by the fact that the CTRL + SHIFT modifiers must be used in (conjunction with the R key), to issue the short cut. The numerical equivalent for the shortcut modifiers: Alt = 16 Ctrl = 8 Shift = 4 When multiple modifiers are used (as in this case), the numerical values must be added together. So in the case of a Reply All keyboard shortcut that uses (CTRL + SHIFT + R) CTRL = 8 Shift = 4 Total: 12 This is why we needed to add the value of 82,12 to the Key and Modifier to Disable entry on the Disable Command Bar Buttons and Menu Items Policy. Screenshot again (see Part 1 of this post): As I mentioned earlier in the post you can apply this knowledge to other Outlook Command IDs and shortcuts rather easily. After deciding on what Outlook Command Button(s) or Short-Cut(s) you want to disable, you simply perform the conversions and add them to the now in-place Custom GPO. For reference these are some additional Command IDs and shortcuts that should prove as a decent guide for double-checking your understanding of how the conversions are performed: Item: Command Bar ID: Short-cut Pair: Actual Outlook Short-cut: New Mail: 1757 78,8 CTRL+N Send Email: 2617 83,16 ALT+S Forward Email: 356 70,8 CTRL+F Print: 4 8 0,8 CTRL+P Delete: 478 68,8 CTRL+D View GAL: 353 66,12 CTRL+SHIFT+B Move to Folder: 2278 86,12 CTRL+SHIFT+V Conclusion: The combination of techniques described in this post provides an easy, legitimate way of disabling Reply-All functionality within the Outlook client (no DCR required!), should and when it be called for. Additionally these techniques can be "massaged" to fit other potential needs with an Active Directory/Exchange/Outlook environment. I hope you found the post interesting and useful. If you did, please share your thoughts with me by leaving some feedback comments (I do read them!). Happy Trails! - Eric NorbergMoving mailboxes? Make sure your Deleted Mailbox Retention is not set to 0.
I wanted to bring to light a specific issue that may occur during mailbox moves in complex environments with multiple Active Directory Sites and multiple Exchange servers. There are several other settings which must be in place in order for this issue to present itself. First, here are the settings which need to be in place: 1. On both the Source and Target mailbox stores, set Deleted Mailbox Retention to 0 days. 2. Note what the Online Maintenance schedule is set to on both stores. The moves need to be scheduled to coincide with Online Maintenance on the Target mailbox store. *Note - for the purposes of my testing, I set Online Maintenance to run Always for my databases. 3. There must be multiple Active Directory Sites so as to introduce AD replication latency (Inter-Site connectors can only replicate every 15 minutes), and there need to be Exchange servers in these different AD sites (or Exchange must be configured to statically point to the GC of the other site). 4. Enable Diagnostics Logging under MSExchangeIS\Mailbox, and set the category General to Maximum (only minimum is necessary though). This is necessary in order to log Online Maintenance events. Some background here: one of the tasks performed by Online Maintenance is to identify mailboxes that are past the retention date and to delete them. As part of this task, it will also run the Cleanup Agent, which is the task that identifies orphaned/reconnected mailboxes. If you recall, in Exchange 2000 and 2003, if you delete a mailbox, it is not immediately deleted, nor is it marked as disconnected. If a mailbox is orphaned (no user connected to it), it gets marked as disconnected; if it is disconnected and past the retention date, it gets deleted. For more information on the tasks run during Online maintenance, please see the following link: http://technet.microsoft.com/en-us/library/aa996226(EXCHG.65).aspx During a mailbox move, the destination mailbox will be created so that data can be copied to it. This destination mailbox is not yet associated with a user account though. This process of associating with the user account does not happen until the very end of the mailbox move and all content has been copied to the destination mailbox. During the final step of the move, the user attributes are updated to point to the new server (if applicable) and new database. This process of updating attributes is what associates the destination mailbox with the user account. If you manually run the Cleanup Agent on the destination mailbox store during a move, you will find that the destination mailbox will show up as a disconnected mailbox. If you then run the Cleanup Agent again right after the move completes, you will find that in some cases the destination mailbox will also be purged. This can cause problems, because when a move is successful, the source mailbox is removed as well. If the Cleanup Agent is run from another Exchange server that is pointing at a different Active Directory Site, and the Exchange attributes (homeMDB, homeMTA, msExchHomeServerName) have not yet been updated, the Cleanup Agent will detect that this mailbox is not attached to a user account, and that it is past the retention date; and therefore, the mailbox will be deleted. You should see the following events indicating that this is occurring: Event 9533 The user account for "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox will be removed from the mailbox store "database" in 0 days. Following that, you will see: Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" The first time I saw this event, the mailbox was not deleted. Then we have round 2, a few minutes later: Event 9531 Starting cleanup of deleted mailboxes that are past the retention date on database "database" Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" 1 deleted mailboxes have been removed Event 9532 The user account "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox has been removed from the mailbox store "database" There are two ways to prevent this from happening: Make sure that Deleted Mailbox Retention is set to a non-zero value. Configure the Online Maintenance interval so that it does not overlap with your scheduled mailbox moves. Alternatively, set Online Maintenance to not run on days when you will be scheduling moves. If you have encountered a situation similar to this, we want to hear from you! Please post a comment. - Ben WinzenzDon't put CAS in the Perimeter network!
We sometimes hear customers talking about locating Exchange 2007 or Exchange 2010 Client Access Servers (CAS) on the perimeter network (also known as the "DMZ" - Demilitarized Zone). A perimeter network is a network zone many companies deploy between the Internet and their intranet as defense-in-depth. The idea behind a perimeter network is to add additional steps to what a hacker would have to do to get access to any intranet resources. To add as strong defense-in-depth as possible, you want to put only servers you trust to withstand Internet attacks in the perimeter, and then you should assume they can be broken into anyway. With Exchange 2000/2003, it was supported and there was documentation explaining how to put an Exchange 2000/2003 Front-End (FE) server into the perimeter network, with a firewall between the FE and the Back-End (BE) servers it accessed. This leads some customers who upgrade from Exchange 2000/E2003 to expect the same deployment pattern with Exchange 2007/2010. As you start planning for deploying an Exchange 2007/2010 CAS server in the perimeter network, you quickly notice that there's no documentation for how to do this though. You'll probably even find the TechNet documentation which explains this is explicitly not supported by Microsoft. Microsoft doesn't test or support any topologies which put firewalls between a CAS and a Mailbox (MBX) server. The only Exchange 2007/2010 role which is supported for deployment in a perimeter network, and with a firewall server separating it from other Exchange server it talks to, is the Edge Transport server role. This is true for Exchange servers talking to one another within and between Active Directory Sites. The fact that there is no support for using firewalls between Exchange servers (except for the Edge Transport server role) sometimes causes confusion for how to use the Windows Server Firewall with Advanced Security on Exchange 2007/2007 servers. It's supported to have the Windows OS firewall turned on for Exchange servers. In fact, we strongly recommend you leave the Windows OS firewall turned on as a defense-in-depth measure. Exchange 2010 setup is smart enough to configure the Windows OS firewall so it'll let through all Exchange traffic appropriately. Note, for Exchange 2007 you need to run the Security Configuration Wizard and apply the Exchange 2007 role-based template. Detailed instructions can be found in Using the Security Configuration Wizard (SCW) to Secure Windows for Exchange Server Roles in Exchange 2007 docs. Note: In Exchange 2010, it's not required to use the Security Configuration Wizard to open the necessary ports for the Exchange 2010 server role and services running on a server. The configuration steps are included in Exchange 2010 Setup, and we don't ship any SCW templates for Exchange 2010. Understanding the reasons why we don't support CAS in the perimeter When discussing the fact that it's not supported to put CAS in the perimeter network, the next question is obviously "why?". If this was supported and documented for Exchange 2000/2003 Front-End servers, why not for Exchange 2007/2010 CAS? The most important reason why customers wanted to install Exchange FE servers in the perimeter network was to block any unauthenticated traffic from reaching servers on the intranet. This is a good practice, but as you'll see below doing this with Exchange FE/CAS servers is no longer the best way to accomplish this goal. It is important to understand that the CAS role in Exchange 2007/2010 is significantly different from the FE server in Exchange 2000/2003. The Exchange 2000/E2003 FE servers were there to authenticate users and proxy traffic to the BE server where the traffic was actually interpreted and responded to. For example, the FE servers in Exchange 2000/2003 don't do any Outlook Web Access (OWA) rendering. That all takes place on the BE servers. The Exchange 2007/E2010 CAS role on the other hand contains all middle-tier logic and rendering code for processes like OWA, Exchange ActiveSync (EAS), Exchange Web Services (EWS), and more. In the same timeframe as Exchange 2007 was available, enough customers had also started using reverse proxies (e.g. Internet Security and Acceleration server (ISA) 2000 FP1, 2004 or 2006) with functionality like pre-authentication. This meant there was now a good way to do authentication of Exchange traffic before it reached the Exchange servers. The role the Exchange 2000/E2003 FE server had played for defense-in-depth by pre-authenticating traffic before it reached servers, which included a lot of Exchange business logic, could now be better handled by these new reverse proxies. The reasons a reverse proxy like this does a better job than an Exchange FE or CAS server for this defense-in-depth role are: Exchange CAS servers require full access to all mailboxes in an AD Site, and significant access rights to the AD. That's a level of access privileged which you should avoid having in the perimeter network. The Exchange FE executed a little bit of Exchange business logic, and the Exchange CAS executes a lot of Exchange business logic. The more business logic you expose in the perimeter network, the more risk you're taking that something in that logic can be hacked. For servers you put in the perimeter network, you want to minimize the logic/code surface area they run and which is exposed to attack from the outside. Reverse Proxies are built with the primary purpose of withstanding Internet attacks like that. Although Exchange servers are also hardened from a security perspective, they run much more logic than a reverse proxy, which increases the risk. Reverse Proxies are built to be put in the perimeter network or at the edge of the network. They include many security features and flexibility for customers to determine the level of defense-in-depth which is right in any particular environment. Some of these defense-in-depth features are easy to just turn on (e.g. using pre-authentication while your reverse proxy is an Active Directory domain member; or avoiding Active Directory domain membership and limiting pre-authentication capabilities), whereas other defense-in-depth features take more work (e.g. using pre-authentication without domain membership by using RADIUS). But the important distinction between the reverse proxies and the CAS is that the reverse proxies have many more defense-in-depth features and deployment models available than Exchange CAS. In addition to these reasons why a reverse proxy does a better job in the perimeter network than an Exchange FE/ CAS does, there's also a problem with FE/CAS in the perimeter which goes away when using a reverse proxy there instead: Deploying an E2000/E2003 FE server in the Perimeter network was difficult. The port settings and other internal firewall configuration required was complicated and many customers ran into problems setting this up correctly. Different types of internal firewalls required different configuration and the symptoms experienced by Internet clients when something was misconfigured weren't always easy to diagnose. This complexity and the errors it caused was a problem for Exchange customers. The internal firewall configuration required when using a reverse proxy in the perimeter is much simpler. This is why we don't offer "CAS in the perimeter network" as a supported solution even for customers who want to take the security risks listed above: people accidentally end up shooting themselves in the foot when trying to configure things for a FE/CAS to work in a perimeter network. If you are curious, the ports used between server roles by E2007 are listed in Exchange Network Port Reference. Conclusion The best way to deploy Exchange CAS with respect to a perimeter network is to put a reverse proxy you trust in the perimeter, configure the firewall between the perimeter and the intranet to be as restrictive as possible and to host the CAS server on the intranet. This will get traffic inspection and other reverse proxy security filtering in place in the perimeter. As extra defense, you can also configure pre-authentication to be done on the reverse proxy. This might not be possible for all Exchange protocols if you want to expose some advanced functionality like Exchange 2010 Federated Free/Busy and Calendar Sharing to the Internet (see Understanding Federation and Understanding Federated Delegation for details about these features). But you can configure the pre-authentication for as many clients and protocols as is supported by the reverse proxy and the scenarios you want to enable. Regards, Kristian Andaker, Jason HendersonFinding High Item Count Folders Using the Exchange Management Shell
EDIT 06/18/2010: Few post changes to match the newest version of the script. Working in Exchange Customer Service and Support, we often see cases where user performance, or overall server performance, is impacted because of a high number of items in critical folders within user's mailboxes. This issue has already been documented in multiple places, including the following articles: Understanding the Performance Impact of High Item Counts and Restricted Views http://technet.microsoft.com/en-us/library/cc535025.aspx Using PFDAVAdmin to get the item count within the folders on an exchange server http://msexchangeteam.com/archive/2007/04/24/438170.aspx For the past few months, I have been using a simple Exchange Management Shell command to find all folders that have more than a certain number of items. The shell command is as follows: Get-Mailbox | Get-MailboxFolderStatistics | Where {$_.ItemsInFolder -gt 5000} | Sort-Object -Property ItemsInFolder -Descending | fl Identity, ItemsInFolder The above command finds all folders in the Organization that have more than 5,000 items, sorts them in descending order, and then gives the full Folder Path and Item Count. By modifying the Get-Mailbox portion of the command, you can target the command to obtain mailboxes from specific Servers or Databases. Since there are different folder item limits for each version of Exchange, I thought it might be beneficial to write a script that could analyze folders on all versions, and determine if they were over their limit. The limits are as follows: Version Folder Item Limit Exchange 2000/2003 5,000 Exchange 2007 20,000 Exchange 2010 100,000 It should be noted that these numbers are just the Microsoft recommended limits. Actual numbers could vary greatly depending on how many users are over the limit, the way mailboxes are being accessed (i.e. Outlook Cached Mode, Outlook Online Mode, via Mobile Phone, etc.) as well as certain 3rd party application integration. The script is called HighItemFolders.ps1. It can be used against the entire organization, a single server, or a single database. It has the option to search all folders, or only critical folders. It can find folders above the Microsoft recommended limits, or above a specified value. And it can send the results solely to the screen, or export the results to a CSV file. Parameters The script has the following parameters, which are all optional: -CriticalFoldersOnly: Specifies whether to check only Critical Folders, which are Calendar, Contacts, Inbox, and Sent Items, or to check all folders. Should be specified as either $true or $false. If omitted, the default value is $true. -Database: Specifies the target database to retrieve mailboxes from. This switch overrides the -Server switch if both are used. -DomainController: Specifies the Domain Controller to use for all mailbox and folder tests. If omitted, the default value is $null. -FormatList: Writes output to the screen in list format instead of table format. Should be input as either $true or $false. If omitted, the default value is $false. -ItemCount: Ignores the Microsoft recommended item limits, and finds folders with the specified item count. -OutputFile: Specifies the file to output the results to. This should be a .CSV file. -ResultSize: Specifies the maximum number of mailboxes to check. If omitted, the default value is unlimited. -Server: Specifies the target Exchange server to retrieve mailboxes from. Examples Obtains all users in the organization, and checks only critical folders over the Microsoft recommended item counts: C:\> .\HighItemFolders.ps1 Obtains all users on a specified database, checks all folders, and outputs to a CSV file: C:\> .\HighItemFolders.ps1 -Database "e2k7-1\First Storage Group\Mailbox Database" -CriticalFoldersOnly $false -OutputFile output.csv Obtains all users on a specific Exchange server with more than 1000 items in any folder: C:\> .\HighItemFolders.ps1 -Server "e2k3-5" -ItemCount 1000 Output The script always writes output to the screen. If the -OutputFile switch is used, it will write to a file in addition to the screen. Screen Output: CSV Output: Script The script can be downloaded as an attachment to this blog post, and then executed from the Exchange Management Shell. Notes 1. In some cases, the CSV file does not separate the columns properly when opening it directly with Excel. To format the columns correctly, do the following (with Excel 2007): Open Excel Choose Open, and browse to the CSV file Choose Delimited as the format. Hit Next Use Tab as the Delimiter. Hit Finish. 2. Error detection has been included in the script to determine if any of the mailboxes reside on a database or server that is inaccessible. If so, that database or server will be skipped so we don't have a lengthy timeout for each mailbox. However, this detection only works on Exchange 2007 and higher. Exchange 2003 mailboxes still time out individually if they are inaccessible, and can cause the script to take a very long time to run. Hope you find this useful! - Mike HendricksonIntroducing the Microsoft Exchange Server Profile Analyzer
Included in this month’s Exchange Tools Web release (direct link) is a new analysis tool called the Microsoft Exchange Server Profile Analyzer Tool (or EPA). We created this tool to help server administrators understand their user profile to help with the process of server sizing or capacity planning. A user profile describes how many actions an average user performs in an average day. When we refer to actions, we are talking about things that a user would do within an e-mail client application like send mail, delete mail, browse folder, etc. The EPA tool attempts to use whatever information is available in user mailboxes to generate an estimated profile, and depending on the characteristics of your users, the estimated profile may not be very accurate (for example, if messages are frequently deleted from the Sent Items folder, EPA will not generate accurate sent message statistics). For those of you who have worked with older versions of Exchange and Outlook, the EPA tool is building a profile in a similar way to the storstat.exe tool. This package includes three separate tools: EPA (available as EPAWin.exe and EPACmd.exe) is designed to generate a user profile based on the contents of user mailboxes. EPAOWA is designed to generate a user profile by analyzing OWA log files EPASummarizer is an assistant tool for EPA that can combine output files from EPA to summarize statistics across multiple data collections. This article will focus specifically on the EPA tool. We will explain how it gathers data, what data it gathers, and specific requirements for running the tool successfully. The major steps that EPA takes to collect data are: Step 1: Load topology from Active Directory. EPA reads Exchange configuration data such as organization, server, storage group, private mailbox store, and http virtual server from AD. This means that the account that runs EPA is required to have the ability to read Exchange configuration data from AD. In the GUI version of EPA (EPAWin.exe), you will see a tree view of the topology once this step is complete. Step 2: Scan HTTP virtual server and virtual directory configuration for each server. For each http virtual server found on the server, EPA reads configuration information from the IIS metabase for two attributes: running state and SSL accessibility. For each virtual server, EPA maintains a list of mailbox virtual directory access links. The format of the link looks like this: http(s)://servername(:portnumber)/virtualdirectoryname/. For a particular virtual server: If EPA detects its state as not running, EPA will ignore it. If EPA fails to read the running state, EPA assumes the virtual server is running. If EPA reads that SSL is not enabled, for each mailbox virtual directory found on the virtual server, EPA adds a corresponding “http://” link to the list If EPA reads that SSL is enabled, for each mailbox virtual directory found on the virtual server, EPA adds a corresponding “https://” link to the list If EPA fails to read the SSL attribute, EPA adds two entries of this virtual server to the list. One assumes the SSL is enabled (https://), and the other does not (http://). At the end, EPA sorts the list to put “https://” links on the top so that we will always attempt to use encrypted connections if they are available. When EPA moves on to Step 4 to collect data from each user mailbox, it will attempt to use each link in the list until it finds one that works. EPA will attempt to match the configured SMTP domain of a virtual server with each user’s SMTP domains to facilitate hosted Exchange scenarios. You may notice that this step would require the account that runs EPA to have access to IIS metabase. If you don’t have access to the IIS metabase, EPA will make some assumptions about your configuration that should allow it to run under most circumstances, however you may see some error messages reported in the log if metabase access is not available. Step 3: For each server and mailbox store we found in the topology, EPA determines whether or not they will be included in the data collection stage based on configuration input, Step 4: Data collection. Based on user’s configuration of the ServerThread and MailboxThreadPerServer attributes in the configuration file, EPA creates single/multiple working threads for data collection. If ServerThread is configured to 1 (which is the default setting), EPA will collect data sequentially on servers. Otherwise, it will create multiple threads for servers, and starts to collect data from multiple servers at the same time. Similar logic applies to MailboxThreadPerServer. The mailbox thread is the actual thread that is doing the data collection from a single mailbox (see the section below for the details of this function). After each mailbox is processed, the statistics generated from the collected data will be summarized to the parent mailbox store. The collection process for a mailbox store is done when all the mailboxes in the store are processed. The statistics for the server level are calculated when the collections for all the mailbox stores on the server are done. Similarly, the statistics at the organization level will be calculated when the collections on all the servers are finished. How EPA collects data from single mailbox EPA accesses items in user’s mailbox by using HTTP/Web Distributed Authoring and Versioning (WebDAV). This requires that the account that runs EPA has to have Full Mailbox Access. Note that EPA only supports Integrated Windows Authentication (NTLM) authentication at this time. If your server does not have Integrated Windows Authentication enabled for HTTP virtual servers, EPA will fail to collect data. EPA will also fail if HTTP virtual servers on back-end mailbox servers have OWA FBA (Forms-Based Authentication) enabled. The primary WebDAV methods that EPA uses are SEARCH, PROPFIND, BPROPFIND and X-MS-ENUMATTS. The SEARCH method is used to get the hierarchy table and content table from a folder. To get the actual properties of a folder or of a message item, EPA uses the PROPFIND and BPROPFIND methods. X-MS-ENUMATTS is used to get the attachment table from a message item. Table 1 shows the sets of properties that EPA reads for different types of store objects such as folder, message, attachment and appointment using WebDAV. Table 2 shows a list of collectors EPA calculates based on the properties listed in Table 1. Table 1: Properties EPA reads by using WebDAV Property Name Namespace Root Mailbox Folder contacts urn:schemas:httpmail: calendar urn:schemas:httpmail: deleteditems urn:schemas:httpmail: drafts urn:schemas:httpmail: inbox urn:schemas:httpmail: outbox urn:schemas:httpmail: sentitems urn:schemas:httpmail: tasks urn:schemas:httpmail: notes urn:schemas:httpmail: journal urn:schemas:httpmail: MsgFolderRootURI urn:schemas:httpmail: Folder Properties href DAV: displayname DAV: childcount DAV: objectcount DAV: haschildren DAV: hassubs DAV: creationdate DAV: foldersize http://schemas.microsoft.com/exchange/ 0x0FFF0102 (EntryID) http://schemas.microsoft.com/mapi/proptag/ 0x0e080003 (Size) http://schemas.microsoft.com/mapi/proptag/ 0x36010003 (FolderType) http://schemas.microsoft.com/mapi/proptag/ 0x663A000B (HasRules) http://schemas.microsoft.com/mapi/proptag/ Message Properties href DAV: creationdate DAV: contentclass DAV: subject urn:schemas:mailheader: to urn:schemas:mailheader: cc urn:schemas:mailheader: bcc urn:schemas:mailheader: hasattachment urn:schemas:httpmail: read urn:schemas:httpmail: htmldescription urn:schemas:httpmail outlookmessageclass http://schemas.microsoft.com/exchange/ 0x0e060040 (DeliveryTime) http://schemas.microsoft.com/mapi/proptag/ 0x0e080003 (Size) http://schemas.microsoft.com/mapi/proptag/ Attachment Properties 0x3703001f (Extension) http://schemas.microsoft.com/mapi/proptag/ 0x0e200003 (AttachmentSize) http://schemas.microsoft.com/mapi/proptag/ 0x3704001f (AttachmentName) http://schemas.microsoft.com/mapi/proptag/ Appointment Properties dtstart urn:schemas:calendar: Note: Please refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wss/wss/_webdav_x-ms-enumatts.asp for a complete list of supported WebDAV properties and detailed descriptions of the data containined within the properties listed above. Table 2: Exchange Server Profile Analyzer Data Collectors Collector Name Description MailboxTotalSize The total size, in bytes, of the mailbox RulesTotalCount Total number of rules defined in the mailbox FolderTotalCount Total number of visible folders in the mailbox FolderMaxMessageCount Maximum number of messages in any one folder FolderTopLevelCount Number of visible folders in the mailbox FolderUserCreatedTopLevelCount Number of user created folders that are direct children of the root of the mailbox SearchFolderCount Number of search folders in the current mailbox FolderHierarchyHeight The height of the folder tree FolderTopLevelAverageSubfolders Average number of children each child of the folder tree root has. FolderTopLevelAverageHeight Average height of each of the root folder’s children's subtrees. FolderSize Size in bytes of all the messages in a folder (takes list of folders to measure, e.g. "Inbox, Deleted Items, Sent Items") FolderSizeAggregates Folder size statistics (across all folders in mailbox) - provides Avg, Min, Max. MessageMailboxCount Number of messages in the mailbox MessageFolderCount Number of messages in a folder (takes a list of folders to measure, e.g. ("Inbox","Deleted Items","Sent Items") MessageUnreadCount Number of messages that are unread MessageDAMCount Number of Deferred Action Messages in the mailbox MessageReplyCount Number of messages where the subject prefix is "RE:" or equivalent subject prefix for the given culture MessageForwardCount Number of messages where the subject prefix is "FW:" or equivalent subject prefix for the given culture MessageContainsAtLeastOneDLCount Number of messages containing at least 1 distribution list in the recipients table MessageContainsAtLeastOneAttachmentCount Number of messages containing at least 1 attachment MessageSizeDistribution Counts messages in a size range (takes a list of ranges, e.g. "2,10,100,1024" would provide counts of messages from 0-2,2-10,10-100,100-1024,1024-beyond) MessageSizeAggregates Message size statistics across all messages (provides Avg,Min,Max) MessageReceivedPerDayAggregates Average number of messages received per day (provides Avg,Min,Max, and can restrict to the last N days) MessageSentPerDayAggregates Average number of rows in each sub table when the sent items folder is categorized by date (provides Avg,Min,Max and can restrict to last N days) MessageRepliesSentPerDayAggregate Average number of messages prefixed with "RE:" sent per day (provides Avg,Min,Max and can restrict to last N days) MessageForwardsSentPerDayAggregates Average number of messages prefixed with "FW:" sent per day (provides Avg,Min,Max and can restrict to last N days) MessageBodyTypesCount Number of messages in each body type requested (takes list of body types as input, e.g. "RTF,HTML,Other") RecipientsPerMessageSentAggregates Average number of recipients of each message in the Sent Items folder RecipientsDLPerMessageSentAggregates Average number of distribution list recipients of each message in the Sent Items folder AttachmentSizeAggregates Attachment size statistics across all attachments (provides Avg,Min,Max) AttachmentSizeDistribution Counts attachments in specified size ranges (takes a range list of inputs, e.g. "2,10,100,1024" provides counts for ranges 0-2,2-10,10-100,100-1024,1024-up) AttachmentPerMessageAggregates Statistics on number of attachments per message (provides Avg,Min,Max) ContactCount Number of contacts in the mailbox ContactCreatedPerDay Number of contacts created per day (provides Avg,Min,Max, can be restricted to last N days) AppointmentCount Number of appointments in the calendar AppointmentCreatedPerDay Number of appointments created per day (provides Avg,Min,Max, can be restricted to last N days) MeetingRequestCount Number of meeting requests in the calendar. MeetingRequestReceivedPerDayAggregates Statistics on number of meeting requestes received per day (provides Avg,Min,Max, can be restricted to last N days) We want to hear from you! Feel free to send your feedback on this tool directly to epafb AT microsoft DOT com and we will use your input to help make future versions of this tool even better. Frequently Asked Questions Question: EPA reports CompletedWithException. Where can I find what exceptions occurred during the data collection process? Answer: EPA reports exception information exceptions in a log file. The default log file will be located at the user's application data path. For example, C:\Documents and Settings\<username>\Application Data\Microsoft\Epa\epalogYYYYMMDD_HHMMSS.log Question: Error: Unable to connect to Active Directory. Please make sure that the user account has enough permission. Error: Unable to check the state of HTTP virtual server 1 on ServerName. Error: Unknown error (0x80005000) Answer: The errors are reported because the account that runs EPA does not have permission to read IIS metabase. The error code may vary. EPA will continue to attempt to collect data from user mailboxes by making some assumptions about the configuration of your Exchange topology. See "Step 2" described above for details. Question: Error: Unable to find an available URI for user ServerName\MDBName\Mailbox x. Answer: The error is reported for two reasons normally. 1. No HTTP virtual server is running. 2. For each HTTP virtual server on the exchange server, SMTP domain of the virtual server does not match with user's SMTP domains. Question: Error: User ServerName\MDBName\Mailbox x cannot access any of the following links:http://ServerName/Exchange/. Answer: The error will come up in the following five cases. 1. The account that runs EPA does not have full mailbox access on the user's mailbox. This can be verified through Exchange System Manager. Please see the EPA documentation for details on how to configure and verify permissions. If the account does have full mailbox access rights, then try using Internet Explorer to access the user's mailbox with OWA. If you are not able to access the mailbox with OWA, EPA will not be able to access it either. 2. The authentication methods configured on the virtual directory do not include Integrated Windows Authentication which is the only method EPA supports. 3. There are restrictions set up on the Exchange Server that restrict TCP/IP traffic in some way so that HTTP or HTTPS traffic from the machine you are running EPA on is blocked. You can work around this by running EPA on a machine that has the ability to connect with the back-end Exchange Server (such as an Exchange front-end server). 4. When SSL is required on the server and the name on the SSL certificate does not match the name that EPA is using to access the server, EPA will fail due to SSL certificate validation errors. We will have a fix for this in next Web Release. 5. When OWA Forms-Based Authentication is enabled on the HTTP virtual server, EPA will fail since the DAV requests submitted by EPA will get "440 Login Timeout" error. This is similar to http://support.microsoft.com/default.aspx?scid=kb;en-us;817379 . We plan to provide better feedback for this case in the next web release version. If these troubleshooting suggestions don't solve your EPA problems, please contact epafb AT microsoft DOT com for further investigation. - Jessie ZhuCommon Trust, Encryption and Digital ID Troubleshooting for Microsoft Outlook and Exchange users
Some of the most common issues the Exchange Client-Server Integration team sees regarding S/MIME issues with Outlook and Exchange are: - Trust Failures - the Trusted Root Certification Authority certificate is not installed on the client or server. - Encryption Issues – not sent with intended cipher strength. - Errors - “Your digital ID name could not be found by the underlying security system.” and “Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates or conflicting or unsupported encryption capabilities” - The Publish to GAL feature in Outlook – usage and issues related to it. Trust Failures Trust and encryption issues can impact users using OWA, Outlook (including RPC over HTTP), Exchange ActiveSync and OMA in a number of scenarios. Secure Mime (S/Mime) is generally used to ensure the sender of a message can be Trusted, i.e., the sender is who they say they are. Microsoft Internet Explorer contains a pre-configured list of Trusted Root Certification Authorities. To view this list, open Internet Explorer, click Tools, click Internet Options, click Content, click Certificates and click the Trusted Root Certification Authorities tab. If you install a Certificate Authority in your network – either the Microsoft Windows Certificate Server or a third-party server – or obtain a client or web server certificate from an authority on the web, you should verify that the Root Certificate is listed here. If it is not, the certificate for your Certificate Authority must be provided to clients or placed in a location where the certificate it can be retrieved by users. If you are working with your own Certificate Server, an Extension within issued certificates for the Certificate Authority, called the Authority Information Access (AIA) can be configured. In Outlook 2003, when you receive a digitally signed message from someone who’s Certificate Authority you do not trust, you are prompted with the following: Certificate Authority Information Your message was digitally signed with a certificate issued by a Certificate Authority. The signature is invalid because you have either distrusted or not yet chosen to trust the following Certificate Authority. Issued by: <authority> Valid From: <validity period> For more information about the Certificate used to digitally sign the message, click Details. This is followed by a View Message button and a Details button. Below these buttons, you see more text: Trusting the Certificate Authority Trusting a Certificate Authority means that you trust mail that is digitally signed by certificates issued from that Certificate Authority. Do you want to trust this Certificate Authority? If you choose Trust, you must also click Yes on the Root Certificate Store dialog that follows to add the certificate to your system. This is followed by buttons for View Certificate Authority…, Trust and Close. A checkbox is below for: Warn me about errors in digitally signed e-mail before the message opens. If this box is unchecked you will not be warned about errors in the future (not desirable). If you click Trust, and click Yes for the Root Certificate Store dialog, the authority will be trusted on your system. With older versions of Outlook, you received a warning, but were not presented with a Trust dialog. You could navigate to and install the Certificate Authority or trust each individual certificate. With web servers, if you receive a message stating “This certificate was issued by a company that you have not chosen to trust”, your computer is not configured to trust the root certification authority that issued the certificate. See the following article from the Microsoft Knowledge Base: 297681 Error message: This security certificate was issued by a company that you have not chosen to trust For additional information, visit the following Microsoft web site: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/sag_PKPUnCertRoot.asp Particularly with RPC over HTTP or when using the Outlook Web Access (OWA) S/MIME control on a client, the root certificate must be installed on the web server as well as the client. Not installing the certificate on the web server leads to different behaviors between OWA and RPC over HTTP. When using OWA to create SSL connections to a web site, you constantly encounter trust warnings when connecting and are prompted on whether to continue or cancel the connection. In RPC over HTTP configurations, proper installation of the web server and root certification authority certificates are required for correct functionality. RPC over HTTP does not return certificate-related errors on the client side, but simply fails to connect. In RPC over HTTP configurations, proper installation of the web server and root certification authority certificates are required for correct functionality. Some good references from the Knowledge Base are: 319574 HOW TO: Use Certificates with Virtual Servers in Exchange 2000 Server 823024 How to Use Certificates with Virtual Servers in Exchange Server 2003 Encryption Issues Encryption strength issues can be due to the method Outlook uses to determine a recipient’s capability to decrypt a message. For example, the sender wants to send using 3DES (168-bit), but sends a 40-bit encrypted item, and doesn’t understand what happened. In a directory, two attributes of a user object, UserCertificate and UserSMIMECertificate, determine cipher strength. In many environments, UserCertificate has no user-specific attributes, meaning it cannot be configured. Thus , the cipher strength returns to a default – 40-bit encryption. There is a certificate extension which can contain a SMIME Capabilities listing the encryption algorithms. Outlook will look at that as a last resort before falling back to 40-bit encryption. UserSMIMECertificate, on the other hand, is a user-published value defining the user’s capabilities. In an Exchange Server 5.5 or Active Directory environment, you can use the “Publish to GAL” feature in Outlook to publish to UserSMIMECertificate. This ensures that people looking up your GAL entry will know your capabilities and can send using 3DES if they wish. NOTE: With Outlook 2003 the new default is 3DES, so Outlook will fall back to 3DES and not 40-bit. With LDAP directories, where UserSMIMECertificate is not present, or the SMIME Capabilities extension is not included certificate in the UserCertificate attribute, the 40-bit encryption issue can be an issue. Outlook cannot publish to UserSMIMECertificate on LDAP servers. In environments with LDAP servers or where users do not use the “Publish to GAL” feature in Outlook to publish their digital ID, the default 40-bit behavior can be overridden by a registry value and is discussed in the following Knowledge Base article: 318589 OL2002: You Cannot Send Encrypted Mail to an LDAP Recipient It is important to note this registry key can have an unintended consequence. If a user does not have a client configured to support 168-bit encryption, they will be unable to read your e-mail. Errors The error “Your digital ID name could not be found by the underlying security system.” is typically caused by one of the following reasons: Your digital certificate is damaged or corrupted in Windows. This is rare and has not been successfully reproduced, though the problem has been observed in some deployment scenarios. In reproduction attempts non-imaged systems or systems with a different image version in the same environment had no problems. Reinstallation of the digital ID has resolved the issue , in most cases. The sender of an encrypted message uses a Public Key for the recipient (the person opening the item) that is not installed on the recipient's computer. This could be due to an old or incorrect digital ID is listed in a directory (LDAP, Exchange 5.5 directory or Active Directory) or the sender’s Outlook Contact for that recipient. When the sender addresses the item, resolves against the LDAP server or Contact and encrypts, the recipient can’t open the item. The message is encrypted for a digital ID that the recipient does not have installed. An example of this issue is where UserA has previously used the “Publish to GAL” feature, but has since received a new Digital ID. That user or someone else working on UserA’s system removed the Private Key for the old (but still valid) digital ID. As the old digital ID’s Public Key is published in UserSMIMECertificate, this is the ID used – UserSMIMECertificate is the preferred value. When you receive the error “Microsoft Outlook had problems encrypting this message because the following recipients had missing or invalid certificates or conflicting or unsupported encryption capabilities”, the problem is usually that: · You do not have a copy of the Public Key for the person you are trying to send to – either in a Contact or in an accessible directory (Global Address List or LDAP). · The recipient has an expired Public Key in the GAL, Contact or LDAP directory. This is documented in the following Knowledge Base article: 884738 You receive an error message when you try to send an encrypted e-mail message to another user who is in the same Exchange organization in Outlook 2002 Another issue is where a valid certificate is listed in the GAL, Contact or LDAP directory, but it is issued by a Certificate Authority that is not trusted. Thus the cert is considered invalid. Installing the Certificate Authority’s certificate on the client will resolve the issue. < /o:p> Publish to GAL The “Publish to GAL” functionality of Microsoft Outlook (2000 and later) is sometimes the key to many issues regarding the use of secure e-mail. This is, as stated above, the process of placing a user-signed blob in the directory that publishes a user’s Public Key with a full description of capabilities. It is important to select the correct “Security Settings” when publish to the directory. To establish a Security Profile in Outlook, click Tools, click Options, click Security and note the contents of the Security Settings box. A name will be displayed “Default Security Settings”, or a custom name if you have so chosen. When you click Publish to GAL, this is the digital ID that is pushed to the directory. If you need to change this (such as if you receive a completely new digital ID), or create a new Security Settings configuration, click the “Security Settings” button, click New and type a name for the setting – “My ID”, etc – then click the Choose button and select the digital ID you wish to use in this configuration. When you use “Publish to GAL”, it is important to remember that – when your digital ID expires or is renewed – the old digital ID remains in the UserSMIMECertificate value in your user object in the directory until you republish. The Exchange Server 5.5 or 2000 Key Management Server (KMS) server enrollment process involves a GAL publishing step (which includes UserSMIMECertificate), but there is no “automated” method of using the “Publish to GAL” functionality with a Windows or third-party Certificate Server. See the following documents for more information on resolving problems of this type: Exchange Server 2003 Message Security Guide, Appendix C: Digital Certificates Cleanup Script http://www.microsoft.com/technet/prodtechnol/Exchange/Guides/E2k3MsgSecGuide/3f9c9231-d623-43f7-88bd-9c2244e69eac.mspx 822504 Outlook 2003 continues to use old certificates after you migrate from Key Management Server to Public Key Infrastructure You can also clean up using the following steps from Outlook: Remove all Security Settings via Tools, Options, Security, Settings Click Publish to GAL Outlook will delete all the certificates from the GAL. This should be used with caution. - Will DuffTroubleshooting Outlook Web Access Logon Failures in Exchange Server 2007
Despite our attempts at documenting various break/fix scenarios, it can often be frustrating when trying to locate the information you need to resolve an issue as quickly as you would like. I decided to share this information in an attempt to help you resolve the majority of issues that can prevent your users from successfully logging on to Outlook Web Access. It won't resolve 100% of the issues and it's not intended to. It's also not intended as a "complete" with step-by-step instructions for each scenario. Rather, in most cases it will help you approach the issue logically and determine your best course of action and which resources to review to learn more about the scenario as well as how to fix your issue. In any event, it's a good resource to peruse before picking up the phone to speak with technical support. The following should guide you through eliminating the most common root causes for this type of scenario. If nothing else, working through these steps should provide you with enough information such that you can minimize your time on the phone should you still find it necessary to call technical support. Probing questions Before you can effectively troubleshoot this issue you should know, or confirm, the following information: 1. If users are receiving an error, what is the exact wording of the error message and does it include an HTTP (IIS) status code that can help you isolate root cause? 2. If a call stack is provided when clicking Show Details, does the exception provide any clue that can help you isolate root cause? 3. Is everyone affected or only some users? For instance, does the issue affect only users connecting from outside the network or everyone regardless of their location? If only users connecting over the Internet are affected, then there's a high probability that Exchange is fine and the cause of the issue is related to a firewall, proxy server, or hardware device like an SSL Accelerator or load balancer. NOTE: Another good test to run if you suspect root cause might be your firewall or network is to try logging on to OWA from the console of the Client Access Server itself. 4. If only some users are affected, does the issue happen from multiple workstations using the same user account? This should help you determine if the issue is user specific or machine specific. 5. If you still have Exchange 2003 mailbox servers in your org, does the issue affect Exchange 2003 and/or Exchange 2007 users who try connecting through the Exchange 2007 CAS? 6. Is the server users connect to a standalone Client Access Server or is the Mailbox role also installed on the same machine? 7. How many Active Directory sites are there? If more than one, which site has the Internet-facing CAS server? Which site has the mailbox server where affected users are homed? 8. Is the CAS server in a perimeter network or DMZ? 9. Did it ever work? If yes, what changes have been made in the environment, i.e. software updates, service packs, rollups, new hardware, firewall changes, etc? Troubleshooting Now that you have a clearer understanding of the issue and environment, let's eliminate the low hanging fruit. 1. If you're in a mixed environment with Exchange 2003 or 2000 and only users homed on Exchange 2003 are unable to log on, read the following with special attention to the Deployment Scenarios section: Outlook Web Access and Exchange 2007, Exchange 2003, and Exchange 2000 Coexistence http://technet.microsoft.com/en-us/library/bb885041.aspx 2. If Exchange 2003 users connecting through Exchange 2007 receive, "Page cannot be displayed", followed by, "Cannot find server or DNS error", and the CAS role is co-located with the Mailbox role, then you will need to deploy a standalone Client Access Server. This is also documented in the coexistence documentation above and is necessary if you intend on having Exchange 2003 users use OWA to connect to their mailbox across the Internet. 3. If Exchange 2007 is deployed across multiple Active Directory sites with an Internet-facing CAS server in one site and other CAS servers in "proxy" sites, read our Redirection and Proxy documentation. Briefly, when you configure your CAS servers for this scenario you must have an external URL entered for the /owa virtual directory in Exchange Management Console. Authentication will typically be either forms-based (FBA) or basic auth. However, the CAS servers in the proxy sites need to be configured quite differently. The InternalUrl for the /owa vdir in the console should be the internal FQDN of the server and the External URL should be blank, or null. Authentication for /owa MUST be set to Integrated Windows Authentication which means you cannot enable FBA on the CAS servers in the proxy sites. If this isn't set up correctly and users with mailboxes in the proxy site are unable to connect, then you should see an event ID 41 for source MSExchange OWA on the Internet-facing CAS. 4. Several different issues can cause a 440 Login Timeout error. If users are seeing this, read the following Knowledge Base article: 941201 Error message when you try to log on to Exchange 2007 by using Outlook Web Access: "440 Login Timeout" http://support.microsoft.com/default.aspx?scid=kb;EN-US;941201 5. If users see "Service Unavailable" when they try to connect, it's possible you intentionally or inadvertently installed the 32-bit version of the.Net Framework. To resolve this issue, refer to the instructions for Asp.Net version 2, 64-bit, in the following Knowledge Base article: 894435 How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version of ASP.NET 2.0 on a 64-bit version of Windows http://support.microsoft.com/default.aspx?scid=kb;EN-US;894435 6. If users report seeing a blank page when connecting to OWA, this might be due to a recent rollup being applied that didn't install correctly. For more information, see kb 935490 which applies to all rollups and not just Rollup 2. 935490 Description of Update Rollup 2 for Exchange 2007 http://support.microsoft.com/default.aspx?scid=kb;EN-US;935490 I hope this helps! As I mentioned earlier, this won't help you resolve every single OWA logon issue. But it's a good place to start and some of the procedures may lead to solutions that aren't documented here. - Joe Turick
