Why can't I modify the objects on my ADC Tools created Recipient CA?
If you create a Recipient Connection Agreement (RCA) with the ADC tools wizard and then go in to view the settings of that RCA, you may notice that the “Select the objects that you want to replicate” options on the From Windows tab are grayed out and you cannot make changes… Example: The reason for this is because of the custom filter created for the RCA by the ADC tools. If you look at the values for the attribute msExchServer1SearchFilter on the agreement itself, you will see a filter specified that is similar to: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=SITE1/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); This is a custom search filter that (in this case) searches for objects in Active Directory that are either of class user, contact, or group AND that also belong to the Administrative Group called SITE1 (or that have been deleted and need that deletion to replicate across to the 5.5 Directory) Since this is a “custom” filter, the objects can’t be edited via the normal GUI interface and that is why the check boxes are not modifiable. Once again you can see from the filter that the connection agreement is in fact already set to replicate users, contacts or groups despite what the GUI seems to indicate at first glance. If you have multiple Administrative groups that have users in the same Active Directory location you would have multiple auto-created RCAs as these will ONLY replicate objects that match the Administrative Group listed in the filter. For example, a second Administrative Group (called AG2) with objects in the same Active Directory location would have a filter like the following: (&(|(objectclass=user)(objectclass=contact)(objectclass=group))(|(legacyExchangeDN=/o=ORG1/ou=AG2/cn=*)(legacyExchangeDN=ADCDisabledMail*)(isDeleted=TRUE))); Ultimately, if you want or need more flexibility with connection agreements (such as limiting or modifying the objects controlled by the RCA) you should create the connection agreements manually using the ADC Services Snap-in instead of having the ADC tools create them automatically. - Kyle LewallenWhy can't I do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree?
I am sure many of you have at one time or another wanted to do a Deep Traversal (subfolder) Search on the MAPI Public Folder Tree. However, as many of you probably know, Exchange does not allow for Deep Traversal (subfolder) Searches on the MAPI Public Folder Tree: http://support.microsoft.com/default.aspx?scid=kb;en-us;254911. The reason you cannot do this is because when the Public Folder system was designed, it was decided that load balancing would be accomplished by putting only some of the content on some of the servers. For example, if there exists 3 folders and 3 servers. Folder1 may be replicated between servers 1 & 2, folder2 between servers 2 & 3, and folder3 between 1 & 3. If the client created a search folder that simultaneously searched all three folders, they’d get different results depending on which actual Public Folder Server they were connected to. To address this issue, search folders cannot be created that search the content of multiple folders; deep traversal, or subfolder, being a special case of “multiple folders”. One way to get around this “limitation” is by setting up a Non-MAPI Public Folder Tree because you can do a Deep Traversal (subfolder) Search against that: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/e2k3/e2k3/_exch2k_specifying_a_deep_traversal.asp?frame=true. However, you cannot view this Public Folder Tree via MAPI (i.e Outlook). So what is the difference you ask? Well, the thought behind Application Public Folder Stores was that, for the most part, the content of the folders would not be replicated to any other server. There’s no actual architectural limitation to enforce this – Exchange originally just foresaw organizations would create only one Application Public Folder Store at all and so replication wouldn’t be an issue. Therefore, users can create Search Folders that can search the content of multiple folders. Given this, though, you do actually step back into the original problem. Namely, the search folder itself is replicated among servers but the content is always generated locally. Also, clients are never referred to a different server – search folders always seem (to the client) to have their exclusive replica on the server presently being queried. So, users should be aware that they will get different results depending on which server they contact for the content, and of course replication latency adds a new dimension to the differing results. - Chris AhlersThe New Cluster Clean Upgrade Method
Prior to releasing Exchange Server 2003 we didn’t test this scenario, and since we only support scenarios that we have tested and have confidence in this was considered unsupported. However, with so many customers interested in this method of upgrading we decided to test it and document the process. A KB article will be released describing the process, but for now here are the steps you need to know. Summary: In some cases it may be preferable to do a clean install of the operating system or Exchange Server rather than upgrading. On a cluster, your existing Exchange 2000 virtual server can be preserved and upgraded even if you need to clean install Windows 2003/Exchange 2003. Some custom configuration may be lost using this method, we recommend performing a standard upgrade if at all possible. Please read and understand all the steps and issues thoroughly before beginning this upgrade process. This kb article covers clusters that meet the following requirements: Windows 2000 SP3 Exchange 2000 SP3 Two nodes Active/Passive configuration Upgrading to: Windows 2003 Exchange 2003 Steps: For this example I’ll run the EVS on node2 while I upgrade node1, but it doesn’t matter which node is upgraded first. 1. Evict the passive node and rebuild Make sure the EVS and all cluster resources are all running on node2 (active node). Use cluster admin from node2 to stop the cluster service on node1 and then evict it from the cluster. On node1, format the disk and clean install W2k3. Rejoin node1 to the cluster (Important! This must happen before running Exchange setup) On node1, clean install E2k3. 2. Configure services On node 1, run services.msc and set Distributed Transaction Service startup type to Manual If you are using POP3 or IMAP set the start up type to manual on each service. (If you are not using these services consider deleting the resources and setting the services to disabled). If you are using full text indexes please see the note below for special instructions. On node2, take the Microsoft Exchange System Attendant resource offline (this will take all Exchange resources offline) 3. Upgrade the Exchange Virtual Server (EVS) Move the offline EVS to rebuilt node (node1) On node1, right click the System Attendant resource and select upgrade EVS The upgraded EVS cannot be failed over to run on the older version node (node2). To prevent this from happening change the System Attendant resource possible owner list to include only the upgraded node. Right click the System Attendant resource and select properties. On the “general” tab next to “possible owners” click “modify”. Under Possible owners select the name of the node that hasn’t been upgraded, and click the ? arrow button to remove it from the list. Click ok. Bring the EVS online 4. Repeat 1-2 (with node2 as the passive node) Running Exchange setup on node2 should add it back to the possible owner list for the System Attendant resource After both existing nodes are upgraded to Windows Server 2003 additional nodes can be added to the cluster. Issues: Full Text Indexes begin a Full Population after upgrading the Exchange Virtual Server After the cluster node has been upgraded to Exchange 2003, the Exchange Virtual Server has been upgraded, and the cluster resources come on-line, a full population will begin on all full-text indexes and the indexes will be disabled for searching. To avoid having the full population begin automatically, manually start and then pause a full or incremental population on all the full-text indexes on the server prior to upgrading the Exchange Virtual Server. If the indexes are already paused when you upgrade, they will remain paused and the upgrade will finish normally. After you have finished upgrading, you can manually resume building the indexes when it is convenient to do so. Once the indexes have been built, you can enable searching on the newly built indexes. One Way Upgrade Once an EVS is upgraded it cannot be run on a node with older versions of Windows and/or Exchange. Other Applications Must Be Installed Again After Upgrade Workflows, virus scanning, event sinks, and any other application installed on your existing server will need to be reinstalled and configured. Make sure all applications you are planning to bring forward are compatible with the newer versions of Windows and Exchange. Customized Registry Keys Lost Any feature that is enabled by setting a registry key (such as journaling) will not be carried forward with this upgrade. Any customization, performance tuning, manually set or altered registry key will not be persisted using this upgrade method. These will need to be manually reset. No Active/Active support Using this method of upgrading Active/Active clusters is not supported. Risk of Downtime Increased by time between upgrading first and second nodes Once the Exchange Virtual Server has been upgraded it cannot be run on the older version node. If anything happens to the upgraded node during this time, it has no passive node to fail to. To reduce the risk of downtime, upgrade the second node soon as possible after upgrading the first. The risk of downtime is increased the longer the EVS has only one node available to run on. - Carol SwalesSo 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 SwaffordAre ghosts modifying distribution groups in your mixed-mode environment?
We've seen a few issues recently where members of DGs (Distribution Groups) in mixed-mode Exchange 200x and 5.5 seem to randomly and mysteriously disappear. We thought we'd share one known root-cause and also show you how to prevent the problem while doing your migration, if for whatever reason you are still running Exchange 5.5 =). One easy way to prevent this problem (and a few others) is to ALWAYS use the Exchange 2003 post SP1 cross-site mailbox migration wizard if you ever have to move mailboxes in a mixed-mode environment. With that said, typically the problem occurs when you use a directory export/import to move mailboxes between Exchange 5.5 sites. For example, if you have two Exchange 5.5 sites Site S (Source) and Site D (Destination) and you would like to move all the mailboxes in Site S to Site D you might perform the following steps. (When we refer to a DL we mean a Distribution List on the Exchange 5.5 side and when we refer to DG we mean a Distribution Group on the Active Directory side) Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source Exchange 5.5 server in Site S Delete the source mailboxes in Site S Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also wait for the Active Directory Account to become mailbox-disabled. Do a directory import of the mailbox information in Site D to recreate the mailboxes. Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site The problem occurs after step 4. The following key points should help you understand why. Replication between Exchange 5.5 sites is governed by USN-Changed values. Any changes made to an object in a directory in one site only replicate to other sites if that object's USN-Changed value is higher than the corresponding value in some other site. For the special case of a mailbox deletion, you would expect the USN-Changed value for any DL that the mailbox is a member of to increment after the mailbox deletion. This is, however, not necessary because when you delete a mailbox from its 'home' site, the member property of the DL changes and the read-only copy of the mailbox in all the other sites gets deleted. When the read-only copy is deleted in all the other sites the DL membership is updated as well. The salient point is without incrementing a DL's USN-Changed, all the necessary changes for the sites to be in-sync are properly accounted for. This works well for a pure Exchange 5.5 environment but creates a problem for a mixed-mode one with an ADC (Active Directory Connector) in the mix. As we know, the ADC compares the msExchServer2HighestUSN value on the RCA (Recipient Connection Agreement) to the USN-Changed value of an object in the Exchange 5.5 directory to determine whether the Exchange 5.5 object should be replicated to the AD. If the USN-Changed on an object is greater than the msExchServer2HighestUSN on the RCA, the object has been changed in the Exchange 5.5 directory and needs to be updated in the AD. If msExchServer2HighestUSN is greater than or equal to USN-Changed, no changes have occurred on the 5.5 object that need to be updated (replicated to) on the AD side. See the following knowledge base article for further details 253840. In this situation, since the DLs' USN-Changed isn't incremented in the 5.5 directory when you delete the mailboxes, the corresponding DG (Distribution Group) membership in the AD isn't updated. If you later make changes that increment the USN-Changed on the DL, the entire object (including the earlier deletions) is replicated to the AD side and so some members seem to randomly disappear from the DG's members list. While replication in Exchange 5.5 is object-based and replication in the AD is attribute-based, Exchange 5.5 to AD replication is still object-based (think lowest common denominator). The solution to this problem is to force the USN-Changed on the DL to increment after performing the deletions in step 3. A DL's USN-changed increments under the following scenarios: If you use the Exchange 5.5 Administrator program to open the DL's properties, modify any value and click Apply or OK (Or if you modify the DL's properties by doing an directory export/import with the standard header fields) If you use the Exchange 5.5 Administrator program to open a mailbox's properties and remove a DL from the list of DLs that the mailbox is a member of If the DL is updated by DRC or ADC replication changes from other 5.5 sites or from the AD respectively Again, a DL's USN-Changed does not increment when you use the Exchange 5.5 administrator program to delete a mailbox from the DLs membership. To force the USN-Changed value on the DL to increment you need to make a 'dummy' change that falls under a, b or c after step 3. Our new steps to ensure we avoid the problem would therefore be: Extract all the DLs of the mailboxes you intend to migrate Export the directory Information from the source 5.5 server in Site S Delete the source mailboxes in Site S Use the Exchange 5.5 Administrator program to modify the "notes" field on all the DLs that contained the deleted mailboxes to force an increment of USN-Changed value. This step is critical Wait for the two Exchange 5.5 sites to synchronize the mailbox deletions. You may force DRC (Directory Replication Connector) replication at this stage to speed things up. Also trigger RCA replication and make sure that the 'member of' list for the AD user accounts that correspond to the deleted mailboxes is empty (except built-in groups such as Domain Users etc) Do a directory import of the mailbox information in Site D to recreate the mailboxes Move the mailboxes from the Exchange 5.5 server in Site D to the Exchange 200x server in the same site. Add the migrated mailboxes to the corresponding DLs manually using the Exchange 5.5 Administrator program. This step may not seem necessary but it is. Usually an administrator may notice that the member list is still present on the AD after performing the previous steps and therefore assume that nothing more needs to be done on the Exchange 5.5 side. Later when some other change increments the USN-Changed the deletions replicate to the AD and members seem to randomly disappear from DGs. Everything should work fine and dandy at this point and you needn't worry about 'ghosts' modifying your DGs! - Jasper Kuria and William YangMail Flow Troubleshooter in Exchange Troubleshooting Assistant (ExTRA) - A closer look
Have you tried the "Exchange Mail Flow Troubleshooter" in Exchange Troubleshooting Assistant v1.0 (ExTRA)? This is a new troubleshooter that you can use to troubleshoot common mail flow problems you see on Exchange servers. It is designed to identify the root cause of detected symptoms so that you can take a right course of corrective actions quickly. For example, the mail flow troubleshooter can identify common root causes such as: Messages backing up in remote delivery queues due to bad DNS configuration or unintentional third party software settings Messages backing up in the Messages awaiting directory lookup queue due to heavy distribution group expansions or permissions inheritance blocks Messages can not be received from the Internet due to metabase corruption For this blog post, I would like to introduce some of the features of this troubleshooter for Exchange 2000 Server and Exchange Server 2003. When you select "Mail Flow Troubleshooter" at the Task Selection screen, you will be presented with the selections of symptoms you would like to troubleshoot. 1. Users are receiving unexpected non-delivery reports when sending messages When you or your users receive a non-delivery report, this is the one you would like to select. The tool will further prompt you what DSN code the non-delivery report contains and provide you with guidance on what the DSN code generally means and what actions are suggested. For example, for the DSN code 5.1.6, you will see the following message in the output report: "The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted. Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid." For some DSN codes, the tool checks whether the records in DNS are consistent. In this v1.0, not many troubleshooting functions for non-delivery reports have been automated but we expect that more will be in future releases. 2. Expected messages from senders are delayed or are not received by some recipients You would like to select this when you or your users see symptoms like the following: - Your organization is not receiving any messages from the Internet - Some users can receive mails from the Internet but some users can not The possible root causes of this kind of issues (or mail flow issues in general) can vary from a transient network condition to a suboptimal SMTP configuration. Thus the mail flow troubleshooter executes a wide variety of troubleshooting steps. Area Troubleshooting Steps Connectivity - 'Ping' the designated gateway/bridgehead server to check general network health - Test connectivity over port 25 and other designated SMTP ports to the designated gateway/bridgehead server - Check SMTP service / SMTP virtual server status - Check filtering configuration (Sender ID, IMF, Recipient, Connection, Sender) Mail Acceptance - Send a test mail from the designated gateway/bridgehead to the designated address - Check for known SMTP proxies that may be blocking SMTP conversations Message Tracking - Scan message tracking logs beginning from the sending server to the destination server to see how far the test message has traveled (start the queue troubleshooter if a backup is detected) Domain Routing - Verify that local domains are correctly registered in the metabase (e.g. an error will be logged if a local domain is registered as an external domain in the metabase) Here are a few examples of the result output for this symptom. 3. Messages destined to recipients are delayed or are not received by some recipients This is the opposite direction of #2 in terms of the mail flow. You may want to select this when: - No messages are going out to the Internet - You can not send messages to a specific domain - You can not send messages to a specific external address Here are the major steps the mail flow troubleshooter executes to troubleshoot this symptom. Area Troubleshooting Steps Message Tracking - Locate the most recent message submitted by the specified sender to the specified recipient - Scan message tracking logs beginning from the sending server to see how far the message traveled (start queue troubleshooting if a backup detected) Exchange Gateway - Check SMTP service / SMTP virtual server status - Check SMTP connector configuration Domain Routing - Check address space (remote domain) settings in SMTP connector and metabase 4. Messages are backing up in one or more queues on a server We call this the "Queue" troubleshooter. It can be launched directly from the Task selection screen as well as it may be triggered by selecting #2 and #3 above. In many cases when we troubleshoot issues like "mails are not coming from the Internet" or "mails are not going out to the Internet," we find out that messages are actually backing up in a queue on an internal Exchange server. In these cases, the mail flow troubleshooter triggers the "Queue" troubleshooter automatically. For this first release, we mainly focused on developing the troubleshooting steps for the following SMTP queues. - Remote delivery - Messages awaiting directory lookup - Local delivery That said, we have general troubleshooting steps for other queues such as "Messages pending submission" and "Messages waiting to be routed" and expect adding specific troubleshooting steps for those queues in future releases. Area Troubleshooting Steps Queue Status - Detect any retry/frozen queues and also queues with a large number of messages Remote Delivery - Test whether DNS servers can be accessed from the "problem" server - Check whether DNS returns valid records for the remote hosts - Test connectivity to the remote hosts (ping, port 25) - Check remote SMTP virtual server configuration/status - Throw various SMTP commands (e.g. BDAT) - Check metabase for event sink registrations - SMTP Proxy existence - Detect antivirus software blocking SMTP ports - Link state check Messages awaiting directory lookup - Categorizer performance - DL expansion checks - Check for common destinations in messages - Check file version for known bugs - Check journaling configurations - Check whether permissions inheritances are correct - Investigate disk performance - DC/GC availability Local Delivery - Check for any dismounted databases - Check for missing SMTP system mailboxes - Event 326/327 occurrence - Common issues (PF hierarchy, Missing working directory, etc.) Here are some examples of the result output for this symptom. Thanks for your interest in the new tool. Please feel free to post comments to this blog post. Also visit microsoft.public.exchange.tools newsgroup for more discussions. - Haruya ShidaIntroducing 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 ZhuHow does duplicate detection work?
Duplicate detection of delivered messages is done by the Exchange store. The store does duplicate detection based on two properties on the message - the Internet Message Id and the client submit time. We would have liked to do duplicate detection based solely on the Internet Message Id but there are several not-to-be named applications out there that use the same Internet Message Id on all their messages. The store keeps track of duplicates using a table in JET called the DeliveredTo table. When a message is delivered to a user, the store checks this table and if no entry is found the message is delivered to the user and a row is added to this table to indicate that the user received the message. If an entry is found, the message is turfed. The store only tracks duplicates for 1 hour by default. This can be changed by changing the value of registry setting: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Track Duplicates (in hours) The maximum value that the store will accept for this registry value is 49 days, if a value greater than 49 days is set, the store will ignore the value and keep duplicates for 24 hours. But keep in mind that increasing this value will cause this table to grow really large and this could slow down delivery. The store will periodically delete the old items from the deliveredTo table which is handled by the background cleanup thread which runs every hour. This is also configurable and the registry setting is: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\<Private/Public-Guid>\Background Cleanup (in msecs). There is still a chance that you will get duplicate email if the delivery of email is delayed because of the following reasons: 1) If either the internet message id or the submit time is different on the two messages, the second message will not be treated as a duplicate. 2) If the two are the same, but time interval between the arrival of the two messages is greater than 1 hour, the store cleanup task would have deleted the original entry in the deliveredTo table and the user will get duplicates. 3) If the user is moved. The deliveredTo table is per database and the information is not moved when the user's mailbox is moved. 4) In older versions of Exchange we had a problem where duplicates would occur when a message was sent to a user and a DL containing the user using OWA. When the message was submitted the store would stamp an Internet Message Id on the outgoing message. However, since OWA submits messages with native MIME and the fact that the Internet Message Id stamped by the store on submission did not update the MIME Message Id header, the MAPI message was out of sync with the native MIME. The message would then be bifurcated by Transport and this would result in messages with different Internet Message Ids and therefore, duplicates. We changed this in Exchange 2003 so that the store only stamps the Internet Message Id on a message if it detects that the MIME has to be regenerated or if it is a pure MAPI message. - Jaya MatthewFun with changing E-Mail Addresses
One may think that making changes to the e-mail address of a mailbox is a simple thing, but Exchange does a bit of work to ensure the changes are correct and will not cause problems in the system. Here's an overview of how the UI updates e-mail addresses and how it validates and checks for uniqueness when changes are made. E-Mail Address Attributes Exchange stores and uses information about the e-mail addresses of a recipient in the following attributes: proxyAddresses This is the main attribute where e-mail address information is kept. When you open the properties of a recipient in Outlook and look at the "E-mail Addresses" tab, you are looking at this attribute. This is a multi-valued string containing all the addresses that represent the recipient. Each value must have the following format: type:address For example: SMTP:nospam@online.microsoft.com When the type is in uppercase letters, the address is considered to be the primary address of that type and it is used as the default reply address of that recipient. When the type is in lowercase letters, the address is considered a secondary address and is used to resolve addresses during e-mail delivery, allowing the same recipient to receive e-mails directed to different e-mail addresses. For example: Primary: SMTP:currentAlias@domain.com Secondary: smtp:oldAlias@domain.com On the 'Users and Computers' snap-in, this property is edited on the 'E-mail Addresses' page of a recipient. targetAddress In contacts and mail-enabled users this attribute contains the type and address of the mailbox represented by the recipient. This will point to a mailbox outside the Exchange organization, for example, to a hotmail account or to another's company address. On the 'Users and Computers' snap-in, this property is edited on the 'Exchange General' page of contacts and mail-enabled users. mail The value of this attribute corresponds to the primary SMTP proxy address. Windows often displays this attribute as the e-mail address of the user. On the 'Users and Computers' snap-in, this property is edited on the 'General' page of recipients. textEncodedOrAddress The value of this attribute corresponds to the primary X400 proxy address. On the 'Users and Computers' snap-in, this property is edited by changing the primary X400 address on the 'E-mail Addresses' page of recipients. It is important to note that the values found in mail, textEncodedOrAddress and targetAddress must also be included in proxyAddresses with their respective types, otherwise they would not be picked up when Exchange makes searches against proxyAddresses. However, this creates a problem: we actually need to keep these attributes synchronized to each other when the administrator makes changes to them, either in the UI or with CDOEXM. The problem is aggravated because in 'Users and Computers' Windows implements the property page that sets the mail attribute, while the Exchange extension implements the property pages with targetAddress and proxyAddresses. Not only do we need to synchronize changes when the property page is saved but we need to synchronize when the administrator flips from one page to the other, to keep the UI consistent. To do that, we run what we call the proxy-sync mechanism. Proxy-Sync Scenarios Proxy-Sync runs when an administrator makes a change in one of the e-mail attributes of a recipient and that change needs to be synchronized to another attribute. For example, when mail changes, the primary SMTP entry in proxyAddresses must also be updated so that both addresses are synchronized, but if you try to delete the mail attribute without mail-disabling the recipient, then we copy the primary SMTP address back to mail. The following list summarizes the changes supported by proxy-sync since Exchange 2000 SP2: 1. Action: Remove e-mail from General page. Results: Primary SMTP from proxyAddresses is copied back to mail. 2. Action: Modify e-mail on General page. Results: There are four cases to be considered: o If the new address already exists in proxyAddresses and: · it is the primary SMTP address: proxy is in sync already. · it is a secondary SMTP address: demote the curr ent primary SMTP and promote the new address to primary SMTP. o If the new address does not already exists in proxyAddresses and: · targetAddress is the primary SMTP: demote the current primary SMTP and add the new address as primary SMTP. · targetAddress is a secondary SMTP: replace the primary SMTP with the new address. 3. Action: Modify the primary SMTP on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary SMTP is copied to mail. 4. Action: Modify the primary X400 on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary X400 is copied to textEncodedOrAddress. 5. Action: Modify the address corresponding to targetAddress in the E-mail Addresses page. Results: The new address is copied to targetAddress. Actions 3 and 4 also apply if the edited address is a primary proxy. 6. Action: Modify the targetAddress in the Exchange General page of contacts and mail-enabled users. Results: The following rules are applied: o If the old targetAddress is the primary SMTP and the new targetAddress: · is also SMTP: remove the old primary SMTP. · is not SMTP: keep the primary SMTP intact. · In either case, continue following the next rules: o If there is already a primary address for the same type, add the targetAddress as a secondary address. o If there is not a primary address for the same type, add the targetAddress as a primary address and if it is SMTP or X400, copy to mail or textEncodedOrAddress, respectively. E-mail Address Validation Well, now that all our e-mail addresses are synchronized, we can try to save them, right? No, we are not quite there yet. Before saving we must make sure that all addresses are valid, according to their type. When validating the proxyAddresses attribute, we'll check the following: o There must be a primary SMTP address o There can be only one primary address of each type o Every secondary address type must have a corresponding primary address o All addresses must pass validation of their type · This is actually done by the proxy generation DLL associated with each type. I won't go in details on that here since you can find more information about them in MSDN. · Now, these DLLs will not be installed in an admin-only installation, so we need to RPC to an Exchange server and let the server perform that validation. The Exchange System Attendant service responds by calling each proxy DLL and letting them validate the e-mail addresses typed by the user. Can we save now? Close, but not yet. There is still one step left. Uniqueness Check We would not like to let an administrator accidentally create duplicate e-mail address when we can prevent that from happening. I mean, if that happens messages would start returning, people will complain and everybody gets frustrated. So let's do this one last thing before saving changes to the e-mail addresses of a recipient: let's make sure they are all unique in the organization. To do that, we perform an LDAP query against the Global Catalog, looking for any object that has any of the proposed values in its proxyAddresses attribute. The query will look somewhat like this, with as many clauses as e-mail addresses we need to check: (| (proxyAddresses=SMTP:alias@domain.com) (proxyAddresses=smtp:alias2@domain.com) ) Of course, we need to properly format and escape the e-mail addresses in the query but most importantly, we need to be aware of the fact that there may be one object with the same addresses that we're trying to save, which would be the object we are editing. That one is ok, but if anyone else shows up in that query, we have a duplicate and we do not allow the changes to be persisted. What about Recipient Policies? You may be wondering why I haven't mentioned Recipient Policies anywhere. The process described above happens in the user interface, completely independent of Recipient Policies. It goes without saying that once the recipient is updated, Recipient Policies will go make sure everything is according to policy, but that's another story. - Fabio PintosBasic Authentication and Exchange Online – July Update
Today we are pleased to announce some new changes to Modern Authentication controls in the Microsoft 365 Admin Center, exposing simpler options for customers to manage both Modern and Basic Authentication requirements within their organizations.
