A user is out of office for some reason – on vacation, sick, on a sabbatical or extended leave of absence, or traveling to a remote location on business, and forgets to set an automatic reply, also known as an Out Of Office message or OOF in Exchange/Outlook lingo. As an Exchange administrator, you get an email from the user’s manager asking you to configure an OOF for the user.

In previous versions of Exchange, you would need to access the user’s mailbox to be able to do this. Out of Office messages are stored in the Non-IPM tree of a user’s mailbox along with other metadata. Without access to the mailbox, you can’t modify data in it. Two ways for an admin to access a mailbox:

1. Grant yourself Full Access mailbox permission to the user’s mailbox.
2. Change the user’s password and log in as user.

It is safe to say that either of these options is potentially dangerous. The first option grants the administrator access to all of the data in the user’s mailbox. The second option grants the administrator access to all of the data that the user account can access within your company and locks the user out of his own user account (as the user in question no longer knows the account password).

In Exchange 2010, you can configure auto-reply options for your users without using either of the above options. You must be a member of a role group that has either the Mail Recipients or User Options management roles.

Configure auto-reply options using the Exchange Control Panel

To configure an auto-reply using the ECP:

1. From Mail > Options, select Another User (default My Organization).
   
   Figure 1: Select Another User

2. Select the user you want to configure the auto-reply for

3. In the new window, ensure the user's name is displayed in the alert message, and then click Tell people you’re on vacation
   
   Figure 2: When managing another user in the ECP, an alert near the top of the page displays the name of the user you're managing

4. From the Automatic Replies tab, configure the auto-reply options for the user (see screenshot).

In Exchange 2007, we introduced the ability to create different Out of Office messages for external and internal recipients. You can also disable or enable Out of Office messages on a per-user basis and on a per-remote domain basis in Remote Domain settings. For details, see previous post Exchange Server 2007 Out of Office (OOF).

Configure auto-reply options using the Shell

This command schedules internal and external auto-replies from 9/8/2011 to 9/15/2011:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Scheduled –StartTime “9/8/2011” –EndTime “9/15/2011” –ExternalMessage “External OOF message here” –InternalMessage “Internal OOF message here”

To configure auto-replies to be sent until they're disabled (i.e. without a schedule), set the AutoReplyState parameter to Enabled and do not specify the StarTime and EndTime parameters. For detailed syntax and parameter descriptions, see Set-MailboxAutoReplyConfiguration.

This command retrieves auto-reply settings for a mailbox.

Get-MailboxAutoReplyConfiguration bsuneja@e14labs.com

This command disables auto-reply configured for a mailbox:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Bharat Suneja

EDIT 10/17/2011: The fix for this issue is now available. Please go here to learn how to get it.

We wanted to write a blog post about an issue that some of you have reported to us, and has been discussed at some length in Exchange Forums also.

After you install Internet Explorer 9 on a computer that has Exchange 2010 or Exchange 2007 management tools installed, you might run into a situation where closing the Exchange Management Console (EMC) results in the following error:

You must close all dialog boxes before you can close Exchange Management Console

This might happen even if there are no property pages left opened that you can see. Please note here that not all of our customers who installed IE9 on a computer with Exchange management tools (server or workstation) have run into this problem.

Are there any workarounds?

As it stands right now, we are not aware of a reliable workaround for this problem. Terminating the EMC using the Task Manager (or possibly a command or script) does not have adverse effects on management tools functionality, but is clearly a non-optimal solution.

What are we doing to address this?

The EMC is implemented as a Microsoft Management Console snap-in. We are working closely with both MMC and Internet Explorer teams to find a solution to this problem. Due to the complex nature of several products involved and the interoperability between them, identifying the root cause was not simple; things are still in process and we do not have a firm solution or a date to share with you yet. We do, however, want to say that we are very aware of this issue and several teams are collaborating and working to get this addressed. Once more details are available, we will be sure to share them here.

Nino Bilic

The Microsoft Exchange team is pleased to present the newest addition to the Exchange Server 2010 Technical Video Series – “Information Protection and Control” hosted by Greg Smiley and Ann Vu. In this video, Greg and Ann talk about the benefits of Security in Exchange 2010. The video includes demonstrations of three common scenarios related to Information Protection and Control: 1) Transport Rules 2) On-Premises Protection, and 3) Cloud Based Protection.

For more information on the Exchange Server 2010 Technical Video Series, check out our previous post. You can also access the rest of the videos in the series directly using the following links:

• Archiving and Discovery
• Mailbox Resiliency
• Management
• Mobility
• Outlook and Exchange
• Outlook Web App
• Unified Messaging

Low bandwidth versions of each of the videos are now provided in the “Related Links” area for those on slower connections.

As always, please help us evangelize these videos to anyone who wants to learn more about Exchange Server 2010, and let us know your thoughts. Your feedback is extremely valuable to us. Many thanks in advance.

Steve Chew
Technical Product Manager

Here's an interesting webcast we have coming up this week... This October Russia will not "fall back" and will essentially remain on summer time. This change has widespread implications to all connected information systems. In this webcast geared toward IT Professionals, we'll walk through a general overview of DST and the impacts and solutions for Windows, Outlook and Exchange.

We're also offering a series of new webcasts to help customers and organizations preparing for daylight saving time, particularly the new changes in Russia this year. This is part of our "step-by-step" program on making the DST transition. You'll find a list of these upcoming webcasts on our DST & TZ site at http://www.microsoft.com/time. We also include a few archived, on-demand webcasts available here: http://support.microsoft.com/gp/dst_webcasts.

Understanding and preparing for 2011 Russian Daylight Savings Time Change (VIR66CAL)

September 15, 2011, 10:00 am to 11:30 am Pacific Daylight Time (Click here to calculate your local time)

Presented By:
M3 Sweatt, Partner Program Manager Lead, Microsoft
Matthew Brown, Senior Program Manager, Microsoft
Mike DeGooyer, Senior Program Manager, Microsoft
Bala Sivakumar, Program Manager, Microsoft
Ron Ragsdale, Program Manager, Microsoft
Jenny Liu, Program Manager, Microsoft

Session Overview: In 2011, the Russian government adopted a law to cancel Daylight Saving Time (DST). As a result, Russia will not "fall back" to Winter time. This webcast will discuss the implications of that decision and what Microsoft is doing to mitigate those implications for our Customers and Partners.

Level: 200

Microsoft Customer Information

Register for the Conference: https://www.eventbuilder.com/event_desc.asp?p_event=u48c3q60

Technical Support: Having trouble with the conference on the day of the session? Click here for Live Meeting support or call: 866-493-2825

Before the Webcast: Please ensure you have downloaded the latest version of Microsoft Office Live Meeting 2007. For an overview of the Microsoft Office Live Meeting 2007 platform and features, please view the Getting Started guide here.

Within Exchange, any Distribution Group(s) or E-mail enabled Security Group(s) which contain Lingering Links will impact the OAB (Offline Address Book) generation process causing it to not replicate correctly. While this issue has been around since AD started with Windows 2000, it is a fairly unknown issue and is related to how the OAB (Offline Address Book) Generation process functions.

A couple options exist to fix this issue. You will either need to delete and recreate the impacted group(s), or re-host the Active Directory partition that contains the group(s) with Lingering Links.

What are Lingering Links?

Some understanding of what a ‘Link’ is in Active Directory might be good here:

Some inter-object references in the Active Directory require back-references for either usability or administrative purposes. For example, if managedBy is an object attribute, you can look at ObjectA and determine that ObjectA is managed by ObjectB. Likewise, it is sometimes helpful to be able to look at ObjectB and determine what objects ObjectB manages (the values of the managedObjects attribute for example). Active Directory maintains referential integrity between objects that reference each other so that when one object is moved in the directory tree, the reference between it and other objects is maintained. This referencing is accomplished through linked attributes.

Two attributes that are linked are marked in the schema as having the same link-pair identifier; one is marked as the forward link and the other as the back link. For example, in the managedBy / managedObjects link pair, managedBy is the forward link. Therefore, to adjust the managedObjects attribute on a user object, you must go to the objects that you want to add or remove from the user's managedObjects value and modify the managedBy value on each object. Back-link attributes are computed when they are requested by a user action.

To find all of the objects that ObjectB manages, links are examined for all records in which the link pair is managedBy / managedObjects and the back-link attribute identifies ObjectB. The link pairs of those records provide the database identifiers of all the records (objects) that are managed by ObjectB.

Distribution list membership is implemented both as a forward-link and as a back-link pair. The back-link objects would be the objects that store the isMemberOfDl attribute. The forward-link member attribute is a multivalued attribute, which allows a user to be a member of more than one distribution list. The back link must always be a multivalued link because it is impossible to restrict who creates links to various objects.

A Lingering Link is a backwards linked attribute that contains the DN (Distinguished Name) of an object that no longer exists in Active Directory. These problems result from Global Catalog servers (and the read only partition residing on GC’s) not receiving sound replication from writable Domain Controllers from the domains which are having an issue. This is why the GC’s typically hold the Lingering Link value that is broken and the writable DC’s are not necessarily experiencing the issue.

Problem symptoms

The OAB Generation process uses a QueryRows function to return attribute values from Active Directory. If there is invalid data returned, there could be error events returned in the application event viewer and OABGen process will not complete.

Error events associated with this issue:

A recently published KB article written by Justin Turner is now available for additional detailed information about how lingering links apply to Exchange:

Exchange Offline Address Book (OAB) generation failures caused by Attributes containing stale or bad data: events 9126 9330 and 9339 with error 8004010e cited
http://support.microsoft.com/kb/2553698

Troubleshooting

Internally, Active Directory engineers periodically cleanup Lingering Objects by using the repadmin command line tool, which is a fairly easy process. The Microsoft ADRAP (AD Risk Assessment Program, a service for our Premier customers) reports if you have any Lingering Objects in your Active Directory environment. While cleaning up Lingering Objects is a pretty well known process, Lingering Links are not easily identified from the AD side.  There is however, an Exchange tool that can identify Lingering Links: oabvalidate.exe http://oabvalidate.codeplex.com/. The author of the tool (Bill Long) actively updates the tool on Codeplex. The OABValidate tool is small (under 800kb) and runs against a specified DC, usually doesn’t take too long to run (depending on the number of objects in your AD environment), and will give you a listing of any groups that contain Linking Links that need to be addressed.

What happens after Exchange is installed and running and you have Lingering Links introduced to your environment? You will get OAB Generating errors which could indicate that you have Lingering Links that need to be addressed.

Mike O’Neill

Definitions

We all know that in the Microsoft Exchange world DAG stands for “Database Availability Group”.

Database – because on a highly available Exchange 2010 Mailbox server, the database, not the server, is the unit of availability and it is the database that can be failed over or switched over between multiple servers within a DAG. This concept is known as database mobility.

Group – because the scope of availability is determined by Mailbox servers in a DAG combined in a failover cluster and working together as a group.

Availability – this word seems to be the least obvious and the most obfuscated term here (and also referred to by both other terms). Ironically, it has a straightforward mathematical definition and plays an important role in understanding overall Exchange design principles.

Wikipedia defines “availability” to mean one of the following:

• The degree to which a system, subsystem, or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition. This is often described as a mission capable rate. Mathematically, this is expressed as 1 minus unavailability.
• The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval.

Using terms of probability theory, both of these definitions mean the same: probability that a given system or component is “operable” or “capable of being used” (i.e. available) at any random moment of time (when we test it).

Mathematically this can be measured by calculating the amount of the time when system is available (“uptime”) during some large statistically representative period (typically a year), and dividing it by the total length of the period. Using the widely adopted terms of Mean Time Between Failures (MTBF) and Mean Time To Repair (MTTR) – the former represents system availability / uptime between the failures, while the latter represents system downtime during any given failure, – availability can be expressed as a fraction:

The opposite mathematical characteristic would be a probability of failure (think “non-availability”):

Availability is often expressed as “number of nines”, according to the following table:

Of course, the availability value would be different depending on whether we take into account both scheduled (planned) and unscheduled (unplanned) downtime or just unscheduled downtime only. The Service Level Agreement that represents business availability requirements must be very specific about it. But in all cases availability of any given system or component depends on many factors, and it is utterly important to identify and understand these dependencies and how they impact availability.

How service dependencies impact availability

The availability of an Exchange mailbox database depends on the availability of many other services and components – for example, the storage subsystem that hosts the database, the server that operates this database, network connectivity to this server, etc. All of these are critical components, and the failure of any single one of them would mean loss of service even if the database itself is perfectly healthy. This means that in order for the database to be available as a service, every single dependency of the database must be available as well. If we properly identify and isolate the dependency components, we can mathematically calculate how they determine the resulting availability of the Exchange mailbox database itself.

For a given Exchange mailbox database, the following components could be considered critical dependencies:

• Database disk / storage subsystem – let’s say its availability is A₁;
• Mailbox server (both hardware and software components) – say its availability is A₂;
• Client Access Server (both hardware and software components) – remember that in Exchange 2010 all clients connect to mailbox database only via Client Access Server, and let’s assume CAS is installed separately from the Mailbox server in this case – say its availability is A₃;
• Network connectivity between clients and the Client Access Server, and between the Client Access Server and the Mailbox server – say its availability is A₄;
• Power in the datacenter where servers and storage are located – say its availability is A₅;

This list could be continued… For example, Active Directory and DNS both represent critical dependency for Exchange as well. Moreover, in addition to pure technological dependencies, availability is impacted by process dependencies such as operational maturity and so on: human error, incorrectly defined operations, lack of team coordination could all lead to service downtime. We will not try to compile any exhaustive list of dependencies here but instead focus on how they impact overall service availability.

Since these components themselves are individually independent of each other, the availability of each of them represents an independent event, and the resulting availability of an Exchange mailbox database represents a combination of all these events (in other words, in order for a mailbox database to be available to clients all of these components must available). From the probability theory, the probability of a combination of independent events is a product of the individual probabilities for each event:

For example, if you toss three coins, the probability of getting heads on all three coins is (1/2)*(1/2)*(1/2) = 1/8.

It is important to realize that since each individual availability value cannot be larger than 1 (or 100%), and the resulting service availability is simply a product of individual component availabilities, the resulting availability value cannot be larger than the lowest of the dependent component availabilities.

This can be illustrated with the example presented in the following table (the numbers here are samples but pretty realistic):

From this example, you can see how critically important service dependencies are. Even for a mailbox database that never fails (never gets corrupted, never gets any virus infection etc.), availability still remains below 93.5%!

Conclusion: A large number of service dependencies decreases availability.

Anything you can do to decrease the number or impact of service dependencies will positively impact overall service availability. For example, you could improve operational maturity by simplifying and securing server management and optimizing operational procedures. On the technical side, you can try to reduce the number of service dependencies by making your design simpler – for example, eliminating complex SAN based storage design including HBA cards, fiber switches, array controllers, and even RAID controllers and replacing it with a simple DAS design with a minimum of moving parts.

Reduction in service dependencies alone might not be sufficient enough to bring the availability to the desired level. Another very efficient way to increase the resulting availability and minimize the impact of critical service dependencies is to leverage various redundancy methods such as using dual power supplies, teamed network cards, connecting servers to multiple network switches, using RAID protection for operating system, deploying load balancers for Client Access servers and multiple copies of mailbox databases. But how exactly does redundancy increase availability? Let’s look more closely at load balancing and multiple database copies as important examples.

How redundancy impacts availability

Conceptually all redundancy methods mean one thing: there is more than one instance of the component that is available and could be used either concurrently with other instances (as in load balancing) or as a substitution (as in multiple database copies). Let’s assume we have n instances of a given component (n servers in a CAS array, or n database copies in a DAG). Even if one of them fails, the other instances can still be used thus maintaining availability. The only situation when we will face actual downtime is when all instances fail.

As defined earlier, the probability of failure for any given instance is P = 1 – A. All instances are statistically independent of each other, which means that availability or failure of any of them does not impact availability of the other instances. For example, the failure of a given database copy does not impact the probability of failure for another copy of that database (a possible caveat here could be logical database corruption propagating from the first damaged database copy to all other copies, but let’s ignore this highly unlikely factor for now – after all, you can always implement a lagged database copy or a traditional point-in-time backup to address this).

Again using the same theorem of probability theory, the probability of failure of a set of n independent components is a product of the probabilities for each component. As all components here are identical (different instances of the same object), product becomes a power:

Apparently, as P < 1, Pⁿ is less than P, which means that probability of failure decreases, and correspondingly, availability increases:

Let’s consider some real life example for clarity. Say, we are deploying multiple mailbox database copies; each copy is hosted on a single SATA drive. Statistically, the failure rate of SATA drives is ~5% over a year[1], which gives us 5% probability of failure: P = 0.05 (which means availability of 95%: A = 0.95). How will availability change as we add more database copies? Look at the following table which should be self-explanatory:

Pretty impressive, isn’t it? Basically, each additional database copy on SATA drive introduces the multiplication factor of 5% or 1/20, so the probability of failure becomes 20 times lower with each copy (and, correspondingly, availability increases). You can see that even with the most unreliable SATA drives deploying just 4 database copies brings database availability to five nines.

This is already very good, but can you make this even better? Can you increase availability even further without making architectural changes (e.g. if adding yet another database copy is out of the question)?

Actually, you can. If you improve the individual availability of any dependency component, it will factor in increasing overall service availability, and lead to a much stronger effect from adding redundant components. For example, one possible way to do this without breaking the bank is to use Nearline SAS drives instead of SATA drives. Nearline SAS drives have an annual failure rate of ~2.75% instead of ~5% for SATA. This will decrease the probability of failure for the storage component in the calculation above and therefore increase overall service availability. Just compare the impact from adding multiple database copies:

• 5% AFR = 1/20 multiplication factor = each new copy makes database failure 20 times less likely.
• 2.75% AFR = 1/36 multiplication factor = each new copy makes database failure 36 times less likely.

This significant impact that additional database copies have on database availability also explains our guidance around using Exchange Native Data Protection which says that multiple database copies could be replacement for traditional backups if a sufficient number (three or more) of database copies is deployed.

The same logic applies to deploying multiple Client Access servers in a CAS array, multiple network switches, etc. Let’s assume we have deployed 4 database copies and 4 Client Access servers, and let’s revisit the component availability table that we analyzed earlier:

You can see how just because we deployed 4 Client Access servers and 4 database copies, the probability of failure of the overall service has decreased more than 10-fold (from 6.5% to 0.6%) and correspondingly service availability increased from 93.5% to a much more decent value of 99.4%!

Conclusion: Adding redundancy to service dependencies increases availability.

Putting the pieces together

An interesting question arises from the previous conclusions. We’ve analyzed two different factors that impact overall service availability in two different ways and have found two clear conclusions:

• adding more system dependencies decreases availability
• adding redundancy to system dependencies increases availability

What happens if both are factors of a given solution? Which tendency is stronger?

Consider the following scenario:

We deploy two mailbox servers in a DAG with two mailbox database copies (one copy on each server), and we deploy two Client Access servers in a load-balanced array. (For simplicity, we’ll only consider the availability of a mailbox database for client connections, leaving Hub Transport and Unified Messaging out of consideration for now). Assuming that every server has its individual probability of failure of P, will the availability of such a system be better or worse than the availability of a single standalone Exchange server with both the Mailbox and Client Access server roles deployed?

In the first scenario, the Mailbox servers are independent and will be unavailable only if both servers fail. The probability of failure for the set of two Mailbox servers will be P × P = P². Correspondingly, its availability will be A_MBX = 1 – P². Following the same logic, CAS services will be unavailable only if both Client Access servers fail, so the probability of failure for the set of two Client Access servers will be again P × P = P², and correspondingly, its availability will be A_CAS = 1 – P².

In this case, as you may have realized, two Mailbox servers or two Client Access servers are examples of redundant system components.

Continuing with this scenario… In order for the entire system to be available, both sets of servers (set of Mailbox servers and set of Client Access servers) must be available simultaneously. Not fail simultaneously but be available simultaneously, because now they represent system dependencies rather than redundant components. This means that overall service availability is a product of availabilities for each set:

Of course, the second scenario is much simpler as there is only one server to consider, and its availability is simply A = 1 – P.

So now that we calculated the availability values for both scenarios, which value is higher, (1-P²)² or 1-P?

If we plot the graphs of both functions, we’ll see the following behavior:

(I used the Wolfram Alpha Mathematica Online free computational engine to do the plotting quickly and easily).

We can see that for the small values of P, the availability of the complex 4-server system is higher than the availability of the single server. There’s no surprise; this is what we expected, right? However, at P ~ 0.618 (more precisely, ) the two plots cross, and for larger values of P the single server system actually has higher availability. Of course you would expect the value of P to be very close to zero in real life; however, if you are planning to build your solution from very unreliable components, you would probably be better with a single server.

Impact of failure domains

Unfortunately, real life deployment scenarios are rarely as simple as the situations discussed above. For example, how does service availability change if you deploy multi-role servers? We noticed in the scenario above that combining the server roles effectively reduces the number of service dependencies, so it would probably be a good thing? What happens if you place two database copies of the same database onto the same SAN array or DAS enclosure? What if all of your mailbox servers are connected to the same network switch? What if you have all of the above and more?

All of these situations deal with the concept of failure domains. In the examples above, server hardware, or a SAN array, or a network switch represent a failure domain. Failure domain breaks independence or redundancy of the components that it combines – for example, failure of server hardware in a multi-role server means that all Exchange roles on this server become unavailable; correspondingly, failure of a disk enclosure or a SAN array means that all database copies hosted on this enclosure or array become unavailable.

Failure domains are not necessarily a bad thing. The important difference is what kind of components constitute a failure domain – are they different system dependencies or are they redundant system components. Let’s consider two of the above examples to understand this difference.

Multi-role server scenario

Let’s compare availability of the two different systems:

1. Both Mailbox and Client Access server roles hosted on the same server which has the probability of hardware failure of P;
2. The same roles hosted on two separate servers, each having the same probability of hardware failure;

In the first case, hardware of a single server represents a failure domain. This means that all hosted roles are either all available or all unavailable. This is simple; overall availability of such a system is A = 1 – P.

In the second case, overall service will be available only when both servers are available independently (because each role represents a critical dependency). Therefore, based on probability theory, its availability will be A × A = A².

Again, as A < 1, it means that A² < A, so in the second case availability will be lower.

Apparently, we can add other Exchange server roles (Hub Transport and Unified Messaging if necessary) to the same scenario without breaking this logic.

Conclusion: Collocation of Exchange server roles on a multi-role server increases overall service availability.

Shared storage scenario

Now let’s consider another failure domain scenario (two database copies sharing the same storage array), and compare database availability in the following two cases:

1. Two database copies hosted on the same shared storage (SAN array or DAS enclosure), which has the probability of failure of P;
2. The same database copies hosted on two separate storage systems, each having the same probability of failure;

In the first case, shared storage represents a failure domain. As in the previous scenario, this means that both database copies are available or unavailable simultaneously, so the overall availability is again A = 1 – P.

In the second case, overall service will be available if at least one system is available, and unavailable only if both systems fail. The storage systems in question are independent; therefore, the probability of failure for the overall service is P × P = P², and correspondingly overall service availability is A = 1 – P².

Again, as P < 1, it means that P² < P, and hence 1 – P² > 1 – P. This means that availability in the second case is higher.

Conclusion: Collocation of database copies on the same storage system decreases overall service availability.

So what is the difference between these two scenarios, why does introducing a failure domain increase availability in the first case and decrease availability in the second?

It’s because the failure domain in the first case combines service dependencies, effectively decreasing their number and therefore improving availability, whereas the failure domain in the second case combines redundant components, effectively decreasing redundancy and therefore impairing availability.

All these concepts and conclusions could be probably visualized as follows:

(No we did not use Wolfram Alpha to draw this graph!)

Summary

Exchange 2010 architecture provides powerful possibilities to add redundancy at the Exchange level (such as deploying multiple database copies or multiple Client Access servers in a CAS array) and to decrease the number of system dependencies (by combining Exchange server roles in a multi-role server or using simpler storage architecture without an excessive number of critical components). The simple rules and formulas presented in this article allow you to calculate the effect on the availability value from deploying additional database copies or from combining Exchange server roles; you can also calculate the impact of failure domains. It is important to note that we tried to use these simple mathematical models to illustrate the concepts, not to pretend to obtain precise availability values. Real life rarely fits the simple basic scenarios, and you need much more complex calculations to get reasonable estimates for the availability of your actual systems; it might be easier to simply measure the availability statistically and verify if it meets the SLA requirements. However, understanding the factors that impact availability and how they play together in a complex engineering solution should help you design the solution properly and achieve a significant increase in overall service availability meeting even the most demanding business requirements.

Boris Lokhvitsky
Delivery Architect

[1] The following studies by Carnegie Mellon University, Google, and Microsoft Research show 5% AFR for SATA drives:

http://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf

http://labs.google.com/papers/disk_failures.pdf

http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2005-166

Earlier today the Exchange CXP team released Update Rollup 5 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of RU4. See 'KB 2602324: Description of Update Rollup 5 for Exchange Server 2007 Service Pack 3' for more details.

We would like to specifically call out the following fixes which are included in this release:

• DST: New updates for August DST - Exchange 2007
• 2536695 "Some items cannot be deleted" error message when you try to delete or modify an email message in a public folder in an Exchange Server 2007 environment
• 2292150 A deleted hyperlink remains in the HTML source of an email message if you create the email message by using OWA in an Exchange Server 2007 environment (article not yet live)

General Notes:

• For DST Changes: http://www.microsoft.com/time
• Update Rollup 6 for Exchange Server 2007 Service Pack 3 is currently scheduled to release in April 2012. This will be in rhythm with next DST changes.

Note for Forefront users: For those of you running Forefront Security for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup's installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

Ron Ragsdale

If you missed Geeking out with Perry, he’s back in top form with a new blog and a special edition episode of Geek Out with Perry. In this episode, Perry addresses a ton of subjects from questions I recorded back in June when I was in Atlanta chatting with folks who were attending Tech·Ed North America. Matt Gossage, who’s a Principal Program Manager Lead on the team, was in Perry’s office when I came over to geek out and Matt helped provide additional insights about Exchange 2010 High Availability topics.

In addition, we also wanted to share some exciting news about Perry, that will no doubt embarrass him (Perry doesn’t like to brag) and cause him to reduce our mailbox size limits as penance for what we are about to say next. Let’s face it, we are Perry Clarke fans, so we couldn’t keep this a secret (as if you needed a bonus reason for why you should read Perry’s blog and check out the Geek Out with Perry video series.. ).

Without further ado…

Perry Clarke becomes Distinguished Engineer

Perry has spent the majority of his 15 years at Microsoft within the Exchange Product Group. During the development of Exchange 2007 and Exchange 2010 he led the Mailbox Server Engineering Team. Currently Perry manages the entire development team for Exchange (the Exchange Product Group, like other product groups, is broken down into four divisions:, program management, development, test, and customer experience).

Today we are happy to announce that Perry is being promoted to the role of Distinguished Engineer; there are less than 60 distinguished engineers at Microsoft.

The Distinguished Engineer title is a technical leadership designation at Microsoft and people who carry this title are recognized for their extraordinary contributions. These employees have a long-standing reputation of deep technical knowledge built on a sustained body of work and are “key people whose technical vision, expertise and world-class leadership have been instrumental in developing and driving products and standards for both the company and the industries.”

Some of Perry’s extraordinary contributions have been:

• Helping to dramatically redefine the storage system over the last two releases of Exchange to enable it to run on small, scaled-out servers with commodity SATA drives with significantly lower IOPS. Perry has personally championed this quest despite some skepticism from the industry – having the deep insight, and making it happen.
• Leadership in driving mailbox resiliency has also helped him play a key role in helping scale Exchange for the cloud with Office 365.
• Perry was a critical member of the team that helped drive corporate email archiving and compliance functionality in Exchange 2010.

From all of us in the Exchange Product Group, congratulations Perry on your well-deserved promotion.

Ann Vu

Today is the magical day when parents tell their tucked-in children the story of the Squeaky Lobster. So here's a Squeaky Lobster-ish post to celebrate the day.

In Exchange 2007, we introduced transport rules – a powerful feature that allows you to inspect different parts of a message such as sender, recipient, subject and headers and take actions like rejecting a message, deleting it, redirecting it to another recipient, adding a message header or a disclaimer. In previous versions of Exchange, you would need to write a transport event sink to accomplish similar things. With an easy-to-use interface in the EMC, transport rules make such tasks as easy as creating Inbox rules (created by users using Outlook/OWA). Command-line jockeys can create and manage transport rules using *-TransportRule cmdlets from the Shell. More about transport rules in Understanding Transport Rules.

In Exchange 2010, we added a number of new predicates (which are used to create conditions and exceptions), including the ability to inspect attachment content and predicates to evaluate Active Directory attributes of the sender or recipients. A complete list of predicates can be found in Transport Rule Predicates.

Ability to inspect Active Directory attributes of the sender or recipients dramatically increases the number of things you can check and the type of rules you can create. For example, you can check if the sender or recipients are in the same department, report to the same manager, check if the sender is the recipients’ manager (or the other way round), check the sender's title, city, state or country, amongst other things. The list of supported attributes is included in the Predicate Properties table in Transport Rule Predicates, or you can also see them in the New Transport Rule and Edit Transport Rule wizards in the EMC.

Evaluate the sender's country or region

You can use the predicate to evaluate the sender's country. This can be useful in many scenarios - for example, applying a disclaimer to messages based on the sender's country.

Important: When using Active Directory attributes to meet business requirements, you must have appropriate processes in place to ensure the necessary attributes are populated and up-to-date.

You can add the country/region property to a user or contact using ADUC, the EMC, the Shell or by using LDAP utilities. If you use ADUC or EMC, you’re greeted with a nice little drop-down list to pick a country/region from. If you use the Shell, you must use the corresponding cmdlet to populate the CountryOrRegion property – Set-User for user accounts, Set-Contact for contacts.

Fig 1: You can select a recipient’s country or region from recipient’s properties in EMC

You need to create a rule to check if message sender is from a specified country – let’s continue with Germany as the example, to apply a disclaimer. You can use the when the sender’s properties contain specific words predicate from the New Transport Rule wizard in EMC to check the CountryOrRegion property. The predicate allows you to pick a supported property and you can type in a string to match. For example, if you’re trying to match senders from Germany, you instinctively type in Germany.

But the transport rule doesn’t fire on any messages sent by recipients from Germany!

You check the rule in EMC – it says Germany. It’s spelt correctly, no typos. You use the Shell to retrieve the properties:

(Get-TransportRule MyRule).Conditions | fl *

The value correctly displays as Germany:

Words : {countryorregion:Germany}
Name : SenderAttributeContains
Rank : 36
LinkedDisplayText : when the sender's properties contain specific words
IsValid : True

You check the recipient’s country property using the Shell.

Get-User bsuneja | select cou*

Squeaky Lobster! The value is Germany! Why wouldn't the rule fire?

The CountryOrRegion Property

Although the CountryOrRegion property displays the country’s name (think of it as a display name), what’s stored in the Country-Name attribute (ldapDisplayName: c) in the recipient object in Active Directory is the 2-letter ISO 3166-1 country/region identifier for the country. For Germany, it’s DE. The full list of ISO codes can be found in the ISO 3166-1 decoding table . (Update: A better-formatted list can be found in ISO 3166-1 on Wikipedia).

Note: Active Directory objects also have two more attributes to identify country or region:
1) Country-Code (ldapDisplayName: countryCode), which corresponds to the ISO 3166-1 numeric code
2) Text-Country (ldapDisplayName: co), which is the country name.
However, only the Country-Name attribute is replicated to the Global Catalog.

Update the rule

Armed with this information, you can fix the rule in EMC.

Or use this command from the Shell to update the SenderADAttributeContains predicate.

Set-TransportRule MyRule –SenderADAttributeContains “CountryOrRegion:DE”

Happy Squeaky Lobster Day!

Bharat Suneja

Over the past few months there have been some exciting updates to the Microsoft Exchange product website at microsoft.com/exchange.

We've made these changes to showcase the product to a wider audience, including customers who want to learn about Exchange Online, and make it easier to learn about Exchange using different types of content. Whether you learn from watching videos with demos, reading technical whitepapers or hearing from customers, there is new content on the site for you. Among the new features worth checking out are:

• Microsoft Exchange Demos: This page contains a series of nine videos that show how to use some of the technology in Exchange through scenarios and product screen shots. Told from the perspective of a fictional 50-person toy company, the content presented here shows features of Exchange for both end users and for administrators.

• Exchange Online Hosted Email: This page has undergone a complete overhaul that coincided with the launch of Office 365 when Exchange 2010 came to Exchange Online. Here you can watch a short animated video about Exchange Online, download a selection of whitepapers, and hear from customers who have used the product. You can also see the different pricing options for Exchange Online and buy the product directly on that page.

• What’s New in Exchange Server 2010: Many customers have asked for a comparison between the past few versions of Exchange and this page was designed with that in mind. Here you can see that voicemail in the inbox came in Exchange 2007, while Database Availability Groups is an Exchange 2010 feature. This one is certain to be a popular one the next time Exchange shows up as a category in your pub trivia game.

We hope you enjoy this new content and encourage you to come back to the site for more exciting updates yet to come.

Ryan Metzger
Product Manager

By now, you have probably read the two previous blogs written by Nagesh Mahadev and Sushil Sharma on this subject. If you haven’t read them lately (or bookmarked them), I urge you to do so now.

This blog is going to discuss alternative methods for collecting data for Exchange Server 2007 and how to setup a data collector set to collect performance data for Version Buckets Allocated and two scheduled tasks to dump the store running on Windows Server 2008.

As part of the data collection, it is important that you download the Exchange 2007/2010 Performance Data Collection Script as discussed in http://archive.msdn.microsoft.com/ExPerfwiz and run it as per instructions to start capturing Performance data.

Here is our Event ID 623 that we will be using in our example:

Source: ESE
Event ID: 623
Task Category: Transaction Manager
Level: Error
Description:
MSExchangeIS (5828) SG4: The version store for this instance (1) has reached its maximum size of 155Mb. It is likely that a long-running transaction is preventing cleanup of the version store and causing it to build up in size. Updates will be rejected until the long-running transaction has been completely committed or rolled back.

Our calculation is the same as it has been in the past: x/1024 *32 = y, where x is the number of version buckets allocated and y is the total Version Store memory. Now, we know that the maximum Version Store memory is 155Mb from the event above and we can therefore work out the maximum number of version buckets allocated. x= (155*1024)/32 so we can see that this is 4960.

Here is where we deviate from the prior blogs. We are going to only get two store dumps:

• One when the version buckets allocated exceeds 80% of the total available
• One when the Event ID 623 is triggered

Our first step is to setup two batch files. One to dump the store when the version buckets allocated triggers and one when the Event ID 623 is triggered:

VersionBucket.bat contents:

C:\procdump\procdump.exe store.exe -MA -accepteula c:\store.dmp  

EventID623.bat contents:

C:\procdump\procdump.exe store.exe -MA -accepteula c:\store.dmp  

Then we create a User Defined Data Collector set named Version Buckets that we are going to use to run VersionBucket.bat. Note that these steps are for Windows Server 2008. If you are running Windows Server 2003, please see the steps here.

1. Open Performance Monitor

2. Under Data Collector Sets, right click User Defined

3. Give it any name, like Version Buckets, select Create manually (Advanced) and click Next.

4. Select Performance Counter Alert and click Next

5. Click Add; Select the MSExchange Database==>Instances as the Performance object, then under Counters select Version Buckets Allocated. Make sure that only SG4 is selected under Instances. Select Add and then Close. 

6. Set Alert when to Above and the Limit value is 3968 (4960*.80) and click Next

7. Select Start this data collector set now and click Finish

We then set up two scheduled tasks to run the batch files:

Creating scheduled task for dumping store when the version buckets allocated triggers

1. Launch Task Scheduler

2. Select Create Basic Task from the action pane

3. Give it any name, like Version Buckets and click Next

4. Select When a specific event is logged and click Next

5. Select Microsoft-Windows-Diagnosis-PLA/Operational  for Log

Select Diagnosis-PLA for Source

Enter 2031 for the Event ID and click Next

6. Select Start a program and click Next

7. Under Program/script, browse to the directory containing VersionBucket.bat and click Next and click Finish

Creating scheduled task for dumping store when Event ID 623 is recorded

1. Launch Task Scheduler

2. Select Create Basic Task from the action pane

3. Give it any name, like Event ID 623 and click Next

4. Select When a specific event is logged  and click Next

5. Select Application for Log, Select Application for Source, Enter 623 for the Event ID and click Next

6. Select Start a program and click Next

7. Under Program/script, browse to the directory containing EventID623.bat and click Next and click Finish

Send in the dump files, application log and performance monitor log that were running when the dump was collected to CSS for further analysis.

Many thanks to Mike Edwards, Michael Blanton and Eric Romero Rodriguez for their assistance with this article.

Eileen O’Rourke

Accepting inbound mail for a DNS domain and relaying it to responsible mail hosts outside your Exchange organization was a simple process in Exchange 2003, albeit one that required some explanation, which was discussed in the following articles:

• KB 321721 How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003
• KB 315511 XADM: How to Set Up Centralized SMTP Domain Sharing in Exchange 2000 Server for Independent Organizations

Exchange 2003 used Recipient Policies to define the domains for which your Exchange servers will accept email and to generate email addresses for your recipients using those domains.

Additionally, Recipient Policies also allowed you to apply Mailbox Manager settings, the Exchange 2003 equivalent of Messaging Retention Management (MRM).

Accepted Domains and Email Address Policies

In Exchange 2007, the Recipient Policy functionality was split into two components – Accepted Domains and Email Address Policies. As the names suggest, Accepted Domains are used to define the SMTP domains for which your transport servers will accept email, and Email Address Policies (EAPs) are used to generate email addresses for your recipients. EAPs use Accepted Domains – you must have an Accepted Domain to be able to create email addresses using that domain. For example, if you wanted your recipients to have email addresses from the domains contoso.com and tailspintoys.com, you first create an Accepted Domain for each of these domains and then create an email address policy to define the format of automatically generated email addresses – for example, firstname.lastname@contoso.com.

Whereas Exchange 2003 allowed you to use LDAP filters to apply Recipient Policies, Exchange 2010 and 2007 filter recipients using OPATH filtering syntax to apply EAPs. A number of pre-canned filters are included in the Email Address Policy interface in EMC or as parameters in the Shell, making it quite easy to use some of the more commonly used recipient properties such as company name, department, state and custom attributes 1-15 to apply policies. The pre-canned filters meet the needs of most Exchange deployments. For more complex filters, you can create a custom recipient filter by using the RecipientFilter parameter from the Shell. A custom recipient filter allow you to use a long list of recipient properties, called filterable properties, in a recipient filter. You can find a list of filterable properties in Filterable Properties for the -RecipientFilter Parameter in Exchange 2007 SP1 and SP2.

Accepted Domains and Sharing SMTP Address Spaces

The separation of domain name and email address policy objects makes sharing SMTP address spaces much easier. You can create the following three types of Accepted Domains in Exchange 2010 and Exchange 2007:

1. Authoritative domains: An authoritative domain means your Exchange organization is authoritative for the domain and knows about all its recipients. Generally, all recipients in an authoritative domain are Exchange recipients – mailboxes, distribution groups, mail-enabled public folders. Recipients can also be in other email systems, but Exchange must have a mail-enabled contact (MailContact) or a mail-enabled user (MailUser) object for them. Although one-off mail contacts or mail users can be created manually, they're generally created using directory synchronization in the following scenarios, for example:

   • Another business unit which has its own Active Directory forest
   • Another messaging system/directory in use within the same organization

   Once replicated, Exchange knows how to deliver mail to these recipients.

   Because Exchange is authoritative for the domain, it must generate a non-delivery report (NDR) for messages it accepts but can’t deliver for any reason, including for recipients it can’t find in Active Directory. You can use Recipient Filtering and silently drop mail for non-existent recipients.

2. External Relay domains: If your Exchange servers must accept email for a domain that it doesn’t have any recipients for, and then forward all such email to another mail host, you can create an External Relay domain. In this case, Exchange has no knowledge of recipients, and thus can’t take actions such as performing recipient filtering and dropping mail for recipients that don’t exist. Accepting inbound mail through a central messaging infrastructure is a common scenario. Because Exchange isn’t authoritative for the domain, it’s only responsible for forwarding mail to the next hop for that domain, which must generate any NDRs upon failure to deliver.

   To forward email for an external relay domain to mail hosts that are authoritative for the domain (or the next hop, which can then relay it on), you must create a Send Connector for that domain and specify the next hop as a smarthost. In topologies with an Edge Transport server, such email is relayed by the Edge Transport and the Hub Transport servers never need to handle messages.

3. Internal Relay domains: Internal relay domains fulfill an important need, one that required a fairly involved setup in Exchange 2003. They allow you to accept email for a domain where some recipients may exist in your Exchange organization, and some recipients may be on another messaging system. Exchange may know about recipients in the other messaging system using mail contacts or mail users. Or it may deliver all messages that can be delivered locally (on any Exchange server in the organization) and relay messages for unknown recipients to another mail host using a Send Connector for the same domain. Because Exchange is not authoritative for this domain, it does not generate NDRs for recipients it’s not responsible for.

   Internal Relay domains and Send Connectors
   One important consideration when using an internal relay domain is that the Send Connector you use to send mail for unknown recipients to another mail host can’t be sourced to an Edge Transport server, because the Edge Transport server has already been instructed to accept all mail for that domain and forward it to Hub Transport servers. Instead, the Send Connector must be sourced to Hub Transport servers and you must specify another mail host as a smarthost.

Figure 1: Creating an Accepted Domain in EMC

More details in Understanding Accepted Domains.

Accepted Domains and Recipient Filtering

When creating Accepted Domains, an important consideration is Recipient Filtering. If you use Exchange’s built-in anti-spam filters, you can filter recipients that don’t exist in your organization using Recipient Filtering. This allows you to drop a large chunk of spam (at the gateway if you’ve implemented an Edge Transport server with EdgeSync). Additionally, it also means your servers won’t be processing mail for non-existent recipients and generating a NDR for the sender, which may also be either non-existent address or a valid addresses spoofed by a spammer.

If you’re in a topology with an Edge Transport server and have EdgeSync configured, recipient information is synchronized from a Hub Transport server to the Edge Transport server, which can then use this information to drop email for recipients that don’t exist in your organization. If you don’t have an Edge Transport server deployed, you can install anti-spam agents on a Hub Transport server and enable Recipient Filtering.

Many third-party SMTP security solutions that are typically deployed in perimeter networks can also lookup recipients in Active Directory, although they may require LDAP connectivity to an Active Directory DC/GC, which sits on your internal network, or some other means for replicating recipient information. Comparatively, EdgeSync communication is outbound (Secure LDAP) from Hub Transport servers to the Edge Transport server and doesn’t require you to open any ports on your internal firewall for inbound traffic.

How does Recipient Filtering treat recipients from different types of accepted domains? For authoritative domains, where Exchange knows about all recipients, Recipient Filtering drops mail for recipients that don’t exist in Active Directory. For External Relay domains, Exchange doesn’t know about any recipients, so such filtering isn’t possible. Internal Relay domains are a grey area – Exchange may or may not know about the recipients.

You can configure whether Recipient Filtering is allowed for an Accepted Domain by setting its AddressBookEnabled property. The default values for each accepted domain type are in the following table:

For internal relay domains, it’s set to false by default – meaning Exchange (i.e. the Recipient Filtering agent, if enabled and configured to drop mail for recipients that don't exist in Active Directory) won’t check if the recipient exists. If you’re using a mechanism to replicate recipients from another Exchange organization or non-Exchange messaging system to Active Directory, you can set the property to true and have Recipient Filter check for valid recipients.

Set-AcceptedDomain foo.com –AddressBookEnabled $true

Bharat Suneja

It’s been a few months since we announced some major changes to our virtualization support statements for Exchange 2010 (see Announcing Enhanced Hardware Virtualization Support for Exchange 2010). Over that time, I’ve received quite a few excellent questions about particular deployment scenarios and how the changes to our support statements might affect those deployments. Given the volume of questions, it seemed like an excellent time to post some additional information and clarification.

First of all, a bit of background. When we made the changes to our support statements, the primary thing we wanted to ensure was that our customers wouldn’t get into a state where Exchange service availability might be reduced as a result of using a virtualized deployment. To put it another way, we wanted to make sure that the high level of availability that can be achieved with a physical deployment of the Exchange 2010 product would not in any way be reduced by deploying on a virtualization platform. Of course, we also wanted to ensure that the product remained functional and that we verified that the additional functionality provided by the virtualization stack would not provide an opportunity for loss of any Exchange data during normal operation.

Given these points, here’s a quick overview of what we changed and what it really means.

With Exchange 2010 SP1 (or later) deployed:

• All Exchange 2010 server roles, including Unified Messaging, are supported in a virtual machine.
• Unified Messaging virtual machines have the following special requirements:
  • Four virtual processors are required for the virtual machine. Memory should be sized using standard best practices guidance.
  • Four physical processor cores are available for use at all times by each Unified Messaging role virtual machine. This requirement means that no processor oversubscription can be in use. This requirement affects the ability of the Unified Messaging role virtual machine to utilize physical processor resources.
• Exchange server virtual machines (including Exchange Mailbox virtual machines that are part of a DAG), may be combined with host-based failover clustering and migration technology, as long as the virtual machines are configured such that they will not save and restore state on disk when moved, or taken offline. All failover activity must result in a cold boot when the virtual machine is activated on the target node. All planned migration must either result in shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live Migration. Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines. Microsoft supports Hyper-V Live Migration of these virtual machines.

Let’s go over some definitions to make sure we are all thinking about the terms in those support statements in the same way.

• Cold boot This refers to the action of bringing up a system from a power-off state into a clean start of the operating system. No operating system state has been persisted in this case.
• Saved state When a virtual machine is powered off, hypervisors typically have the ability to save the state of the virtual machine at that point in time so that when the machine is powered back on it will return to that state rather than going through a “cold boot” startup. “Saved state” would be the result of a “Save” operation in Hyper-V.
• Planned migration When a system administrator initiates the move of a virtual machine from one hypervisor host to another we call this a planned migration. This could be a single migration, or a system admin could configure some automation that is responsible for moving the virtual machine on a timed basis or as a result of some other event that occurs in the system other than hardware or software failure. The key point here is that the Exchange virtual machine is operating normally and needs to be relocated for some reason – this can be done via a technology like Live Migration or vMotion. If the Exchange virtual machine or the hypervisor host where the VM is located experiences some sort of failure condition, then the result of that would not be “planned”.

Virtualizing Unified Messaging Servers

One of the changes made was the addition of support for the Unified Messaging role on Hyper-V and other supported hypervisors. As I mentioned at the beginning of this article, we did want to ensure that any changes we made to our support statement resulted in the product remaining fully functional and providing the best possible service to our users. As such, we require Exchange Server 2010 SP1 to be deployed for UM support. The reason for this is quite straightforward. The UM role is dependent on a media component provided by the Microsoft Lync team. Our partners in Lync did some work prior to the release of Exchange 2010 SP1 to enable high quality real-time audio processing in a virtual deployment, and in the SP1 release of Exchange 2010 we integrated those changes into the UM role. Once that was accomplished, we did some additional testing to ensure that user experience would be as optimal as possible and modified our support statement.

As you’ll notice, we do have specific requirements around CPU configuration for virtual machines (and hypervisor host machines) where UM is being run. This is additional insurance against poor user experience (which would show up as poor voice quality).

Host-based Failover Clustering & Migration

Much of the confusion around the changed support statement stems from the details on combination of host-based failover clustering & migration technology with Exchange 2010 DAGs). The guidance here is really quite simple.

• First, let’s talk about whether we support third-party migration technology (like VMware’s vMotion). Microsoft can’t make “support” statements for the integration of 3rd-party hypervisor products using these technologies with Exchange 2010, as these technologies are not part of the Server Virtualization Validation Program (SVVP) which covers the other aspects of our support for 3rd-party hypervisors. We make a generic statement here about support, but in addition you need to ensure that your hypervisor vendor supports the combination of their migration/clustering technology with Exchange 2010. To put it as simply as possible: if your hypervisor vendor supports their migration technology with Exchange 2010, then we support Exchange 2010 with their migration technology.

• Second, let’s talk about how we define host-based failover clustering. This refers to any sort of technology that provides automatic ability to react to host-level failures and start affected VMs on alternate servers. Use of this technology is absolutely supported within the provided support statement given that in a failure scenario, the VM will be coming up from a cold boot on the alternate host. We want to ensure that the VM will never come up from saved state that is persisted on disk, as it will be “stale” relative to the rest of the DAG members.

• Third, when it comes to migration technology in the support statement, we are talking about any sort of technology that allows a planned move of a VM from one host machine to another. Additionally, this could be an automated move that occurs as part of resource load balancing (but is not related to a failure in the system). Migrations are absolutely supported as long as the VMs never come up from saved state that is persisted on disk. This means that technology that moves a VM by transporting the state and VM memory over the network with no perceived downtime are supported for use with Exchange 2010. Note that a 3rd-party hypervisor vendor must provide support for the migration technology, while Microsoft will provide support for Exchange when used in this configuration. In the case of Microsoft Hyper-V, this would mean that Live Migration is supported, but Quick Migration is not.

With Hyper-V, it’s important to be aware that the default behavior when selecting the “Move” operation on a VM is actually to perform a Quick Migration. To stay in a supported state with Exchange 2010 SP1 DAG members, it’s critical that you adjust this behavior as shown in the VM settings below (the settings displayed here represent how you should deploy with Hyper-V):

Let’s review. In Hyper-V, Live Migration is supported for DAG members, but Quick Migration is not. Visually, this means that this is supported:

And this is not supported:

Hopefully this helps to clarify our support statement and guidance for the SP1 changes. We look forward to any feedback you might have!

Jeff Mealiffe

Today we have released a minor update to the Exchange 2010 Mailbox Server Role Requirements Calculator that includes enhancements like 3TB disk support and new processor core options.  In addition, there are several bug fixes. 

Please go to our Mailbox Server Role Storage Requirements Calculator updates tracking page to see what has changed.

A blog post explaining how to use the calculator is here and or you can download the calculator directly.

Ross Smith IV

With the release of Exchange 2010 SP1, we introduced the /hosting mode switch – a feature which deploys Exchange using an Active Directory structure that affords complete separation between tenant organizations shared on the same underlying platform. /Hosting mode makes the need for a solution like Hosted Messaging and Collaboration largely redundant when hosting multi-tenant Exchange. /Hosting mode does not ship with any automation tools necessary for hosters to operate a service at scale, but it does address the requirements typical of a multi-tenant infrastructure (such as tenant organizations and service plans).

On one hand, /hosting mode solves many challenges inherent to offering this type of service. On the other hand, /hosting mode offers a reduced feature set as compared to the typical on-premises configuration. In the time since we released SP1 and /hosting mode, we have heard from customers and partners alike that many of these features are a fundamental requirement for doing business, and so to this end I announced that hosters would be supported when using the on-premises configuration from SP2 onwards (assuming their configuration meets certain design requirements). In addition, we also provided perspective on which is the right approach for hosters to take.

The purpose of this blog post is to explain the next step in the evolution of our thinking regarding /hosting mode. After hearing feedback about the importance of these features, we have concluded that the best approach to multi-tenant hosting on Exchange is to use the on-premises configuration as the basis for a hosting infrastructure. As such, no additional features will be added to /hosting mode, and it will not be carried forward into the next version of Exchange. Here are a few key facts you’ll need to know:

• /hosting mode will be supported through the standard support lifecycle for Exchange 2010. It will still be available in SP2 and any future service packs or roll-ups. No additional functionality or features will be added to /hosting mode, however, and we don’t recommend using /hosting mode going forward due to its reduced feature set and the fact that it will add complexity to future upgrades.
• Multi-tenant hosting on the next version of Exchange will be supported, in a similar fashion to the approach we will take with Exchange 2010 SP2.
• Migrating from Exchange 2010 /hosting mode to the on-premises configuration of Exchange (2010 or future versions) will require deployment into a separate forest.
• Microsoft will publish guidelines for hosting a multitenant environment using the on-premises configuration. Microsoft will also publish a step-by-step process for upgrading from Exchange 2007 HMC or migrating from Exchange 2010 SP1 /hosting to Exchange 2010 SP2 using the on-premises configuration.
• Hosting automation tools and control panel solutions will be provided by our hosting ISV partners. We are working closely with them to ensure their solutions meet our hosting guidelines (and will therefore be supported).

While this represents a change in direction, and will no doubt result in varying amounts of migration work on the part of hosters who have deployed /hosting mode, there is good news. This new approach means that hosters will be able to offer a wider set of hosted Exchange features to their customers. In addition, integrating Lync into a hosted service portfolio will be more streamlined and much simpler.

Looking at the data we presented at Worldwide Partner Conference, this opens up a sizeable market opportunity for hosters. Most customers looking to upgrade to Exchange 2010 cite the product’s advanced capabilities (such as Exchange UM – not available in /hosting mode) and a hosted UC service as a primary driver.

The obvious question you’re probably asking yourself is “what should I do now?” If you haven’t yet deployed Exchange 2010, our recommendation is to avoid /hosting mode and go directly to Exchange 2010 SP2 using the on-premises configuration. This will allow you to offer the features customers are looking for, and avoid a cross forest migration down the road.

If you’ve already deployed /hosting mode, you will continue to be fully supported through the standard support lifecycle of Exchange 2010, though you will continue to have a reduced set of features at your disposal. In addition, if you’re planning on hosting Lync and have deployed Exchange using /hosting mode, you will need to deploy Lync in a separate forest. You might consider switching to Exchange 2010 SP2 using the on-premises configuration.  If neither of these issues are considerations, stay the course until the next version of Exchange is available.

As I mentioned above, documentation for hosting as well as a step-by-step process for both scenarios will be forthcoming from my team in the coming months.

We appreciate the challenges involved with this decision are considerable, but we do believe this is the best, most flexible course of action available for our service provider partner community going forward. We will provide more information and details in the coming months, but wanted to be clear about this directional change as you make plans for your infrastructure today.

Kevin Allison
General Manager
Exchange Customer Experience

We are happy to report that a fix for the Exchange Management Console (EMC) issues when Internet Explorer 9 is installed is now available. To be specific, we have talked about this in a previous blog post:

Exchange 2007 or 2010 EMC might fail to close with "You must close all dialog boxes before you can close Exchange Management Console"

How does this fix need to be applied?

In order to install the fix, a released version of IE9 needs to be installed on the machine first. Then:

• MS11-081: Cumulative Security Update for Internet Explorer: October 11, 2011 needs to be installed. This can be obtained from Windows Update or - if you need to download it for local network installation, the packages can be obtained here. Please note that the packages for client and server OSes might be different, depending on what you need. The installation of this package is REQUIRED for proper operation of the EMC hotfix.
• In order to obtain the actual hotfix that resolves the interoperability problem with EMC, you will need to call Microsoft support and request a hotfix. The hotfix package is currently not available for public download, but can be obtained from support engineers, who can get it from internal hotfix servers. When you talk to support, the hotfix that you need to request is for the KB 2624899. Please note that this article is not publicly available at this time either.

How do I call support? Will I need to pay for this?

In order to reach Microsoft support, you can find the correct support contact for your location here. Microsoft does not charge for hotfixes or support cases related to product bugs. Both IE and Exchange support teams should be able to get this patch for you.

Why is this fix not available for public download?

It's planned that this fix will be rolled into a version of Internet Explorer or a fix that will be released at a later time. Due to the amount of feedback we've received about this issue, we wanted to give you a way to resolve this problem right now, if you are impacted by it. Individual hotfix packages such as this one do not go through as extensive testing as our roll-up fixes and therefore we want to have a way to reach out to customers who use it in case there's a problem that is identified with it at a later time.

Finally, I would like to thank the Internet Explorer team for working with us on this interoperability issue and producing this hotfix.

Nino Bilic

Exchange Message Tracking Logs hold a wealth of information about email messages during transport. Utilities that can parse message tracking logs and analyze them for administrators have historically been important tools when troubleshooting certain mail flow problems.

With Exchange 2010, the message tracking log format has been modified to hold additional fields about messages. For those who enjoyed using "Process Tracking Log tool for Exchange Server 2007" in the past, you would be very pleased. We have come up with the new version which works with both Exchange 2007 and Exchange 2010. Same looks and great generated reports included!

When to use Process Tracking Log:

PTL may help in following situations:

• Message Looping
• Message failures, such as in Delivery Status Notifications (DSNs)
• List of top mail senders
• List of top mail recipients
• Top large message size generators
• Queues backing up
• Performance issues due to message load
• Simply monitoring server message load

To learn more about PTL tool and the reports it generates please review the original article, "Process Tracking Log tool for Exchange Server 2007". The article provides example outputs and how you can use these to further analyze your mail flow.

Where to download the new Process Tracking Log tool:

To install the latest PTL, please go here to download it.

Please note: this script is not officially supported by Microsoft. Please see the script for more details!

How to Use this tool:

The command set used to run the PTL script are still the same as the original tool.

Usage:

cscript ProcessTrackingLog.vbs <LogFilePath> <NumFiles> <hub|edge|all> [ <mm/dd/yyyy> | today | yesterday ]

Examples:

1) To parse one file:

cscript ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking\MSGTRK20110401-1.LOG" 1 all

2) To parse one file in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 1 all

3) To parse all files in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs “C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking” 0 all

4) To parse all files in all subdirectories in a single directory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all

5) To parse 3 files in each subdirectory:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 3 all

6) To parse all files in each subdirectory that were logged yesterday:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all yesterday

7) To parse all files in each subdirectory that were logged on 6/5/2011:

cscript \data\scripts\ProcessTrackingLog.vbs "C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\MessageTracking" 0 all 6/5/2011

NOTE: use of hub and edge assume "HUB" or "GWY" in directory path, otherwise specify all. Also note that the message tracking log path location has changed between Exchange 2007 and 2010 since in Exchange 2010 the path has “V14” folder added.

All results are stored in “c:\temp\msgtrack\output” folder.

Some enhancements:

• PTL now works with both Exchange 2007 and 2010 message tracking log. Note that the actual path for message tracking log differs between Exchange 2007 and 2010.
• The tool will now automatically create the path folder “c:\temp\msgtrack\output” where the output results will be stored.
• The summary file, “MTSummaryResults.txt”, will have the Exchange version as well as PTL version listed.

We will maintain this tool from time to time or provide enhancements. Please contact Nasser, Nadeem, or me if you have any questions.

Nasser Salemizadeh, Mohammad Nadeem, Shawn Zaravar, Todd Luttinen

Just like we want to get to know you better, we want you to get to know us better. We like long walks on the beach, poetry, candlelit dinners, remote PowerShell and we love to Geek Out with Perry. More importantly, we wanted you all to get special behind-the-scenes insights into the Exchange team so you can get to know us as teams and individuals who design, build and run Exchange rather than some faceless collective like The Borg. Get a glimpse into how we think about Exchange, what’s important to us, what motivates us and what keeps us coming back for more through a new video series titled, ESE Access to Exchange. Go check out our very first episode with folks on the team discussing what it’s like to evolve from building only software to providing Exchange in the cloud and running a vital service for customers.

In the future, we’d like to share additional episodes with you that cover specific feature teams, design topics and insights into how we do things as well as fun memories or interesting tidbits about us. We’re still brainstorming ideas on other subjects to cover so please comment back and let us know if there is something you’d really like to know about Exchange team members.

Enjoy!

Ann Vu
Technical Product Manager

I just wanted to drop a quick note that our and other blogs hosted on TechNet will go down later today for scheduled maintenance. We expect that this will not last more than a few hours. The scheduled window is:

Friday the 28th from 3:00-7:00pm PST

Nino Bilic

Earlier today the Exchange CXP team released Update Rollup 6 for Exchange Server 2010 SP1 to the Download Center.

This update contains a number of customer-reported and internally found issues since the release of SP1. See 'KB 2608646: Description of Update Rollup 6 for Exchange Server 2010 Service Pack 1' for more details.

This update contains a number of customer reported and internally found issues since the release of RU5. In particular we would like to specifically call out the following fixes which are included in this release:

• 2627769  Some time zones in OWA are not synchronized with Windows in an Exchange Server 2010 environment
• 2528854  The Microsoft Exchange Mailbox Replication service crashes on a computer that has Exchange Server 2010 SP1 installed
• 2544246 You receive a NRN of a meeting request 120 days later after the recipient accepted the request in an Exchange Server 2010 SP1 environment
• 2616127  "0x80041606" error code when you use Outlook in online mode to search for a keyword against a mailbox in an Exchange Server 2010 environment.
• 2549183  "There are no objects to select" message when you try to use the EMC to specify a server to connect to in an Exchange Server 2010 SP1 environment

• For general DST related information please see: http://www.microsoft.com/time

Availability of this update on Microsoft Update is planned for late November.

General Notes

An issue with management of RBAC roles when RU6 is partially deployed in the organization: Due to changes shipped in this update, certain warnings can be displayed when managing RBAC roles, if RU6 is not yet deployed to all servers in the organization. Please see the following KB article for more information:

Managing RBAC roles might display warnings or errors if Exchange 2010 SP1 RU6 is partially deployed in the organization
http://support.microsoft.com/kb/2638351

Note for Forefront users: For those of you running Forefront Protection for Exchange, before installing the update, stop all Forefront services.

Ron Ragsdale