Moving mailboxes? Make sure your Deleted Mailbox Retention is not set to 0.
I wanted to bring to light a specific issue that may occur during mailbox moves in complex environments with multiple Active Directory Sites and multiple Exchange servers. There are several other settings which must be in place in order for this issue to present itself. First, here are the settings which need to be in place: 1. On both the Source and Target mailbox stores, set Deleted Mailbox Retention to 0 days. 2. Note what the Online Maintenance schedule is set to on both stores. The moves need to be scheduled to coincide with Online Maintenance on the Target mailbox store. *Note - for the purposes of my testing, I set Online Maintenance to run Always for my databases. 3. There must be multiple Active Directory Sites so as to introduce AD replication latency (Inter-Site connectors can only replicate every 15 minutes), and there need to be Exchange servers in these different AD sites (or Exchange must be configured to statically point to the GC of the other site). 4. Enable Diagnostics Logging under MSExchangeIS\Mailbox, and set the category General to Maximum (only minimum is necessary though). This is necessary in order to log Online Maintenance events. Some background here: one of the tasks performed by Online Maintenance is to identify mailboxes that are past the retention date and to delete them. As part of this task, it will also run the Cleanup Agent, which is the task that identifies orphaned/reconnected mailboxes. If you recall, in Exchange 2000 and 2003, if you delete a mailbox, it is not immediately deleted, nor is it marked as disconnected. If a mailbox is orphaned (no user connected to it), it gets marked as disconnected; if it is disconnected and past the retention date, it gets deleted. For more information on the tasks run during Online maintenance, please see the following link: http://technet.microsoft.com/en-us/library/aa996226(EXCHG.65).aspx During a mailbox move, the destination mailbox will be created so that data can be copied to it. This destination mailbox is not yet associated with a user account though. This process of associating with the user account does not happen until the very end of the mailbox move and all content has been copied to the destination mailbox. During the final step of the move, the user attributes are updated to point to the new server (if applicable) and new database. This process of updating attributes is what associates the destination mailbox with the user account. If you manually run the Cleanup Agent on the destination mailbox store during a move, you will find that the destination mailbox will show up as a disconnected mailbox. If you then run the Cleanup Agent again right after the move completes, you will find that in some cases the destination mailbox will also be purged. This can cause problems, because when a move is successful, the source mailbox is removed as well. If the Cleanup Agent is run from another Exchange server that is pointing at a different Active Directory Site, and the Exchange attributes (homeMDB, homeMTA, msExchHomeServerName) have not yet been updated, the Cleanup Agent will detect that this mailbox is not attached to a user account, and that it is past the retention date; and therefore, the mailbox will be deleted. You should see the following events indicating that this is occurring: Event 9533 The user account for "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox will be removed from the mailbox store "database" in 0 days. Following that, you will see: Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" The first time I saw this event, the mailbox was not deleted. Then we have round 2, a few minutes later: Event 9531 Starting cleanup of deleted mailboxes that are past the retention date on database "database" Event 9535 Cleanup of deleted mailboxes that are past the retention date is finished on database "database" 1 deleted mailboxes have been removed Event 9532 The user account "user" does not exist in the directory or is not enabled for Exchange mail. This mailbox has been removed from the mailbox store "database" There are two ways to prevent this from happening: Make sure that Deleted Mailbox Retention is set to a non-zero value. Configure the Online Maintenance interval so that it does not overlap with your scheduled mailbox moves. Alternatively, set Online Maintenance to not run on days when you will be scheduling moves. If you have encountered a situation similar to this, we want to hear from you! Please post a comment. - Ben WinzenzAre 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 YangI'll have some transaction log files for breakfast day
With viruses spreading quick out there today, we had several cases where Exchange transaction logs got either deleted, quarantined or "cured" by file-level anti-virus software that is running on Exchange servers... the result is a bad thing... stores down, transaction logs missing. In some cases the only thing you can do is go back to the last backup if one that is good is available. Otherwise - you are looking at possible repair (= data loss) + Isinteg (maybe 2-3 times) + mandatory offline defrag = a lot of time that is lost :( Please, do not let Exchange directories be scanned by file-level AV. Not "on-demand" one, not the memory resident one. Have Exchange directories excluded, the M: drive excluded, and actually - exclude specifically .log, .edb and .stm files too just to be extra careful. To be more specific, excluding the following on Exchange server is a GREAT idea: Exchange databases and log files. By default, these are located in the Exchsrvr\Mdbdata folder. You can verify the locations by pulling up properties of your databases in ESM and checking the Database tab. Exchange MTA files in the Exchsrvr\Mtadata folder. Additional log files such as the Exchsrvr\server_name.log file. The Exchsrvr\Mailroot virtual server folder. The working folder that's used to store streaming temporary files used for message conversion. By default, this folder is located at \Exchsrvr\MDBData, but you can configure the location. The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility. Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder. Microsoft Internet Information Service (IIS) system files in the %SystemRoot%\System32\Inetsrv folder. The Exchange 2000 Server drive M. More appropriate reading: 328841 XADM: Exchange and Antivirus Software 823166 Overview of Exchange Server 2003 and Antivirus Software Nino BilicWhat'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 teamTooManyBadItemsPermanentException error when migrating to Exchange Online?
Some of you may have noticed that more migrations might be failing due to encountering 'too many bad items'. Upon closer review, you may notice that the migration report contains entries referencing corrupted items and being unable to translate principals. I wanted to take a few minutes and provide more information to help understand what this means, why these are now occurring, and what can be done about them. Ready to geek out? During a mailbox migration, there are several stages we go through. We start off with copying the folder hierarchy (including any views associated with those folders), then perform an initial copy of the data (what we call the Initial Sync). Once the initial data copy process is complete, we then copy rules and security descriptors. Reviewing a move report shows entries similar to these. Stage: CreatingFolderHierarchy. Percent complete: 10 Initializing folder hierarchy from mailbox <guid>: X folders total Folder hierarchy initialized for mailbox <guid>: X folders created Stage: LoadingMessages Copying messages is complete. Copying rules and security descriptors. For our discussion today, we are interested in the stage of “Copying rules and security descriptors”. Security descriptors are Access Control Lists (ACLs), which are then comprised of Access Control Entries (ACEs, or the individual permissions entries) and stored in SDDL format. In the context of a mailbox, we include both the Mailbox security descriptor (Mailbox permissions) as well as Folder security descriptors (permissions on individual folders). When we look at the Mailbox Security descriptor, it should be noted that only Explicit mailbox permissions are copied. These would include permissions granted by using the Add-MailboxPermission cmdlet, by using the Exchange Management Console (2010) or Exchange Admin Center (2013 and 2016) to add Full Access rights. Any Inherited permissions are not evaluated during the copy process. For example, granting the Receive-As permission on a database object in Active Directory results in an Inherited Allow for Full Access for all mailboxes on that database. When mailboxes on that database are migrated to Exchange Online, those Inherited permissions will not get copied. Now that we have briefly covered security descriptors, let’s look at the issue. About midway through 2016, a change was introduced to Exchange Online whereby if a security principal could not be successfully validated/mapped to an Exchange Online object, it would be marked as a bad item. Previously, the behavior was that invalid permissions would simply be ignored, and administrators were then left to wonder why some permissions no longer worked after the migration. With this new behavior, corrupt/invalid permissions are now logged so that administrators will know that there are problems with permissions. From my perspective as a Support Engineer, this is a change for the better because as Administrators, you are now able to see when there are issues with permissions. It is possible that this behavior will continue to evolve over time, but I would advise to become familiar with this new behavior so that you understand what is happening. Now how does this affect you? Since we are now incrementing the bad item count for each corrupt/invalid permission, this means that if we encounter more corrupt/invalid permissions than your current bad item limit is set to (default is 10 for a migration batch), the migration will fail. Depending on the state of permissions, you could potentially see a LOT of bad entries being logged. If you are looking at the migration report text file (downloadable from the Exchange Online Portal), you may see entries similar to the following: 11/12/2016 8:44:43 AM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals for folder "Folder Name"/"FolderNTSD": Failed to find a principal from the source forest. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: Alias: <alias>; DisplayName: <Display Name>; MailboxGuid: <mailbox guid>; SID: <SID of User>; ObjectGuid: <Object GUID>; LegDN: <legacyExchangeDN>; Proxies: [X500:<legacyExchagneDN format>; SMTP:user@contoso.com;];. 5/19/2016 6:33:50 PM [EXO MRS Server] A corrupted item was encountered: Unable to translate principals to the target mailbox: Failed to find a principal in the target forest that corresponds to the following source forest principal values: SID: <SID of User>; ObjectGuid: <Object GUID>;. So, what is the logic used to validate permissions? I’m glad you asked! Here is the process spelled out. There are four basic steps to this process, broken out as follows. Exchange Online - I need to resolve this SID which is present in the security descriptor (Folder or Mailbox) Exchange Online - Make a request to the On-Premises MRS Proxy, passing the SID to resolve On-Premises MRS Proxy - Look up the SID against Active Directory and return a set of attributes (including primary SID and legacyExchangeDN) Exchange Online – Take the legExchangeDN value provided, and attempt to match it up with a user account in the cloud which has that stamped as an X500 proxy address. Normally, Directory Synchronization will take care of stamping the legacyExchangeDN from each side as an X500 proxy address, but this does mean that the On-Premises legacyExchangeDN must match a Mail-enabled recipient (i.e. Mailbox, MailUser, Mail-enabled Security Group) in the cloud by an X500 Proxy. If it does not, then resolving that permission entry will fail. I do want to differentiate between the different types of permissions errors you may see. SourcePrincipalMappingException – these mean that when MRS Proxy tried to look up the SID against On-Premises Active Directory, it couldn’t be resolved. This is a common scenario when users leave the company and their accounts are deleted. You could also encounter these issues if the SID in question is part of the SIDHistory of an On-Premises account. When MRS Proxy attempts to look up the SID, we only search by ObjectSID or msExchMasterAccountSID. MRS Proxy does not evaluate against SIDHistory, so the SID failing to be resolved would be expected behavior. SIDHistory being populated won’t be a common scenario, but it is nonetheless something to be aware of. Note: Exchange Online has a special built-in bad item limit of 1000 for these Source Principal Mapping errors, so these moves will not fail unless you encounter more than 1000 of these types of bad items. TargetPrincipalMappingException – these mean that we can’t map the permission to a user account in the Target forest (Exchange Online). A common scenario here would be if a user or group was given permissions on a mailbox, but that user or group is not in your dirsync scope. After trying to move that mailbox via MRS, that user or group is not going to be present in Exchange Online, so this error would be expected. Another scenario is if a security group (not mail-enabled!) was used to assign permissions. Non mail-enabled security groups are not synchronized to Exchange Online, so they won’t exist in the Target forest. To resolve this issue, there are really two options. Increase the bad item limit to account for permissions errors. In complex legacy environments where multiple Exchange versions have been in place, and there has been a lot of user turnover, I’ve seen where permissions errors can number into the thousands. Be prepared that you may need to increase the bad item limit to a number higher than you expect. The good news here is that with improvement to Exchange over the years, the odds of encountering actual bad messages is relatively slim, so odds are good that the vast majority of bad items are bad permissions. The second bit of good news here is that we log the type of bad item that is encountered and make this information available in the move report. I’ll show you how to dig into a move report and look at the bad items later on in this blog post. Cancel the move, fix the bad permissions from the folder or mailbox by either removing them or fixing the issue causing the user/group to not be resolved in Exchange Online, and then submit the move again. But – you may ask – what if I want to fix the permissions on the current move and then resume it? Well, I’m not going to stop you from fixing bad permissions. But I will tell you that it won’t make any difference for the current move. We only evaluate permissions once, at the end of the initial data copy. If the move fails due to bad items (permissions), even if you fix the bad permissions we won’t re-evaluate the now fixed-up permissions and allow the move to complete successfully. You either have to up the bad item limit, or remove the move and fix the permissions and submit a new move. Now, I promised earlier that I would go through how to review the permissions errors. You can do this by using PowerShell and saving the move report into a variable where it is stored in memory. I typically have the move report exported out to an XML file because I don’t have direct access to customer tenant information. If you are reviewing failed moves within your own tenant, there is no need to do that if you don’t want. I’ll provide the context to do both just in case you want to know both methods. To save the move report to a variable, you would run the following from PowerShell connected to Exchange Online. $movereport = Get-MoveRequestStatistics <move request identity> -IncludeReport To save the move report to an XML file, then import the XML file into PowerShell, you would run the following from PowerShell connected to Exchange Online. Get-MoveRequestStatistics <move request identity> -IncludeReport | Export-CliXml c:\temp\movereport.xml Once the file is saved, then you import it into PowerShell. Note that this PowerShell instance does not have to be connected to Exchange Online. It can be just a regular PowerShell instance. $movereport = Import-CliXml c:\temp\movereport.xml If you never dug into a move report, let me just say that there are all sorts of golden nuggets of information buried inside (which won’t show in the text file from the Portal, by the way!) Now that you have the move report imported as a variable, you can access all the rich information within the report. We specified our variable earlier as $movereport, so we just need to call that variable, and access the information stored inside it. $movereport.report.baditems – this gives you a list of all the bad items encountered. A cool tip is that you can use the Out-GridView PowerShell function to open another window with the list. $movereport.report.baditems | Out-GridView What is nice about the Grid View is that you can then filter the output. For example, to validate that all of your bad items are permissions errors, you can simply choose “Add criteria”, check the “Kind” box, and click “Add”. Change “Contains” to “Does not contain”, and type Security. This will quickly show you if there are any other types of bad items. Now that we have identified the behavior change, and gone over how to address it, let’s end by talking about what approach should be taken for migrating mailboxes. The recommended approach to this new change in behavior would be to continue to migrate using low bad item counts, and then manually remediate those that fail. We recommend this approach because migrations that fail would indicate either a LOT of bad source permissions (more than 1000), or it indicates there are valid, working permissions On-Premises that are failing to be correctly mapped to objects in Exchange Online. Both of these conditions should not be common, so investigation would be warranted to ensure that you are in fact dealing with bad permissions. Special thanks to Brad Hughes and the rest of the MRS team for their assistance and review of this content. Ben WinzenzAnnouncing 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 Shida
