Guest Post – How to Improve Your Exchange Performance

 

With more users each day identifying email as their most important tool, every incremental improvement you can squeeze out of your Exchange performance is victory. Unfortunately, it is the very criticality of email to your users that makes this an uphill battle. As users conduct more and more business using email, their storage needs increase, and as a result, the overall performance of your Exchange system can decrease. Fortunately, there's an easy-to-implement solution to this seeming paradox; and no, it doesn't require your users to delete messages, or for you to restrict them to mailboxes measured in megabytes. Email archiving can provide a big boost to your Exchange performance in several ways. Here are three that can provide you with immediate results.

1. Decreased database size
As databases grow, Exchange must spend more time on database management, more CPU cycles indexing and maintaining the database, and more RAM caching data. Much of what resides in a mailbox database is old; email that has no immediate need, but that users want to keep "just in case". Traditional Exchange management practices limited mailbox sizes which drove users to move old email to PSTs. PSTs are not scalable, and with the disk I/O improvements of Exchange, larger mailboxes reduce the need for PSTs, but these ever larger databases must still be indexed, and defragmented. Implementing an email archiving solution enables you to move older email to another data store on a separate system. Exchange databases are smaller, reducing the overhead associated with maintenance, but users are still able to access their older emails online. It's an easy way to improve Exchange performance.

2. Faster backups and restores
As nice as those huge mailboxes are, there comes a point where the time it takes to backup a database exceeds the time in your backup window. Worse still, should disaster strike, restoring larger databases can take longer than your recovery time objectives. Dividing mailboxes across more and more databases is not a scalable solution, as the administrative overhead of all those databases will soon overwhelm you, and you'd still have to prioritize your restores. Who gets restored first – The CEO or the Payroll team? By implementing email archiving, older messages can be moved to the archive, trimming the size of the mailbox databases without deleting important messages or reducing the available storage. Your Exchange performance gets a huge boost in the backup and restore category.

3. Accessibility
Too many times, the answer to email storage is the use of PST files. PSTs have a number of issues, not the least of which is that email contained within a PST in only accessible to the Outlook client that can physically access the file. Webmail, smartphones, and discovery efforts will all have problems accessing messages stored in PSTs. By implementing an email archiving solution, messages remain accessible to all mail clients, without having to add more and more storage to Exchange. Again, Exchange performance is improved by keeping mail accessible.

As you can see, implementing an email archiving solution is an easy way to boost your Exchange performance while also improving your DR and data accessibility positions.

This guest post was provided by Casper Manes on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. Read more on how to improve your Exchange performance.

All product and company names herein may be trademarks of their respective owners.

Recommended Exchange Reference Material

 

We all have books, whitepapers and documentation that we often end up referring to from time to time, whether it's a refresher on a topic you're a little rusty on or just to double check a few facts. For my benefit, and hopefully yours, here's my handy list of Exchange reference material…

Books

Exchange Server 2010 Inside Out – Tony Redmond
Exchange Server 2010 Best Practices – Siegfried Jagott & Joel Stidley
Exchange 2010 Powershell Cookbook – Mike Pfeiffer

Whitepapers

Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V
Exchange 2010 on VMware – Best Practices Guide
Microsoft Exchange Server 2010 Performance on vSphere 5
Best Practices for Exchange Server Public Folders
Publishing Exchange Server 2010 with Forefront UAG 2010 and TMG 2010
Exchange 2010 Large Mailbox Vision Whitepaper

Documentation and Reference

Exchange 2010 SP2 Full Help CHM Dec 2011
Exchange 2010 SP1 Infrastructure Planning and Design Guide
Exchange 2010 EPDS Deployment and Planning Services (EPDS)
JetStress Field Guide
Exchange Server 2010 Architecture Poster
Microsoft Exchange Server 2010 Transport Server Role Architecture Diagrams
RFC 2821 – SMTP
RFC 2822 – Internet Message Format
RFC 3501 – IMAP 4 Rev 1
RFC 1939 – POP3
RFC 2595 – Using TLS with IMAP, POP3 and ACAP
RFC 3261 – Session Initiation Protocol (SIP)

Updated – Recommended Exchange Reference Material

 

Now SP2 has been released, I've updated my list of Exchange Reference Material to contain the link to the new Exchange 2010 SP2 downloadable help file, also available here.

Thanks to Bart Smith for the tip. Bart also recommends Windows PowerShell in Action, Second Edition (which is also recommended as Exchange MCM prep). I haven't personally read it myself, but it looks worth checking out.

Updated – Disabling Auto-mailbox mapping in Exchange 2010

 

In February this year I wrote about how to disable the automatic mapping of shared mailboxes in Exchange 2010 SP1, using a custom PowerShell script that "wraps" the Add-MailboxPermission command and after execution, removes the attribute in Active Directory that is used to automatically mount the mailbox in Outlook.

With Exchange 2010 SP2, there's great news - this workaround is no longer required, as in SP2 a new parameter has been added to the native cmdlet.

Check out the updated article here, and stay tuned for a future article explaining how to extend this functionality to the Exchange Management Console

How to use Multi-Valued Custom Attributes in Exchange 2010 SP2

 

One of the new features in Exchange Server 2010, SP2, is the new ability to use Multi-Valued Custom attributes:

Exchange 2010 SP2 introduces five new multi-value custom attributes that you can use to store additional information for mail recipient objects. The ExtensionCustomAttribute1 to ExtensionCustomAttribute5 parameters can each hold up to 1,300 values. You can specify multiple values as a comma-delimited list.

These attributes (accessible only via the Exchange Management Console) can be used with most types of recipients, including Mailboxes, Mail Contacts, Remote Mailboxes and Distribution Groups, and you could use them to store all kinds of extra text-based information against accounts.

So, how do you use the new features? Well, if you are using Powershell, you can use them by assigning an array to the new Extension Custom Attribute1 - 5 properties. As an example, I'll create a simple array, assign it to ExtensionCustomAttribute1 property and then retrieve it:

As it's stored as an array, we can then use PowerShell to add extra attributes to it on demand:

In my example, I am using it to record changes. Although it's got limits, it still could be ideal to store a change log of certain actions to an account, such as the date a quota change was applied for example.

By the way, you'll notice the @{Add="Value"} syntax in the example above; if you aren't familiar with the syntax, you can read more here about Using Multivalued Properties in Exchange 2010.

 

New-TestCasConnectivityUser.ps1Error

When you run TestCasConnectivityUser.ps1 , you need to have mail enabled test user account for the script to run properly. new-TestCasConnectivityUser.ps1 Drill down to Script directory on your exchange server, and run "new-TestCasConnectivityUser.ps1" Program Files Microsoft Exchange Server V14 Scripts Make sure the password you are using at the first time meets the password requirements and if you need specify the OU where the account will get created ( replace STP25.gov to your own Domain name space.) Get-MailboxServer mccnpwinmbx1 | .\new-TestCasConnectivityUser.ps1 -OU STP25.gov/users If you open ADUC you will be able to see this user, in the default users container. get-user extest_e7a1882f51284   No running  Test-OutlookWebServices -ClientAccessServer EXCCAS1 should work Respectfully, http://smtp25.blogspot.com/ (Blog) http://telnet25.wordpress.com/ (Blog)

View article...

 

How to Find what Exchange 2010 Version you are running on your Server.

Use fallowing  PS to figure out what version of exchange 2010 you are running. [PS] C:\>Get-ExchangeServer | Format-Table Name, *Version* http://social.technet.microsoft.com/wiki/contents/articles/exchange-server-and-update-rollups-builds-numbers.aspx [PS] C:\>Get-help Get-ExchangeServer [PS] C:\>Get-ExchangeServer | Format-List Respectfully, http://smtp25.blogspot.com/ (Blog) http://telnet25.wordpress.com/ (Blog)

View article...

Exchange 2010 Administrator Audit log Powershell GUI

An interesting and useful new feature of Exchange 2010 is Administrator audit logging where each time a EMS cmdlet is run in the Exchange in the EMS, EMC or ECP this is logged. Within ECP you can do a search of the admin Audit logs and have the result emailed to you and what you receive in your inbox is an email with an a attachment called searchresult.xml. While this file contains a lot of great information there are a few problems with this format for administrators firstly is that OWA and Oultook will usually block the XML attachments so it can firstly be hard to get to the attachment. Secondly XML isn't the most readable format when it comes to trying to intemperate what was going on especially if you search across a larger number of days. So what I've put together is a GUI that first uses the EWS Managed API to find these any of these emails within your inbox and then gives you the option of exporting the raw xml or converting the XML to a CSV file or lastly using a separate report winform that groups the data retrieved and displays it back to the user. The later i think is a lot more useful as it lets you work more intuitively with the data and the better you can do this the more likely it is that you would spot an abnormality which is one to the purposes of auditing. eg this is what it looks like Note this GUI currently only handles the Admin Audit logs not the Mailbox Audit log which are in a different format. I've put a download of this script here

View article...

 

Exchange 2010 Database Size, EDB file Path etc.….

You might wonder what is the size of  your Exchange Server databases , and their path etc. In Exchange 2010 the task is pretty real easy. Get-MailboxDatabase -Status | select ServerName,Name,DatabaseSize,EdbFilePath,LogFolderPath Now here how the output would look like to export this into CSV file add the fallowing at the end of PS Export-Csv c:\scripts\DBSize.csv Full Script would be like this Get-MailboxDatabase -Status | select ServerName,Name,DatabaseSize,EdbFilePath,LogFolderPath | Export-Csv c:\scripts\DBSize.csv Finally we will plug this into PowerGUI Give it a name Respectfully, http://smtp25.blogspot.com/ (Blog) http://telnet25.wordpress.com/ (Blog)

View article...

Disable permanently Outlook Team Calendar

Outlook 2010 introduced new future called "Team Calendar". This future might be annoying or not acceptable in certain cases and un-ticking check mark to make it not seen might not be sufficient enough. If so and you are wondering how to disable this here is the solution. Team Calendars , star popping up from people outlook. –Reason: the AD Attribute called "Manager" is populated see picture When manager is listed for given user,  outlook is automatically creating calendar in this format  Team: Name of the manager Calendar inside peoples outlook see picture   Fire up reg edit on the problem workstation…..Drill down to fallowing directory [HKEY_CURRENT_USER Software Microsoft Office 14.0 Outlook Options WunderBar Create reg key if one does not exist "Value disablereportinglinegroupcalendar" This policy setting prevents Reporting Line Group Calendar from appearing in the navigation pane. If you enable this policy setting, Reporting Line Group Calendar will not appear in the navigation pane. If you disable or do not configure this policy setting, My Reporting Line Group Calendar will appear in the navigation pane. Before After Respectfully, http://smtp25.blogspot.com/ (Blog) http://telnet25.wordpress.com/ (Blog)

View article...

 

Setup wizard for update rollup 6 for Exchange server 2010 service pack 1 ended prematurely because of an error….

If you are attempting to install RU on Exchange 2010 server and receiving fallowing error, there is easy way to go around to get the install working without such issues. Problem: Install attempt RU XX on Exchange 2010 server is failing with above or similar error Solution: Run the setup file with Administrator privileges Cause: Most likely UAC turned on ( no need to try to turn it off ) Now here is the big secret , in old days we were able to say copy and paste into CMD window without typing the full path of the install file, you will quickly realize this is not working on Windows 2008 and you are like come on (-: on the install file hold "SHIFT" key down and left click to get option " Copy as path" Open CMD as administrator and "paste" will work now , Wowwww got to love this, whom ever though of making such improvement into Windows 2008, Now install will work flawless. Http://smtp25.blogspot.com (Blog Http://telnet25.spaces.live.com (Blog) Http://telnet25.wordpress.com (Blog)

View article...

 

Version Build number Release date

Version Build number Release date

Microsoft Exchange Server 4.0 ---------- 4.0.837 --- Apr-96
Microsoft Exchange Server 4.0 (a) ----- 4.0.993 --- Aug-96
Microsoft Exchange Server 4.0 SP1 --- 4.0.838 --- May-96
Microsoft Exchange Server 4.0 SP2 --- 4.0.993 --- Aug-96
Microsoft Exchange Server 4.0 SP3 --- 4.0.994 --- Nov-96
Microsoft Exchange Server 4.0 SP4 --- 4.0.995 --- Apr-97
Microsoft Exchange Server 4.0 SP5 --- 4.0.996 --- May-98

Microsoft Exchange Server 5.0 ---------- 5.0.1457 --- Mar-97
Microsoft Exchange Server 5.0 SP1 --- 5.0.1458 --- Jun-97
Microsoft Exchange Server 5.0 SP2 --- 5.0.1460 --- Feb-98
Microsoft Exchange Server 5.5 ---------- 5.5.1960 --- Nov-97
Microsoft Exchange Server 5.5 SP1 --- 5.5.2232 --- Jul-98
Microsoft Exchange Server 5.5 SP2 --- 5.5.2448 --- Dec-98
Microsoft Exchange Server 5.5 SP3 --- 5.5.2650 --- Sep-99
Microsoft Exchange Server 5.5 SP4 --- 5.5.2653 --- Nov-00

Microsoft Exchange 2000 Server ---------- 6.0.4417 --- Oct-00
Microsoft Exchange 2000 Server (a) ----- 6.0.4417 --- Jan-11
Microsoft Exchange 2000 Server SP1 --- 6.0.4712 --- Jul-11
Microsoft Exchange 2000 Server SP2 --- 6.0.5762 --- Dec-11
Microsoft Exchange 2000 Server SP3 --- 6.0.6249 --- Aug-11
Microsoft Exchange 2000 Server SP3 --- 6.0.6487 --- Sep-11
Microsoft Exchange 2000 Server SP3 --- 6.0.6556 --- Apr-11
Microsoft Exchange 2000 Server SP3 --- 6.0.6603 --- Aug-11
Microsoft Exchange Server 2003 ---------- 6.5.6944 --- Oct-11
Microsoft Exchange Server 2003 SP1 --- 6.5.7226 --- May-11
Microsoft Exchange Server 2003 SP2 --- 6.5.7638 --- Oct-11

Microsoft Exchange Server 2007 ---------- 8.0.685.25 --- Dec-11
Microsoft Exchange Server 2007 SP1 --- 8.1.0240.006 --- Nov-11

What is Back Pressure in Exchange Server 2010

Microsoft Exchange Server 2010 Hub Transport and Edge Transport server role uses Back Pressure feature for system resource monitoring. Back Pressure monitors system resources like hard disk space and memory. If system resource utilization exceeds the specified limit, the Exchange server stops receiving new messages.

In Exchange Server 2007, when a Hub Transport or Edge Transport server resources are highly used, any new incoming connections are rejected. This has been changed in Exchange Server 2010 where incoming connections are accepted, but incoming messages are accepted at slower rate or are rejected.

There are three back pressure levels:-

· Normal means resource not overused. The server accepts new connections and messages.

· Medium means resource slightly overused. Back pressure is applied to the server in a limited manner. Mail from senders in the authoritative domain can flow. However, the server rejects new connections and messages from other sources.

· High means resource highly overused. Full back pressure is applied. All message flow stops, and the server rejects all new connections and messages.

1 AD Site, 1 DAG = no DAC

So as the TechNet article (Understanding Datacenter Activation Coordination Mode) explains you can’t enable DAC mode in Exchange Server 2010 for a DAG where all members are in the same AD site… So what happens if you lose your primary data centre where your Witness Server is located and you do have a single DAG spanning 2 data centres with all members in the same AD site?

First – work out if the loss is permanent. If it’s not it might be worth waiting until the data centre is back – that way you can probably avoid the risk of split brain since you can shutdown the remaining DAG members and wait for a managed recovery. If it is permanent then you have to do a bit of work – nothing that is going to take you too long but it’s not as simple as running a couple of PowerShell commandlets; and you have to consider what happens if you cannot manage the recovery of the lost DAG members – it is likely that you will have to do a full seed as opposed to an incremental reseed as at a minimum there is likely to be divergence which the store may not be able to recover from. The steps that worked for me in our test rig are as follows:

• Bring the cluster online - “net start clussvc /forcequorum”
• Evict the lost cluster nodes (I used cluster manager)
• Update the DAG membership by removing the failed servers - “Remove-DatabaseAvailabilityGroupServer –id <DAG> -mailboxserver <server> -configurationonly>”
• Create a new Witness Directory - “Set-DatabaseAvailabilityGroup –id <DAG> -witnesserver <server>”
• Reboot the remaining DAG members (might get away with restarting the cluster service and\or the information store and mounting the database)
• Databases should mount automatically according to AutoDatabaseMountDial

The better news is that Exchange Server 2010 SP1 is hopefully going to change the game. As Scott Schnoll writes…

“DAC mode has been extended to support DAGs that have all members deployed in a single Active Directory site, including Active Directory sites that have been extended to multiple locations.”

(http://blogs.technet.com/scottschnoll/archive/2010/04/10/new-high-availability-features-in-exchange-2010-sp1.aspx)

Take notice of the note that accompanies the blog though:

But a quick note: everything in this post is based on pre-release software and preliminary information that is subject to change. These are things we are working on or are about to work on. The feature names, behaviors and descriptions used below might not be the final names, behaviors and descriptions. The behvaiors described may or may not make it into the final shipping version of SP1 or a future version of the product. Standard disclaimers apply regarding pre-Beta software and content.”

The other idea that was given to me to avoid split brain and the need for a full seed in the event of failback is to mark the databases not to mount at startup. This means that where you cannot manage the startup of the lost DAG members the databases will not mount. Unfortunately this prevents automated failover where there is data loss but where the lost logs are within AutoDatabaseMountDial since the replicas will not be activated and get left in a failed state. Nice idea but didn’t work in my testing..

How to find out which domain controller i'm talking to?

To find out which domain controller your PC is talking to, use the following command:

nltest /dsgetdc:domainname.local



This is very handy when testing your active directory sites and services topology to ensure it is setup correctly. If you want to understand the process in which a client computer locates its domain controller please see this post:

http://clintboessen.blogspot.com/2010/05/how-clients-locate-domain-controllers.html

How to Enable Mailtips In Exchange 2010

If you are not up to speed on Mailtips I suggest you reading this article by the MS Exchange Team:

http://msexchangeteam.com/archive/2009/04/28/451193.aspx

To enable Mail Tips you need to use powershell with the Set-OrganizationConfig cmdlet. There are various components of mailtips you can enable or disable.

- MailTipsAllTipsEnabled. Controls whether MailTips are enabled. The default is $True.

- MailTipsExternalRecipientTipsEnabled. Controls whether MailTips for external recipients are enabled. The default is $False. External recipients are determined by reference to the accepted domains list. Any domain in this list is deemed internal; any other domain is deemed external.

- MailTipsGroupMetricsEnabled. Controls whether MailTips that depend on group sizes are enabled. The default is $True.

- MailTipsLargeAudienceThreshold. Controls the threshold for the number of recipients on a message before MailTips flags it as large. The default value is 25. This value is probably too low for large organizations, where big distribution groups are common. In this scenario, it makes sense to increase the value to 50 to stop MailTips from nagging users for no good reason.

- MailTipsMailboxSourcedTipsEnabled. Controls whether MailTips that depend on mailbox data such as out-of-office notices are enabled. The default is $True

Note: If all are enabled, it will increase load on your client access servers by 5%.

Detach Mailbox from User Account

To Detach or Disconnect a Exchange Mailbox from a user account use Disable-Mailbox in powershell. This removes the exchange attributes from the user account in Active Directory.

To reattach the mailbox to another user account use Connect-Mailbox

You can also permanently delete a disconnected mailbox at any time by using the Remove-Mailbox cmdlet in the Exchange Management Shell

Use the Clean-MailboxDatabase cmdlet to scan the Active Directory directory service for disconnected mailboxes that are not yet marked as disconnected in the Microsoft Exchange store and update the status of those mailboxes in the Exchange store

Flush Transaction Logs in Exchange

This article applies to all versions of Exchange from 5.5 to 2010.

The following knowledge base article gives you all the fruit about flushing transaction logs but I assume you just want to know how to do it right?

http://support.microsoft.com/kb/240145

Your Exchange Logs get deleted when your database backup completes. When your exchange server receives an email it dumps the email to the transaction logs. When the exchange server free's up it then plays these logs into the database. Sometimes Exchange may not have played all the log files into the database, so you cant simply "delete" them.

1. Dismount the all Exchange Mailbox Databases under the Storage Group you wish to clean up.

2. Use the ESEUTIL program to view if all the logs have been played into the Exchange Database.

eseutil /MH database.edb



If all the databases are in a Clean Shutdown or Consistent state, you may remove all the transaction logs. Older versions say "Consistent", New Versions of Exchange say "Clean Shutdown". In my screenshot I'm using Exchange 2010.

Note: If it is not in a "Clean Shutdown" or "Consistent" state, you can use eseutil to reply the log files into the database or remount the database and allow Exchange to replay them.
Caution: Do not delete log files if the state is not "Clean Shutdown" or "Consistent" as you will loose email!

3. Delete all log files including the chk file. The checkpoint file keeps track of which log files have been and have not been played into the database. Since there are no log files anymore, the checkpoint is not needed.

Caution: If your database is in the same directory as your log files be careful you dont accidently delete your edb database file as well!

4. Re-mount your exchange databases in your storage group. This will automatically create a new checkpoint file ready to go!

A quick way to determine your bridgehead servers?

You want to determine which bridgehead servers have been elected in each Active Directory site to troubleshoot replication issues?

Use the following command:

repadmin /bridgeheads

Outlook does not Redirect to Exchange 2010 SP1 CAS Array

Problem:

You have a single Exchange 2010 SP1 server "Ex2010.domain.local" running HT, MBX and CAS roles. You move a mailbox from the Exchange 2010 SP1 install to a new Exchange 2010 SP1 CAS Array installation "CASArray01.domain.local".

Outlook 2003, 2007 and 2010 will still points at the mailbox "Ex2010.domain.local", it will not automatically update and point at "CASArray01.domain.local". This is because the RPC CA service doesn't respond with a "ecWrongServer" like previous versions of Exchange did.

Microsoft is aware of this issue however their is no easy resolution in terms of a little code tweak.

How do I prevent this from happening:

Microsoft has been telling customers for a long time to always create a CAS Array even if they have one server - they need a one server array. If all servers single servers were setup in an Array from the beginning this problem would not exist.

Is there a way to force all Outlook clients to automatically perform a full re-autodiscover and attach to the new server?

Yes - if you remove the "Host A" record from DNS for the old Exchange 2010 server old Exchange 2010 server "Ex2010.domain.local" the Outlook clients should do a full re-autodiscover and attach to the new CAS array "CASArray01.domain.local" automatically.

This however is generally impractical especially when you want to stage your mailbox move slowly instead of attempt the big bang approach where all mailboxes are moved in one hit. For small server migrations this is a workable solution.

Is there another work around other then removing a Host A record from DNS?

Yes - create a PRF (Outlook Profile) configuration file to automatically update Outlook to point to the new server. You will need to script this out to ensure it automatically runs on all workstations.

http://technet.microsoft.com/en-us/library/cc179062.aspx

Please look at this article for information on pushing these settings via Group Policy or Script:

http://www.howto-outlook.com/howto/deployprf.htm

DO NOT USE - Outlook Cached Exchange Mode

Cached Exchange Mode is the process of when 2003/2007/2010 downloading a copy of the users mailbox and storing it locally on their workstation. This means all emails opened by the user from there onwards does not hit the Exchange servers significantly reducing load.

Many clients however still disabled cached Exchange mode on their users workstations. When asking them "why", their answer is always:

Because we need the user can access the most updated address book when they click the global address book.

If your company has this requirement this doesn't mean you need to disable Cached Exchange Mode. You can configure a registry key on your clients to simply keep the address book in online mode.

For more information on this key for Outlook 2003/2007/2010 please see:

http://support.microsoft.com/kb/841273

Generally the only time you want to disable cached exchange mode is if your users run on a terminal services or Citrix shared environment where you do not want a copy of EVERY users mailbox downloaded and stored locally on the terminal server!

Can’t send a Calendar sharing message

When you think you’ve covered the basics. This is one of those cases where a reader was part way through implementing Federated Free/Busy and Calendar Sharing between Exchange On-Premises and Live@EDU using the instructions in my guide, and when trying to share a calendar from an on-premises mailbox to a Live@EDU mailbox:

Hi Steve
Sorry - I'm stuck with this. Do you mind me bothering you some more?
I've set it all up, and sent my colleague (who has a 2010 mailbox) a calendar sharing offer and request from my admin@live.contoso.edu mailbox.
I've set his external email address on Live to in1150@exch.contoso.edu.
The invitation is delivered fine. If he opens the calendar of admin@live.contoso.edu from the message, he can see it, and it gets updated dynamically. However, when he tries to share his calendar with admin@live.contoso.edu (using the request in the message), he gets an error message:

This is very odd, because sharing is definitely set up with our domain…

That error again, for the benefit of anyone else experiencing this – “Your organization is not set up for secure sharing with this recipient”.

The first thing we did was check the basics for sharing were setup correctly which they were, but on further inspection and investigation into the Exchange On-Premises environment, the solution was pretty simple. For sharing to work you need to set the ExternalURL for the Exchange Web Services (EWS) virtual directory.
To set the ExternalURL attribute on the EWS Virtual Directory, use the following command against each of the Client Access Servers providing the facility to Internet clients, replacing servername and mail.contoso.edu with appropriate values for your organization:

Set-WebServicesVirtualDirectory -Identity "servername\EWS (Default Web Site)" -ExternalUrl https://mail.contoso.edu/EWS/Exchange.asmx

Windows 8 to Feature a Patten Logon Screen

 
Some clever guys working for MyDigitalLife have done it again, this article is going to uncover another brand new screen shots of the upcoming Windows 8. Well, some users have managed to show us a pattern logon screen of Windows 8 that looks some what similar to the authentication system we’ve got in Android OS. We all know very well that Windows 8 has been in spot light for couple of weeks and then disappeared in the thin air. This may have held because people were unable to reveal anything about it but not for so long. What we saw previously was that, MDL forum members managed to discover numerous hidden features like, Ribbon UI that will be supporting Internet Explorer, Advanced Task Manager, Native PDF Viewer and Native Webcam Apps.
 

The uncovered pattern logo screen is definitely targeted at touch screen users though you can also operate it with your mouse connected to a USB port or something. Basically, this operating system is being designed from the ground-up and making multi-tasking work an easy task for all the users. Did you know that, this would be very first time, a version of Windows will be supporting ARM chipsets, which has the potential to carry on with handheld devices, including tablets. Other features include a more touch screen simplified task manager and an all new Internet Explorer. What this Immerse Internet Explorer does is, it makes the usage out of your desktop Trident rendering engine but this version of Windows is to be offering you a tile-based user interface, you may get a quick handy clue about it if you have seen an IE for Windows Phone 7, do check it out.

The company seems already saddened over the undesirability of Windows 7 which was meant to be launched as a tablet operating system. Once again, it is very clear to us that Android is the only available operating system that can go on and compete with iOS. Certainly, If Microsoft thinks that they would cling on top of the chart by just integrating bits and pieces of Metro and Ribbon then they’re largely mistaken, Android has overwhelmed most of the companies by its performance and holds an upper hand. Mean while, Windows M3 was released to only trusted partners on 29th March. We would certainly be getting a good clear idea about Windows 8, if things don’t stop leaking over the Internet. For now on, you can check out this new Windows 8 logon screen video and judge it yourself.

Windows 2008/R2 & SysPrep - Still Necessary

Most people are virtualizing these days. One of the great things about virtualization is that you can create a VHD of your guest and clone it for very fast build outs. But, despite what Microsoft has been coming out and saying, you STILL need to SysPrep your machine AND make sure to check the 'generalize' option before making a clone of your .VHD. (I recently made the mistake of not checking the 'generalize' option when doing SysPrep, and it essentially made it pointless.) If you don't, and especially if you create a domain controller from this image, you will have all kinds of weird things happen to you without it throwing any errors. Things such as not being able to add domain accounts to local user groups (it will show a weird SID name'd version of the account/group, and it will then disappear when clicking ok or apply) as well as failure for authentication, etc. It will drive you up the wall, so be careful!

Here are the instructions for SysPrep;

1) Run Sysprep (on Windows Server 2008 this is located in c:\Windows\System32\Sysprep\Sysprep.exe)
2) Ensure ‘System Out-of-Box Experience (OOBE)’ is selected
3) Tick the ‘Generalize’ option (this resets the SID)
4) Select ‘Shutdown’ from the Shutdown Options.
5) Once the machine has shutdown, take your image and you are good to go!

Exchange 2010 High Availability Misconceptions Addressed

I’ve recently returned from TechEd North America 2011 in Atlanta, Georgia, where I had a wonderful time seeing old friends and new, and talking with customers and partners about my favorite subject: high availability in Exchange Server 2010. In case you missed TechEd, or were there and missed some sessions, you can download slide decks and watch presentations on Channel 9.

While at TechEd, I noticed several misconceptions that were being repeated around certain aspects of Exchange HA. I thought a blog post might help clear up these misconceptions.

Exchange 2010 High Availability and Site Resilience Terminology

But first let’s start with some terminology to make sure everyone understands the components, settings and concepts I’ll be discussing.

Term	Description	How Configured
Activation	The process of making a passive database copy into an active database copy.	Move-ActiveMailboxDatabase cmdlet
Activation Suspended or Blocked	The process of suspending or blocking a single database or an entire server from automatic activation.	Suspend-MailboxDatabaseCopy or Set-MailboxServer cmdlets
Active Manager	An internal Exchange component which runs inside the Microsoft Exchange Replication service that is responsible for failure monitoring and corrective action within a DAG.	N/A
Alternate Witness Directory	An optional property of a DAG that specifies the name of the directory that is shared on the Alternate Witness Server for quorum purposes.	Set-DatabaseAvailabilityGroup cmdlet or Exchange Management Console (EMC)
Alternate Witness Server	An optional property of a DAG that specifies the witness server that will be used by DAG after you have performed a datacenter switchover.	Set-DatabaseAvailabilityGroup cmdlet or EMC
Attempt Copy Last Logs (ACLL)	A process performed during Best Copy Selection in which the system attempts to copy from the original active database copy any log files missing by the passive copy selected for activation.	N/A
AutoDatabaseMountDial	Property setting of a Mailbox server that determines whether a passive database copy will automatically mount as the new active copy, based on the number of log files missing by the copy being mounted.	Set-MailboxServer cmdlet
Best Copy Selection (BCS)	A process performed by Active Manager to determine the best passive mailbox database copy to activate either in response to a failure affecting the active mailbox database copy, or as a result of an administrator performing a targetless switchover.	N/A
Continuous Replication Block Mode	A form of continuous replication that replicates blocks of ESE transaction data between the ESE log buffers on the active mailbox database copy to replication log buffers on one or more passive mailbox databases copies.	N/A – not configurable The system automatically switches between file mode and block mode based on the passive copy’s ability to keep up with continuous replication.
Continuous Replication File Mode	A form of continuous replication that replicates closed transaction log files from the active mailbox database copy to one or more passive mailbox database copies.	N/A – not configurable
Datacenter	In Exchange, typically this refers to an Active Directory site; however, it can also refer to a physical site.  In the context of this blog post, datacenter equals Active Directory site.	N/A
Datacenter Activation Coordination (DAC) Mode	A property of the DAG setting that, when enabled, forces starting DAG members to acquire permission in order to mount databases.	Set-DatabaseAvailabilityGroup cmdlet
Datacenter Activation Coordination Protocol (DACP)	A bit in memory (0 or 1) that is used by DAG members in DAC mode. A value of 0 indicates the DAG member cannot mount databases; a value of 1 indicates the DAG member can mount active databases that it currently hosts.	N/A – Automatically used when the DAG is configured for DAC mode.
Datacenter Switchover	The manual process performed to activate the Exchange components of a standby datacenter and restore Exchange service and data after failure of a primary datacenter.	Process documented in Datacenter Switchovers.
Failover	The automatic process performed by the system in response to a failure affecting one or more active mailbox database copies.	N/A – Happens automatically by the system; although you can activation-block or suspend individual mailbox database copies or an entire DAG member.
File Share Witness	A cluster-managed resource that is created and use when the cluster uses the node and file share majority quorum model.	N/A – Automatically created and destroyed by Exchange, as needed, based on the number of DAG members.
Incremental Resync	A built-in process that corrects certain forms of divergence that occur between mailbox database copies in a DAG (typically between a new active copy and the previous active copy).	N/A – Happens automatically by the system
Lossy Failover	A database failover condition in which the passive copy being activated is mounted with one or more log files missing.	Partially controlled via AutoDatabaseMountDial
Primary Active Manager (PAM)	An Active Manager role held by a single DAG member at any given time that is responsible for responding to failures an initiating corrective action in the form of a database or server failover.	N/A – The PAM role is automatically held by the DAG member that owns the cluster’s core resource group.
Quorum	Has a dual meaning: Refers to the consensus model used by members of a cluster to ensure consistency within the cluster. Exchange uses two of the four cluster quorum models: Node Majority (for DAGs with an odd number of members) Node and File Share Majority (for DAGs with even number of members) Refers to the data (e.g., “quorum data”) shared by the cluster members that is used to maintain quorum	N/A – Automatically configured by Exchange, as needed, based on the number of DAG members.
RPCClientAccessServer	A property of a Mailbox database that specifies the Client Access server or Client Access server array through which MAPI/RPC clients (Outlook 2003, Outlook 2007, Outlook 2010) access their mailboxes on that database.	Set-MailboxDatabase cmdlet
Site	Active Directory Site, which is defined as one or more fast, reliable and well-connected (< 10 ms latency) subnets.	N/A – Configured outside of Exchange by using Active Directory Sites and Services
Split Brain	A condition in which multiple cluster members believe they are authoritative for one or more common resources.	N/A
Standby Active Manager (SAM)	An Active Manager role held by all DAG members that do not hold the PAM role that is responsible for monitoring for local failures and responding to queries from CAS and Hub as to the location of the user’s mailbox database.	N/A – The SAM role is automatically held by the DAG members that do not own the cluster’s core resource group.
StartedMailboxServers	A list of DAG members that are currently operational and functional.	Automatically added to list during normal operations Manually added to list as part of re-activation of primary datacenter using Start-DatabaseAvailabilityGroup cmdlet
StoppedMailboxServers	A list of DAG members that have been marked as non-operational or non-functional.	Automatically added to list during normal operations Manually added to list as part of activation of second datacenter using Stop-DatabaseAvailabilityGroup cmdlet
Switchover	In the context of a single database, it is the manual process used to move the active mailbox database copy to another server. In the context of an entire server, it is the manual process used to move all active mailbox database copies from one server to one or more other servers.	Move-ActiveMailboxDatabase cmdlet
Targetless Switchover	A switchover process in which the administrator does not specify which passive mailbox database copy should become active, but instead allows Active Manager’s BCS process to choose the best copy to activate.	Move-ActiveMailboxDatabase cmdlet (specifically without using the TargetServer parameter)
Transport Dumpster	A feature of the Hub Transport role that retains copies of messages sent to users on replicated mailbox databases in a DAG so that messages can be recovered by the system in the event of a lossy failover of the user’s database.	Set-TransportConfig cmdlet or EMC
Witness Directory	A required property of every DAG that specifies the name of the directory that is shared on the Witness Server for quorum purposes.	Set-DatabaseAvailabilityGroup cmdlet or EMC
Witness Server	A required property of every DAG that specifies the server external to the DAG that should be used as a participant in quorum for the DAG’s underlying cluster when the DAG contains even number of members.	Set-DatabaseAvailabilityGroup cmdlet or EMC

OK, that’s enough terms for now. 

Exchange 2010 High Availability and Site Resilience Misconceptions

Now let’s discuss (and dispel) these misconceptions, in no particular order.

Misconception Number 1: The Alternate Witness Server (AWS) provides redundancy for the Witness Server (WS)

The actual name – Alternate Witness Server – originates from the fact that its intended purpose is to provide a replacement witness server for a DAG to use after a datacenter switchover. When you are performing a datacenter switchover, you’re restoring service and data to an alternate or standby datacenter after you’ve deemed your primary datacenter un-usable from a messaging service perspective.

Although you can configure an Alternate Witness Server (and corresponding Alternate Witness Directory) for a DAG at any time, the Alternate Witness Server will not be used by the DAG until part-way through a datacenter switchover; specifically, when the Restore-DatabaseAvailabilityGroup cmdlet is used.

The Alternate Witness Server itself does not provide any redundancy for the Witness Server, and DAGs do not dynamically switch witness servers, nor do they automatically start using the Alternate Witness Server in the event of a problem with the Witness Server.

The reality is that the Witness Server does not need to be made redundant. In the event the server acting as the Witness Server is lost, it is a quick and easy operation to configure a replacement Witness Server from either the Exchange Management Console or the Exchange Management Shell.

Misconception Number 2: Microsoft recommends that you deploy the Witness Server in a third datacenter when extending a two-member DAG across two datacenters

In this scenario, you have one DAG member in the primary datacenter (Portland) and one DAG member in a secondary datacenter (Redmond). Because this is a two-member DAG, it will use a Witness Server. Our recommendation is (and has always been) to locate the Witness Server in the primary datacenter, as shown below.

Figure 1: When extending a two-member DAG across two datacenters, locate the Witness Server in the primary datacenter

In this example, Portland is the primary datacenter because it contains the majority of the user population. As illustrated below, in the event of a WAN outage (which will always result in the loss of communication between some DAG members when a DAG is extended across a WAN), the DAG member in the Portland datacenter will maintain quorum and continue servicing the local user population, and the DAG member in the Redmond datacenter will lose quorum and will require manual intervention to restore to service after WAN connectivity is restored.

Figure 2: In the event of a WAN outage, the DAG member in the primary datacenter will maintain quorum and continue servicing local users

The reason for this behavior has to do with the core rules around quorum and DAGs, specifically:

• All DAGs and DAG members require quorum to operate. If you don’t have quorum, you don’t have an operational DAG. When quorum is lost, databases are dismounted, connectivity is unavailable and replication is stopped.
• Quorum requires a majority of voters to achieve a consensus.Thus, when you have an even number of members in a DAG, you need an external component to provide a weighted vote for one of the actual quorum voters to prevent ties from occurring.
• In a Windows Failover Cluster, only members of the cluster are quorum voters. When the cluster is one vote away from losing quorum and the Witness Server is needed to maintain quorum, one of the DAG members that can communicate with the Witness Server places a Server Message Block (SMB) lock on a file called witness.log that is located in the Witness Directory. The DAG member that places the SMB lock on this file is referred to as the locking node. Once an SMB lock is placed on the file, no other DAG member can lock the file.
• The locking node then acquires a weighted vote; that is, instead of its vote counting for 1, it counts for 2 (itself and the Witness Server).
• If the number of members that can communicate with the locking node constitutes a majority, then the members in communication with the locking node will maintain quorum and continuing servicing clients. DAG members that cannot communicate with the locking node are in the minority, and they lose quorum and terminate cluster and DAG operations.
• The majority formula for maintaining quorum is V/2 + 1, the result of which is always a whole number. The formula is the number of voters (V) divided by 2, plus 1 (for tie-breaking purposes).

Going back to our example, consider the placement of the Witness Server in a third datacenter, which would look like the following: 

Figure 3: Locating the Witness Server in a third datacenter does not provide you with any different behavior

The above configuration does not provide you with any different behavior. In the event WAN connectivity is lost between Portland and Redmond, one DAG member will retain quorum and one DAG member will lose quorum, as illustrated below: 

Figure 4: In the event of a WAN outage between the two datacenters, one DAG member will retain quorum

Here we have two DAG members; thus two voters. Using the formula V/2 + 1, we need at least 2 votes to maintain quorum. When the WAN connection between Portland and Redmond is lost, it causes the DAG’s underlying cluster to verify that it still has quorum.

In this example, the DAG member in Portland is able to place an SMB lock on the witness.log file on the Witness Server in Olympia. Because the DAG member in Portland is the locking node, it gets the weighted vote, and now therefore holds the two votes necessary to retain quorum and keep its cluster and DAG functions operating.

Although the DAG member in Redmond can communicate with the Witness Server in Olympia, it cannot place an SMB lock on the witness.log file because one already exists. And because it cannot communicate with the locking node, the Redmond DAG member is in the minority, it loses quorum, and it terminates its cluster and DAG functions. Remember, it doesn’t matter if the other DAG members can communicate with the Witness Server; they need to be able to communicate with the locking node in order to participate in quorum and remain functional.

As documented in Managing Database Availability Groups on TechNet, if you have a DAG extended across two sites, we recommend that you place the Witness Server in the datacenter that you consider to be your primary datacenter based on the location of your user population. If you have multiple datacenters with active user populations, we recommend using two DAGs (also as documented in Database Availability Group Design Examples on TechNet).

Misconception Number 2a: When I have a DAG with an even number of members that is extended to two datacenters, placing the witness server in a third datacenter enhances resilience

In addition to Misconception Number 2, there is a related misconception that extending an even member DAG to two datacenters and using a witness server in a third enables greater resilience because it allows you to configure the system to perform a “datacenter failover.” You may have noticed that the term “datacenter failover” is not defined above in the Terminology section. From an Exchange perspective, there’s no such thing. As a result, no configuration can enable a true datacenter failover for Exchange.

Remember, failover is corrective action performed automatically by the system. There is no mechanism to achieve this for datacenter-level failures in Exchange 2010. While the above configuration may enable server failovers and database failovers, it cannot enable datacenter failovers. Instead, the process for recovering from a datacenter-level failure or disaster is a manual process called a datacenter switchover, and that process always begins with humans making the decision to activate a second or standby datacenter.

Activating a second datacenter is not a trivial task, and it involves much more than the inner workings of a DAG. It also involves moving messaging namespaces from the primary datacenter to the second datacenter. Moreover, it assumes that the primary datacenter is no longer able to provide a sufficient level of service to meet the needs of the organization. This is a condition that the system simply cannot detect on its own. It has no awareness of the nature or duration of the outage. Thus, a datacenter switchover is always a manual process that begins with the decision-making process itself.

Once the decision to perform a datacenter switchover has been made, performing one is a straightforward process that is well-documented in Datacenter Switchovers.

Misconception Number 3: Enabling DAC mode prevents automatic failover between datacenters; therefore, if I want to create a datacenter failover configuration, I shouldn’t enable DAC mode for my DAG

Datacenter Activation Coordination (DAC) mode has nothing whatsoever to do with failover. DAC mode is a property of the DAG that, when enabled, forces starting DAG members to acquire permission from other DAG members in order to mount mailbox databases. DAC mode was created to handle the following basic scenario:

• You have a DAG extended to two datacenters.
• You lose the power to your primary datacenter, which also takes out WAN connectivity between your primary and secondary datacenters.
• Because primary datacenter power will be down for a while, you decide to activate your secondary datacenter and you perform a datacenter switchover.
• Eventually, power is restored to your primary datacenter, but WAN connectivity between the two datacenters is not yet functional.
• The DAG members starting up in the primary datacenter cannot communicate with any of the running DAG members in the secondary datacenter.

In this scenario, the starting DAG members in the primary datacenter have no idea that a datacenter switchover has occurred. They still believe they are responsible for hosting active copies of databases, and without DAC mode, if they have a sufficient number of votes to establish quorum, they would try to mount their active databases. This would result in a bad condition called split brain, which would occur at the database level. In this condition, multiple DAG members that cannot communicate with each other both host an active copy of the same mailbox database. This would be a very unfortunate condition that increases the chances of data loss, and make data recovery challenging and lengthy (albeit possible, but definitely not a situation we would want any customer to be in).

The way databases are mounted in Exchange 2010 has changed. Yes, the Information Store still performs the mount, but it will only do so if Active Manager asks it to. Even when an administrator right-clicks a mailbox database in the EMC and selects Mount Database, it is Active Manager that provides the administrative interface for that task, and performs the RPC request into the Information Store to perform the mount operation (even on Mailbox servers that are not members of a DAG).

Thus, when every DAG member starts, it is Active Manager that decides whether or not to send a mount request for a mailbox database to the Information Store. When a DAG is enabled for DAC mode, this startup and decision-making process by Active Manager is altered. Specifically, in DAC mode, a starting DAG member must ask for permission from other DAG members before it can mount any databases.

DAC mode works by using a bit stored in memory by Active Manager called the Datacenter Activation Coordination Protocol (DACP). That’s a very fancy name for something that is simply a bit in memory set to either a 1 or a 0. A value of 1 means Active Manager can issue mount requests, and a value of 0 means it cannot.

The starting bit is always 0, and because the bit is held in memory, any time the Microsoft Exchange Replication service (MSExchangeRepl.exe) is stopped and restarted, the bit reverts to 0. In order to change its DACP bit to 1 and be able to mount databases, a starting DAG member needs to either:

• Be able to communicate with any other DAG member that has a DACP bit set to 1; or
• Be able to communicate with all DAG members that are listed on the StartedMailboxServers list.

If either condition is true, Active Manager on a starting DAG member will issue mount requests for the active databases copies it hosts. If neither condition is true, Active Manager will not issue any mount requests.

Reverting back to the intended DAC mode scenario, when power is restored to the primary datacenter without WAN connectivity, the DAG members starting up in that datacenter can communicate only with each other. And because they are starting up from a power loss, their DACP bit will be set to 0. As a result, none of the starting DAG members in the primary datacenter are able meet either of the conditions above and are therefore unable to change their DACP bit to 1 and issue mount requests.

So that’s how DAC mode prevents split brain at the database level. It has nothing whatsoever to do with failovers, and therefore leaving DAC mode disabled will not enable automatic datacenter failovers.

By the way, as documented in Understanding Datacenter Activation Coordination Mode on TechNet, a nice side benefit of DAC mode is that it also provides you with the ability to use the built-in Exchange site resilience tasks.

Misconception Number 4: The AutoDatabaseMountDial setting controls how many log files are thrown away by the system in order to mount a database

This is a case where two separate functions are being combined to form this misperception: the AutoDatabaseMountDial setting and a feature known as Incremental Resync (aka Incremental Reseed v2). These features are actually not related, but they appear to be because they deal with roughly the same number of log files on different copies of the same database.

When a failure occurs in a DAG that affects the active copy of a replicated mailbox database, a passive copy of that database is activated one of two ways: either automatically by the system, or manually by an administrator. The automatic recovery action is based on the value of the AutoDatabaseMountDial setting.

As documented in Understanding Datacenter Activation Coordination Mode, this dial setting is the administrator’s way of telling a DAG member the maximum number of log files that can be missing while still allowing its database copies to be mounted. The default setting is GoodAvailability, which translates to 6 or fewer logs missing. This means if 6 or fewer log files never made it from the active copy to this passive copy, it is still OK for the server to mount this database copy as the new active copy. This scenario is referred to as a lossy failover, and it is Exchange doing what it was designed to do. Other settings include BestAvailability (12 or fewer logs missing) and Lossless (0 logs missing).

After a passive copy has been activated in a lossy failover, it will create log files continuing the log generation sequence based on the last log file it received from the active copy (either through normal replication, or as a result of successful copying during the ACLL process). To illustrate this, let’s look at the scenario in detail, starting before a failure occurs.

We have two copies of DB1; the active copy is hosted on EX1 and the passive copy is hosted on EX2. The current settings and mailbox database copy status at the time of failure are as follows:

• AutoDatabaseMountDial: BestAvailability
• Copy Queue Length: 4
• Replay Queue Length: 0
• Last log generated by DB1\EX1: E0000000010
• Last Log Received by DB1\EX2: E0000000006

At this point, someone accidentally powers off EX1, and we have a lossy failover in which DB1\EX2 is mounted as the new active copy of the database. Because E0000000006 is the last log file DB1\EX2 has, it continues the generation stream, creating log files E0000000007, E0000000008, E0000000009, E0000000010, and so forth.

An administrator notices that EX1 is turned off and they restart EX1. EX1 boots up and among other things, the Microsoft Exchange Replication service starts. The Active Manager component, which runs inside this service, detects that:

• DB1\EX2 was activated as part of a lossy failover
• DB1\EX2 is now the active copy
• DB1\EX1 is now a diverged passive copy

Any time a lossy failover occurs where there original active copy may be viable for use, there is always divergence in the log stream that the system must deal with. This state causes DB1\EX1 to automatically invoke a process called Incremental Resync, which is designed to deal with divergence in the log stream after a lossy failover has occurred. Its purpose is to resynchronize database copies so that when certain failure conditions occur, you don’t have to perform a full reseed of a database copy.
In this example, divergence occurred with log generation E0000000007, as illustrated below:

Figure 5: Divergence in the log stream occurred with log E0000000007
 DB1\EX2 received generations 1 through 6 from DB1\EX1 when DB1\EX1 was the active copy. But a failover occurred, and logs 7 through 10 were never copied from EX1 to EX2. Thus, when DB1\EX2 became the active copy, it continued the log generation sequence from the last log that it had, log 6. As a result, DB1\EX2 generated its own logs 7-10 that now contain data that is different from the data contained in logs 7-10 that were generated by DB1\EX1.

To detect (and resolve) this divergence, the Incremental Resync feature starts with the latest log generation on each database copy (in this example, log file 10), and it compares the two different log files, working back in the sequence until it finds a matching pair. In this example, log generation 6 is the last log file that is the same on both systems. Because DB1\EX1 is now a passive copy, and because its logs 7 through 10 are diverged from logs 7 through 10 on DB1\EX2, which is now the active copy, these log files will be thrown away by the system. Of course, this does not represent lost messages because the messages themselves are recoverable through the Transport Dumpster mechanism.

Then, logs 7 through 10 on DB1\EX2 will be replicated to DB1\EX1, and DB1\EX1 will be a healthy up-to-date copy of DB1\EX2, as illustrated below: 

Figure 6: Incremental Resync corrects divergence in the log stream
I should point out that I am oversimplifying the complete Incremental Resync process, and that it is more complicated than what I have described here; however, for purposes of this discussion only a basic understanding is needed.

As we saw in this example, even though DB1\EX2 lost four log files, it will still able to mount as the new active database copy because the number of missing log files was within EX2’s configured value for AutoDatabaseMountDial. And we also saw that, in order to correct divergence in the log stream after a lossy failover, the Incremental Resync function threw away four logs files.
But the fact that both operations dealt with four log files does not make them related, nor does it mean that the system is throwing away log files based on the AutoDatabaseMountDial setting.

To help understand why these are really not related functions, and why AutoDatabaseMountDial does not throw away log files, consider the failure scenario itself. AutoDatabaseMountDial simply determines whether a database copy will mount during activation based on the number of missing log files. The key here is the word missing. We’re talking about log files that have not been replicated to this activated copy. If they have not been replicated, they don’t exist on this copy, and therefore, they cannot be thrown away. You can’t throw away something you don’t have.

It is also important to understand that the Incremental Resync process can only work if the previous active copy is still viable. In our example, someone accidentally shut down the server, and typically, that act should not adversely affect the mailbox database or its log stream. Thus, it left the original active copy intact and viable, making it a great candidate for Incremental Resync.

But let’s say instead that the failure was actually a storage failure, and that we’ve lost DB1\EX1 altogether. Without a viable database, Incremental Resync can’t help here, and all you can do to recover is to perform a reseed operation.
So, as you can see:

• AutoDatabaseMountDial does not control how many log files the system throws away
• AutoDatabaseMountDial is a completely separate process that does not require Incremental Resync to be available or successful
• Incremental Resync throws away log files as part of its divergence correction mechanism, but does not lose messages as a result of doing so

Misconception Number 5: Hub Transport and Client Access servers should not have more than 8 GB of memory because they run slower if you install more than that

This has been followed by statements like:

a Hub Transport server with 16 GB of memory runs twice as slow as a Hub Transport server with 8 GB of memory, and the Exchange 2010 server roles were optimized to run with only 4 to 8 GB of memory.

This misconception isn’t directly related to high availability, per se, but because scalability and cost all factor into any Exchange high availability solution, it’s important to discuss this, as well, so that you can be confident that your servers are sized appropriately and that you have the proper server role ratio.

It is also important to address this misconception because it’s blatantly wrong. You can read our recommendations for memory and processors for all server roles and multi-role servers in TechNet. At no time have we ever said to limit memory to 8 GB or less on a Hub Transport or Client Access server. In fact, examining our published guidance will show you that the exact opposite is true.
Consider the recommended maximum number of processor cores we state that you should have for a Client Access or Hub Transport server. It’s 12. Now consider that our memory guidance for Client Access servers is 2 GB per core and for Hub Transport it is 1 GB per core. Thus, if you have a 12-core Client Access server, you’d install 24 GB of memory, and if you had a 12-core Hub Transport server, you would install 12 GB of memory.

Exchange 2010 is a high-performance, highly-scalable, resource-efficient, enterprise-class application. In this 64-bit world of ever-increasing socket and core count and memory slots, of course Exchange 2010 is designed to handle much more than 4-8 GB of memory.
Microsoft’s internal IT department, MSIT knows first-hand how well Exchange 2010 scales beyond 8 GB. As detailed in the white paper, Exchange Server 2010 Design and Architecture at Microsoft: How Microsoft IT Deployed Exchange Server 2010, MSIT deployed single role Hub Transport and Client Access servers with 16 GB of memory.

It has been suggested that a possible basis for this misconception is a statement we have in Understanding Memory Configurations and Exchange Performance on TechNet that reads as follows:

Be aware that some servers experience a performance improvement when more memory slots are filled, while others experience a reduction in performance. Check with your hardware vendor to understand this effect on your server architecture.

The reality is that, the statement is there because if you fail to follow your hardware vendor’s recommendation for memory layout, you can adversely affect performance of the server. This statement, while important for Exchange environments, has nothing whatsoever to do with Exchange, or any other specific application. It’s there because server vendors have specific configurations for memory based on a variety of elements, such as chipset, type of memory, socket configuration, processor configuration, and more. By no means does it mean that if you add more than 8 GB, Exchange performance will suffer. It just means you should make sure your hardware is configured correctly.

As stated in the article, and as mentioned above:

• Our memory sizing guidance for a dedicated Client Access server role is 2GB/core.
• Our memory sizing guidance for a dedicated Hub Transport server role is 1GB/core.

Misconception Number 6: A Two-Member DAG is designed for a small office with 250 mailboxes or less

This misconception is really related more to Misconception Number 5 than to high availability, because again it’s addressing the scalability of the solution itself. Like Misconception Number 5, this one is also blatantly wrong.

The fact is, a properly sized two-member DAG can host thousands of mailboxes, scaling far beyond 250 users. For example, consider the HP E5000 Messaging System for Exchange 2010, which is a pre-configured solution that uses a two-member DAG to provide high availability solutions for customers with a mailbox count ranging from 250 up to 15,000.

Ultimately, the true size and design of your DAG will depend on a variety of factors, such as your high availability requirements, your service level agreements, and other business requirements. When sizing your servers, be sure to use the guidance and information documented in Understanding Exchange Performance, as it will help ensure your servers are sized appropriately to handle your organization’s messaging workload.

What Have You Heard?

Have you heard any Exchange high availability misconceptions? Feel free to share the details with me in email. Who knows, it might just spawn another blog post!

For More Information

For more information on the high availability and site resilience features of Exchange Server 2010, check out these resources:

Blogcasts

• High Availability in Exchange Server 2010, Part 1
• High Availability in Exchange Server 2010, Part 2
• High Availability in Exchange Server 2010, Part 3
• High Availability in Exchange Server 2010, Part 4

TechNet Documentation

• Understanding High Availability and Site Resilience
• Understanding Database Availability Groups
• Understanding Mailbox Database Copies
• Understanding Active Manager
• Understanding Datacenter Activation Coordination Mode
• Database Availability Group Design Examples
• Database Copy Layout Design
• Planning for High Availability and Site Resilience
• Deploying High Availability and Site Resilience
• Managing High Availability and Site Resilience
• Switchovers and Failovers
• Datacenter Switchovers

TechEd Presentations

• EXL312 Designing Microsoft Exchange 2010 Mailbox High Availability for Failure Domains – TechEd North America 2011
• EXL327 Real-World Site Resilience Design in Microsoft Exchange Server 2010?– TechEd North America 2011
• EXL401 Exchange Server 2010 High Availability Management and Operations – TechEd North America 2011
• UNC401 Microsoft Exchange Server 2010: High Availability Deep Dive (including changes introduced by SP1) – TechEd Europe 2010
• UNC302 Exchange Server 2010 SP1 High Availability Design Considerations – TechEd New Zealand 2010

Scott Schnoll