This is the official blog of the Exchange Server Product Group. All content here is considered authoritative and supported by Microsoft, unless otherwise specified.
Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.
Today the Exchange team released security bulletin MS13-105. Updates are being made available for the following versions of Exchange Server:
Customers who are not running one of these versions will need to upgrade to an appropriate version in order to receive the update.
Security bulletin MS13-105 contains details about the issues resolved, including download links.
For Exchange Server 2007/2010 customers, the update is being delivered via an Update Rollup per standard practice. Due to the timing of the release of our most recent Update Rollups, the only difference between the previously released Update Rollup and the Security Update Rollup released today is the inclusion of the security updates identified in MS13-105. We did not include updates for any other customer reported issues in these packages to ease their adoption.
For Exchange Server 2013 customers, security updates are always delivered as discrete updates and contain no other updates. Security updates for Exchange 2013 are cumulative in nature based upon a given Cumulative Update. This means customers who are running CU2 who have not deployed MS13-061 can move straight to the MS13-105 update because it will contain both security updates. Customers who are already running MS13-061 on CU2 may install MS13-105 on top of MS13-061 without removing the previous security update. If MS13-061 was previously deployed, Add/Remove Programs will indicate that both updates are installed. If MS13-061 was not previously deployed, only MS13-105 will appear in Add/Remove Programs.
These updates are being made available via Microsoft Update and on the Microsoft Download Center.
Exchange Team
The previous post for Exchange ActiveSync mailbox log analysis gave an overview of the various commands a device may send. Now we want to dig just a little bit deeper and provide a way to link items within an EAS mailbox log to the items inside the mailbox.
Unless verbose logging is enabled you do not see the full details of the item (subject, sender, etc.) This leads us to the question: How do you know what item the ActiveSync request/response was for within the mailbox? The next few sections will show you how to correlate an appointment, message, and attachment between the mailbox log and mailbox contents.
The first step is locating the item within the mailbox and pulling the Global Object ID (GOID) property value for the item. We cannot do this using Outlook, so we will need to download MFCMAPI. Launch MFCMAPI, go to the Session menu and select Logon to select your Outlook profile. Open the mailbox and expand the Root Container and Top of Information Store. Right-click on the Calendar and select Open contents table.
Find your appointment inside the Calendar table. Then right-click on the tag 0x80000102 and select Edit property. In this example, we will use the appointment with the subject “Blog demo”.
Copy this binary value so you will have it available for a search against the mailbox log.
The Mailbox Log Parser utility allows you to search and review mailbox logs easily. Here we can use this tool to search for the GOID of the appointment. Launch Mailbox Log Parser, click Import Mailbox Logs to Grid, locate your mailbox log and click Open. Once the log is open, enter the binary value you copied from MFCMAPI into the Search raw log data for strings text box and click Search. The search results will filter the log entries so you only see log entries containing the GOID value of your appointment. Here you will notice the UID value within the mailbox log matches the GOID value from MFCMAPI (click to see full resolution):
Review each log entry to determine what action was taken against the appointment. The above image shows a log entry where a Sync request resulted in a change to the appointment. The details for the update can be found within the log entry on the far right. You may also want to consider performing a search using the ServerId value for the appointment found in the log entry. There may be responses that do not contain the UID such as a Delete.
Now let us look at how we can take the calendar item from the mailbox log and find the appointment within the mailbox. For our example we will use the UID value from the mailbox log we used earlier (in image above). We need to open the Calendar contents table using the steps outlined earlier using MFCMAPI. Inside the Calendar table, go to the Table menu and select Set columns.
Click OK on the Set Columns window. In the Column set window, click the Add button. In the Property Tag Editor window, enter the Property Tag value 0x80000102 and click OK twice. This will add the UID column to our table view.
Sort your Calendar table by this Property tag column you just added and then scroll down until you find the matching UID from the mailbox log. Here you can see we found our appointment once again with the subject “Blog demo”.
Copy the binary value and paste it into a tool like Notepad. This value is not as straightforward as the Global Object ID for an appointment. We need to break down this value into a few parts. The following example is from the third message in a conversation thread:
01CEC617632457F0D646F5744F4990165503AB61C52F00000CF610
The value is broken down as follows:
Note: Additional information on tracking conversations can be found here.
Alright, so what does that mean to us? Once again we will use the Mailbox Log Parser tool to search for our item. This time enter the ConversationId value extracted from the previous step into the Search raw log data for strings window. In the results below, you can see we found two messages with this ConversationId value. Remember, this search will return all messages related to the conversation including messages in Sent Items.
Analysis of the log entry shows the item being added to the folder on the device.
Keep in mind we have two results for this conversation. You need to use the Conversation Index value to locate the exact message in the log.
What about the reverse? Just make note of the ConversationId value from the mailbox log for your message. Then open MFCMAPI to open the content table for the folder where the message resides. Sort the table using the Conversation ID column and search for the ConversationId value from the mailbox log. You should find your message(s) for this conversation.
We can see in this example there are two messages within this conversation using the Conversation ID. We would need to examine the property further for each item to obtain the Conversation Index value to locate the exact message.
What about those attachment errors you see in the mailbox log? The mailbox log does give us the information we need to locate the attachment inside the mailbox. The following example shows the FileReference value of the attachment is 5%3a10%3a1. This equates to 5:10:1 or attachment 1 for ServerId 5:10.
First we have to search the mailbox log for this ServerId to determine the message if we do not already know it. Using the example attachment above, we can see the message being added to the folder:
Now we can use the steps from earlier section to locate the message within MFCMAPI using the ConversationId. Once we locate the message, right-click on the message and select Attachments > Display attachment table.
We can determine what attachment the ActiveSync mailbox log reference by matching the Num column from the log value. In our example, the attachment referenced was _Read~1.pdf.
Each item that is synchronized to and from Exchange contains a unique identifier that we can use to locate the item in either the mailbox or ActiveSync client. Calendar items have a unique Global Object ID and mail items have a ConversationIndex and ConversationId value. Now you can review an Exchange ActiveSync mailbox log with more confidence, knowing that you can associate items within the log with items inside the mailbox.
Jim Martin
Today we released v6.1 of the Exchange 2013 Server Role Requirements Calculator. You can view what changes have been made, or download the update directly.
Ross Smith IV Principal Program Manager Office 365 Customer Experience
One of the requirements for properly integrating with Microsoft Office 365 is to ensure that your clients and (in some instances such as hybrid Exchange) servers have access to all of the proper endpoints. To achieve this, most customers simply allow their clients internet access and there is no outbound restrictions put in place that would prevent access to the services.
However, there are some customers that want to only allow access to a minimal amount of endpoints on the Internet and have an outbound proxy device that is in place to ensure that they can control this closely. This control can be done in one of two ways:
Many customers ask, “What are the challenges involved with IP vs. URL filtering? Which option is best for me? Is there a recommended option?”
Keeping up with changes is the first challenge customers may face. The IP addresses and URL’s that are used in the service are mentioned here and if configured today, could change at any time. We do have an RSS feed for this page to try to alert customers of changes and we do try to prevent IP address changes by using larger IP ranges, but in the end there are still times when we have additional datacenters come online or other factors that lead to more IP addresses than is on the list.
Some features will simply not work is the second challenge (such as OWA for customers that decide to use IP addresses as the mechanism for preventing outbound connectivity instead of URL based blocking). The reason behind this is documented here; some of the IP addresses we Use are dynamic and could change without notice for non-secure traffic. Things such as images for OWA are retrieved from third party content delivery networks (a.k.a. CDN) outside of the Microsoft controlled IP address space to improve performance.
Here is the “important” snip from the above mentioned article:
“Microsoft Office 365 relies on third-party content caching engines to achieve good performance and response times. The types of content cached with these third parties are non-SSL resources, such as the images downloaded to draw the Outlook Web App user interface. As stated above, it's possible and supported to use IP-based filtering for the SSL content downloaded from Office 365 and for the Office 365 end-points that make in-bound calls to an on-premises environment. However, it isn’t possible or supported to use IP-based filtering for the non-SSL resources hosted on third-party content caching engines. To express filtering rules that allow those non-SSL resources to be downloaded to clients on your intranet, you need to use hostname-based filtering (as opposed to IP-based filtering). This is because the IPs used by the third-party content caching engines change frequently in a manner which makes it impractical to track each individual IP change. Allow the following hostnames for these non-SSL resources: r3.res.outlook.com r4.res.outlook.com prod.msocdn.com”
You may ask if URL based filtering requires no upkeep and will continue to work after you initially configure it.
The answer is no, not 100% anyway. There will still be times when URL’s for the service could change and changes will be reflected in the articles mentioned above. However, the frequency of the changes is dramatically decreased when URL filtering is used.
Often a customer will choose IP based filtering not because it is easier, but instead because their outbound proxy device cannot do URL based filtering. While this may be true for many older devices, we have seen many times where the application of a software update to your device may allow for URL based filtering functionality. URL based filtering is becoming more prevalent and most devices do give you the opportunity to adapt to this style of filtering.
Some features may not work depending on where users are physically situated is the third major challenge. In some situations we have seen customers attempt to allow only the IP addresses of only Office 365 geographical region datacenters they signed up in. For example, a North American Office 365 customer’s IT staff may attempt to allow only the North American datacenter IP ranges by watching what IP addresses their clients are connecting to then removing the IP ranges they do not see being accessed from the allowed IP list. At first, this may appear to work until (hypothetically speaking) you get a call from your CEO on business travel to Europe asking if Office 365 is down because they cannot access any of the services. Let’s first talk about why this may happen.
Microsoft utilizes geographically aware DNS (aka Geo-DNS) to respond to incoming DNS queries. Microsoft DNS servers first compare the IP address of an incoming request from the querying device against a database of industry standardized IP ranges and what regions of the planet they reside in. Microsoft DNS servers will then issue a DNS response back to the querying device that will be the closest physical entry point to the Office 365 services in the identified IP region. For example a traveling North American Office 365 customer in Europe will be given a European Office 365 entry point. This will prevent the user’s network traffic from having to travel long distances across the public Internet before reaching the desired services. Using Geo-DNS we get the user’s network traffic into the closest Microsoft datacenter and then pass their network traffic across our low latency global private network back to the user’s home datacenter region. This allows Microsoft to provide the best user experience possible for all regions of the planet by reducing dependencies on the public Internet where possible.
So back to our CEO example. The CEO may be in a European hotel on business using the hotel Wi-Fi with a company laptop to do some work. The DNS response they get back for outlook.office365.com will point them at European datacenter. Due to the fact you have only allowed the IP ranges of the North American datacenters, the user is unable to connect to services. You may think forcing the laptop to always utilize corporate DNS servers would help here. Remember that by going down that path you would be forcing the client to traverse the public Internet to reach the North American datacenter and not be able to take advantage of Microsoft’s low latency private network between its datacenters, thus giving your user a less optimal experience.
What is the best or recommended option is based on the challenges outlined above. Microsoft would like to see all customers use URL based filtering to overcome those challenges. URL based filtering will provide you with the fewest number of changes over time, prevent unwanted situations when some content may be unreachable due to changes at the third-party CDNs level, and allow users outside of their home region to always access the most appropriate datacenter for their client connectivity.
Thanks to Brian Day and Joshua Maher for review / comments on this post.
Timothy Heeney
The Exchange team is announcing today the availability of our most recent quarterly servicing update to Exchange Server 2013. Cumulative Update 3 for Exchange Server 2013 and updated UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 3 includes fixes for customer reported issues, minor product enhancements and previously released security bulletins. A complete list of customer reported issues resolved in Exchange Server 2013 Cumulative Update 3 can be found in Knowledge Base Article KB 2892464.
Note: Some article links may not be available at the time of this post's publication. Updated Exchange 2013 documentation, including Release Notes, will be available on TechNet soon.
We would like to call attention to an important fix in Exchange Server 2013 Cumulative Update 3 which impacts customers who rely upon Backup and Recovery mechanisms to protect Exchange data. Cumulative Update 3 includes a fix for an issue which may randomly prevent a backup dataset taken from Exchange Server 2013 from restoring correctly. Customers who rely on Backup and Recovery in their day-to-day operations are encouraged to deploy Cumulative Update 3 and initiate backups of their data to ensure that data contained in backups may be restored correctly. More information on this fix is available in KB 2888315.
In addition to the customer-reported fixes in Cumulative Update 3, the following new enhancements and improvements to existing functionality have also been added for Exchange Server 2013 customers:
More information on these topics can be found in What’s New in Exchange Server 2013, Release Notes and Exchange 2013 documentation on TechNet.
Here are some things to consider before you deploy Exchange 2013 CU3.
Our next update for Exchange 2013, Cumulative Update 4, will be released as Exchange 2013 Service Pack 1. Customers who are accustomed to deploying Cumulative Updates should consider Exchange 2013 SP1 to be equivalent to CU4 and deploy as normal.
The Exchange Team
The Exchange team is announcing today the availability of Update Rollup 3 for Exchange Server 2010 Service Pack 3. Update Rollup 3 is the latest rollup of customer fixes available for Exchange Server 2010. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 3 is not considered a security release as it contains no new previously unreleased security bulletins. A complete list of issues resolved in Exchange Server 2010 Service Pack 3 Update Rollup 3 may be found in KB2891587.
Note: The KB article may not be fully available at the time of publishing this post.
The release is now available on the Microsoft Download Center.
Today on the Office blog we announced that service pack 1 for the 2013 set of products including Office, SharePoint and Exchange will be released early next year. We know our Exchange customers have been looking for confirmation of the release but also have a desire for an early look at what's coming with Exchange Server 2013 Service Pack 1 (SP1). So let's have a first look a few things you can expect to see in SP1. But wait… we haven’t released CU3 – well, news about CU3 is imminent - stay tuned for more information about CU3 coming very soon.
In this post we are highlighting a few of the notable improvements to be included in SP1. This isn't an all-inclusive list, so stay tuned for additional details as we approach release.
SP1 will require customers to update their Active Directory schema - customers should assume this requirement for all Exchange Server 2013 updates. Plan for this required update to quickly take advantage SP1 updates. Active Directory Schema updates for Exchange are additive and always backwards compatible with previous releases and versions.
On behalf of the Exchange Product Group, thanks again for your continued support. As always, let us know what you think!
Brian Shiers Exchange Technical Product Manager
Outlook prompting users for credentials? Outlook users disconnected from their mailboxes? These are a couple of common issues and they can be frustrating to the user. Enter the Outlook Connectivity Guided Walkthrough (GWT).
Outlook connectivity issues with Exchange server can be a very frustrating for both the user and the administrator. Unfortunately, connectivity issues aren't uncommon and will likely occur at some point in time whether your mailboxes are hosted on-premises, in Office 365, or a combination of both, i.e. Hybrid setup. Earlier this year we released a guided walkthrough for Outlook connectivity issues in Office 365.
To assist you in troubleshooting Outlook connectivity issues in an Exchange on-premises environment, we’ve now released the Outlook Connectivity Guided Walkthrough (GWT). You can use this walkthrough for troubleshooting some common issues which include:
The goal for this guided walkthrough is to help you resolve Outlook Connectivity issues with Exchange in a timely manner by providing troubleshooting steps in a logical manner depending on the symptoms of the issue being experienced.
I’d like to thank everyone who contributed to the development of this troubleshooter with special recognition going to the following folks: Victor Zhang, Sainath Vijayaraghavan, Melissa Grewing, Shaun Gimberline and Amir Haque.
We’re approaching the one-year anniversary of the release of Exchange Server 2013. This is traditionally the time when people start asking questions like:
When is Service Pack 1 coming? What’s the timeline for the next Exchange Server release? What are you cooking up for the next version of Exchange?
This time around, we’re also hearing a few customers ask:
Will there be another version of Exchange Server?
We hope the answer to that question is obvious, but we wanted to go on record to make sure no one is confused. Here are the facts:
It’s true that customers are shifting their Exchange deployments from on-premises to the cloud, and it’s true that we are investing heavily in Office 365. We’re fans of Office 365 because we’ve seen that when customers run email in our cloud, they save money, they get larger mailboxes, and they get faster access to our latest innovations. IT admins spend less time maintaining servers and more time lighting up features that make users happy. Running Office 365 also brings us real-world experience that helps us build a better on-premises product.
While we are enthusiastic about the cloud, we also understand that our customers will transition to the cloud at their own pace. Many customers will remain on-premises or in hybrid deployments for the foreseeable future, and we want to keep delivering our newest and best features to them. Fortunately, our development process allows us to do that. We have a single code base that serves both cloud and on-premises customers, so we can deliver innovation to both groups.
Our development strategy continues to focus on Office 365 as the initial platform where we roll out new features. This approach allows us to introduce and test new features at scale before including relevant functionality into on-premises updates. The benefits of the strategy can be seen in Exchange 2013, where features such as Managed Availability are directly based on work done to automate and improve our datacenter operations. If you want clues about what’s coming in the next version of Exchange Server, keep an eye on what’s happening in Office 365.
It’s an exciting time for messaging and collaboration. Today’s technology trends— cloud, mobile devices, social computing, machine learning—all have the opportunity to make email more useful and powerful. We’ve got some great stuff cooking, and we’re committed to bringing innovation to all of our customers, whether they choose to deploy Exchange in the cloud or on-premises. The Exchange product team and our customers have a 17+ year history of successfully navigating changes in IT architecture and management together. We look forward to continuing that tradition with you.
Perry Clarke Corporate Vice President Microsoft Exchange
In the last related blog post we discussed recovering public folders and its contents from dumpster when they are deleted and various recovery steps using the Outlook client and Exchange Management Shell. In this blog we will be moving further and discussing some more advanced recovery scenarios.
Secondary hierarchy mailboxes contain public folder content as well as read-only copy of the public folder hierarchy. At mailbox creation, each public folder mailbox gets associated with its own disabled active directory user account. Those user accounts should never be deleted or modified! When deletion happens though, access to public folders in that content mailbox will get disrupted. The affected public folders will still be seen in the public folder hierarchy, but they might not be accessible since the mailbox holding the folder content is unavailable.
To understand this better let’s consider a scenario where active directory user account which is associated with the Secondary public folder hierarchy mailbox gets mistakenly deleted and it needs to be recovered. The name of the secondary public folder mailbox is called PF-2 and its associated disabled user account is now gone. The associated mailbox will be available in the associated database in disabled state till the retention period expires. During that time, public folders which are hosted on the disconnected secondary public folder mailbox will still show up in Outlook because they are still present in the hierarchy. The associated mailbox content information will be unavailable for the folders associated with the affected public folder content mailbox in Exchange Admin Center as illustrated here:
In order to perform recovery for such types of issues, you will need to create a new disabled user account and reconnect the disconnected public folder content mailbox by connecting to the new created account using Connect-Mailbox.
To view the disabled mailboxes run the command:
Get-MailboxDatabase | Get-MailboxStatistics | Where { $_.DisconnectReason -eq "Disabled" } | ft DisplayName,Database,DisconnectDate,DisconnectReason,*type*
If the public folder content mailbox is not listed in the disabled state but you know the account is missing, you need to force the cleanup on the store by running the below command:
Get-MailboxStatistics -Database “Database name“ | ForEach { Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$false }
Note: Update-StoreMailboxState is the Exchange 2013 replacement for the Clean-MailboxDatabase in previous versions. When running this command, make sure you have proper retention settings in place or else you might end up purging disconnected mailboxes that you did not intend to purge!
As mentioned earlier, create a new user account with same name (like the mailbox, to keep things simpler) or, if the account has been recovered through some sort of AD recovery process, we can simply reconnect the mailbox to it. By creating account with same name the Connect-mailbox will automatically try to connect to the matching user.
Connect the mailbox using the Exchange Admin Center or Exchange Management Shell as described in the article Connect a Disabled Mailbox.
Once the mailbox is connected, the public folder should automatically start serving the contents.
Things to note about mail enabled public folders:
Note: Under usual circumstances, it is not possible to disable a public folder mailbox which is hosting the folders by using the Disable-Mailbox CMDLet. The associated folders and contents needs to be migrated to a different public folder mailbox prior to disabling it.
Let’s consider a scenario where a secondary public folder mailbox which contained a set of public folders with data has been deleted. In order to recover public folder data in such types of scenarios your only option is to restore the last full good backup for the affected mailbox.
Once the restore is completed using the recovery database, run the following CMDLet to see which mailboxes are available for recovery:
Get-MailboxStatistics –Database “Name of Recovery database”
To view a set of public folders which are orphaned in the organization run the command:
Get-PublicFolder –Recurse | Where { $_.ContentMailboxName –eq ‘’ }
Note: Before you begin with the restore process, you need to set the orphaned public folders to an active public folder content mailbox. You can create a public folder mailbox with same old name (you can get the mailbox name from the restored database by running Get-mailboxstatistics) and set the public folders to point to newly created mailbox. This can be done by executing the command:
Set-PublicFolder –Identity “\Name of the public folder” –OverrideContentmailbox “Name of the new content public folder mailbox”
If you skip above step and proceed further, the restore is going to fail since there is no target mailbox available to which data can be restored.
To set the mailbox for multiple orphaned public folders run the command:
Get-PublicFolder –Recurse | Where { $_.ContentMailboxName –eq ‘’ } | Set-PublicFolder –OverrideContentmailbox “Name of the content public folder mailbox”
Once the public folder has been pointed to an active public folder content mailbox, follow the method discussed earlier in the blog for merging the contents to required public folders from recovery database and that’s all. You should see the recovered contents in the recovered folders.
Note: In case you need to restore the contents from the entire public folder mailbox, do not use the –IncludeFolders switch. The restore process will restore the available data from recovery mailbox to all the available folders in the Target mailbox provided the folder structure is present. If you need to restore individual public folders, you can use the mentioned switch.
More information:
How to recover primary hierarchy public folder mailbox when the Active Directory account is deleted?
The primary hierarchy mailbox is pretty much the most important component when it comes to public folder hierarchy. The primary hierarchy mailbox is the one writable copy of the public folder hierarchy. The public folder hierarchy is copied to all other public folder mailboxes, but these will be read-only copies. If this mailbox is disconnected or is not accessible it will affect all the public folders access and administration. When this happens it will no longer be possible to create new public folders since the primary public folder hierarchy mailbox is unavailable.
The following error will be seen when creation of new public folder is attempted and your public folders are in this state:
If the associated account for the public folders is deleted then, the primary hierarchy mailbox will remain in the database till the retention settings expire. The mailbox will be in a disabled state. Public folders themselves will not be visible in the Exchange Admin Center as shown below:
The recovery of this mailbox is possible provided the associated primary hierarchy mailbox is available in disconnected state in the associated mailbox database. You can create a new disabled user account with same name and then reconnect the mailbox using the Connect or Restore a Deleted Mailbox command to connect the mailbox as mentioned prior in the blog.
When a primary hierarchy mailbox is deleted and past the database retention period the only option would be to restore the last full good backup for the database on which the primary hierarchy mailbox resides.
Recovering the public folder hierarchy structure would be only possible if you restore the database directly to the production or use the dial tone recovery method to recover the public folder hierarchy.
As you are recovering the database, any folder content which was modified, deleted or created after the backup of that database was taken might be lost. Once the database is restored and mounted the first thing that happens is that the primary hierarchy mailbox will initiate full hierarchy sync with all the secondary hierarchy mailboxes and only the hierarchy present from that last restored backup will be available.
Looking at the above possibility it becomes very important to plan for the high availability of public folders especially the primary hierarchy mailboxes and this is where the Database Availability Group can be the answer.
Few related notes:
In the above blog post I tried to shed some light on how to recover the contents from secondary content public folder mailboxes after they are deleted and also discussed possible scenarios when primary hierarchy mailboxes could become unavailable. I plan to continue posting some additional more complex scenarios related to recovery of the public folder mailboxes / data.
I would like to again Thank Ben Winzenz, Bill Long, Charlotte Raymundo, Nino Bilic and Bhalchandra Atre for their help in reviewing this blog post.
Siddhesh Dalvi
We have received consistent feedback from our customers that the ability to reject messages for invalid recipients at the service network perimeter is important. We are aggressively working to design a solution that will make Directory Based Edge Blocking (DBEB) available within Exchange Online Protection (EOP). This functionality is targeted to be added to the service in the first quarter of 2014.
In the meantime, here are some suggested configurations to help customers who want this type of capability until the service is able to offer recipient validation:
Wendy Wilkes Senior Program Manager Office 365 Customer Experience
Updated 11/21/2013 to include the target release timeframe.
Microsoft Office Content Publishing is now producing guidance on cross-product solutions involving Exchange Server 2013, SharePoint 2013, Lync Server 2013, Office 365, and Windows Azure. Our goal is to help our customers solve bigger business problems than could be solved through any of these products individually.
We have some ideas regarding what solutions to get started on but we need your input to find out if these are the right ones and what other ones we should do.
We are forming a Solutions Advisory Board (SAB) consisting of customers, Microsoft Most Valuable Professionals (MVPs), and people in various roles inside of Microsoft. The SAB will:
If you would like to participate in the discussion around solutions that use any combination of Exchange 2013, SharePoint 2013, Lync Server 2013, Office 365, or Windows Azure, we invite you to join this new group.
Please contact us at sab@microsoft.com to join.
Office Solutions Content Team
I continue to run into this issue over and over in the field so I wanted people to be aware of this possible problem. In a Database Availability Group (DAG), if your databases are randomly mounting or flipping from one server to another, for no apparent reason (including across datacenters) you may be suffering from your network interface card (NIC) going to sleep. And that’s not a good thing.
In the power management settings for the NIC on Windows Server, make sure you are not allowing the NIC to go into power save mode. Why is this important? It seems like at least once a month I’ve run into customers who have this power management setting turned on and more than one of them even had it turned on for their replication network. They were seeing some odd behavior - for example, their databases randomly flipping from one DAG node to another for no apparent reason. And yes, they were all on physical machines.
Here are the steps to look at this configuration: use Device Manager to change the power management settings for a network adapter.
To disable all Power Management settings in Device Manager, expand Network Adapters, right-click the adapter > Properties > Power Management, and then clear the Allow the computer to turn off this device to save power check box.
Figure 1: Disable power management for the network adapter from the Power Management tab
Some of your network adapters may not have the Power Management tab available. This is a good thing, as your NIC is not able to go to sleep. This means there is one less item to worry about in your setup!
CAUTION Be careful when you change this setting. If it's enabled and you decide to disable it, you must plan for this modification as it will likely interrupt network traffic. It may seem odd that by just making a seemingly non-impacting change that the NIC will reset itself, but it definitely can. Trust me; I had a customer ‘test’ this during the day by accident… oops!
In addition, now that PowerShell is able to be used for just about everything, there is this page that has a PS script available to make this change. There are additional links and related forum threads to review with supplementary information near the bottom of the script download page.
This modifying script will run against all physical adapters to the machines you deploy it to, and you can also modify the script to disable wireless NIC’s. With PS, don’t forget that you can use this script to blast down these changes to all of your Exchange servers with a single step.
For those of you that are more comfortable with regedit and creating GPO’s to help control these settings, that option is also available. This page has information on both ‘one off’ fixes that you can download a .reg file and manually deploy, or using GPO Preferences, you can edit the values in a GPO and apply those changes to an Exchange Server OU (Organizational Unit).
The one step to note with the regedit process is which NIC you are working with and how many NIC’s your server has. The registry only knows of the first, second, third, etc. number of NIC’s. Now if you have identical builds between all of your servers, then this option certainly will ensure that all current and any future servers placed into an OU with the GPO applied will adhere to the proper registry settings.
Also don’t forget, you can record all of your changes on a Windows Server 2008R2 or higher OS, by using the Problem Steps Recorder (PSR) tool.
There you have it: if your DAG Databases are randomly becoming active from one server to another with no apparent reason, you may have a sleepy NIC. Please confirm that you have avoided this setting as you build out not only your DAG environment, but all Exchange related servers. Thank you.
Mike O'Neill
Windows 8.1 and Windows RT include a built-in email app named Windows Mail. Mail includes support for IMAP and Exchange ActiveSync (EAS) accounts.
This article includes some key technical details of Windows Mail in Windows 8.1. (See Supporting Windows 8 Mail in your organization for Windows 8.0.) Use the information to help you support the use of Mail in your organization. Read this article start to finish, or jump to the topic that interests you. Use the reference links throughout the article for more information.
NOTE Mail, Calendar, and People apps run on Windows 8.1 and Windows RT. Although this article discusses the Mail app, please note that much of the information in this article also applies to the Calendar, and People apps. When connected to a server that supports Exchange ActiveSync, the Calendar, and People apps may also display data that was downloaded over the Exchange ActiveSync connection.
Mail lets users connect to any service provider that supports either of the following two protocols:
Post Office Protocol (POP) is not supported.
NOTE All Windows Communications apps (Mail, Calendar, and People) can use the data that is synchronized using Exchange ActiveSync. After a user connects to their account in the Mail app, their contacts and calendar data is available in the other Windows Communications Apps and vice versa.
Mail can be configured to synchronize data at different times as follows:
If a push email connection can’t be established, it will automatically switch to poll at fixed intervals.
Push email requires that accounts are either Exchange ActiveSync (which all support Push) or IMAP with the IDLE extension. Not all IMAP servers support IDLE, and it is supported only for the Inbox folder.
When a push connection can’t be established, Mail will change to polling on 30 minute intervals. Push email on Exchange ActiveSync requires that HTTP connections must be maintained for up to 60 minutes, and IMAP IDLE requires TCP connections to be maintained for up to 30 minutes.
Windows 8.1 and Windows RT users can add email accounts to Mail using the Settings charm. The Settings charm is always available on the right side of the Windows 8.1 and Windows RT screen. (For more visual details about Charms & the Windows 8.1 user interface, see Search, share, print & more.)
NOTE This section provides an overview of account setup in Mail. For step-by-step procedures for setting up an account, see What else do I need to know? at the end of this guide.
To make it as easy as possible to add accounts, account setup only prompts the user to enter the email address and password for the account they want to set up. From that data, Mail attempts to automatically configure the account as follows:
Figure 1: Exchange ActiveSync (EAS) configuration in Windows Mail
If automatic configuration fails, the following additional information is required to connect to a server via Exchange ActiveSync:
Figure 2: IMAP/SMTP configuration in Windows Mail
The information required to connect to a server via IMAP/SMTP is:
Mail provides administrators with some level of security through Exchange ActiveSync policies (Mobile Device Mailbox Policies in Exchange 2013). It doesn’t support any means of managing or securing PCs that are connected via IMAP. EAS includes support for certificate-based authentication and remote wipe.
Exchange ActiveSync devices can be managed using Exchange ActiveSync policies. Mail supports the following EAS policies. :
Important If AllowNonProvisionableDevices is set to false in an EAS policy and the policy contains settings that are not part of this list, the device won’t be able to connect to the Exchange server.
Most of the policies listed above can be automatically enabled by Mail, but there are certain cases where the user has to take action first. These are:
If a Windows 8.x user uses a picture password and Exchange ActiveSync policy requires a password, the user will still need to create and enter a password in accordance with the policy.
If a Windows 8.1 PC is joined to an Active Directory domain and controlled by Group Policy, there may be conflicting policy settings between Group Policy and an Exchange ActiveSync policy. In the event of any conflict, the strictest rule in either policy takes precedence. The only exception is password complexity rules for domain accounts. Group policy rules for password complexity (length, expiry, history, number of complex characters) take precedence over Exchange ActiveSync policies – even if group policy rules for password complexity are less strict than Exchange ActiveSync rules, the domain account will be deemed in compliance with Exchange ActiveSync policy.
Communications applications can connect to a corporate Exchange service configured to require certificate-based authentication. User authentication certificates can be provisioned to Windows 8.1 devices by administrators or end-users can browse to certificate and install to user certificate storage.
User can add and connect an email account using a certificate. (For account setup, password entry is required per standard account setup.) User may be prompted to give the Mail application permission to access their user certificate, and should accept the prompt to enable certificate usage. In cases where multiple certificates are available, the user can go to account Settings to select the desired certificate.
Non-PIN protected software certificates are supported.
Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phone (which deletes all data on the device), Mail scopes the data deleted to the specified Exchange ActiveSync account for which the remote wipe command is issued. The user's personal data is not deleted. Additionally, attachments saved from that account are made inaccessible.
For example, if a user has an Outlook.com account for personal use and a Contoso.com account for work use, a remote wipe directive from the Contoso.com server would impact Windows 8.1 and Windows Phone 7 as follows:
To make it as easy as possible for users to have all of their accounts set up on all of their devices, Windows 8.1 uploads vital account information to the user’s Microsoft account. This information includes email address, server, server settings, and password. When a user signs into a new PC with their Microsoft account, their email accounts are automatically set up for them.
Passwords are not uploaded from a PC for any accounts which are controlled by any Exchange ActiveSync policies. Users will have to enter their password to begin syncing a policy-controlled account on a new PC.
If using client certificate authentication, the client certificate, and the certificate selection for an account will not be roamed. Users will have to select their desired client certificate to begin syncing a client certificate account on a new PC.
By default, users are required to have a Microsoft account, formerly known as Windows Live ID, to use the Windows Communications apps. This will usually be the Microsoft account that the user is signed into Windows with, but if they have not done so, they will be prompted to provide one before proceeding.
You can apply a Group Policy to a device to make a Microsoft Account optional for the Windows Communications apps.
Note, the Group Policy setting is configured in Computer Configuration node in the Group Policy and applies to all users of the computer/device to which it's applied. The policy setting lets you control whether Microsoft accounts are optional for Windows Store apps that require an account to sign in. This policy only affects Windows Store apps that support it. Windows RT devices can use Local Group Policy.
To apply the Group Policy setting:
If the Group Policy is applied and a Microsoft account is not used, the Communications apps will:
A user can add additional accounts if desired. You can use corporate firewalls or other mechanisms to block access to any consumer email services as needed.
The following functionality will be unavailable to a user without a Microsoft Account:
By default, Mail only downloads one month of email (up from 2 weeks in Windows 8.0). This is user configurable and can potentially download the user’s entire mailbox. For Exchange ActiveSync accounts, all contacts are downloaded and calendar events are downloaded only for three months behind the current date and 18 months ahead.
Additionally, messages can be only partially downloaded to reduce bandwidth use as follows:
Embedded images in email messages are downloaded on-demand as the user reads them, and attachments which are not downloaded can be downloaded on-demand as the user attempts to open them.
Mail downloads all folders for an account. Users can configure the period of email which is downloaded to adjust the size of data for an account. Mail does not enforce any limits on number and size of attachments users can send.
Mail allows users to view and set their automatic reply messages (aka Out of Office or OOF messages). There is a visual indication when auto-reply is enabled. Users can view and set automatic reply plain text content. For corporate accounts, separate internal and external auto-reply messages are supported.
There is no date/time support for specifying start or end time for automatic replies.
The communications applications can connect over LAN or WiFi connections via authenticated proxies which use standard authentication methods including: NTLM, Digest, Negotiate, and Basic authentication.
Any user credentials entered can be cached for the session, or remembered persistently.
The communications applications warn the user with a prompt providing an option to connect anyway when trying to connect to services with common service certificate issues. See Self-Signed Certificates in Limitations below for details and recommendations.
The following features are currently not supported by Mail:
Direct mailbox connections using POP: Only EAS and IMAP protocols are supported.
Note This does not mean that Windows 8.1 does not support POP. This post is about the Mail app. See Using email accounts over POP on Windows 8.1 and Windows RT 8.1 for workarounds.
Opaque-Signed and Encrypted S/MIME messages When S/MIME messages are received in Mail, it displays an email item with a message body that begins with “This encrypted message can’t be displayed.”
To view email items in the S/MIME format, users must open the message using Outlook Web App, Microsoft Outlook, or another email program that supports S/MIME messages. For more information, see Opaque-Signed and Encrypted S/MIME Message on MSDN.
Users may experience connectivity errors when trying to connect to an Exchange server that uses a self-signed certificate or a certificate with other common issues. The user may receive the following error message.
There’s a problem with a server’s security certificate. It might not be safe to connect to the server because… <details>.
You can use one of the following options to resolve this issue.
At the prompt, users can connect anyway to ignore common service certificate issues such as self-signed certificates, allowing the communications applications to use an encrypted connection to the email service with the certificate issue. If users choose to connect anyway and ignore the service certificate issues, their selection will be remembered, (can be viewed and changed any time via Settings for account).
We recommend that users select Cancel when they receive a certificate-related error and contact the administrator to fix the issue (option 1).
See Digital Certificates and SSL for more information.
This enables Exchange to work for Windows 8.1 devices that have the certificate installed.
Note The administrator must provide a certificate file (.cer). The certificate can be installed to the trusted root certificate authority store for either of the following options:
The user or the system administrator can use the .cer file to install the certificate. To do this, use one of the following methods:
At an elevated command prompt, run the following command:
certutil.exe -f -addstore root.cer
NOTE The command installs the certificate for all users on the device.
If a Mail user can't successfully connect to an account, consider the following:
TIP The user will see the following message if they haven't registered their account: “We couldn’t find the settings for. Provide us with more info and we’ll try connecting again.”
Based on the feedback I received it looks like our readers enjoyed the previous set of articles (Part 1, Part 2, and Part 3) that were published about IIS ARR and because of that, the pirates Arrr!!! back with another article on how to use IIS ARR for O365 Exchange Online Hybrid configurations.
We have many customers who are running Hybrid with O365 today or are planning to sign up to O365 and coexist in a Hybrid configuration, and this article was written to help those customers effectively use or plan for IIS ARR as a Reverse Proxy solution.
As you may or may not know, if you use TMG in a hybrid configuration with Exchange Online, it is not supported to have TMG performing any pre-authentication against ADFS, Exchange Web Services (EWS) or AutoDiscover. So, when you are in an Exchange Hybrid Configuration, out of a total of five services we can only perform pre-authentication against two of available services (Outlook Anywhere and OWA), and this is not even considering the web traffic for Lync on-premises and Lync Online, which should not be pre-authenticated either.
When you look at it like this, if you read the previous articles that describe what IIS ARR offers, these limitations should lead you to conclude that IIS ARR is a great solution as it can provide both Reverse Proxy and L7 Load Balancing capabilities for your O365 Hybrid Configuration.
When an organization is setup as an Exchange Hybrid we can break down the traffic into two types ie: Inbound Traffic and Outbound Traffic. We are going to use these terms to explain how to control these two types of traffic in a Hybrid Scenario.
Illustration of the setup:
When we refer to Inbound Exchange Traffic, from the Internet to on-premises, it usually means traffic for the usual Exchange clients such as Outlook Anywhere, EAS, OWA and EWS (users whose mailboxes are still on-premises). However in Hybrid scenarios we have additional requests for the Security Token Service (STS), or ADFS Proxy Servers by another name. Hence when configuring IIS ARR for inbound traffic we have to make sure that we add the necessary configuration required for the STS.
STEP1: Follow the earlier articles (here, here and here) which explain how to create the Web Farms and their corresponding URL Rewrite rules for the Exchange Services (Outlook Anywhere, OWA, EAS, AutoDiscover etc). For this example I have chosen the simplest implementation described in the previous blog posts (Option1) for the Exchange traffic.
STEP2: Create a new Web Farm for your STS endpoints (sts.roopdemo.co.uk in my example) and add each of your ADFS Proxy servers. This assumes that you have not setup any network load balancing between the ADFS Proxy servers, which is fine because we’ll be making use of IIS ARR’s load balancing capabilities to achieve load balancing and high availability of the ADFS Proxy servers.
STEP3: Configure the properties of the Web Farm (sts.roopdemo.co.uk)
Make sure you enter the Healthy in the Response match box (response match is an optional test that searches the body of a response and looks for an expected string. Since the HealthCheck.txt file contains the word “Healthy,” the response match test will look for the word “Healthy”).
STEP4: Edit the URL rewrite rule.
Under Action:
In the end you should be left with something that looks similar to this;
When your organization is in a Hybrid configuration there is of course web traffic flowing from your on-premises environment to the O365 services and this traffic needs to be controlled. Some organizations don’t allow traffic that is destined to the internet, to go directly out from the end-users workstation. Instead all internet based traffic would be first sent to a Web Proxy (installed on-premises) where some form of filtering would take place (based on corporate policy) and only then would the requested page/content on the internet be accessible. This Web Proxy thus acts as a Forward Proxy for all internet (Exchange Online, Lync Online etc) based traffic. All this web traffic to the O365 service is encrypted using SSL.
The IIS team doesn't support IIS ARR as a Forward Proxy for SSL traffic.
Thus for such organizations, you would need to invest in a third party Forward Proxy application to allow end-users to access the O365 services (Exchange Online, Lync Online & SharePoint online).
If you want to lock down the protocols allowed by IIS ARR within a single URL Rewrite rule then you can write a Regular Expression as below. This is a much better control of the web request that are being forwarded to the CAS servers, as opposed to a wildcard (*). In the example below, within my URL Rewrite Rule for mail.roopdemo.co.uk, I have added the below Pattern which would thus only allow the below mentioned protocols/services.
Recommendations for sizing the IIS ARR servers:
There is currently no specific guidance published for sizing of IIS ARR servers, however you can use the sizing guidance for the TMG servers as a starting point. The IIS ARR servers are only performing URL Filtering and thus the guidance shown below should be ideal.
In summary, we have seen that IIS ARR server (or server farm) can act as the ingress and egress point for all your O365 Hybrid web traffic. This thus makes IIS ARR act like a traffic controller for all the corresponding traffic and hence provides a better management experience for the admins. For all inbound traffic, IIS ARR provides a great Reverse Proxy solution, but it also natively provides a L7 load balancing solution. So you don’t have to invest in 3rd party HLB’s and in effect reduce the total overall cost of implementing an O365 Hybrid solution.
My heartiest thanks to Greg Taylor (Principal PM Lead) for his help with reviewing this article.
Good luck and feel free to post comments and questions if you have them.
Roop Sankar Bagepalli Senior Premier Field Engineer, UK
Office 365 Service Descriptions provide comprehensive details about features and functionality available in different Office 365 subscription plans.
Now there’s a quick way to compare features in different plans. The Office 365 service descriptions Excel web part allows you to select a service or on-premises scenario, select the specific Office 365 service (e.g. Exchange Online, SharePoint Online, Lync Online), and an Office 365 plan to see the features available in the selected plan.
Let us know what you think!
When designing a site resilient Exchange Server solution, one of the required planning tasks is to determine how many transaction logs are generated on an hourly basis. This helps figure out how much bandwidth will be required when replicating database copies between sites, and what the effects will be of adding additional database copies to the solution. If designing an Exchange solution using the Exchange Server Role Requirements Calculator, the percent of logs generated per hour is an optional input field.
Previously, the most common method of collecting this data involved taking captures of the files in each log directory on a scheduled basis (using dir, Get-ChildItem, or CollectLogs.vbs). Although the log number could be extracted by looking at the names of the log files, there was a lot of manual work involved in figuring out the highest the log generation from each capture, and getting rid of duplicate entries. Once cleaned up, the data still had to be analyzed manually using a spreadsheet or a calculator. Trying to gather data across multiple servers and databases further complicated matters.
To improve upon this situation, I decided to write an all-in-one script that could collect transaction log statistics, and analyze them after collection. The script is called GetTransactionLogStats.ps1. It has two modes: Gather and Analyze. Gather mode is designed to be run on an hourly basis, on the top of the hour. When run, it will take a single set of snapshots of the current log generation number for all configured databases. These snapshots will be sent, along with the time the snapshots were taken, to an output file, LogStats.csv. Each subsequent time the script is run in Gather mode, another set of snapshots will be appended to the file. Analyze mode is used to process the snapshots that were taken in Gather mode, and should be run after a sufficient amount of snapshots have been collected (at least 2 weeks of data is recommended). When run, it compares the log generation number in each snapshot to the previous snapshot to determine how many logs were created during that period.
Instead of looking at the files within log directories, the script uses Perfmon to get the current log file generation number for a specific database or storage group. This number, along with the time it was obtained, is the only information kept in the output log file, LogStats.csv. The performance counters that are used are as follows:
Exchange 2013: MSExchangeIS HA Active Database\Current Log Generation Number Exchange 2007/2010: MSExchange Database ==> Instances\Log File Current Generation
Exchange 2013:
MSExchangeIS HA Active Database\Current Log Generation Number
Exchange 2007/2010:
MSExchange Database ==> Instances\Log File Current Generation
Note: The counter used for Exchange 2013 only contains the active databases on that server. The counter used for Exchange 2007/2010 contains all databases on that server, including passive copies. To only get data from active databases on an Exchange 2007/2010 server, make sure to manually specify the databases for that server in the TargetServers.txt file.
The script takes a simple input file, TargetServers.txt, where each line in the file specifies the server, or server and databases to process. If you want to get statistics for all databases on a server, only the server name is necessary. If you want to only get a subset of databases on a server (for instance if you wanted to omit secondary copies on an Exchange 2007 and 2010 server), then you can specify the server name, followed by each database you want to process.
The script has the ability to analyze the output log file, LogStats.csv, which was created when run in Gather mode. It does a number of common calculations for you, but also leaves the original data in case any other calculations need to be done. Output from running in Analyze mode is sent to multiple .CSV files, where one file is created for each database, and one more file is created containing the average statistics for all analyzed databases. The following columns are added to the CSV files:
The script has the following parameters:
Run the script in Gather mode, taking a single snapshot of the current log generation of all configured databases:
PS C:\> .\GetTransactionLogStats.ps1 -Gather
Run the script in Gather mode, and indicates that no Exchange 2013 servers are configured in TargetServers.txt:
PS C:\> .\GetTransactionLogStats.ps1 -Gather -MonitoringExchange2013 $false
Run the script in Gather mode, and changes the directory where TargetServers.txt is located, and where LogStats.csv will be written to:
PS C:\> .\GetTransactionLogStats.ps1 -Gather -WorkingDirectory "C:\GetTransactionLogStats" -ResetStats
Run the script in Analyze mode:
PS C:\> .\GetTransactionLogStats.ps1 -Analyze
Run the script in Analyze mode, sending the output files for the analysis to a different directory. Specifies that only sample durations between 55-65 minutes are valid, and that each sample can be taken a maximum of 10 minutes past the hour before being discarded:
PS C:\> .\GetTransactionLogStats.ps1 -Analyze -LogDirectoryOut "C:\GetTransactionLogStats\LogsOut" -MaxSampleIntervalVariance 5 -MaxMinutesPastTheHour 10
The following example shows what the TargetServers.txt input file should look like. For the server1 and server3 lines, no databases are specified, which means that all databases on the server will be sampled. For the server2 and server4 lines, we will only sample the specified databases on those servers. Note that no quotes are necessary for databases with spaces in their names.
When run in Gather mode, the log generation snapshots that are taken are sent to LogStats.csv. The following shows what this file looks like:
The following shows the analysis for a single database after running the script in Analyze mode:
Since the script is designed to be run an hourly basis, the easiest way to accomplish that is to run it using a Scheduled Task. The way I like to do that is to create a batch file which calls Powershell.exe, launches the script, and then create a scheduled task which runs the batch file. The following is an example of the command that should go in the batch file:
powershell.exe -noninteractive -noprofile -command "& {C:\LogStats\GetTransactionLogStats.ps1 -Gather -WorkingDirectory C:\LogStats}"
In this example, the script, as well as TargetServers.txt, are located in C:\LogStats. Note that I specified a WorkingDirectory of C:\LogStats so that if the scheduled task runs in an alternate location (by default C:\Windows\System32), the script knows where to find TargetServers.txt and where to write LogStats.csv. Also note that the command does not load any Exchange snap-in, as the script doesn’t use any Exchange-specific commands.
By default, the Windows Firewall on an Exchange 2013 server running on Windows Server 2012 does not allow remote Perfmon access. I suspect this is also the case with Exchange 2013 running on Windows Server 2008 R2, but haven’t tested. If either of the below errors are logged, you may need to open the Windows Firewall on these servers to allow access from the computer running the script.
ERROR: Failed to read perfmon counter from server SERVERNAME ERROR: Failed to get perfmon counters from server SERVERNAME
ERROR: Failed to read perfmon counter from server SERVERNAME
ERROR: Failed to get perfmon counters from server SERVERNAME
Update:
After noticing that multiple people were having issues getting this to work through the Windows Firewall, I tried enabling different combinations of built in firewall rules until I could figure out which ones were required. I only tested on an Exchange 2013 server running on Windows Server 2012, but this should apply to other Windows versions as well. The rules I had to enable were:
File and Printer Sharing (NB-Datagram-In) File and Printer Sharing (NB-Name-In) File and Printer Sharing (NB-Session-In)
Mike Hendrickson
Note: Part 2 of this series can be found here.
One of best troubleshooting tools for Exchange ActiveSync (EAS) is mailbox logging. This logging allows us to see the incoming request sent by the device and the outgoing response from the Exchange server. Exchange ActiveSync Mailbox Logging provides the steps for enabling ActiveSync mailbox logging and breaks down the components of the log. Here we're going to use one of these logs to analyze how a mobile device running an EAS client (for e.g. a Windows Phone) initializes a profile with Exchange and a few standard commands.
A device must be provisioned before it can synchronize with Exchange. The device sends the Provision command with the device settings contained within the request. The server response includes the security settings based on the ActiveSync mailbox policy associated with the mailbox. It is important to note now that there are two status codes for most ActiveSync requests. The HttpStatus code only provides the IIS response to the request, and a 200 response does not mean the request was successful. The second status code is for the ActiveSync command and varies depending on the command sent by the device. A status code of 1 is most commonly a success.
The following example shows the request and response from a Provision command:
The device sends another Provision command to complete the provisioning process.This request includes the policy key from the previous response. The following example shows the second Provision command sending the PolicyKey.
For more detailed analysis of EAS provisioning process & Policies, see Provisioning, Policies, Remote Wipe, and ABQ in Exchange ActiveSync on The Exchange Dev Blog.
Once the device is provisioned, it will send a FolderSync command to obtain the folder hierarchy of the mailbox. If you capture this FolderSync request in the ActiveSync mailbox log, you will have the folder name that correlates to the CollectionId values in future ActiveSync requests. Alternatively, see ActiveSync - Mapping a Collection ID to a Mailbox Folder to determine which folder the CollectionId represents. The following example shows the response from a FolderSync request:
After the EAS client has obtained the folder hierarchy of the mailbox from Exchange, it can begin to populate folders on the device . Windows Phone leverages a hanging Sync request to retrieve data from these folder. We should however expect the first Sync request by this device to have an immediate response with new items for one or more folders. It is also important to notice the SyncKey sent by the device in this first request is 0. This is because the folders (have just been created on the device and) currently have no synchronization state. The response for each Sync request will include a new SyncKey value that the subsequent Sync request should send. The following example shows the request and response for a Sync command:
We will typically either see no status code or a status code of 1 in the response for a Sync request. Any other status code would require further investigation by reviewing the protocol document. A status code of 1 represents a successful Sync request and no status code simply means there were no changes within the heartbeat interval for the request.
Typically you will see items being added to the device in the Sync response. You can see detailed information including the sender and subject if verbose logging has been enabled on the CAS servers. The following example shows a response sending a new item to the Inbox:
There are several uses for the ItemOperations command and one of the most common requests is for downloading an attachment onto the device. The request will contain the FileReference value for the attachment which can be seen in the Sync response if available. The following examples show two responses for the ItemOperations command. We can see the first response is a success and the server sending the attachment. However the second response throws an exception and has a different status code. Lookup this status code in the protocol documentfor more information on the exception.
Were you able to determine the issue? The exception within the ActiveSync mailbox log for this example does provide enough detail to know the attachment was too large. It is very important to know how to use the protocol document to look up status codes for the various ActiveSync commands.
Now that we have covered the most common command that will be found in the ActiveSync mailbox log (that is the Sync command), it is now time to dig a little bit deeper. One of the most common issues with ActiveSync devices is calendaring. Most ActiveSync users rely on their mobile device to have accurate calendar information so they do not miss an appointment. Calendar items can be added to a mailbox as either an appointment created by the mailbox or a meeting request sent by either the mailbox owner or another organizer.
We are going to review the life of an appointment as we find it within the ActiveSync mailbox log. This appointment will start as a meeting request sent by an organizer within the organization. The following example shows a Sync response where this appointment is first added to the device:
Here we can see the appointment has a unique ServerId value for this item on the device. We also know that the appointment is currently showing a status of tentative in the BusyStatus. This is the standard placeholder that Exchange creates in the calendar when a new meeting request is received. The following example shows the corresponding meeting request:
The complex part of this process begins when the user responds to the appointment on the device. This response results in several requests which include MeetingResponse, SendMail, MoveItems, and Sync commands. We are going to cover each of these steps to see how the commands impact the items on the device and within the mailbox.
The MeetingResponse command is in the first ActiveSync command sent by the device to accept, decline, or tentatively accept the meeting. This request does not sent the response to the organizer. The request includes the meeting request item within the Inbox the response is for while the response from the Exchange server also includes the appointment item. The following examples show the request and response for a MeetingResponse command:
The SendMail command is the response message sent back to the organizer. The following is an example of the request for a SendMail command:
The MoveItems command is sent by the device to move the meeting request item from the Inbox to the Deleted Items folder. The following example shows the request for a MoveItem command:
The Sync command is sent by the device to update the calendar item on the mailbox. This Sync request is sending a Change for the appointment to update this status from Tentative to Busy. The following example shows the request sending a change for the BusyStatus:
You may also notice another Sync command sent by the device and that the response includes an Add for the Sent Items folder. Here we are getting the meeting acceptance message from the Sent Items and adding in onto the device.
All that we just covered was the original meeting request being received by the device. That is the origin of the appointment for our example. Next we need to look at how this appointment changes as time moves forward. The next evolution in this appointment’s life is a when the organizer sends an update for a single instance of the series.
A change to a recurring appointment is called an exception and that is exactly what we will see in the ActiveSync mailbox log. The first part of the response shows us that we have a Change for an item and further down within that response we will see the exceptions. The following example shows our appointment receiving a change and the exception includes a new start time:
Wait. Our appointment has not stopped experiencing life changes. The organizer has decided to cancel an instance of this recurring appointment. The following example once again shows a change for our appointment but this time the exceptions have grown. This example was done intentionally so we can see how difficult it becomes to read these logs when an appointment has a large number of exceptions.
The good news is these exceptions are sent in the order in which they were made, so the last exception is the most recent. In our example above, the last exception shows this instance of the meeting has been canceled.
The focus has intentionally been on the Calendar item and its changes. However we cannot forget that with each change to the appointment the user also gets an updated meeting request. This means we will also see a Sync request that includes a response adding the meeting request to the Inbox. The following example shows the response adding the updated meeting request:
Just like the original meeting request for the series, the user has the ability to accept and decline the changes from the device. If you do not remember the process, don’t hesitate to jump back and take a second look. That is exactly what this article is intended to show.
The last topic we are going to cover is sending a message from a Windows Phone device. There are two commands that we may see from an ActiveSync device when a user is sending a message. The Search command will be sent when a user types text into the To field and perform a search against the Global Address List. The following examples show a request and response for a Search command:
Then the device will send a SendMail command when the user hits the Send icon. Unless an error is encountered during this request there should be an empty response from the Exchange server. The following example shows a request for the SendMail command:
At this point you should have some understanding of how Exchange ActiveSync functions and what to look for in the ActiveSync mailbox log. Here are a few reminders:
Jim Martin (EXCHANGE)
We’ve listened to your feedback for improving the on-premises and hybrid Exchange Server deployment experience, and we’re happy to announce the release of the new, consolidated Deployment Assistant!
The Exchange Server Deployment Assistant now combines all the on-premises and hybrid deployment scenarios from both the Exchange 2013 Deployment Assistant and the Exchange 2010 Deployment Assistant into a single tool. We’ve eliminated the need for the installation of Silverlight and provide guidance for all Exchange Server deployments in a true one-stop shop experience. We’ve also kept the same, convenient question-and-answer format to create a customized, step-by-step checklist with instructions to deploy Exchange 2013 or Exchange 2010.
Starting your Exchange deployment is familiar and convenient, no matter whether you’re deploying Exchange 2013 or Exchange 2010. Just select the one of the three basic deployment tracks: On-premises, Hybrid, or Cloud Only to get started, as shown in Figure 1.
Figure 1: The Exchange Server Deployment Assistant home page
After selecting your basic deployment track, you’ll be able to choose from either an Exchange 2013-based or Exchange 2010-based path for either on-premises or hybrid deployment scenarios. If you selected the Cloud Only scenario, the deployment path is the same for both Exchange 2013 and Exchange 2010 organizations and you’re on your way to getting started with an Exchange Online-only deployment.
Figure 2: Choose either the Exchange 2013 or Exchange 2010 deployment path
After you’ve chosen either the Exchange 2013 or Exchange 2010 deployment path (see Figure 2), you’ll answer a few questions about your deployment needs and you’re off to the races with your customized deployment checklist! For example, see Figure 3, which shows a checklist for an on-premises Exchange 2013 deployment.
Figure 3: Exchange 2013 on-premises deployment path
And, here’s some more good news! If you’ve bookmarked links to the Exchange 2013 and Exchange 2010 Deployment Assistants, there’s no action required to go to the new tool when using your bookmarks. You’ll be automatically redirected to the new tool when using the URL for the previous version of the Deployment Assistant.
We hope you enjoy the convenience of having all the Exchange 2013 and Exchange 2010 deployment scenario guidance in a single tool. We’d love your feedback and comments! Please feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the 'Feedback' link located in the header of every page of the Deployment Assistant.
Happy deploying!
The Deployment Assistant Team
Update 11/14/13: We believe that we have resolved all of the related issues; if you still see problems with Remote Connectivity Analyzer, please send us feedback.
We’re having some technical issues with the Remote Connectivity Analyzer site, which is causing occasional errors when running tests. Although we continue to monitor, please send us feedback using the tool if you're impacted. While we can’t respond to each inquiry, this helps us measure the impact. Sorry for the inconvenience; we're working hard to mitigate it!
For status updates, you can follow us on Twitter @ExRCA
RCA Team
We wanted to let you know that we have released a Beta version of Microsoft Office 365 Best Practices Analyzer for Exchange Server 2013. You can download the bits and read more about the release here. While this Beta has been available for a little while, we have been updating the build once a month with more improvements.
A couple of notes on this release:
We’d like to hear your feedback on this release. You are welcome to post comments here, but if you have specific BPA feedback, we’d like to get an email from you so we can get all the details we might need.
Nino Bilic
In Exchange 2013 we introduced the concept of “Server Component States”. Server Component State provides granular control over the state of the components that make up an Exchange Server from the point of view of the environment it is running in. This is useful when you want to take an Exchange 2013 Server out of operation partially or completely for a limited time, but still need the Exchange services on the server to be up and running.
One example of such a situation is when “Managed Availability” (MA) comes to the conclusion that a specific server is not healthy in some respects and therefore should be bypassed temporarily until the bottleneck has been identified and removed. MA does so by utilizing so-called “Offline Responders”. They are explained in some detail in Lessons from the Datacenter: Managed Availability. Their counterpart are “Online Responders”, which bring the server back online when it is determined as being healthy again.
Another example is when a server is being updated, for example with a new CU.
In both situations, the server cannot be taken offline completely, but it also should not be considered as a fully operational member of its Exchange organization as well.
The primary purpose of Managed Availability is, to make the life of Exchange Administrators easier so that they usually do not have to bother themselves with the details. However, in other situations, a certain level of knowledge about the basic concepts behind “Server Component States” might prove to be useful.
A first overview over the current State of all Server Components can be displayed in the Exchange PowerShell with the Get-ServerComponentState –Identity <ServerID> cmdlet:
You see, that the Server Components listed here do not map 1:1 to Exchange Services or processes running on the server. Instead, they provide an abstraction-layer and display “Components” which together make up the interfaces an Exchange Server provides to its environment. The majority of the components have a name like “*Proxy”. They are specific for the CAS Role, while other components like “HubTransport” and “UMCallRouter” are part of the Mailbox server role and “Monitoring” and “RecoveryActionsEnabled” belong to both roles.
In addition to the single components which can be managed individually, there’s also a component called “ServerWideOffline”, which is used to manage the state of all components together, with the exception of “Monitoring” and “RecoveryActionsEnabled”. For this purpose, “ServerWideOffline” overrides individual settings for all other components. It doesn’t touch “Monitoring” and “RecoveryActionsEnabled” because these two components need to stay active in order to keep MA going. Without them, no “OnlineResponder” could bring “ServerWideOffline” back to “Active” automatically.
Usually, Server Components are in one of two States: “Active” or “Inactive”. A third state, called “Draining”, is only relevant for the Components “FrontendTransport” and “HubTransport”.
Whenever the state of a component is supposed to be changed, it has to be done by a “Requester”. For example, the parameter –Requester is mandatory when you run the cmdlet Set-ServerComponentState:
There are altogether five “Requesters” defined:
Requesters are labels - you can choose any of them when running Set-ServerComponentState. But each Requester is treated and stored individually (more on this in the next section) and you should select the Requester that best matches your intention. For example, when you need to set “ServerWideOffline” to “Inactive” for maintenance purposes, it makes no sense to use “HealthAPI” as Requester. You might get what you want that way in terms of functionality; but such a choice will make troubleshooting unnecessarily complicated in case something does not work as expected, and you might get into a conflict with MA. Whenever MA triggers an OfflineResponder or an OnlineResponder it uses “HealthAPI” as Requester; therefore it is a good idea to consider “HealthAPI” as reserved for use by MA.
As stated above, each Requester is handled and stored individually. There’s no relationship or hierarchy amongst them. However, in case of a conflict between two or more Requesters, “Inactive” has a higher priority than “Active”.
Here’s a practical example:
Imagine that “ServerWideOffline” has been set to “Inactive” by two different Requesters, say “Functional” and “Maintenance”:
Then, you set back “ServerWideOffline” to “Active” with one of the two Requesters
As a Result, “ServerWideOffline” and all dependent Components still remain in the state “Inactive”:
In order to set them back to “Active” again, Set-ServerComponentState … -State Active needs to be executed with the second Requester as well.
Obviously, administrators will rarely configure such combinations purposefully. However, we have seen them happening as the result of a mix of processes running in the background and manual configuration.
Information about “Server Components”, “Requesters” and “States” is stored in two different places: Active Directory and the server’s Registry. Storage in the Active Directory facilitates running Set-ServerComponentState against a remote server.
In order to determine precedence in case of a divergence between the two places, a timestamp is used. The newer setting is considered as the intended one.
In Active Directory, the settings are stored in the “msExchComponentStates” attribute of the Exchange Server object in the Configuration-namespace:
In the Registry, the settings are stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\ServerComponentStates:
You can use the Get-ServerComponentState cmdlet from the Shell to retrieve these settings:
<variable>.LocalStates displays the settings in the local Registry and <variable>.RemoteStates displays the settings in the Active Directory.
Most Exchange Server components pick up changes in their Component State “on the fly”. However, this is not the case for the two Components “FrontendTransport” (mapped to the “Microsoft Exchange Frontend Transport” service on CAS Servers) and “HubTransport” (mapped to “Microsoft Exchange Transport” on Mailbox Servers). They pick up changes upon their next restart only. This can cause confusion about their actual state. For example, they might be displayed as “Inactive” in Get-ServerComponentState but functionally still be active since they haven’t been restarted since their state has changed.
In order to alert the Administrator about such an inconsistency they write warnings into the Application Event Log. These warnings (7011 for MSExchangeTransport and 7012 for MSExchangeFrontEndTransport) inform the Administrator about the current and the expected state:
MA has Responders which take care of such inconsistencies and resolve them after a while by a forced crash and restart of the affected services. These Responders have the name “FrontendTransport.ServiceInconsistentState.Restart.Responder” and “HubTransport.ServiceInconsistentState.Restart.Responder”. They can be identified in the Microsoft.Exchange.ActiveMonitoring/ResponderDefinition crimson channel using the methodology described in What Did Managed Availability Just Do To This Service? blog post.
In Exchange 2013 CU2 and CU3 they are only triggered once per day for standalone Mailbox Servers and up to four times per day for DAG members. This might change in future versions, though.
After the inconsistencies have been cleared, Events 7009 from Source “MSExchangeTransport” (or “MSExchangeFrontendTransport”) and Category “Components” are logged, which show the current state:
When the state of one or both of these components is set to “Inactive”, each attempt to connect to the SMTP service on the server (on TCP port 25) triggers the response “421 4.3.2 Service not active” (for the FrontendTransport component) and “451 4.7.0 Temporary Server error” (for the HubTransport component) and corresponding entries are written to the respective SmtpReceive Protocol Logs.
As mentioned in KB 2866822 , messages sent from internal stay in the Outbox or Drafts folder and “Service not active” entries are logged in the “Connect*”-Logs in the “Submission”-Folder underneath “TransportRoles\Logs\Mailbox\Connectivity\” when “HubTransport” is set to “Inactive”.
While an Exchange 2013 Server is updated with CU2, the setup- sets “Monitoring”, “RecoveryActionsEnabled” and “ServerWideOffline” to Inactive using the Requester “Functional” at the beginning, as can be seen in the “ExchangeSetup”-Logfile:
However, when the update exits prematurely because it encounters an unrecoverable error-condition, it does not restore the original state. Even when the Administrator restarts all stopped Exchange services or reboots the server, the Exchange components still remain in the Inactive state.
In order to recover from this situation, you must either find the root cause for the error and remove it so that the setup completes successfully, or manually set the ServerComponentStates back to Active with the Requester “Functional”.
This issue might be fixed in future CUs and SPs.
Perhaps the two most important scenarios where manual changes of Server Component States come into play are:
Scenario 1 is described for DAG-members in some detail in Managing Database Availability Groups on TechNet. However, in practice, it can prove to be trickier than expected, depending on the details of the planned maintenance measure.
The article does not mention that “FrontendTransport” and “HubTransport” have to be restarted, before a change in their Component State becomes effective at all. Without a restart, you continue to receive warning events 7011 and 7012 in the Application Event Log, but the state of the components remains the same as before, until eventually MA detects the inconsistency and force restarts the services.
Also, the problem with the prematurely exiting CU setups mentioned above in the section “Practical Experiences” cannot be resolved by following the recommendations in the article to the dot, because Setup uses the Requester “Functional”, while the article talks about the Requester “Maintenance”.
Special thanks to Bhalchandra Atre, Stephen Gilbert for their contributions as well as Abram Jackson and Bharat Suneja for their review.
Helmut Krüger
The Office Sustained Engineering team has an important update about a potential issue with Outlook 2013 after installing the September 2013 Update. For details about the issue and how to fix affected installations, see Outlook 2013 Folder Pane Disappears After Installing September 2013 Public Update on the Office Sustained Engineering blog.
We’re happy to announce that we’ve added some tests to Microsoft Remote Connectivity Analyzer (RCA), to help you test your mail flow configuration. These tests are intended for customers who use the Exchange Online Protection service to perform spam and malware filtering before sending email messages to your email servers. You can run these tests when setting up the service, or whenever you want to verify that your mail flow is set up correctly.
The Verify MX Record and Outbound Connector Test, shown in the image below, verifies that the MX record for your domain points to EOP, so that mail is routed to EOP for filtering before it reaches your mailboxes. This test also verifies that you have an Outbound on-premises connector configured to deliver email to your on-premises environment.
Figure 1: Verify MX Record and Outbound Connector Test
The Verify Service Delivery Test verifies delivery from the service to your on-premises environment by testing the connection between the service and your IP addresses or fully qualified domain names (FQDNs) defined in your Outbound on-premises connector.
For more information about how to run these tests, see Test Mail Flow With the Remote Connectivity Analyzer.
We welcome any feedback; please send comments to the following email address: exrcafb@microsoft.com.
Exchange Online Protection (EOP) Team