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.
When customers receive an email with a suspected virus, they often ask “What do I do now?”
This blog post helps answer that question and guides you through our recommended process. This is intended for customers using Office 365 or Exchange Online Protection with on-premises Exchange servers.
First, it is important to understand the difference between an infected and uninfected email. Any email that has an attachment containing a script or malicious executable is considered ‘a virus’ for our purposes. This does not include subscription-based messages with links to malicious sites. Those messages would be considered spam and not viruses, and a different approach is used for spam messages (see this and this).
To deal with an email virus, here are some quick actions that you can perform:
1. Start at the filtering layer. We recommend using EOP, as it is the default option for Office 365 users. However, if you are using a third-party filtering mechanism, you will need to contact your vendor to investigate further. If the email virus has gone through Exchange Online Protection (EOP), or if header information is missing, then proceed to the next step.
2. Create a Transport Rule to block the message. Note that Office 365 Small Business and Small Business Premium customers will not have this feature access as mentioned here. See here also for information about transport and inbox rules limits. If you are an EOP customer, you can perform these steps as mentioned in Microsoft Knowledge Base article 2959596:
Under Apply this rule if, choose any attachment has executable content. At this point you can also choose an action under Do the following. We recommended choosing Block the message…
Make sure no other Transport rules exist that would override this rule. See Manage Transport Rules for more information.
3. Submit the email virus sample immediately to Microsoft Malware Protection Center (MMPC) for further analysis. In order to receive analysis updates, please sign into the MMPC Web site, or enter a valid email address. We recommend you to use your Microsoft account email address.
4. Once you have logged in, select O365 and Exchange Online Protection. Follow the instructions outlined on the MMPC to understand if you need to compress the email virus sample before uploading it to the site. Once you have completed the procedure, make note of the final MMPC ID that will be sent to you from the MMPC Submission Support Team.
If you are dealing with an email virus that has a sender of administrator@domain.com or fax@domain.com with domain.com being same as your Office 365 domain, we also recommend blocking the sending server’s IP address and enabling the SPF hard fail in addition to the steps mentioned above. Also, see Best Practices for Configuring EOP.
If you continue receiving infected messages or attachments, then you should copy the message headers from the email virus, and contact Microsoft Customer Service and Support for further assistance. Be sure to have your MMPC ID handy, as well.
Irol PintoTechnical Advisor, Microsoft Corporation
In the last related blog postwe gave some introduction about Exchange Online Protection (EOP), what needs to be done when EOP is not working as desired and spam email troubleshooting process and classification. In this blog we will be moving further and discussing some more advanced option to stop spam emails.
The “IP block list” option enables us to block email messages that came from a specific mail server (specific IP).
EOP - using the the IP Block list
Additional reading
The “International spam” is an interesting option that enables us to block or identify mail as “spam” based on the classification of Geographical location or Language.
Note: We need to be cautious when using this option because we can very easily get into the scenario in which legitimate mail is identified as “bad\spam” mail and be blocked.
Using the International spam option
We can use one (or both) of the following options:
Blocking mail written in the specific language
Blocking mail by Geographical location
Before we begin with instruction of how to use EOP advanced option for spam mail, let’s explore additional classifications of spam mail types and the tools we can use. Using a high level classification, we can define 3 “families” of spam mail types:
The “Advanced options” section under the Content Filter section enables us to “harden” the default spam policy that is implemented by the Office 365 mail security gateways. To avoid incorrectly marking legitimate messages as spam, we can use the “Test mode” (we can describe this as a “Learning mode”). This mode enables us to use the “additional security filter” and decide what will happen when a specific mail item is recognized as spam by the security filter without actuallyperforming any action. We can choose to block\delete the mail item or just report the mail item (Test mode).
Using Content Filter - Advanced options
As you can see there are many possible options that we can select. The options are divided into 2 categories: Increase spam Score and, Mark as spam.
To be able to demonstrate options available in the Content Filter - Advanced options let describe two scenarios:
Scenario 1: Blocking spam mail with malicious content
Over the last month, users were complaining about spam mail that contains malicious content. When users open the mail item, they are automatically redirected to a web site, and once there are invited to download an executable file. To be able to block this spam mail item, we would activate three additional filters: mark as spam if the mail item is or contains:
Empty messages JavaScript or VBScript in HTML Frame or IFrame tags in HTML
Empty messages
JavaScript or VBScript in HTML
Frame or IFrame tags in HTML
By default, each of the security filter status is: Off. When we click on the “option arrow," we can see that we can choose the options: “Off," “On” or “Test." In case that we choose the option “On," each mail that contains content that is not allowed by one of the security filters that was selected (such as JavaScript or VBScript in HTML) will be marked as spam.
In case that we just want to test the “new security filter” we can choose the option “Test." In the following screenshot, we can see that we can choose one of the following three options:
Scenario 2: Blocking spam mail classified as NDR backscatter
NDR backscatter is a special kind of spam because the “mechanism” that’s used by the spammer is different from the “Standard spam mail." NDR backscatter is when spammer forges the user’s email address and sends email on their behalf to other recipients. If the “destination mail system” recognizes the mail as a spam or if the mail is sent to non-existing users, the “destination mail system” creates an NDR message that is sent to the organization recipient (the user whose email address was used by the spammer).
Generally speaking, Office 365 security gateway servers are configured to block this kind of spam mails, but in case that the spam mail manages to “sneak” through, we can add the following filter using the Content Filter - Advanced options.
Using Content Filter - Advanced options - NDR backscatter
That is all for this time. Until we meet again,
Eyal Doron Tech Lead | Office 365 | Israel
Probes are one of the three critical parts of the Managed Availability framework (monitors and responders are the other two). As I wrote previously, monitors are the central components, and you can query monitors to find an up-to-the-minute view of your users’ experience. Probes are how monitors obtain accurate information about that experience.
There are three major categories of probes: recurrent probes, notifications, and checks.
The most common probes are recurrent probes. Each probe runs every few minutes and checks some aspect of service health. They may transmit an e-mail to a monitoring mailbox using Exchange ActiveSync, connect to an RPC endpoint, or establish CAS-to-Mailbox server connectivity. All of these probes are defined in the Microsoft.Exchange.ActiveMonitoring\ProbeDefinition event log channel each time the Exchange Health Manager service is started. The most interesting properties for these events are:
On a typical Exchange 2013 multi-role server, there are hundreds of these probes defined. Many probes are per-database, so this number will increase quickly as you add databases. In most cases, the logic in these probes is defined in code, and not directly discoverable. However, there are two probe types that are common enough to describe in detail, based on the TypeName of the probe:
The basics of a recurrent probe are as follows: start every RecurrenceIntervalSeconds and check (or probe) some aspect of component health. If the component is healthy, the probe passes and writes an informational event to the Microsoft.Exchange.ActiveMonitoring\ProbeResult channel with a ResultType of 3. If the check fails or times out, the probe fails and writes an error event to the same channel. A ResultType of 4 means the check failed and a ResultType of 1 means that it timed out. Many probes will re-run if they timeout, up to the MaxRetryAttempts property.
The ProbeResult channel gets very busy with hundreds of probes running every few minutes and logging an event, so there can be a real impact on the performance of your Exchange server if you perform expensive queries against this event channel in a production environment.
Notifications are probes that are not run by the health manager framework, but by some other service on the server. These services perform their own monitoring, and then feed data into the Managed Availability framework by directly writing probe results. You will not see these probes in the ProbeDefinition channel, as this channel only describes probes that are run within the Managed Availability framework.
For example, the ServerOneCopyMonitor Monitor is triggered by Probe results written by the MSExchangeDagMgmt service. This service performs its own monitoring, determines whether there is a problem, and logs a probe result. Most Notification probes have the capability to log both a red event that turns the Monitor Unhealthy and a green event that make the Monitor healthy once more.
Checks are probes that only log events when a performance counter passes above or below a defined threshold. They are really a special type of Notification probe, as there is a service monitoring the performance counters on the server and logging events to the ProbeResult channel when the configured threshold is met.
To find the counter and threshold that is considered unhealthy, you can look at Monitor Definitions with a Type property of:
· Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor or
· Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor
This means that the probe the Monitor watches is a Check probe.
From the Monitor’s perspective, all three probe types are the same as they each log to the ProbeResult channel. Every Monitor has a SampleMask property in its definition. As the Monitor executes, it looks for events in the ProbeResult channel that have a ResultName that matches the Monitor’s SampleMask. These events could be from recurrent probes, notifications, or checks. If the Monitor’s thresholds are reached or exceeded, it becomes Unhealthy.
It is worth noting that a single probe failure does not necessarily indicate that something is wrong with the server. It is the design of Monitors to correctly identify when there is a real problem that needs fixing versus a transient issue that resolves itself or was anomalous. This is why many Monitors have thresholds of multiple probe failures before becoming Unhealthy. Even many of these problems can be fixed automatically by Responders, so the best place to look for problems that require manual intervention is in the Microsoft.Exchange.ManagedAvailability\Monitoring crimson channel. These events sometimes also include the most recent probe error message (if the developers of that Health Set view it as relevant when they get paged with that event’s text in Office 365).
There are more details on how Monitors work, and how they can be overridden to use different thresholds in the Managed Availability Monitors article.
Abram JacksonProgram Manager, Exchange Server
Update 8/26/14: changed the resolution to include the release of Exchange 2013 Cumulative Update 6 (CU6).
An important update is now available to resolve issues customers are currently experiencing when using the Hybrid Configuration Wizard (HCW) to create a new or manage an existing hybrid deployment with Microsoft Exchange Server 2013.
If you currently have an Exchange 2013-based hybrid deployment configured, you will not notice any issues unless you rerun the HCW as part of updating or managing your existing hybrid features. If you need to reconfigure your hybrid deployment, you should instll Exchange Server 2013 (Cumulative Update 6) to correct this issue with the HCW.
For Exchange 2013 organizations creating new or managing an existing hybrid configuration with the HCW, the following HCW error message indicates you are experiencing the issue this update addresses:
Subtask CheckPrereqs execution failed: Check Tenant Prerequisites Deserialization fails due to one SerializationException: Microsoft.Exchange.Compliance.Serialization.Formatters.BlockedTypeException: The type to be (de)serialized is not allowed: Microsoft.Exchange.Data.Directory.DirectoryBackendType
If you experience this issue, please install Exchange 2013 Cumulative Update 6 (CU6).
Brian Shiers Technical Product Manager
Q: I’ve already configured a hybrid deployment with Exchange Server 2013 and I don’t need to make any changes to my hybrid configuration or features, do I need to apply this (interim) update?
A: No, you can wait for the fix to be delivered in the next Exchange Server 2013 update as long as you don’t have the need to run the Hybrid Configuration Wizard. EDIT: CU6 is now released and available.
Q. I may need to make updates to my Exchange 2013-based hybrid deployment before the next Exchange Server 2013 update, what are my options?
A. If you need to update your hybrid deployment features, install Exchange Server 2013 Cumulative Update 6 (CU6). Attempting to manually configure a new or update an existing hybrid deployment without HCW can result in unsupported hybrid deployment states.
Q: Are customers who use Exchange Server 2010 impacted by this update?
A: No, this only applies to customers using Exchange Server 2013 to configure a hybrid deployment with Office 365.
Q: If we apply the update specific for SP1 or CU5 do I have to do anything special to update to CU6 or later in the future?
A: The interim update does NOT need to be uninstalled. We allow later CU’s to install over Interim Updates and Security Updates directly as of CU3.
I wanted to write a series of blog posts talking about email spam in Office 365. While majority of spam mail is blocked by the Office 365 mail security gateways, there are no perfect systems that will block 100% of spam all the time, some can still get through. In case that we do experience spam mail, we can use several tools and configuration options that are available for us in Office 365 to deal with it and improve effectiveness.
In this series, we will quickly review different types of spam mail. Then we will present different tools that we can use for fighting spam mail in an Office 365 environment and try to “match” the “spam tool” for the task based on the type of the spam.
Also please note that while we are approaching this from Office 365 viewpoint, many of the procedures listed here apply to both on-premises and hybrid deployments.
One of the advantages of using Office 365 is that transparently, behind the scenes, we implement EOP – Exchange Online Protection (the former mail security infrastructure was implemented by FOPE services).
The Exchange Online Protection infrastructure serves as mail gateways, which are responsible for the “Hygiene” of incoming and outgoing mail flow. The purpose of this mail gateway’s is to filter any malware, virus or spam that might be included in the mail flow that comes from external sources to Office 365 recipients (incoming mail flow) and also mail that is sent from Office 365 recipients to external sources. A bit over-simplified but think of it like this:
EOP aims to provide the best possible protection, but from time to time Office 365 subscribers can experience spam mail that gets into their mailbox.
Before going further into this, let’s not forget that there is no “perfect solution” that will block 100% of spam mail because “spam solutions\gateways”, will always need to face issues of:
Certainly any hygiene solution, even a cloud-based one, will have times when a few messages originating from a creative spammer sneak through before it is recognized as a threat. The advantage that a cloud-based solution offers is that it is set up to recognize those threats quickly, partially due to the quantity of email that it processes.
Additionally, different users will always have slightly different expectations. It is therefore challenging to have a default configuration setting that is perfect for different business customers, each with unique requirements. One person’s spam email can be another person’s legitimate business email. EOP defaults tend to be slightly less strict rather than risk a false positive. If these defaults are not adequate for your organization, EOP offers great flexibility in allowing customization of anti-spam settings.
This series of blog posts will help you understand what to do in either situation.
To create a clear path of the troubleshooting process, we will need to implement the workflow similar to the one in the following diagram:
The most basic step is to get essential information about the spam message. Determine if the mail message is truly a spam message and if so, try to recognize the type of spam. Based on this information, choose the right “tools” for mitigating it (we will cover more of those in future posts).
Questions to answer
Here is a list of questions that could help gather required information:
General characteristics:
When we deal with spam mail, we need to try to block the spam mail by using the available option from the “Server side” (Exchange online and EOP) and the “Client side” (Outlook). The process of blocking the spam mail could be implemented as a combined operation of using tools for filtering spam mail and other tools for reporting (sending a sample of the spam mail) to the Microsoft team that manages the EOP infrastructure.
1. Microsoft Junk E-mail Reporting Add-in
The Microsoft Junk E-mail Reporting Add-in, is a very useful Outlook add-in that enables each of the users to report the offending message to Microsoft.
By selecting the mail item and then choosing the option of “Report Junk," the mail item will automatically be sent to the Microsoft mail security team for further analysis and investigation to help to improve the effectiveness of our junk e-mail filtering technologies.
Using the Microsoft Junk E-mail Reporting Add-in
In Outlook 2010\2013, the Microsoft Junk E-mail Reporting Add-in is implemented by additional menu option named: Report junkthat is added to the “Junk” section to be able to report an email as spam. To “mark” mail item as Junk use the following procedure:
A warning message appears and informs the user that the mail item will be reported as spam. Choose the “Yes” option.
When we choose the “yes” option, the following events will occur:
In Outlook 2007, the option to “report junk” will be added on the top menu option.
2. Outlook Junk option - block sender
Another option that is available for us from “client side” is the Outlook junk component and the option of “block sender” (Add a sender to the Blocked Senders list).
This option is most suitable in a scenario that the spam mail is delivered from a specific recipient email address. In reality, many times the “spammers” mange to send the spam mail by using a different source recipient email address, so the option to “block sender” will not help us in such scenarios.
Add a sender to the Blocked Senders list
In case that you want to block the sender who sends spam mail, we can use the junk menu for blocking this recipient.
Additional reading:
3. Unsubscribe from a mailing list
In case that the user reports “spam mail” and when checking the mail item, we see that the sender is not considered as “spammer” (mail is just a standard advertising email that is sent to a distribution list that the user is on), most of the time the mail will include an option that enables the user to unsubscribe from the mailing list. So, before we start to use the “heavy artillery," please check if the option of “unsubscribe” exists and unsubscribe from the mailing list.
4. Educate users: How to avoid spam
Educating users to avoid spam belongs to a “proactive” section in which we are trying to avoid a scenario that could lead to spam mail.
By providing our users instructions and guidance about behavior they should avoid, we can prevent or significantly reduce in advance the occurrence of “spam events."
You can read more information about this subject by using the following link:
10 tips on how to help reduce spam
That is all for today – part 2 (starting to talk about server side solutions) to follow soon!
Quick note to let you know we've announced a new unified technology event for enterprises. If you've attended Microsoft Exchange Conference (MEC), SharePoint Conference, Lync Conference or Project Conference, this event is for you! Head over to Office Blogs for more.
Bharat Suneja
While we do not post about purely development subjects very often, I wanted to point you to a pretty cool post on the Exchange dev blog:
Zapier’s Office 365 API Journey
It may come as a surprise to some just how seamless it is to jump into leveraging Office 365 APIs. If this interests you, enjoy!
Nino Bilic
In the last week there have been two big improvements related to CalCheck and OffCAT that will make life a little easier when troubleshooting ‘calendar’ issues.
2678030 Information about the Calendar Checking Tool for Outlook (CalCheck)
The detailed solutions added under each type of error/warning flagged by CalCheck will help you resolve/fix meetings more quickly.
Also, there is an HTML bookmark on each bullet item in the article so OffCAT can point you directly to the solution instead of requiring you to find the solution in the above article.
This link will take you directly to the bookmarked section of article 2678030 so you can go right to the section of the article that applies to the error/warning flagged by CalCheck.
To see this new functionality in OffCAT, just search for ‘calendar checking’ in Configuration Details to see this new node.
The link for the error shown in the above figure takes you to the ‘No dispidRecurring property’ section of the article under Item-level checks.
And, the solution for this problem is found directly underneath.
Thanks,
The OffCAT team
Update: Scale improvements have been rolled out for Office 365 announced in 10x increase in Public Folder limits.
It has been about two months since I was in Austin at my first Microsoft Exchange Conference. I must say Austin left quite an impression on me, partly because of the wonderful people and great music, but mostly because of the immensely passionate public folder customers I got a chance to meet. Public folders are one of the oldest living artifacts in Exchange Server and MEC was a reconfirmation that they continue to serve some critical and unique collaboration scenarios for our customers. MEC allowed me to meet with some of our largest and most complex public folder customers to discuss in great detail how some companies’ entire business processes rely on public folders.
At MEC, customers asked us for higher scale and more functionality in Exchange modern public folders. The 3 top asks in the order of priority for the public folder team included:
As discussed at MEC, scaling up modern public folders is a priority for us. We have already made significant strides towards improving public folder scale. We have removed the design limitation which was the root cause for the hard limit of 10,000 total folders - this opens up new doors for scale. Synchronization of public folder hierarchy was a major component responsible for the 10,000 folder limitation. Full hierarchy sync has been improved to the point where it can scale linearly as folder count grows within the environment. There have also been storage optimizations which will provide better performance in operations on public folders in run state.
The good news is that with these recent changes you can expect to see higher limits on public folders rolled out in the next few months. Office 365 customers should see the total folder limit increase to 100,000by early July. For our large on premises customers, we are targeting to increase this limit further with the CU6 release. As we get closer to the CU6 date we will publish an update on how far we were able to push the limit for on premises customers.
This is just the first round in the public folder scale improvements we are working to deliver. As we move forward with these improvements, our goal is to scale to at least 1 million folders. We are also looking into making improvements to migration as well as store more bytes in more public folder mailboxes with more users accessing them.
Scale updates is complex business. Investigating and working through fixes on scale required a significant lead time and these updates didn’t fit into the CU5 timeline as work from multiple teams with features dependent on each other were involved. So we plan to roll in the above mentioned scale improvements in CU6 for our on-premises customers. Office 365 customers however will see these updates as soon as the code containing all of the necessary public folder scale improvements rolls out into service. This service update is targeted for early July, but as with all Office 365 updates some tenants will see it sooner than others until the service update has been deployed world-wide. We will be publishing another blog around the CU6 timeframe to share news about the next round of public folder scale updates.
We expect calendar and contact public folders support in OWA to follow the scale updates. We do not have exact timelines on these yet. Following calendar & contact folder support in OWA we will be working to deliver additional management tooling to assist in your management of public folders. Stay tuned for updates.
At Exchange we live to solve tough problems. Public folders were re-architected in Exchange 2013 to take advantage of the well proven mailbox design and deliver a solution for customers moving to Office 365 with public folders. We will continue building towards this promise as we proceed to meet customer requirements. Thanks to the customers who provided input at MEC. We will keep you updated with further details in advance on the Exchange Blog.
Kanika RamjiProgram Manager, Exchange Public Folders
This article continues the analysis I started in my previous article, DAG: beyond the “A”.
We all understand that a good technology solution must have high levels of availability, and that simplicity and redundancy are the two major factors that drive solution availability. More specifically:
My previous article provides mathematical formulas that allow you to calculate planned availability levels for your specific designs. However, this analysis was performed from a standpoint of a single datacenter (site). Recently the question was asked: how does bringing site resilience to an Exchange design affect the solution's overall level of availability? How much, if any, will we increase overall solution availability if we deploy Exchange in a site resilient configuration? Is it worth it?
Let us reiterate some of the important points for a single site/datacenter solution first. Within a datacenter, there are multiple critical components of a solution, and the availability of an entire solution can be analyzed using the principles described in DAG: beyond the “A”, based on the individual availability and redundancy levels of the solution components.
Most interestingly, availability depends on the number of redundant database copies deployed. If the availability of a single database copy is A = 1–P (this includes the database copy, and the server and disk that are hosting it), then the availability of a set of N database copies will be A(N) = 1–PN = 1–(1–A)N. The more copies, the higher the availability; the fewer copies, the lower the availability. The graph below illustrates this formula showing the dependency of A(N) on N:
Figure 1: Availability dependence on the number of redundant copies
Note: All plots in this article were built using the Wolfram Alpha online mathematical computation engine.
For example, if A = 90% (value selected on the graph above), and N=4, then A(4) = 99.99%.
However, the full solution consists not just of the redundant database copies but of many other critical components, as well: Active Directory, DNS, load balancing, network, power, etc. We can assume that the availability of these components remains the same regardless of how many database copies are deployed. Let’s say the overall availability of all of these components taken together in a given datacenter is Ainfra. Then, the overall availability of a solution that has N database copies deployed in a single datacenter, is A1(N)= Ainfrax A(N).
For example, if Ainfra = 99.9%, A = 90%, and N=4, then A1(4)= 99.89%.
So we figured that availability of a single datacenter solution is A1 (for example, A1=99.9%=0.999). Correspondingly, probability of a datacenter failure is P1=1–A1 (in this example, P1=0.1%=0.001).
Let’s assume that a second site/datacenter has availability of A2 (it could be the same value as A1 or it could be different – it depends on the site configuration). Correspondingly, its probability of failure is P2=1– A2.
Site resilience means that if the solution fails in the first datacenter, there is still a second datacenter that can take over and continue servicing users. Therefore, with site resilience the solution will fail only when *both* datacenters fail.
If both datacenters are fully independent and don’t share any failure domains (for example, they don’t depend on the same power source or network core switch), then the probability of a failure of both datacenters is P= P1xP2. Correspondingly, the availability of the solution that involves site resilience based on two datacenters is A = 1–P = 1–(1–A1)x(1–A2).
Because values of both P1 and P2 are very small, the availability of a site resilient solution effectively sums the “number of nines” for both datacenters. In other words, if DC1 has 3 nines availability (99.9%), and DC2 has 2 nines availability (99%), the combined site resilient solution will have 5 nines availability (99.999%).
This is actually a very interesting result. For illustration, let us use datacenter tier definitions adopted by ANSI/TIA (Standard TIA-942) and the Uptime Institute, with the availability values for four datacenter tiers defined as follows:
We can see that if we deploy two relatively inexpensive Tier 2 datacenters, the resulting availability of the solution will be higher than if we deploy one very expensive Tier 4 datacenter:
Of course, this logic applies not only to datacenter considerations but also to any solution that involves redundant components. Instead of deploying an expensive single component (e.g., a disk, a server, a SAN, a switch) with a very high level of availability, it might be cheaper to deploy two or three less expensive components with properly implemented redundancy, and it will actually result in better availability. This is one of the fundamental reasons why we recommend using redundant commodity servers and storage in the Exchange Preferred Architecturemodel.
The advantage of having two site resilient datacenters instead of a single datacenter is obvious if we assume that site resilient solutions are based on the same single datacenter design implemented in each of the two redundant datacenters. For example, if we compare one site with 2 database copies and two sites with 2 database copies in each, obviously the second solution has much higher availability, not so much because of site resilience but simply because now we have more total copies – we moved from 2 total copies to 4.
But this is not a fair comparison. What is the effect of the site resilience configuration itself? What if we compare the single datacenter solution and the site resilient solution when they have the same number of copies? For example, single datacenter solution with 4 database copies and a site resilient solution with two sites with 2 database copies in each site (so that both solutions have 4 total database copies). Here the calculation becomes more complex.
Using the results from above, let’s say the availability of a solution with the single site and M database copies is A1(M) (for example, A1(4)=99.9%=0.999). Obviously, availability of the same solution but with fewer database copies will be lower, (for example, A1(2)=90%=0.9).
Let’s assume similar logic for the second site: let it have N copies and a corresponding availability of A2(N).
Now we need to compare the following values:
These values are not very easy to calculate, so let us assume for simplicity that both datacenters are equivalent (A1 = A2) and both have equal number of copies (M=N). Then we have:
AS = A1(2N)
ASR = 1–(1– A1(N))2
We know that A1 = Ainfra x A(N), and that A(N) = 1–PN = 1–(1–A)N. Since we consider datacenters equivalent, we can assume that Ainfrais the same for both datacenters. This gives us:
AS = Ainfra x (1–(1–A)2N)
ASR = 1–(1– Ainfra x (1–(1–A)N))2
These values depend on three variables: Ainfra, A, and N.
To compare these values, let us fix two of the variables and see how the result depends on the third one.
One comparison is to see how the values change depending on A if Ainfra and N are fixed. For example, let Ainfra= 99% = 0.99, and N=2:
Figure 2: Availability dependence on number of redundant copies for the single site and site resilient scenarios
The blue line (bottom curved line) represents the single datacenter solution, and the purple line (top curved line) represents the site resilient solution. We can see that site resilient solution always provides better availability, and the difference is steady even if the availability of an individual database copy approaches 1. This is because the availability of other critical components (Ainfra) is not perfect. The better Ainfra(the closer it is to 1), the smaller the difference between the two solutions.
To perform another comparison and confirm the last conclusion, let us see how availability changes depending on Ainfraif A and N are fixed. For example, let A=0.9 and N=2:
Figure 3: Availability dependence on the datacenter infrastructure availability for the single site and site resilient scenarios
Again, we can see that the site resilient solution provides better availability but the difference between the two availability results is proportional to 1–Ainfra and so it vanishes when Ainfra–>1, which confirms the conclusion made earlier.
In other words, if your single datacenter has a perfect 100% availability, then site resilient solution is not needed. Now isn’t that obvious without any calculations?
The following table illustrates these results:
You can leverage this simple Excel spreadsheet that allows you to play with the numbers representing Ainfra, A, and N (they are formatted in red), and see for yourself how it affects resulting availability values.
Deploying a site resilient design increases availability of a solution, but the benefit of site resilience diminishes if a single datacenter solution has high level of availability by itself.
Using the formulas above, you can calculate exact availability levels for your specific scenarios if you use proper input values.
Note: To avoid confusion, everywhere above we are talking about planned availability. This purely theoretical value demonstrates what can be expectedof a given solution. On comparison, the actually observed availability is a statistical result; in actual operations, you might observe better or worse availability values, but the averages over the long period of monitoring should be close to the theoretical values.
Acknowledgement: Author is grateful to Ramon Infante, Director of Worldwide Messaging Community at Microsoft, and Jeffrey Rosen, Solution Architect and US Messaging Community Lead, for helpful and stimulating discussions.
Boris Lokhvitsky Delivery Architect Microsoft Consulting Services
The Exchange team is announcing today the availability of our most recent quarterly servicing update to Exchange Server 2013. Cumulative Update 5 for Exchange Server 2013 and updated UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 5 represents the continuation of our Exchange Server 2013 servicing and builds upon Exchange Server 2013 Service Pack 1. The release 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 5 can be found in Knowledge Base Article KB2936880. Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 5 today. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 5 as well.
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 your attention to a couple of items in particular about the Cumulative Update 5 release:
For the latest information and product announcements please read What’s New in Exchange Server 2013, Release Notesand product documentation available on TechNet.
Cumulative Update 5 includes Exchange related updates to Active Directory schema and configuration. For information on extending schema and configuring the active directory please review the appropriate TechNet documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474to adjust the settings.
Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU5) or the prior (e.g., CU4) Cumulative Update release.
The Exchange Team
The Exchange team is announcing today the availability of Update Rollup 6 for Exchange Server 2010 Service Pack 3. Update Rollup 6 is the latest rollup of customer fixes available for Exchange Server 2010 Service Pack 3. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 6 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 6 may be found in KB2936871. Customers running any Service Pack 3 Update Rollup for Exchange Server 2010 can move to Update Rollup 6 directly.
The release is now available on the Microsoft Download Center. Update Rollup 6 will be available on Microsoft Update in early July.
Note: KB articles may not be fully available at the time of publishing of this post.
Cumulative Update 5 (CU5) for Exchange Server 2013 will be released soonTM, but before that happens, I wanted to make you aware of a behavior change in the Offline Address Book that is shipping in CU5. Hopefully this information will aid you in your planning, testing, and deployment of CU5.
In all previous major releases, the Offline Address Book (OAB) was generated by a particular server within your organization based on an administrator defined schedule. This architecture provided flexibility as it allowed you to deploy OAB generation servers based on the needs within your environment, and depending on how you deployed your OABs, could even enable users to download the OAB from the closest CAS available.
Let’s apply this information to an example. Contoso operates as a distributed messaging environment, with offices in Redmond and Portland. Each site has an OAB generated based on the Default Global Address List, allowing the local users to download the OAB without traversing an expensive (and possibly highly latent) WAN. If the users travel, they download the OAB changes across the WAN link.
Figure 1: Exchange 2010 OAB Contoso Architecture
While this model provided flexibility, it unfortunately had a single point of failure – if the server failed, OAB generation stopped. This also meant that high availability architectures in Exchange 2010 did not provide any benefit to the OAB.
Exchange 2013 has introduced dramatic changes to the OAB. The OAB is no longer generated by a server; instead, the OAB is generated by a special type of arbitration mailbox, known as an organization mailbox. The generation is controlled by a time-based assistant, OABGeneratorAssistant, which works in conjunction with the workload management infrastructure to ensure that the system is not burdened by the OAB’s generation.
This new infrastructure can also take advantage of the high availability architecture of Exchange 2013. The OAB mailbox can be deployed on a mailbox database that has multiple copies, thereby mitigating a failure mode that occurred in previous releases.
From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which attempts to proxy the request to an OAB mailbox within the local site. If there is no OAB generation mailbox located within the local AD site, CAS picks one in another site with the lowest site connection cost. If there is more than one OAB generation mailbox with same lowest cost, CAS will pick one at random.
However, this new architecture introduces some deficiencies.
Referring back to the previous example, now upgraded to Exchange 2013, Contoso’s administrator created an OAB generation mailbox in Portland, mirroring the Exchange 2010 architecture. Both OAB generation mailboxes generate the Redmond and Portland OABs:
Figure 2: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes
If Contoso contained more locations, each hosting its own OAB, then the number of OABs generated by the OAB generation mailbox increases proportionally. Each OAB generated increases the compute cycles and capacity requirements on each Mailbox server hosting an OAB generation mailbox.
This tenet means that traveling users and single namespace designs are impacted. Referring back to Figure 2, with the environment now utilizing a single namespace across the two locations, there is a fifty percent chance that a user will hit CAS infrastructure that is not located within the same site as the user’s mailbox. CAS will utilize the local OAB instance vs. proxying between sites as the local site contains the closest OAB generation mailbox. As a result, users will download full OABs each time Outlook’s OAB synchronization request is processed in a different site when compared to the mailbox’s location.
There’s another way this tenet can impact clients – deploying more than a single OAB generation mailbox in a site. For example, if the Redmond site had two OAB generation mailboxes, both OAB generation mailboxes would generate unique, separate instances of the Redmond OAB. Even if the Redmond users were always directed to the Redmond CAS infrastructure, because there are two OAB generation mailboxes, CAS could proxy to either mailbox. As a result, each time an Outlook client is directed to a different OAB download instance, a full OAB download is triggered. In other words, if there are two (or more) OAB generation mailboxes located within the same Active Directory site, a user could download either OAB, resulting in full OAB downloads each time the user accesses a different OAB generation mailbox’s OAB files.
Figure 3: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes in a Single Site
These deficiencies led to the guidance of deploying only a single OAB generation mailbox per organization. While this guidance resolves the aforementioned issues, it is not practical in large distributed on-premises environments or in hosting environments because it forces the users to download the OAB over expensive (and often times, saturated) WAN links and it is a single point of failure – if connectivity to the site hosting the OAB generation mailbox is inaccessible, clients cannot retrieve updated OAB data.
CU5 moves away from the previous model where an OAB generation mailbox generates all the OABs in the organization. While an OAB generation mailbox can continue to generate multiple OABs (the default behavior when you deploy Exchange 2013), what’s new in CU5 is that an OAB can only be assigned to a single OAB generation mailbox.
This architectural change addresses the aforementioned deficiencies:
From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which proxies the request to the linked OAB generation mailbox that is responsible for generating the requested OAB.
As a result, Contoso can now deploy the following OAB architecture:
Figure 4: Exchange 2013 OAB Contoso Architecture
Redmond users will now only download the Redmond OAB from the Redmond AD site and Portland users will only download the Portland OAB from the Portland AD site. Neither set of users will have an OAB full download as a result of traveling between locations because the users will always be referred back to the Mailbox server hosting the OAB generation mailbox that contains their OAB.
When you upgrade to CU5, all existing OABs are linked to the system arbitration mailbox, SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, regardless of whether there are additional OAB generation mailboxes within the environment. This ensures that all OABs are still generated after CU5 is installed. This has two implications:
Note: Users will not experience full OAB downloads after CU5 is deployed if your deployment does not contain multiple OAB generation mailboxes.
The upgrade order of the roles only matters if you have multiple OAB generation mailboxes deployed. In CU5, the HTTP proxy logic in the Client Access server role was updated to ensure that an OAB request is routed to the correct OAB generation mailbox. Therefore, it is important to upgrade your Client Access servers prior to upgrading your Mailbox servers if you have multiple OAB generation mailboxes deployed in your environment. If you upgrade your Mailbox servers to CU5 before upgrading your Client Access servers, users will potentially be routed to OAB generation mailboxes that are not responsible for the OAB the user is requesting, resulting in failed download requests.
Once CU5 is deployed, you can dedicate existing OABs to specific OAB generation mailboxes by executing the following command, utilizing the GeneratingMailbox parameter:
Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox "CN=OAB Mailbox 1,CN=Users,DC=contoso,DC=com"
Important: If your OAB generation mailboxes are deployed in DAGs, upgrade all Mailbox servers to CU5 before dedicating an OAB to a specific OAB generation mailbox. If you do not, when the database hosting the OAB generation mailbox is activated on a server running an older version, the OAB assistant will generate all OABs.
The GeneratingMailbox parameter only accepts the distinguished name value of the OAB generation mailbox; other identity types (e.g., domain\account, UPN, alias, etc.) do not work. One way around this is to utilize the following process:
$mbx = get-mailbox oabmbx1 –arbitration Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox $mbx.Identity
Once you have linked the OAB to an OAB generation mailbox, you will need to execute Update-OfflineAddressBook:
Update-OfflineAddressBook "Portland OAB"
When creating new OABs you need to specify the GeneratingMailbox property:
New-Mailbox -Arbitration -Name "OAB Mailbox 3" -Database DB4 -UserPrincipalName oabmbx3@contoso.com –DisplayName "OAB Mailbox 3" Set-Mailbox "OAB Mailbox 3" –Arbitration –OABGen $true New-OfflineAddressBook -Name "Bel Air OAB" –GeneratingMailbox "CN=OAB Mailbox 3,CN=Users,DC=contoso,DC=com" –AddressLists "Default Global Address List"
Note: GeneratingMailbox is not a required parameter when creating an OAB. If the GeneratingMailbox parameter is not specified, the Exchange Management Shell will return the following warning: GeneratingMailbox is null; this OAB will not be generated until GeneratingMailbox is set to an arbitration mailbox with the OABGen capability.
Once you have created the OAB in your environment, you will need to execute Update-OfflineAddressBook:
Update-OfflineAddressBook "Bel Air OAB"
We have heard your feedback loud and clear that the Exchange 2013 OAB architecture does not meet the needs of distributed messaging environments. Dedicating OABs to specific OAB generation mailboxes is the first step in improving the capabilities of the OAB in the on-premises product. I won’t go into specifics at this early stage of development, but we are not finished with improving the OAB architecture. As the plans finalize, I will share more.
Ross Smith IV Principal Program Manager Office 365 Customer Experience
Among the many new features delivered in Exchange 2013 SP1 is a new method of connectivity to Outlook we refer to as MAPI over HTTP (or MAPI/HTTP for short). We’ve seen a lot of interest about this new connection method and today we’ll give you a full explanation of what it is, what it provides, where it will take us in the future, and finally some tips of how and where to get started enabling this for your users.
MAPI over HTTP is a new transport used to connect Outlook and Exchange. MAPI/HTTP was first delivered with Exchange 2013 SP1 and Outlook 2013 SP1 and begins gradually rolling out in Office 365 in May. It is the long term replacement for RPC over HTTP connectivity (commonly referred to as Outlook Anywhere). MAPI/HTTP removes the complexity of Outlook Anywhere’s dependency on the legacy RPC technology. Let’s compare the architectures.
MAPI/HTTP moves connectivity to a true HTTP request/response pattern and no longer requires two long-lived TCP connections to be open for each session between Outlook and Exchange. Gone are the twin RPC_DATA_IN and RPC_DATA_OUT connections required in the past for each RPC/HTTP session. This change will reduce the number of concurrent TCP connections established between the client and server. MAPI/HTTP will generate a maximum of 2 current connections generating one long lived connection and an additional on-demand short-lived connection.
Outlook Anywhere also essentially double wrapped all of the communications with Exchange adding to the complexity. MAPI/HTTP removes the RPC encapsulation within HTTP packets sent across the network making MAPI/HTTP a more well understood and predictable HTTP payload.
An additional network level change is that MAPI/HTTP decouples the client/server session from the underlying network connection. With Outlook Anywhere connectivity, if a network connection was lost between client and server, the session was invalidated and had to be reestablished all over again, which is a time-consuming and expensive operation. In MAPI/HTTP when a network connection is lost the session itself is not reset for 15 minutes and the client can simply reconnect and continue where it left off before the network level interruption took place. This is extremely helpful for users who might be connecting from low quality networks. Additionally in the past, an unexpected server-side network blip would result in all client sessions being invalidated and a surge of reconnections being made to a mailbox server. Depending on the number of Outlook clients reconnecting, the re-establishing of so many RPC/HTTP connections might strain the resources of the mailbox server, and possibly extend the outage in scope (to Outlook clients connected to multiple servers) and time, caused by a single server-side network blip.
You are probably asking yourself why the Exchange team would create a complete replacement for something so well-known and used. Let us explain.
The original Outlook Anywhere architecture wasn’t designed for today’s reality of clients connecting from a wide variety of network types – many of these are not as fast or reliable as what was originally expected when Outlook Anywhere was designed. Consider connections from cellular networks, home networks, or in-flight wireless networks as a few examples. The team determined the best way to meet current connection needs and also put Exchange in the position to innovate more quickly was to start with a new simplified architecture.
The primary goal of MAPI/HTTP is provide a better user experience across all types of connections by providing faster connection times to Exchange – yes, getting email to users faster. Additionally MAPI/HTTP will improve the connection resiliency when the network drops packets in transit. Let’s quantify a few of these improvements your users can expect. These results represent what we have seen in our own internal Microsoft user testing.
When starting Outlook users often see the message “Connecting to Outlook” in the Outlook Status bar. MAPI/HTTP can reduce the amount of time a user waits for this connection. In the scenario when a user first launches Outlook the time to start synchronization improved to 30 seconds vs. 90 seconds for Outlook Anywhere for 70% of the monitored clients.
Improvements are also delivered when clients are resuming from hibernation or simply re-connecting to a new network. Testing showed that 80% of the clients using MAPI/HTTP started syncing in less than 30 seconds vs. over 40 seconds for Outlook Anywhere clients when resuming from hibernation. This improvement was made possible as MAPI/HTTP implements a pause/resume feature enabling clients to resume using an existing connection rather than negotiating a new connection each time. Current sessions for MAPI/HTTP are valid for 15 minutes, but as we fine tune and expand this duration, these improvements will be even more noticeable.
Improvements aren’t limited to end users. IT administrators will gain greater protocol visibility allowing them to identify and remediate situations faster and with more confidence. Due to MAPI/HTTP moving to a more traditional HTTP protocol payload, the ability to utilize already known tools common to HTTP debugging is a reality. IIS and HttpProxy logs will now contain information similar to other HTTP based protocols like Outlook Web App and be able to pass information via headers. At times in the past, certain debug procedures for RPC/HTTP were only available via proprietary internal Microsoft tools. This move should put all customers on the same level playing field as far as what tools are available for debug purposes.
Exchange administrators also will find response returned by Autodiscover for MAPI/HTTP to Outlook is greatly simplified. The settings returned are just protocol version and endpoint URLs for Outlook to connect to Exchange mailbox and directory from inside or outside the customer’s corporate network. Outlook treats the URLs returned as opaque and uses as-is, minimizing the risk of connectivity breaking with future endpoint changes. Since MAPI/HTTP, like any other web protocol, simply sends an anonymous HTTP request to Exchange and gets back the authentication settings, there is no need for Autodiscover to advertise the authentication settings. This makes it easier to roll out changes in authentication settings for Outlook.
MAPI/HTTP puts the Exchange team in position to innovate more quickly. It simplifies the architecture removing dependency on the RPC technologies which are no longer evolving as quickly as the customers demand. It provides the path for extensibility of the connection capabilities. A new capability that is on the roadmap for Outlook is to enable multi-factor authentication for users in Office 365. This capability is made possible with the use of MAPI/HTTP and is targeted to be delivered later this year. For a deeper look at this upcoming feature you can review the recent Multi-Factor Authentication for Office 365 blog post. This won’t stop with Office 365 MFA, but provides the extensibility foundation for 3rdparty identity providers.
Let’s walk through the scenario of an Outlook 2013 SP1 client connecting to Exchange Server 2013 SP1 after MAPI/HTTP has been enabled.
So now we have a clear set of advantages you can offer users, let’s review the requirements to enable MAPI/HTTP.
Server Requirements: Use of MAPI/HTTP requires allExchange 2013 Client Access Servers to be updated to Exchange Server 2013 SP1 (or later). The feature is disabled by default in SP1 so you can get the servers updated without anyone noticing any changes. If you are an Office 365 Exchange Online customer you won’t have anything to worry about on the service side of deployment.
Client Requirements:Outlook clients must be updated to use MAPI/HTTP. Office 2013 SP1 or Office 365 ProPlus February update (SP1 equivalent for ProPlus) are required for MAPI/HTTP. It is recommend you deploy the May Office 2013 public update or the April update for Office 365 ProPlus to eliminate the restart prompt when MAPI/HTTP is enabled for users.
Prior version clients will continue to work as-is using Outlook Anywhere. Outlook Anywhere is the supported connection method for those clients. We do plan to add MAPI/HTTP support to Outlook 2010 in a future update. We will announce timing when we are closer to its availability.
Part one of getting ready is to get the required updates to your servers and clients as described in the prior section. Part two of getting ready is evaluating potential impacts MAPI/HTTP might have on your on-premises servers. Again if you an Office 365 customer you can ignore this bit.
When you implement MAPI/HTTP in your organization, it will have an impact on your Exchange server resources. Before you go any further you need to review the impacts to your server resources. The Exchange 2013 Server Role Requirements Calculatorhas been updated to factor in use of MAPI/HTTP. You need to use the most recent version of the calculator (v6.3 or later) before you proceed. MAPI/HTTP increases the CPU load in the Exchange Client Access Servers. This is a 50% increase over Exchange 2013 RTM, however it is still lower than Exchange 2010 requirements. As you plan be mindful that deploying in a multi-role configuration will minimize the impact to your sizing. Again use the calculator to review potential impacts this may have in your environment. This higher CPU use is due to the higher request rate with several short-lived connections, with each request taking care of authentication and proxying.
To provide the best MAPI/HTTP performance you need to install .NET 4.5.1 on your Exchange 2013 servers. Installing .NET 4.5.1 will avoid long wait times for users thanks to a fix to ensure the notification channel remains asynchronous to avoid queued requests.
The change in communication between Exchange and Outlook has a small impact on the bytes sent over the wire. The header content in MAPI/HTTP is responsible for an increase in bytes transferred. In a typical message communications we have observed an average packet size increase of 1.2% versus Outlook Anywhere for a 50 KB average packet. In scenarios of data transfers over 10 MB the increase in bytes over the wire is 5-10%. These increases assumes an ideal network where connections are not dropped or resumed. If you consider real world conditions you may actually find MAPI/HTTP data on the wire may be lower than Outlook Anywhere. Outlook Anywhere lacks the ability to resume connections and the cost of re-syncing items can quickly outweigh the increase from the MAPI/HTTP header information.
Now that you have prepared your servers with SP1, updated your clients, and reviewed potential sizing impacts you are ready to get on with implementing MAPI/HTTP. It is disabled by default in SP1 and you must take explicit actions to configure and enable it. These steps are well covered in the MAPI over HTTPTechNet article.
A few important things to remember in your deployment.
NOTE: If you require more specific control you can control the client behavior with a registry key on each client machine. This is not recommended or required but included if your situation demands this level of control. This registry entry prevents Outlook from sending the MAPI/HTTP capable flag to Exchange in the Autodiscover request. When you change the registry key on a client it will not take effect until the next time the client performs an Autodiscover query against Exchange.To disallow MAPI/HTTP and force RPC/HTTP to be used.HKEY_CURRENT_USER\Software\Microsoft\Exchange]“MapiHttpDisabled”=dword:00000001To allow MAPI/HTTP simply delete the MapiHttpDisabled DWORD, or set it to a value of 0 as below.HKEY_CURRENT_USER\Software\Microsoft\Exchange]“MapiHttpDisabled”=dword:00000000
There are a few quick ways to verify your configuration is working as expected.
1. Test with the Test-OutlookConnectivity cmdlet
Use this command to test MAPI/HTTP connectivity:
Test-OutlookConnectivity -RunFromServerId Contoso -ProbeIdentity OutlookMapiHttpSelfTestProbe
This test is detailed in the MAPI over HTTPTechNet Article.
2. Inspect MAPI/HTTP server logs
Administrators can review the following MAPI/HTTP log files to validate how the configuration is operating:
Location
Path
CAS:
%ExchangeInstallPath%Logging\HttpProxy\Mapi\HTTP
Mailbox:
%ExchangeInstallPath%Logging\MAPI Client Access\
%ExchangeInstallPath%Logging\MAPI Address Book Service\
3. Check Outlook connection status on clients
You can also quickly verify that the client is connected using MAPI/HTTP. The Outlook Connection status dialog can be launch by CTRL-right clicking the Outlook icon in the notification area and selecting Connection Status. Here are the few key fields to quickly confirm the connection is using MAPI/HTTP.
Field
Value
Protocol
HTTP (v/s RPC/HTTP for Outlook Anywhere)
Proxy Server
Empty
Server name
Actual server name (v/s GUID for Outlook Anywhere connections)
MAPI/HTTP provides a simplified transport and resulting architecture for Outlook to connect with Exchange. It enables improved user experiences to allow them faster access to mail and improves the resilience of their Outlook connections. These investments are the foundation for future capabilities such as multi-factor authentication in Outlook. It also helps IT support and troubleshoot client connection issues using standard HTTP protocol tools.
As with all things new you must properly plan your implementation. Use the deployment guidanceavailable on TechNet and the updated sizing recommendations in the calculator before you start your deployment. With proper use it will guide you to a smooth deployment of MAPI/HTTP.
Special thanks to Brian Day and Abdel Bahgat for extensive contributions to this blog post.
Brian Shiers | Technical Product Manager
We collected a number of questions which frequently came up during the development, internal dogfooding, and customer TAPtesting of MAPI/HTTP. We hope these answer most of the questions you may have about MAPI/HTTP.
No, it is an organization-wide Exchange setting. The user experience mentioned during database failovers when one server is not yet MAPI/HTTP capable made the functionality to turn MAPI/HTTP on and off per server not a viable solution.
No, there is not currently a Set-CasMailbox parameter to enable/disable MAPI/HTTP for a single mailbox.
The registry entry simply controls what Outlook sends to Exchange about its MAPI/HTTP capability during an Autodiscover request. It does not immediately change the connection method Outlook is using nor will it change it with a simple restart of Outlook. Remember, the Autodiscover response Outlook gets only has MAPI/HTTP or RPC/HTTP settings in it so it has no way to immediately switch types. You must allow Outlook to perform its next Autodiscover request and get a response from Exchange after setting this registry entry before the change will take place. If you must attempt to speed along this process, there are two options.
E.g. When not all mailbox servers in a DAG are MAPI/HTTP capable and MAPI/HTTP has already been enabled in the organization, and then a mailbox failover takes place between the SP1 (or later) and pre-SP1 servers. Additionally this could happen if you move a mailbox from a MAPI/HTTP capable mailbox server to a server that is not MAPI/HTTP capable.
In the above example Outlook would fail to connect and when Autodiscover next ran the user would get an Outlook restart notification warning because MAPI/HTTP is no longer a viable connection method due to the mailbox being mounted on a pre-SP1 server. After the client restart the client profile would be back to utilizing RPC/HTTP.
Note: While a mix of MAPI/HTTP capable and non-capable mailbox Exchange servers in the same DAG are supported in an environment with MAPI/HTTP enabled, it is very strongly not recommended due to the possible user experience outlined above. It is suggested the entire organization be upgraded to SP1 or later before enabling MAPI/HTTP in the organization.
Outlook profiles can continue access additional resources using non-MAPI/HTTP connectivity methods even if the user’s primary mailbox utilizes MAPI/HTTP. For example a user can continue to access Legacy Public Folders or Shared Mailboxes on other Exchange servers not utilizing MAPI/HTTP. During the Autodiscover process Exchange will determine and hand back to Outlook the proper connectivity method necessary for each resource being accessed.
No, a user’s profile will never attempt to use RPC/HTTP if MAPI/HTTP becomes unavailable because the original Autodiscover response only contained one connection method to use. There is no fallback from MAPI/HTTP to RPC/HTTP or vice versa. Normal high availability design considerations should ensure the MAPI/HTTP endpoint remain accessible in the event of server or service failures.
No, MAPI/HTTP is not a replacement for EWS and there are no plans to move current EWS clients to MAPI/HTTP.
Over time this may take place as non-MAPI/HTTP capable Outlook versions age out of their product support lifecycle, but there are no immediate plans to remove RPC/HTTP as a valid connection method.
A huge architectural improvement by moving to MAPI/HTTP is that MAPI/HTTP is abstracted from authentication. In short authentication is done at the HTTP layer, so whatever HTTP can do, MAPI/HTTP can use.
No, the Lync client uses the same profile as configured by Outlook and will connect via whatever connectivity method is in use by Outlook.
The MAPI/HTTP protocol is publically documented (PDF download) and has the same level of documentation support as RPC/HTTP. There are no plans to update the MAPI CDO library for MAPI/HTTP and third party companies are still encouraged to utilize Exchange Web Services as the long-term protocol for interaction with Exchange as discussed in Exchange 2013 Client Access Server Rolearticle.
Use of MAPI/HTTP requires Outlook 2013 clients to obtain Office 2013 Service Pack 1 or the February update for Office 365 ProPlus clients. MAPI/HTTP is planned to be ported to Outlook 2010 at a future date. At this time no other version of Windows Outlook supports MAPI/HTTP.
Publishing Exchange 2013 with MAPI/HTTP in use does not change very much. You will need to ensure devices in front of Exchange handling user access to CAS are allowing access to the Default Web Site’s /mapi/ virtual directory.
At this time UAG SP3 is not compatible with MAPI/HTTP even with all filtering options disabled. UAG plans to add support for MAPI/HTTP in a future update.
Still want more information? Review the following sessions on this topic from Microsoft Exchange Conference 2014
Outlook Connectivity: Current and FutureOutlook Connectivity: Current and FutureOutlook Connectivity: Current and Future
What's New in Outlook 2013 and Beyond
What's New in Authentication for Outlook 2013
With the huge scale environment I currently work in my team has had some difficulty when it comes to validating customer transport changes, specifically when adding new send connectors or new smart hosts. The same goes for troubleshooting mail flow….you know…whip out good ole’ Telnet, check SMTP status manually and then go on from there. What happens when security bans Telnet? What happens when you have 40 transport servers that you need to validate against 20 - 30 smart hosts over multiple connectors? Or you have a gazillion address spaces over a gazillion send connectors….you need some way of automating the checks to help you with troubleshooting if you need to, or validate a transport change when you make changes to send connectors.
Well, let me introduce a very simple, yet efficient tool I branded PelNet…..yes, that’s my take on PowerShell Telnetting :-)
So, let’s see what this baby can do.
Before I get into the usages, let’s talk about the parameters the script accepts:
The logic is simple: Depending on what parameters you specify, the script will validate accordingly and give you a nice CSV output that you can use to check the SMTP status codes for each server.
Show the full help with examples
Get-help .\pelnet.ps1 –full
Let’s say you want to test your 50 transport servers against a new smarthost that needs to be added to a send connector soon.
.\PelNet.ps1 -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com
Test all source transport servers in all send connectors with a specific address space against a specific smarthost.
.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com
Test all send connectors with a specific address space against a multiple smarthosts on a custom port.
.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com –port 25070
Test every send connector with a specific address space against all the smarthosts in those send connectors.
.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com
Test all source transport servers against all smarthosts in a sendconnector.
.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –sendConnector Outbound_Contoso
Test a specific address space from all source transport servers to all smarthosts in all send connectors (bear in mind execution time here).
.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com
Test a specific address space from selected source transport servers to a smarthost and queue the mail for delivery.
.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com –sourceTransportServers EX15-01,EX15-02,EX15-03 -mailSubmissionTest
Now that we covered the usage examples, let’s chat about the output.
The console output will look similar to the below screenshot. As you can see, this will show you on which transport server the tool is currently invoking the code.
The files that the tool will output is a log file and most importantly a comma separated value (.csv) file that contains the data you can use to get a holistic view of the situation you tested.
The csv file contains the following columns:
SmartHost,SendConnector,SMTPVerb,Status,TransportServer
Using the values in these columns you can determine if the server is accepting traffic or not. Please note that the SendConnector column depends on the parameters you used.
Let’s take a look at an example. Let’s say I want to test connectivity to all smarthosts for the contoso.com address space in my organization (with a mail submission test).
.\PelNet.ps1 –From Michael.Hall@uclabz.com -Rcpt user@targetdomain.com –addressSpace Contoso.com -mailsubmissiontest
Within the BLUEbox you’ll notice the status responses and return string back from the server.
Within the REDbox, if a remote smarthost is not accepting traffic on the port you’re trying to connect to or not reachable, you‘ll get a status and ReturnString value of CONN_ERROR.
Finally in the GREEN box, the mailSubmissionTest switch was used so the tool tried to submit the test message for delivery. No response would be sent from the smarthost during the subject and content portion, thus the columns showing NULL.
It’s easy to filter on any of these columns and determine if you have a connectivity issue. You can also create a pivot table to get an overview of the results.
As you can see, this tool can be very powerful when you need to quickly test mail flow or validate a bunch of servers against a smart host or multiple smart hosts.
I hope this tool will help you, as always I’m open to any feedback or improvements.
Happy PelNetting….
Michael Hall Service Engineer Office 365
A few weeks ago we wrapped up MEC 2014 in Austin, TX with the farewell Austin post. Today we are happy to announce that the MEC 2014 keynote and breakout sessions are published on Channel 9. This includes the latest content on Exchange foundational topics and the latest features including groups, and many more. The conference provides content for both Exchange on-premises and Office 365 customers. If you missed the event in person, begin by watching the MEC 2014 keynote to get you up to speed on the latest initiatives the Exchange engineering team is working on plus a segment with Perry Clarke.
MEC isn’t just an event but also a community. Keep active in Twitter using the #IamMEC community hashtag and join us in the Office 365 IT Pro Network to engage in Exchange conversations in the Exchange IT Pro group. Enjoy the MEC 2014 sessions.
Brian ShiersTechnical Product Manager | Exchange
During my session at the recent Microsoft Exchange Conference (MEC), I revealed Microsoft’s preferred architecture (PA) for Exchange Server 2013. The PA is the Exchange Engineering Team’s prescriptive approach to what we believe is the optimum deployment architecture for Exchange 2013, and one that is very similar to what we deploy in Office 365.
The PA is designed with several business requirements in mind. For example, requirements that the architecture be able to:
The specific prescriptive nature of the PA means of course that not every customer will be able to deploy it (for example, customers without multiple datacenters). And some of our customers have different business requirements or other needs, which necessitate an architecture different from that shown here. If you fall into those categories, and you want to deploy Exchange on-premises, there are still advantages to adhering as closely as possible to the PA where possible, and deviate only where your requirements widely differ. Alternatively, you can consider Office 365 where you can take advantage of the PA without having to deploy or manage servers.
Before I delve into the PA, I think it is important that you understand a concept that is the cornerstone for this architecture – simplicity.
Failure happens. There is no technology that can change this. Disks, servers, racks, network appliances, cables, power substations, generators, operating systems, applications (like Exchange), drivers, and other services – there is simply no part of an IT services offering that is not subject to failure.
One way to mitigate failure is to build in redundancy. Where one entity is likely to fail, two or more entities are used. This pattern can be observed in Web server arrays, disk arrays, and the like. But redundancy by itself can be prohibitively expensive (simple multiplication of cost). For example, the cost and complexity of the SAN based storage system that was at the heart of Exchange until the 2007 release, drove the Exchange Team to step up its investment in the storage stack and to evolve the Exchange application to integrate the important elements of storage directly into its architecture. We recognized that every SAN system would ultimately fail, and that implementing a highly redundant system using SAN technology would be cost-prohibitive. In response, Exchange has evolved from requiring expensive, scaled-up, high-performance SAN storage and related peripherals, to now being able to run on cheap, scaled-out servers with commodity, low-performance SAS/SATA drives in a JBOD configuration with commodity disk controllers. This architecture enables Exchange to be resilient to any storage related failure, while enabling you to deploy large mailboxes at a reasonable cost.
By building the replication architecture into Exchange and optimizing Exchange for commodity storage, the failure mode is predictable from a storage perspective. This approach does not stop at the storage layer; redundant NICs, power supplies, etc., can also be removed from the server hardware. Whether it is a disk, controller, or motherboard that fails, the end result should be the same, another database copy is activated and takes over.
The more complex the hardware or software architecture, the more unpredictable failure events can be. Managing failure at any scale is all about making recovery predictable, which drives the necessity to having predictable failure modes. Examples of complex redundancy are active/passive network appliance pairs, aggregation points on the network with complex routing configurations, network teaming, RAID, multiple fiber pathways, etc. Removing complex redundancy seems unintuitive on its face – how can removing redundancy increase availability? Moving away from complex redundancy models to a software-based redundancy model, creates a predictable failure mode.
The PA removes complexity and redundancy where necessary to drive the architecture to a predictable recovery model: when a failure occurs, another copy of the affected database is activated.
The PA is divided into four areas of focus:
In the Namespace Planning and Load Balancing Principles articles, I outlined the various configuration choices that are available with Exchange 2013. From a namespace perspective, the choices are to either deploy a bound namespace (having a preference for the users to operate out of a specific datacenter) or an unbound namespace (having the users connect to any datacenter without preference).
The recommended approach is to utilize the unbound model, deploying a single namespace per client protocol for the site resilient datacenter pair (where each datacenter is assumed to represent its own Active Directory site - see more details on that below). For example:
Figure 1: Namespace Design
Each namespace is load balanced across both datacenters in a configuration that does not leverage session affinity, resulting in fifty percent of traffic being proxied between datacenters. Traffic is equally distributed across the datacenters in the site resilient pair, via DNS round-robin, geo-DNS, or other similar solution you may have at your disposal. Though from our perspective, the simpler solution is the least complex and easier to manage, so our recommendation is to leverage DNS round-robin.
In the event that you have multiple site resilient datacenter pairs in your environment, you will need to decide if you want to have a single worldwide namespace, or if you want to control the traffic to each specific datacenter pair by using regional namespaces. Ultimately your decision depends on your network topology and the associated cost with using an unbound model; for example, if you have datacenters located in North America and Europe, the network link between these regions might not only be costly, but it might also have high latency, which can introduce user pain and operational issues. In that case, it makes sense to deploy a bound model with a separate namespace for each region.
To achieve a highly available and site resilient architecture, you must have two or more datacenters that are well-connected (ideally, you want a low round-trip network latency, otherwise replication and the client experience are adversely affected). In addition, the datacenters should be connected via redundant network paths supplied by different operating carriers.
While we support stretching an Active Directory site across multiple datacenters, for the PA we recommend having each datacenter be its own Active Directory site. There are two reasons:
In the PA, all servers are physical, multi-role servers. Physical hardware is deployed rather than virtualized hardware for two reasons:
By deploying multi-role servers, the architecture is simplified as all servers have the same hardware, installation process, and configuration options. Consistency across servers also simplifies administration. Multi-role servers provide more efficient use of server resources by distributing the Client Access and Mailbox resources across a larger pool of servers. Client Access and Database Availability Group (DAG) resiliency is also increased, as there are more servers available for the load-balanced pool and for the DAG.
Commodity server platforms (e.g., 2U servers that hold 12 large form-factor drive bays within the server chassis) are use in the PA. Additional drive bays can be deployed per-server depending on the number of mailboxes, mailbox size, and the server’s scalability.
Each server houses a single RAID1 disk pair for the operating system, Exchange binaries, protocol/client logs, and transport database. The rest of the storage is configured as JBOD, using large capacity 7.2K RPM serially attached SCSI (SAS) disks (while SATA disks are also available, the SAS equivalent provides better IO and a lower annualized failure rate). Bitlocker is used to encrypt each disk, thereby providing data encryption at rest and mitigating concerns around data theft via disk replacement.
To ensure that the capacity and IO of each disk is used as efficiently as possible, four database copies are deployed per-disk. The normal run-time copy layout (calculated in the Exchange 2013 Server Role Requirements Calculator) ensures that there is no more than a single copy activated per-disk.
Figure 2: Server Design
At least one disk in the disk pool is reserved as a hot spare. AutoReseed is enabled and quickly restores database redundancy after a disk failure by activating the hot spare and initiating database copy reseeds.
Within each site resilient datacenter pair you will have one or more DAGs.
As with the namespace model, each DAG within the site resilient datacenter pair operates in an unbound model with active copies distributed equally across all servers in the DAG. This model provides two benefits:
Each datacenter is symmetrical, with an equal number of member servers within a DAG residing in each datacenter. This means that each DAG contains an even number of servers and uses a witness server for quorum arbitration.
The DAG is the fundamental building block in Exchange 2013. With respect to DAG size, a larger DAG provides more redundancy and resources. Within the PA, the goal is to deploy larger DAGs (typically starting out with an eight member DAG and increasing the number of servers as required to meet your requirements) and only create new DAGs when scalability introduces concerns over the existing database copy layout.
Since the introduction of continuous replication in Exchange 2007, Exchange has recommended multiple replication networks for separating client traffic from replication traffic. Deploying two networks allows you to isolate certain traffic along different network pathways and ensure that during certain events (e.g., reseed events) the network interface is not saturated (which is an issue with 100Mb, and to a certain extent, 1Gb interfaces). However, for most customers, having two networks operating in this manner was only a logical separation, as the same copper fabric was used by both networks in the underlying network architecture.
With 10Gb networks becoming the standard, the PA moves away from the previous guidance of separating client traffic from replication traffic. A single network interface is all that is needed because ultimately our goal is to achieve a standard recovery model despite the failure - whether a server failure occurs or a network failure occurs, the result is the same, a database copy is activated on another server within the DAG. This architectural change simplifies the network stack, and obviates the need to eliminate heartbeat cross-talk.
Ultimately, the placement of the witness server determines whether the architecture can provide automatic datacenter failover capabilities or whether it will require a manual activation to enable service in the event of a site failure.
If your organization has a third location with a network infrastructure that is isolated from network failures that affect the site resilient datacenter pair in which the DAG is deployed, then the recommendation is to deploy the DAG’s witness server in that third location. This configuration gives the DAG the ability to automatically failover databases to the other datacenter in response to a datacenter-level failure event, regardless of which datacenter has the outage.
Figure 3: DAG (Three Datacenter) Design
If your organization does not have a third location, then place the witness server in one of the datacenters within the site resilient datacenter pair. If you have multiple DAGs within the site resilient datacenter pair, then place the witness server for all DAGs in the same datacenter (typically the datacenter where the majority of the users are physically located). Also, make sure the Primary Active Manager (PAM) for each DAG is also located in the same datacenter.
Data resiliency is achieved by deploying multiple database copies. In the PA, database copies are distributed across the site resilient datacenter pair, thereby ensuring that mailbox data is protected from software, hardware and even datacenter failures.
Each database has four copies, with two copies in each datacenter, which means at a minimum, the PA requires four servers. Out of these four copies, three of them are configured as highly available. The fourth copy (the copy with the highest Activation Preference) is configured as a lagged database copy. Due to the server design, each copy of a database is isolated from its other copies, thereby reducing failure domains and increasing the overall availability of the solution as discussed in DAG: Beyond the “A”.
The purpose of the lagged database copy is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption. It is not intended for individual mailbox recovery or mailbox item recovery.
The lagged database copy is configured with a seven day ReplayLagTime. In addition, the Replay Lag Manager is also enabled to provide dynamic log file play down for lagged copies. This feature ensures that the lagged database copy can be automatically played down and made highly available in the following scenarios:
By using the lagged database copy in this manner, it is important to understand that the lagged database copy is not a guaranteed point-in-time backup. The lagged database copy will have an availability threshold, typically around 90%, due to periods where the disk containing a lagged copy is lost due to disk failure, the lagged copy becoming an HA copy (due to automatic play down), as well as, the periods where the lagged database copy is re-building the replay queue.
To protect against accidental (or malicious) item deletion, Single Item Recovery or In-Place Hold technologies are used, and the Deleted Item Retention window is set to a value that meets or exceeds any defined item-level recovery SLA.
With all of these technologies in play, traditional backups are unnecessary; as a result, the PA leverages Exchange Native Data Protection.
The PA takes advantage of the changes made in Exchange 2013 to simplify your Exchange deployment, without decreasing the availability or the resiliency of the deployment. And in some scenarios, when compared to previous generations, the PA increases availability and resiliency of your deployment.
We’re happy to announce updates to the Exchange Server Deployment Assistant! These updates offer you more deployment options and outline new features that make deployments more flexible and easier to configure.
We’ve updated the Deployment Assistant to include the following:
New in Exchange 2013 SP1, Edge Transport servers minimize the attack surface by handling all Internet-facing mail flow, which provides SMTP relay and smart host services for your Exchange organization, including connection filtering, attachment filtering and address rewriting. For more information, see Edge Transport Servers.
Also newly released, you can now use the new product key wizard to submit your request to Microsoft Support to obtain an Exchange 2013 or Exchange 2010 product key for use in hybrid deployments. The request process is quick and easy and you’ll have your product key in minutes!
You can request a Hybrid Edition product key if all the following conditions apply to you:
And, there’s even more on the way!
We’re working hard on testing and adding new deployment scenarios to support configuring hybrid deployments with an Office 365 tenant and multi-forest on-premises Exchange organizations. We’ll start by supporting scenarios for multi-forest Exchange 2010 organizations that add Exchange 2013 SP1 servers for hybrid support, and then follow with scenarios supporting for native multi-forest Exchange 2013 and Exchange 2007 organizations. Keep checking back here for release announcements.
In case you're not familiar with it, the Exchange Server Deployment Assistant is a free web-based tool that helps you deploy Exchange 2013 or Exchange 2010 in your on-premises organization, configure a hybrid deployment between your on-premises organization and Office 365, or migrate completely to Office 365.
The tool asks you a small set of simple questions and then, based on your answers, creates a customized checklist with instructions to deploy or configure Exchange Server. Instead of trying to find what you need in the Exchange library, the Deployment Assistant gives you exactly the right information you need to complete your task. Supported on most major browsers, the Deployment Assistant is your one-stop shop for deploying Exchange.
Do you have a deployment success story about the Deployment Assistant? Do you have suggestions on how to improve the tool? We would love your feedback and comments! 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
Do your users want to share their calendar with anonymous users? Here's a tip related to sharing your calendar via a web link for anonymous users (users outside of your organization). Users can publish their calendar for anonymous viewers using OWA. Organization administrators can also publish a user's calendar. Here we will share both of those ways.
Note: Publishing your calendar for anonymous users allows anyone with the link to the calendar to view it without having to log-on.
Publishing your calendar: Log on to OWA and go to Calendar. Right click the calendar you want to share and choose permissions:
Change the permissions drop-down from “Not Shared” (Default) to “Availability only” (or whichever permission you intend to grant) and press Save:
Retrieve the link to share it with users outside of your organization: Right click Calendarpermissions > and then View Calendar. This will bring up a browser window with the sharing link (URL). You can also right click on the View Calendar link and then select Copy Shortcut to get copy the link. You can send the link to users outside your organization to allow them to view your calendar
Administrators must configure a sharing policy to allow users to share their calendar with all domains. For details, see the following articles:
If you're an organization admin, here's how you can publish the calendar of a user or a resource/room using PowerShell.
Example:
PS C:\Windows\system32> set-MailboxCalendarFolder calroom1:\calendar -PublishEnabled:$true PS C:\Windows\system32> Get-MailboxCalendarFolder calroom1:\calendar RunspaceId : 0f40e5da-5712-4043-8bbc-fb11049c0307Identity : calroom1:\calendarPublishEnabled : TruePublishDateRangeFrom : ThreeMonthsPublishDateRangeTo : ThreeMonthsDetailLevel : AvailabilityOnlySearchableUrlEnabled : FalsePublishedCalendarUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.htmlPublishedICalUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.icsIsValid : TrueObjectState : Unchanged
For more on other calendar sharing options in Exchange Online, please look at thispage.
Sathish Venkat Rangam
With the release of Exchange 2013 SP1, it’s time to revise our sizing guidance given feedback from customers, observations from our own large-scale deployments, and requirements associated with new and changed components in SP1. In addition to this brief article, I’ve also updated the original blog post with updated formulas and tables to reflect the changes described here.
There are two specific changes that need to be highlighted:
With the introduction of the MAPI/HTTP protocol, our existing sizing guidance for CAS processor utilization needs to be changed. Usage of MAPI/HTTP has a fairly dramatic increase in rate of requests handled by the CAS role, when compared to requests generated by clients using RPC/HTTP. As each connection has a measurable amount of processing overhead, this results in an overall increase to our CPU requirements on CAS, moving from a 1:4 ratio of CAS to Mailbox processor cores, to a 3:8 ratio (a 50% increase). It’s important to call out that MAPI/HTTP is disabled by default, as we expect that customers will want to carefully evaluate the deployment requirements and impact of MAPI/HTTP before enabling it. Because it is disabled by default, existing Exchange 2013 deployments do not need to immediately add more CPU resources at the CAS layer. Instead, we expect that additional capacity will be considered as part of the evaluation and deployment process for MAPI/HTTP. We do anticipate that over time it will become the standard method of connectivity for Outlook clients so it’s important to include these requirements in our sizing guidance as early as possible.
It’s also critical to deploy .NET Framework 4.5.1 if you intend to use MAPI/HTTP, as it contains an important fix that impacts the performance and scalability of MAPI/HTTP at the CAS layer.
Ross has updated the Exchange Server 2013 Server Role Requirements Calculator to take into account this guidance change in version 6.3.
As memory requirements have increased for Exchange, our historical guidance for sizing the pagefile has become more and more challenging from a deployment perspective. Previously, our guidance was to set a fixed pagefile size equal to the size of RAM + 10MB. On servers that are commonly deployed with 128GB of RAM or more, requiring a pagefile sized to RAM+10MB results in a large amount of space consumed (typically on the system drive) with questionable benefit. In our large-scale internal deployments, we have been running with a cap on pagefile size for quite some time, and as a result we are comfortable recommending that all of our on-premises customers follow that same guidance. Moving forward with Exchange 2013, we recommend a fixed pagefile of the smaller of RAM size + 10MB or 32,778 MB (which is 32GB + 10MB). Hopefully this will free up some needed space on your servers.
As we continue to learn more from customer feedback and monitoring of our own deployments, we will keep updating this guidance via posts to the blog.
Jeff Mealiffe Principal Program Manager Lead Exchange Customer Experience
The bands are silent, the booths are dismantled, the R/C racecars are quiet, and Squeaky Lobster has left the building. Microsoft Exchange Conference 2014 is officially done. As we head home stuffed with Exchange knowledge and barbeque brisket, we thought we’d give you a brief photo sampling of the fun, selected from the full gallery at iammec.com.
The Exchange museum included a must-see documentary about the past, present, and future of Exchange, along with plenty of original artifacts and exhibits:
(click for larger version)
We took over historic Rainey Street, an eclectic collection of homes converted to bars in downtown Austin, for an old-fashioned block party.
And, of course, we made new friends and had intense discussions about Exchange in between sessions, at MAPI hour, and all week long.
For those who couldn’t make it to Austin, you can search #iammec on Twitter to see what you missed, and follow the #iammec community conversation all year round. Session recordings and decks will be posted for everyone in about a month, and the Office Garage series from the MEC show floor will be out soon.
Jon Orton
This week at MEC, we’ve been talking a lot about the power of the Office graph, and how it helps us deliver personalized and proactive experiences for email users. As part of that journey, we’re excited to announce an advanced predictive email assistance feature coming to Exchange. This exciting technology leverages big-data and machine-learning capabilities to enable users to create routine emails and responses more efficiently.
Research has shown that most business emails in an organization follow identifiable patterns. In a law office, for example, an attorney may write dozens of routine follow-up emails to similar questions from his clients. Convention requires that every email be created from scratch. Now, Exchange will begin to recognize the type of email he is creating and offer assistance completing it.
The new virtual intelligence engine examines a user’s individual emailing patterns, and uses machine learning to detect when a received message resembles a set of emails that have been previously sent.
To unlock the power of this technology for users, we’ve also created a friendly in-product persona that will appear and offer a pre-written email based on the accumulated learnings from previous emails and information based on ranked keywords from the email chain.
Developed under the code name “Green”, email network virtual intelligence (ENVI) is a key part of our vision for a smarter, more tailored inbox experience.
Let’s take a closer look at how ENVI works. Back in our attorney’s office, the attorney begins to respond to a client’s question about a specific rule in that state’s building wastewater disposal statutes. ENVI leverages the Office Graph and the Microsoft Clustering algorithm to recognize that the email the attorney is starting meets the parameters of similar emails he has sent in the past. The friendly envelope character appears onscreen and offers a completed email borrowing from prose the attorney has written repeatedly in similar responses. Our attorney quickly and easily accepts ENVI’s draft and hits send, saving him valuable minutes of his day.
Preliminary testing of this feature in our Early Adopter Program has been phenomenally successful. With more than 2000 participants involved, ENVI reports showed an average email auto-generation success rate of 86.357%. This translates to nearly 17 minutes per day (or 6205 minutes per year) for each user.
We will begin rolling out the ENVI update to on-premises Exchange customers this afternoon. Office 365 customers will be able to download the update later this year for $.99 (Canadian version of dollars) per email per user per month. Initially ENVI will only be available in English and Australian with all other languages and Wingdings* being available early next year.
*Wingdings 3 not supported in Texas or space. Happy April 1st
Greetings from downtown Austin, where Microsoft Exchange Conference (MEC) 2014 is now underway. Since attendees started rolling into town on Saturday, local bars and restaurants have been full of the sounds of Exchange: conversations about load balancing, debates about EAC vs. PowerShell, and tales of MEC legends and lore.
This year’s MEC follows our tried and true recipe: find a great host city, bring tons of people from the product team, and add customers, partners, and MVPs. Mix them all together, add beverage and music, and all involved can savor the strange concoction that results.
This morning Julia White hosted our keynote session, which featured top engineering leaders discussing the future of Exchange. Jeff Teper explained how we are transforming Office and Exchangeby leveraging the power of the cloud, enterprise social, mobile and big data. Kristian Andaker talked about how we are extending compliance and security capabilities across the Office suite. Harv Bhela showed off the ways that email is becoming more social, intelligent, and mobile-focused. Perry Clarke wrapped things up by answering questions about our new software release process and giving us his predictions for the future.
During the keynote we announced and demonstrated several new features including codename "Clutter," new methods of document collaboration, and OWA for Android phone. You can read all about the features we unveiled in this blog post about the evolution of email.
If you couldn’t make it to MEC in person this time, you haven’t completely missed out. We’ll post recordings of the keynote and breakout sessions for public viewing in about a month. In the meantime, you can follow the action on Twitter at #iammec, and enjoy these short video clips from today’s keynote:
Innovation Lab - Greg Taylor and David Espinoza show us the research facility where the Exchange team cooks up new features:
Ex Ed - As social concepts come to email, some users may have questions. This educational film is designed to help them understand their changing world:
Secret Switch - When an Exchange admin moves his company’s email servers to Office 365, will end users notice?
When you're migrating on-premises mailboxes to Office365, there are a lot of factors that can impact overall mailbox migration speed and performance. This post will help you investigate and correct the possible causes by using the AnalyzeMoveRequestStats.ps1 script to analyze the performance of a batch of move requests to identify reasons for slower performance.
The AnalyzeMoveRequestStatsscript provides important performance statistics from a given set of move request statistics. It also generates two files - one for the failure list, and one for individual move statistics.
Step 1: Download the script and import using the following syntax
> . .\AnalyzeMoveRequestStats.ps1
Step 2: Select the move requests that you want to analyze
In this example, we’re retrieving all currently executing requests that are not in a queued state.
> $moves = Get-MoveRequest | ?{$_.Status -ne 'queued'}
Step 3: Get the move reports for each of the move requests you want to analyze
Note: This make take a few minutes, especially if you’re analyzing a large number of moves
> $stats = $moves | Get-MoveRequestStatistics –IncludeReport
Step 4: Run the ProcessStats function to generate the statistics
> ProcessStats -stats $stats -name ProcessedStats1
The output should look similar to the following:
StartTime: 2/18/2014 19:57EndTime: 3/3/2014 17:15MigrationDuration: 12 day(s) 19:10:55MailboxCount: 50TotalGBTransferred: 2.42PercentComplete: 95MaxPerMoveTransferRateGBPerHour: 1.11MinPerMoveTransferRateGBPerHour: 0.43AvgPerMoveTransferRateGBPerHour: 0.66MoveEfficiencyPercent: 86.36AverageSourceLatency: 123.55AverageDestinationLatency: IdleDuration: 1.16%SourceSideDuration: 78.93%DestinationSideDuration: 19.30%WordBreakingDuration: 9.63%TransientFailureDurations: 0.00%OverallStallDurations: 4.55%ContentIndexingStalls: 1.23%HighAvailabilityStalls: 0.00%TargetCPUStalls: 3.32%SourceCPUStalls: 0.00%MailboxLockedStall: 0.00%ProxyUnknownStall: 0.00%
The first step in understanding the results are to understand the definitions of the report items:
Report Item
Definition
StartTime
Timestamp of the first injected request
EndTime
Timestamp of the last completed request. If there isn’t a completed/autosuspended move, this is set to the current time.
MigrationDuration
EndTime – StartTime
MailboxCount
# of mailboxes
TotalGBTransferred
Total amount of data transferred
PercentComplete
Completion percentage
MaxPerMoveTransferRateGBPerHour
Maximum per-mailbox transfer rate
MinPerMoveTransferRateGBPerHour
Minimum per-mailbox transfer rate
AvgPerMoveTransferRateGBPerHour
Average per-mailbox transfer rate. For onboarding to Office 365, any value greater than 0.5 GB/h represents a healthy move rate. The normal range is 0.2 - 1 GB/h.
MoveEfficiencyPercent
Transfer size is always greater than the source mailbox size due to transient failures and other factors. This percentage shows how close these numbers are and is calculated as SourceMailboxSize/TotalBytesTransferred. A healthy range is 75-100%.
AverageSourceLatency
This is the duration calculated by making no-op WCF web service calls to the source MRSProxy service. It's not the same as network ping and 100ms is desirable for better throughput.
AverageDestinationLatency
Similar to AverageSourceLatency, but applies to off-boarding from Office 365. This value isn’t applicable in this example scenario.
IdleDuration
Amount of time that the MRSProxy service request waits in the MRSProxy service's in-memory queue due to limited resource availability.
SourceSideDuration
Amount of time spent in the source side which is the on-premises MRSProxy service for onboarding and Office 365 MRSProxy service for off-boarding. The typical range for this value is 60-80% for onboarding. A higher average latency and transient failure rate will increase this rate. A healthy range is 60-80%.
DestinationSideDuration
Amount of time spent in the destination side which is Office 365 MRSProxy service for onboarding and on-premises MRSProxy service for off-boarding. The typical range for this value is 20-40% for onboarding. Target stalls such as CPU, ContentIndexing, and HighAvailability will increase this rate. A healthy range is 20-40%.
WordBreakingDuration
Amount of time spent in separating words for content indexing. A healthy range is 0-15%.
TransientFailureDurations
Amount of time spent in transient failures, such as intermittent connectivity issues between MRS and the MRSProxy services. A healthy range is 0-5%.
OverallStallDurations
Amount of time spent while waiting for the system resources to be available such as CPU, CA (ContentIndexing), HA (HighAvailability). A healthy range is 0-15%.
ContentIndexingStalls
Amount of time spent while waiting for Content Indexing to catch up.
HighAvailabilityStalls
Amount of time spent while waiting for High Availability (replication of the data to passive databases) to catch up.
TargetCPUStalls
Amount of time spent while waiting for availability of the CPU resource on the destination side.
SourceCPUStalls
Amount of time spent while waiting for availability of the CPU resource on the source side.
MailboxLockedStall
Amount of time spent while waiting for mailboxes to be unlocked. In some cases, such as connectivity issues, the source mailbox can be locked for some time.
ProxyUnknownStall
Amount of time spent while waiting for availability of remote on-prem resources such as CPU. The resource can be identified by looking at the generated failures log file.
Next, you need to identify which side of the migration components is slower by looking at the SourceSideDuration and DestinationSideDurationvalues.
Note: The SourceSideDuration value + DestinationSideDuration value is usually, but not always, equal to 100%.
If you see that the SourceSideDuration value is greater than the normal range of 60-80%, this means the source side is the bottleneck. If the DestinationSideDurationvalue is greater than the normal 20-40%, this means the destination side of the migration is the bottleneck
There are several possible reasons the source side of the migration in an onboarding scenario may be causing slower than normal performance.
Most common reason for transient failures is the connectivity issue to the on-premises MRSProxy web service on your Mailbox servers. Check the TransientFailureDurations and MailboxLockedStallvalues in the output and also check the failure log generated by this script to verify any failures. The source mailbox may also get locked when a transient failure occurs and this will lower migration performance.
Another common reason for connectivity issues are misconfigured load balancers. If you're load balancing your servers, the load balancer needs to be configured so that all calls for a migration specific request is directed to the same server hosting the MRSProxy service instances.
Some load balancers use the ExchangeCookieto associate all the migration requests to the same Mailbox server where the MRSProxy service is hosted.
If your load balancers are not configured correctly, migration calls may be directed to the “wrong” MRSProxy service instance and will fail. This causes the source mailbox to be locked for some time and lowers migration performance.
The Office 365 MRSProxy service makes periodic dummy web service calls to the on-premises MRSProxy service and collects statistics from these calls. The AverageSourceLatencyvalue represents the average duration of these calls. If you see high values for this parameter (greater than 100ms), it can be caused by:
In this case, you can try to reduce the network latency by
Example: ExportBufferSizeOverrideKB="7500"
Important: You need to have Exchange 2013 SP1 installed on your Client Access server to increase the export buffer size. This will also disable cross forest downgrade moves between Exchange 2013 and Exchange 2010 servers.
In this care you can try to release some of the system resources (CPU, Memory, Disk IO etc.) on the Mailbox and Client Access servers.
The resource consumption on the on-premises Mailbox or Client Access servers may be high if you're not load balancing the migration requests or you're running other services on the same servers. You can try distributing the source mailboxes to multiple Mailbox servers and moving mailboxes to different databases located on separate physical hard drives.
There are several possible reasons the destination side of the migration in an onboarding scenario may be causing slower than normal performance. Since the destination side of the migration is Office 365, there are limited options for you to try to resolve bottlenecks. The best solution is to remove the migration requests and re-insert them so that migration requests are assigned to less busy Office 365 servers.
Office 365 system resources: This is likely due to insufficient system resources in Office 365. Office 365 destination servers may be too busy with handling other requests associated with normal support of services for your organization. Stalls due to word breaking: Any mailbox content that is migrated to Office365 is separated into individual words so that it can be indexed later on. This is performed by the Office 365 search service and coordinated by the MRS service. Check the WordBreakingDuration values to see how much time is spent in this process. If it's more than 15%, it usually indicates that the content indexing service running on the Office 365 target server is busy. Stall due to Content Indexing: Content indexing service on the Office 365 servers is too busy. Stall due to High Availability: High availability service that is responsible to copy the data to multiple Office 365 servers is too busy. Stall due to CPU: The Office 365 server's CPU consumption is too high.
Office 365 system resources: This is likely due to insufficient system resources in Office 365. Office 365 destination servers may be too busy with handling other requests associated with normal support of services for your organization.
Stalls due to word breaking: Any mailbox content that is migrated to Office365 is separated into individual words so that it can be indexed later on. This is performed by the Office 365 search service and coordinated by the MRS service. Check the WordBreakingDuration values to see how much time is spent in this process. If it's more than 15%, it usually indicates that the content indexing service running on the Office 365 target server is busy.
Stall due to Content Indexing: Content indexing service on the Office 365 servers is too busy.
Stall due to High Availability: High availability service that is responsible to copy the data to multiple Office 365 servers is too busy.
Stall due to CPU: The Office 365 server's CPU consumption is too high.
Karahan Celikel and the Migration Team
Now that we understand the load balancing and namespace planning principles and how clients connect in an Exchange 2013 environment that has Exchange 2007 and/or Exchange 2010 deployed, the proper certificates can be constructed and deployed as part of the upgrade process.
Of course it goes without saying that there are a few rules you should follow in crafting your certificates:
Wildcard certificates are an option as well. A wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, legacy.contoso.com, and autodiscover.contoso.com namespaces.
To understand what host names should be included in the certificate request, three scenarios will be considered that leverage the architecture principles discussed in the prior articles.
Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web Access, and IMAP clients connecting to an Exchange 2007 platform deployed in both sites.
They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso will continue to offload SSL at the load balancer.
As part of the upgrade to Exchange 2013, Contoso will deploy a site resilient Database Availability Group in an active/active configuration.
As a result of these choices, Contoso will require the following namespaces:
Figure 1: Scenario 1 - Layer 7 Load Balancing with Unbounded Model
Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS, SMTP and IMAP services.
Contoso has offices in Redmond, WA and Bel Air, MD. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web App, connecting to an Exchange 2010 platform deployed in both sites.
Contoso has sufficient bandwidth to replicate databases between datacenters; however, Contoso prefers that the users access their data out of their local datacenter, unless there is a failure event.
As part of the upgrade, Contoso decides to leverage the enhancements in Exchange 2013 by disabling SSL offloading on the load balancers. As a result, Contoso recognizes they will need to deploy client specific namespaces so that they can manage the health correctly on the load balancers.
Figure 2: Scenario 2 - Layer 4 Load Balancing with Bounded Model
Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS service.
Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere and Outlook Web App connecting to an Exchange 2007 platform deployed in both sites.
They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso has decided to not utilize SSL offloading at the load balancer once the namespace is moved to Exchange 2013.
Figure 3: Scenario 3 - Layer 4 Load Balancing with Unbounded Model
Hopefully this article ties together the namespace and load balancing principles with respect to certificate planning. As you can see from the above examples, the choices you make with respect to your load balancing, namespace model, and DAG architecture greatly affect the number of host names required on the certificate.