Why all Exchange ActiveSync experiences aren't the same and how to know what you are getting
One of the most frequent questions I get as the Product Manager for Exchange ActiveSync (EAS) is for a list of EAS -enabled devices customers can use for mobile email and what functionality they support. This is often a difficult thing to provide since Microsoft licenses patents (which are Microsoft’s Intellectual Property) to EAS licensees. Along with licensing our Intellectual Property (IP), we provide public access to the Exchange ActiveSync protocol documentation. IP licensing does not include Microsoft writing the code for the licensee’s devices or services— that would require Microsoft to write the code for each of the many platforms licensees have and also make us update it every time those platforms were updated. As part of their implementation, each licensee makes the decision about what parts of EAS they want to implement and how they might best want to do it with their platforms. We always try to work with our licensees to help them create great experiences, but at the end of the day it’s up to each licensee to decide what features they want to make available to their customers. Since each licensee does their own implementation of the EAS protocol, many people ask if there is a list of features implemented by each licensee, so that they can determine which devices meet their organization's needs. A helpful chart of some of the more common implementations (Windows Phone, Nokia (Symbian), iPhone (iOS), Palm Pre (WebOS), Android, etc.) can be found in Comparison of Exchange ActiveSync Clients. You may notice that this chart is posted on Wikipedia. This is another way that information is available to the Exchange community, and since it’s a Wiki, you’re all able to contribute! With always updating software, new devices coming out, and a growing number of EAS licensees making options available, EAS devices are a particularly hard thing to keep track of. We think this is an easy way for each of you to share the information you discover with each other, and a way of building upon some of the great work some of you in the Exchange community are already doing (here’s an example). We hope this can be a useful resource to you in managing mobile devices on Exchange and that you are able to help contribute to the benefit of all folks managing Exchange-connected devices. Adam Glick Sr. Technical Product ManagerWhat's new with Microsoft Remote Connectivity Analyzer? A lot!
Have you ever gotten a call from someone you know whose Outlook client is having trouble connecting to their email server? Don’t you just wish you had a tool that you could send to them that would walk them through a connectivity test and provide a simple way for them to send the results back to you? Or perhaps you’re an administrator that has been using the Remote Connectivity Analyzer for years to verify email configuration, but wish you had a way to verify the same tests from within your organization, that provided the same diagnostic details as the RCA website? We’ve heard requests like these, and our team has built a tool for just these scenarios. I’d like to introduce you to the Microsoft Connectivity Analyzer (beta), a portable version of the Remote Connectivity Analyzer website. Here is a short 49 second video that introduces the Microsoft Connectivity Analyzer. This tool contains the same tests as the website, in a slightly simpler UI – something you can share with your users, family, or your neighbor down the street. In addition, we’ve split the results into two views – a simplified view which only shows results that your mom could understand, and the full detailed results that only an administrator would love (yes, that’s you). And the additional details for administrators is shown under “Review all the tests we ran”: Or ask your user to save the detailed results and send them to you! The detailed results are saved as an HTML file and can be viewed in your browser. Microsoft Connectivity Analyzer Pre-Requisites The tool supports the following operating systems: 64bit Windows 7, Windows 7, Windows Server 2008+ Microsoft .NET Framework 4.5 is required. Browsers requirements: The installation will work on all modern browsers. However… If you are using Google Chrome, you will need to install ClickOnce for Google Chrome If you are using FireFox, you will need to install Microsoft .Net Framework Assistant for FireFox. You can find the full release notes here. We're not finished yet. We have plans to add additional tests. Just like when we first released the website, this first version of the Microsoft Connectivity Analyzer is a work in progress. Having a tool on site with the end user, we’ re in a unique position to extend the testing to include common problems with all types of connectivity. This early version of the tool is just the beginning. And that’s not all! In addition to providing a new tool, we’ve joined forces with the Lync Remote Connectivity Analyzer, and brought the two tools together. You’ll notice we’ve dropped the “Exchange” from the name, and we have a new way to access the website: http://testconnectivity.microsoft.com. That’s right – all the same great tests for Lync and Exchange available on the same website. Tests include: Microsoft Lync Mobile Auto-Discover Web Service Remote Connectivity Test will test your remote connectivity to the Microsoft Lync Mobile Auto-Discover Web Service Server Microsoft Office Communications Server Test will test your remote connectivity to the Microsoft Office Communications Server, it will auto-discover the Access Edge and port to connect to, OR allow you to specific an Access Edge server. Microsoft Lync Server Remote Connectivity Test will test your remote connectivity to the Microsoft Lync Server, it will auto-discover the Access Edge and port to connect to, OR allow you to specific an Access Edge server. But wait, there’s more… Did we mention we’ve been busy this year? On the Office 365 tab, you’ll notice two new tests – the Office 365 Lync DNS test, and the Free/Busy test. The Office 365 Lync DNS Test will check the external domain name settings for your custom domain user in Office365. Thanks to the Office 365 Deployment Services team, the RCA website now hosts the Office 365 Free/Busy test. This test verifies an Office 365 mailbox can access the free/busy information of an on-premises mailbox and vice versa. This includes: a check to confirm the system time of the hybrid server is not offset by more than five minutes, which causes failures when requesting delegation tokens from the Microsoft Federated Gateway. a check to verify inbound connectivity to the hybrid server does not require firewall pre-authentication; that is, the firewall allows pass-through authentication. a check to verify the hybrid server meets the minimum Exchange Server version requirement (Exchange Server 2010 SP1). a basic free/busy query against the target Availability Service. Links to guidance on the Hybrid Configuration Wizard, a common source of hybrid deployment misconfiguration Phew! Thanks for reading this far. We hope you enjoy the new updates, and we look forward to hearing from you, Nicole Allen On behalf of the RCA teamRobert's Rules of Exchange: Namespace Planning
Overview Robert's Rules of Exchange is a series of blog posts in which we take a fictitious company, describe their existing Exchange implementation, and then walk you through the design, installation, and configuration of their Exchange 2010 environment. See Robert's Rules of Exchange: Table of Blogs for all posts in this series. Namespace planning is a serious topic that must take place relatively early in the Exchange 2010 planning and deployment process. Many companies choose to purchase certificates from a third party certificate authority (CA) rather than deploy a certificate generated from an internal CA , as this ensures the majority of devices have a trusted root certificate. I'll purchase a certificate from a CA for this series. Deploying a certificate with the incorrect namespace values can be costly as you will have to generate a new CSR and thus repurchase a new certificate with the correct namespace values because you didn't plan correctly. Some CAs will allow you to resubmit a CSR and issue you a new certificate at no charge.) In this article, we'll talk about a few of the things you must consider when planning your Exchange 2010 namespaces. The Big Three There is some great documentation written around namespace planning for your CAS deployment. For instance: The TechNet article Understanding Client Access Server Namespaces, which take you through the thought processes around multiple datacenter models and the kind of namespaces you'll need for each of those datacenter models. Our Transitioning Client Access to Exchange Server 2010 post, which calls out the simple model where we need mail, autodiscover and legacy namespaces for our Internet domain. We're going to go a bit beyond those three namespaces for our deployment, but we do need to start with this list of "big three" namespaces. For the Robert's Rules scenario, we'll have a single main Internet "Point of Presence" or PoP in the HSV (Huntsville, AL) datacenter, with plans to fail over to a secondary PoP in the LFH (Lightfoot Hollow, Winchester, TN) datacenter if necessary. All client access will come in through the main namespace mail.robertsrules.ms. This includes Outlook Web App (OWA), Exchange ActiveSync (EAS), Offline Address Book (OAB) downloads, and the Availability Service (and all other Exchange Web Services clients). For Autodiscover, we will use autodiscover.robertsrules.ms. And for our legacy OWA redirection, we will use legacy.robertsrules.ms. So that's our "big three" for our namespace planning. I would propose to you that all three of these will be needed in any single forest Exchange 2003/2007 to Exchange 2010 upgrade/coexistence scenario. Obviously, if you're not upgrading from Exchange 2003 or 2007, you won't need the legacy.robertsrules.ms namespace; or, if you're moving between forests, it's quite possible that you'll have a different set of name designs. Redirect Sites With the single mail.robertsrules.ms namespace defined for user access, we can function in a world where we only have a single Internet PoP and we'll always proxy HTTP requests to the secondary datacenter. This is one of the scenarios that I want to demonstrate in this series, so we'll show this and demonstrate how the client experience differs from other scenarios, but it's not really what the Robert's Rules requirements dictate. Because Robert's Rules requires that we have a secondary PoP for Internet access, even if we won't use it except in cases of a total failure of the primary datacenter, we'll need to have a second namespace for general user access. For this, we'll utilize mailLFH.robertsrules.ms. As you'll see in the next section, we'll utilize this secondary namespace for other reasons as well. CAS Array Names The ClientAccessArray (as created with the New-ClientAccessArray cmdlet) is a logical construct in Active Directory designed to group together Client Access servers located in an AD site in a single namespace. This namespace is then applied to the mailbox databases that are hosted in that AD site (the RpcClientAccessServer attribute of the mailbox database), and that name's returned to Outlook and other RPC clients as their MAPI target server. For more details, see Understanding RPC Client Access. I said above that the namespace planning is important because we need to get our SSL certificate names (the subject name and subject alternative name - or SAN - fields) correct. Wait. What? MAPI doesn't use SSL certs! So why do we care about a name for the "CAS Array"? The answer is that I'm not talking about the ClientAccessArray object. Yes, it's a bit confusing, but I'm talking about a load-balanced array of Client Access servers, created using the Network Load Balancing feature in Windows Server or by using a hardware load-balancer. The Client Access servers in the load-balanced array may or may not be the exact same servers as those in the ClientAccessArray. During normal operations, both will generally include the same set of servers. The only time that they wouldn't be the same is during maintenance operations, when we may remove one or more servers from the load-balanced array temporarily. But those Client Access servers need to provide certain other services that may also be load-balanced, and therefore require SSL. Clients will need to find the virtual IP address (VIP) of the load-balanced array, and we'll therefore need a DNS record for that fully-qualified domain name (FQDN) so it can be discoverable. I don't know if there's a proper or accepted name for "the load-balanced array of Client Access Servers", but we're not talking about the ClientAccessArray object, just a name of that array used in DNS, so I choose to call it the CAS Array, and to be very specific and use the object name ClientAccessArray when talking about the object used for MAPI access. Until someone corrects me and provides a better name, I'll stick with it throughout this blog series. (In Windows' Network Load Balancing terminology, load-balanced arrays are called Network Load Balancing clusters -Editor) I will use OutlookHSV and OutlookLFH for my ClientAccessArray names (we'll need these FQDNs in DNS as well), but for HTTPS -type connections (and therefore our SSL certificate) I will use two names we've already chosen to use in other scenarios: mail.robertsrules.ms and maillfh.robertsrules.ms. FailbackURL Names In Exchange 2010 RTM (pre-SP1, that is), there's a situation that can happen during a datacenter failure scenario. During the "fail back" scenario when services are being relocated back to the primary datacenter, in some circumstances an OWA client will get a redirect that sends them to the server they just connected to, causing an outage for that user. For instance, let's use our names we just defined above and assume that the datacenter that hosts mail.robertsrules.ms has failed. We moved all services over to the LFH datacenter, including making some DNS changes to point users trying to find mail.robertsrules.ms to the VIP that is actually maillfh.robertsrules.ms. When we go to "fail back", we reactivate the services in the HSV datacenter, redirect DNS and everything seems to work as expected. But one thing we can't control from the servers is the client browser cache. Browsers can maintain their own DNS cache that is separate from the operating system. Internet Explorer (IE) has a cache that acts similar to the DNS TTL value (note that you can manage this setting on your clients - see KB 263558). If you haven't made these changes, IE will hang on to an IP address for a given URL for 30 minutes before it asks the OS to re-query DNS for a new IP address. You can clear this cache by restarting IE , but that's a poor client experience. This means that even if we set the TTL on the DNS record for mail.robertsrules.ms to 5 minutes, we could have up to 25 additional minutes where a client requests information from what it thinks is mail.robertsrules.ms but is really maillfh.robertsrules.ms. After you move the databases back over to the other datacenter, maillfh.robertsrules.ms replies back to the client, "Hey, welcome back. I see that your mailbox is in the other Active Directory Site and because the CAS in that site have an ExternalURL defined, please use that URL (which happens to be mail.robertsrules.ms) and try to log in." The user takes this redirect (the user is prompted, and the user manually accepts this redirect - meaning that there is no "single sign on" redirect here) and tries to reconnect to "mail.robertsrules.ms", asking the user to re-authenticate. Problem is that the IE cache is still pointing at the IP address of "maillfh.robertsrules.ms". So the client gets in a loop for up to 25 minutes with OWA just prompting for credentials over and over again. Not great — especially if that user happens to be the person who signs your paycheck. In Exchange 2010 SP1 (which we'll be deploying at Robert's Rules), we added the FailbackURL parameter to the OWA Virtual Directory (we'll set this using the Set-OwaVirtualDirectory cmdlet). When OWA detects that the client is in this looping condition, it'll redirect it to the FailbackURL. Thus, we have a cleaner fail back scenario which provides a better availability stance for our clients. To implement this, we need our FailbackURL values to be included in our list of SAN s. For our environment, I've chosen some equally obvious names: FailbackHSV.robertsrules.ms and FailbackLFH.robertsrules.ms. Email Delivery and SMTP Some organizations will have another namespace called SMTP. For instance, if you are supporting a POP or IMAP client base, you might want to have a secured SMTP namespace for the POP/IMAP users to connect. POP3 and IMAP4 are becoming less prevalent in Exchange customers, especially as more mobile devices support the Exchange ActiveSync protocol. I have chosen to not have a separate SMTP namespace for these users because we don't support POP/IMAP at Robert's Rules. Further, we'll use the mail.robertsrules.ms namespace for our Domain Secure demonstration. As such, we won't need the smtp.robertsrules.ms namespace in the Robert's Rules environment. This doesn't mean that it would be wrong to use the "smtp" namespace — we just chose not to in this environment. Putting It All Together Now we've defined 6 names we need to include in our certificate. It's possible that in some large organizations with Exchange deployed to many sites, you could have dozens, or even over a hundred names that you need to define. There is no rule that says you need to use a single certificate to support all of these various sites. In fact, the use of a wildcard certificate could be part of your plans. But wildcard certificates are sometimes quite expensive, and in my experience, "security guys" don't like wildcard certs and tend to push back on those. For our purposes at Robert's Rules, we'll purchase a single SAN cert, and include the following subject alternative names: mail.robertsrules.ms mailLFH.robertsrules.ms legacy.robertsrules.ms autodiscover.robertsrules.ms failbackHSV.robertsrules.ms failbackLFH.robertsrules.ms We'll designate mail.robertsrules.ms as the Subject Name. We'll talk more about how to order a certificate, the impacts of using a single certificate when using Outlook Anywhere, and many other things related to our namespace decisions as we move through the upcoming posts in this series. Stay tuned for more! Robert GilliesDoes your Transport think it is Squeaky Lobster Day in your CountryOrRegion?
Today is the magical day when parents tell their tucked-in children the story of the Squeaky Lobster. So here's a Squeaky Lobster-ish post to celebrate the day. In Exchange 2007, we introduced transport rules – a powerful feature that allows you to inspect different parts of a message such as sender, recipient, subject and headers and take actions like rejecting a message, deleting it, redirecting it to another recipient, adding a message header or a disclaimer. In previous versions of Exchange, you would need to write a transport event sink to accomplish similar things. With an easy-to-use interface in the EMC , transport rules make such tasks as easy as creating Inbox rules (created by users using Outlook/ OWA ). Command-line jockeys can create and manage transport rules using *-TransportRule cmdlets from the Shell. More about transport rules in Understanding Transport Rules. In Exchange 2010, we added a number of new predicates (which are used to create conditions and exceptions), including the ability to inspect attachment content and predicates to evaluate Active Directory attributes of the sender or recipients. A complete list of predicates can be found in Transport Rule Predicates. Ability to inspect Active Directory attributes of the sender or recipients dramatically increases the number of things you can check and the type of rules you can create. For example, you can check if the sender or recipients are in the same department, report to the same manager, check if the sender is the recipients’ manager (or the other way round), check the sender's title, city, state or country, amongst other things. The list of supported attributes is included in the Predicate Properties table in Transport Rule Predicates, or you can also see them in the New Transport Rule and Edit Transport Rule wizards in the EMC . Evaluate the sender's country or region You can use the predicate to evaluate the sender's country. This can be useful in many scenarios - for example, applying a disclaimer to messages based on the sender's country. Important: When using Active Directory attributes to meet business requirements, you must have appropriate processes in place to ensure the necessary attributes are populated and up-to-date. You can add the country/region property to a user or contact using ADUC , the EMC , the Shell or by using LDAP utilities. If you use ADUC or EMC, you’re greeted with a nice little drop-down list to pick a country/region from. If you use the Shell, you must use the corresponding cmdlet to populate the CountryOrRegion property – Set-User for user accounts, Set-Contact for contacts. Fig 1: You can select a recipient’s country or region from recipient’s properties in EMC You need to create a rule to check if message sender is from a specified country – let’s continue with Germany as the example, to apply a disclaimer. You can use the when the sender’s properties contain specific words predicate from the New Transport Rule wizard in EMC to check the CountryOrRegion property. The predicate allows you to pick a supported property and you can type in a string to match. For example, if you’re trying to match senders from Germany, you instinctively type in Germany. Fig 2: Checking a sender CountryOrRegion property using a transport rule But the transport rule doesn’t fire on any messages sent by recipients from Germany! You check the rule in EMC – it says Germany. It’s spelt correctly, no typos. You use the Shell to retrieve the properties: (Get-TransportRule MyRule).Conditions | fl * The value correctly displays as Germany: Words : {countryorregion:Germany} Name : SenderAttributeContains Rank : 36 LinkedDisplayText : when the sender's properties contain specific words IsValid : True You check the recipient’s country property using the Shell. Get-User bsuneja | select cou* Squeaky Lobster! The value is Germany! Why wouldn't the rule fire? The CountryOrRegion Property Although the CountryOrRegion property displays the country’s name (think of it as a display name), what’s stored in the Country-Name attribute (ldapDisplayName: c) in the recipient object in Active Directory is the 2-letter ISO 3166-1 country/region identifier for the country. For Germany, it’s DE. The full list of ISO codes can be found in the ISO 3166-1 decoding table . (Update: A better-formatted list can be found in ISO 3166-1 on Wikipedia). Note: Active Directory objects also have two more attributes to identify country or region: 1) Country-Code (ldapDispla yName: countryCode), which corresponds to the ISO 3166-1 numeric code 2) Text-Country (ldapDisplayName: co), which is the country name. However, only the Country-Name attribute is replicated to the Global Catalog. Update the rule Armed with this information, you can fix the rule in EMC. Figure 3: Use the Edit Transport Rule wizard to update values for the CountryOrRegion property Or use this command from the Shell to update the SenderADAttributeContains predicate. Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE” Happy Squeaky Lobster Day! Bharat SunejaExchange ActiveSync and Windows Phone 7 phantom data issue
Some of you may have seen stories about higher than expected data usage for a very small percentage of Windows Phone 7 users being caused by an inefficiency between Windows Phone 7 client and Yahoo! Mail. You may have also seen that these stories mention that there is a separate Exchange ActiveSync (EAS) issue that is impacting a small percentage of users. Unfortunately, like a game of telephone, many of the stories I've seen are combining these two issues into one, or mentioning both of these issues as if they have equal impact on users. For the record, Yahoo! Mail is not connected to Windows Phone 7 using EAS , and the Windows Phone 7 EAS implementation issue is much smaller. In some of the most egregious cases, some have called this a protocol level bug in EAS . This is untrue — this is a client issue. We on the Exchange team know that you all work very hard to make sure your Exchange servers are running well, so we wanted to get you some good information (straight from us here at Microsoft) about these issues. First off; for administrators, there's no need for any changes to your Exchange servers — the issues here are client-side and thus do not impact your servers nor increase the load on your servers. That said, we know that many of you work closely with your users and always try to help them out with good support information. If you have users who are contacting you about this issue or may be impacted, there are mitigations available for each of these issues while the Windows Phone 7 team continues to work with Yahoo! on a full software fix that is expected in the near term. For Windows Phone 7 EAS issue, users might see increased data usage when a message is "stuck" in their outbox. A user might encounter this state if they send email to an invalid email address or if they send a message that's larger than the allowed message size (server side policy) from their phone. In these cases, users can go to their Outbox folder and delete the stuck message and the phone's data use will return to normal. Below are the steps a user can take to see if there is a message stuck in their outbox and how to delete it. Note: This impacts only a very small percentage of Windows Phone 7 users and does not impact EAS users on other phone platforms. Click the folder icon at the bottom of the EAS -enabled inbox Select the Show all folders option Select the folder called Outbox (if you have a lot of folders, you may have to scroll down to see this folder) Delete any messages in this folder The Yahoo! Mail issue is not connected to EAS, but users can lessen the impact by changing the frequency that the Yahoo! Mail account is checked for new messages. Below are the steps to make this change: On the Start screen of Windows Phone 7, click on the arrow at the top right Choose Settings from the app list Choose email & accounts Choose Yahoo! Mail Click on the setting under Download new content Select a less frequent setting. If you are using the default setting (every 2 hours), change this setting to manually Click on the setting under Download email from Select a shorter time range. If you are using the default setting (the last 2 weeks), change this setting to the last 7 days Adam Glick Sr Technical Product Manager - ExchangeAnnouncing Microsoft Connectivity Analyzer (MCA) 1.0 and Microsoft Remote Connectivity Analyzer (RCA) 2.1
Back in November 2012, we announced our MCA Beta client. We have been very busy working to improve the testing options that are available from the MCA client. Here’s what we’ve built for the 1.0 release: Microsoft Connectivity Analyzer Tool 1.0 We are excited to announce the 1.0 release of the Microsoft Connectivity Analyzer. This tool is a companion to the Microsoft Remote Connectivity Analyzer web site. The MCA tool provides administrators and end users with the ability to run connectivity diagnostics for five common connectivity symptoms directly from their local computer. Users can test their own connectivity, and save results in an HTML format that administrators will recognize from viewing results on the RCA website. Install the MCA 1.0 tool here: https://testconnectivity.microsoft.com/?tabid=client Watch the Introduction Video: The MCA tool offers five test symptoms: “I can’t log on with Office Outlook” – This test is equivalent to the Exchange RCA test for “Outlook Anywhere (RPC over HTTP)”. There is an option to run the SSO test provided on the parameters page. “I can’t send or receive email on my mobile device”. – This test is equivalent to the Exchange RCA test for Exchange ActiveSync. ***New MCA Test*** “I can’t log on to Lync on my mobile device or the Lync Windows Store App” – This test checks for the Domain Name Server (DNS) records for your on-premise domain to ensure they are configured correctly for supporting Mobile Lync clients. Also it connects to the Autodiscover web service and makes sure that the authentication, certificate, web service for Mobility is correctly set up ***New MCA Test*** “I can’t send or receive email from Outlook (Office 365 only)” – This test checks Inbound/Outbound SMTP mail flow and also includes Domain Name Server validation checks for O365 customers. ***New MCA Test*** “I can’t view free/busy information of another user” – This test verifies that an Office 365 mailbox can access the free/busy information of an on-premises mailbox, and vice versa (one direction per test run). Microsoft Lync Connectivity Analyzer Tool: You will also notice the Lync Connectivity Analyzer Tool on the client page. We are working on combining MCA with MLCA in the near future but wanted to make both these great tools available to customers now to improve our client diagnostics options. To learn more about MLCA – go HERE Feedback: Send all feedback to the MCA Feedback alias. Please let us know what you think of the tool and whether this will be helpful in troubleshooting connectivity scenarios. Also feel free to provide feedback on additional tests you would like to see added in the future. Microsoft Remote Connectivity Analyzer 2.1 We are excited to announce the 2.1 release of the Microsoft Remote Connectivity Analyzer web site. The tool provides administrators and end users with the ability to run connectivity diagnostics for our servers to test common issues with Exchange, Lync and Office 365. We have added new Office 365 Domain Name Server tests, enhanced existing tests, and improved the overall site experience. Check out the updates to the website here: https://testconnectivity.microsoft.com Here are the highlights of the 2.1 RCA release: Version 2.1 (March 2013) Added support for localized language support for 60 languages Updated version of the downloadable Microsoft Connectivity Analyzer v1.0 Tool for troubleshooting connectivity from the local machine Added Microsoft Lync Connectivity Analyzer downloadable tool for troubleshooting Lync issues from the local machine Added Office 365 General Tests section Added Office 365 Exchange Domain Name Server (DNS) Connectivity Test Enjoy! Thanks. Brian Feck on behalf of the entire MCA/RCA team. Follow the team on Twitter - @ExRCAMail 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 ShidaRecurring Meeting Requests with Conflicting Instances 2: The Power of Delegates
The key takeaway from my last post on this topic was that the Resource Booking Assistant never allows double booking of a resource room calendar as a result of a recurring meeting request (please see Automatic Processing of Recurring Meeting Requests with Conflicting Instances). Since there are times that an administrator may want to allow double-booking, we offered two workarounds that I’d like to address in a bit more depth. I'd also like to offer a third one that wasn’t mentioned before: 1) Send Follow-Up Nonrecurring Meeting Requests to Double Book Recall that if a recurring meeting series is accepted individual conflict notifications will be emailed to the organizer in addition to the acceptance email for the series. The organizer can use those declined-instance emails as a reference for following the first of our workarounds, which would be to send additional non-recurring meeting requests to double-book the intended resource room for each declined instance. This method, though laborious, allows fine control over when a resource is double booked and when not. Suppose on the other hand an administrator follows the second workaround, and hands control to a trusted delegate instead of the Resource Booking Assistant? A delegate has the human discretion to allow all recurring meeting conflicts to double book by accepting an entire recurring meeting series. It also turns out a delegate can selectively decline any number of conflicting instances while accepting the series, something the assistant cannot. The question came up about how exactly they can do this, so let’s take a look: 2) Allow a Delegate to Double Book Resources The request policy on a resource mailbox can be configured to require delegate control over resolving recurring meeting request instance conflicts. But how exactly do they use that power? What might the process look like, and what tools can they use carry it out? The best functionality for this is in Outlook 2010. Let’s go to an example. Say we have a resource room, called Green Room, which is managed by a delegate named Howard. As meeting requests for the Green Room come in Howard accepts them for the room calendar. Presently there’s a meeting scheduled for 2PM on Wednesday, and another for 3PM on the following Thursday. Now a new recurring meeting request with the Green Room as the room resource goes out to several recipients. The room’s request policy requires Howard to approve all meeting requests, so this new one gets forwarded to him. We see that the recurring meeting request is for four instances, Tuesday through Thursday, from 2:30PM - 3:30PM each day. Outlook helpfully points out (highlighted in yellow and also below the Calendar Preview) that two of the four instances conflict with the existing appointments: If Howard wishes to accept the entire series, and allow double booking he can just accept the whole thing. But what if he wants to decline one conflict, but allow the other? Howard can click on the arrow next to “Conflicts: 2” and get a preview of each area of the calendar where conflicts overlap with an existing appointment. He does so, and sees the first conflict is with the Wednesday, 2PM Catalog Review meeting: The second is with the Sales Presentation meeting on Thursday: Suppose Howard wishes to decline the double booking on Thursday, but let the Wednesday conflict get booked? To decline the Thursday instance he can simply double-click on the item in the Calendar Preview section of the forwarded meeting request. That action will open up a view for that time from the Green Room’s calendar. Howard can then right click on the instance that he wishes to decline, go to the Decline menu item, then select an option to decline just this occurrence: Now that Howard has determined which instance to decline and which to allow he can simply go back to the original forwarded meeting request, and accept the series. This will accept all the remaining instances while preserving the manually declined instances: So to summarize a delegate's power in this area, they can use the conflict notifications provided in Outlook 2010 to quickly decline (or accept) individual occurrences of a recurring meeting request. 3) Send a Series Update Without Changing Details There is a third known way of working around the Resource Booking Assistant’s refusal to double book a room due to a recurring meeting request. Thanks to feedback from a customer relayed to me by my colleague Patriciu Seliceanu, we now know that a meeting organizer can simply send an update for a recurring meeting but without changing any details. The amazing result is that conflict instances declined before are then accepted. This workaround of course requires that conflicts be allowed for single-instance meeting requests, which by default is enabled in virtue of the AllowConflicts attribute set to "True" for calendar processing settings. The update to the recurring meeting works because each recipient receives not another recurring meeting request, but an update meeting request (with no actual changes) for each individual instance. Since Exchange sees much the same as the single-instance meeting requests from workaround method 1 above it allows double-booking for each updated instance. This may save a bit of labor over the steps required in item 1 of this list, such as when the number of conflicts is high, and assuming every conflict should be double booked. In conclusion, there are a number of ways to work around the safety mechanism inherent in the Resource Booking Assistant which prevents recurring meeting request from double-booking a resource mailbox. The most robust and powerful of these is the intrepid delegate with Outlook 2010 at their fingertips and Exchange 2010 at the ready. Please note though that for the majority of cases, you should not even have to worry about doing this, as in most cases, the default behavior is the correct one. Thanks to Tom Kern for his help and counsel, and to Patriciu Seliceanu for method 3. Jesse TedoffIntroducing 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 ZhuAfter Installing Exchange 2010 Service Pack 1, Searching via OWA or Outlook Online Mode Fails
Update 7/2/11: The installation steps have been modified to make it clear the script must be executed on the Mailbox server using elevated credentials. With Exchange 2010 Service Pack 1, you may find that performing a search via Outlook Web App (OWA) results in an error message, “The action couldn’t be completed. Try again later.” Additionally, Outlook clients operating in Online Mode can no longer search for attachments or embedded emails. When this issue occurs, you will see the following events in the application log: Log Name: Application Source: MSExchangeIS Mailbox Store Event ID: 9877 Task Category: Content Indexing Level: Error Description: Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch. Mailbox Database: <Database Name> Error Code: 0x80043629 Log Name: Application Source: MSExchangeIS Mailbox Store Event ID: 9842 Task Category: Content Indexing Level: Error Description: Function CISearch::EcGetRowsetAndAccessor detected that content indexing was disabled for database '<Database Name>' because of error '0x80041820' from MSSearch. When you check the CatalogData folder in the same subfolder as the database, you may see that the content indexing files (.CI files) are not growing. If you perform a ResetSearchIndex.ps1 on the index, you may see that the total size of the CatalogData folder only grows to a few KB or a few MB and either no .CI files are generated or only a few .CI files are generated and are only a few KB each. What causes this issue? This problem typically is a result of installing or upgrading a multi-role server (a server that has the Mailbox, Client Access, and Hub Transport roles installed) to SP1 and then removing the Hub Transport and Client Access roles, thereby leaving the server with only the Mailbox role installed. There is a symbolic link for each language referenced in the registry, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\Language. The symbolic links (ActiveX CLSID of the class used) allow for word breaking and stemming for the locale corresponding to the language. During the Exchange 2010 Service Pack 1 uninstall process for the Hub Transport role, setup removes the symbolic links, regardless of the fact that the Mailbox role is still present. The removal of the symbolic links causes the generation of content indexing files to fail. How do we resolve this issue? You will need to execute a script on the affected Mailbox servers that reinstalls the symbolic links: Download the script Repair-ExchangeSearchSymlinks.ps1 from the Script Center. Copy the Repair-ExchangeSearchSymlinks.ps1 script to the Scripts directory on the Mailbox server (default installation is C:\Program Files\Microsoft\Exchange Server\v14\Scripts). On the afflicted Mailbox server, open the Exchange Management Shell by right-clicking the shortcut and selecting “Run as Administrator”. Within the Exchange Management Shell, navigate to the Exchange Scripts directory. Within the Exchange Management Shell, run the following script: .\Repair-ExchangeSearchSymlinks.ps1 Within the Exchange Management Shell, run the following script (without the symbols [] and substitute the database name(s) for any databases you wish to reset: .\ResetSearchIndex.ps1 [-force] <dbname> [<dbname>]... You will receive an Event ID 109 when the rebuilding of the index starts for each database and an Event ID 110 for each database when the index rebuild has completed. After receiving Event ID 110 for each database, test to make sure search functions correctly with both OWA and Outlook operating in Online Mode. Bob Want
