Since its release in 2009, the interest in Exchange 2010 has been fantastic. While working with customers to educate them and prep them for moving to Exchange 2010, we've uncovered some common misconceptions. One trend has to do with misconceptions around the Client Access Server array object, or CAS array object for short. Technical Writer and frequent blogger Scott Schnoll suggested I put pen to paper… err… keys to keyboard (?) when I was commenting on this trend on an internal Microsoft distribution group, so here we are with this post.

I’m not going to go into all of the technical aspects of a CAS array object in this post. That's already been covered wonderfully by Nagesh Magadev in a prior post: Exploring Exchange 2010 RPC Client Access service.

The following list is a collection of truths many customers are not aware of when it comes to the CAS array object which I'll try to demystify. Part 1 will discuss the first three items and l'll cover the last three items in part 2.

1. A CAS array object does not load balance your traffic
2. A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP
3. A CAS array object's fqdn does not need to be part of your SSL certificate
4. A CAS array object should not be resolvable via DNS by external clients
5. A CAS array object should not be configured or changed after creating Exchange 2010 mailbox databases and moving mailboxes into the databases
6. A CAS array object should be configured even if you only have one CAS or a single multi-role server.

Everyone confused? Nice. Let’s try to fix that as best we can by going through each of these one at a time. You'll see some server names throughout this article so why don’t I show you what I’m working with in my lab first?

OK, let's dig in!

1. A CAS array object does not load balance your traffic

A CAS array object performs no load balancing. It's an Active Directory object used to automate some functions within Exchange and that's all. Exchange 2010 documentation says all over the place that it's recommended to use load balancers (LB) to load balance CAS traffic. So what do I mean by saying the CAS array object performs no load balancing?

What you're actually doing with a load balancer is balancing traffic across a pool of CAS or perhaps you could call it an array of CAS - but not the CAS array object itself. The difference is subtle yet distinct; perhaps we didn’t make the names distinct enough to help prevent the confusion in the first place.

The primary reason, and perhaps the only reason, a CAS array object exists is to automatically populate the RpcClientAccessServer attribute of any new Exchange 2010 mailbox database created in the same Active Directory site (as the CAS array object).

The RpcClientAccessServer attribute is used to tell Outlook clients during the profile creation process what server name should be in the profile. That’s pretty much it folks, there's no more magic going on here and once you've created your CAS array object it's simply an object in Active Directory and there's zero load balancing going on at this point in time.

The rest is up to you at this point. It's up to you to:

• Create an ‘A’ record in DNS that'll allow the client machine to resolve the hostname to an IP address. This IP address will most likely be the virtual IP (VIP) of the LB reachable only by internal clients. This VIP is where Outlook or any other MAPI/RPC capable application will then connect to gain access to Exchange 2010 mailbox resources.
• Configure your load balancing solution to pass traffic to the pool of CAS servers by way of the VIP.

The CAS themselves have no idea there is any load balancing happening.

You may also be confused by what can be seen after creating a CAS array object using the New-ClientAccessArray cmdlet or viewing a pre-existing CAS array object using the Get-ClientAccessArray cmdlet.

Here I'm creating a new CAS array object in my lab with the Name CASArray-A, the FQDN of outlook.lab.local, and in the Active Directory site very aptly named Site-A.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields don’t match because the Name is a display name - it's purely cosmetic. It's whatever you want to name it so you know what that CAS array object is being used for. The FQDN is the record you must then create in DNS or else clients will never be able to resolve it to an IP address to connect to. At this point, I’ll remind you that there can be only one CAS array object per Active Directory site.

So why is the Members property populated with two CAS immediately after creation? Didn’t I tell you there's no load balancing going on at this point? It looks kind of like I lied to you doesn’t it?

To be honest, the Members property is a touch misleading. If you didn’t read up on the steps to create a CAS array object you may think you’re done at this stage. You created your CAS array object and you can see two CAS have automatically joined the array. By this time you may be off for a celebratory drink or going down cube-town hallway to steal some cookies from this guy. Not quite yet my friend!

Due to the fact that we associated the CAS array object to Active Directory site Site-A, the cmdlet simply goes and finds all Client Access servers registered as residing in Site-A and then lists them in the Members column. I like to tell customers to think of this column as the Potential Members column or as my colleague Kamal Abburi, another PFE here at Microsoft, suggests it's the Site CAS Members column. You can add these Client Access servers as nodes in your load balancing solution because they all reside in the same Active Directory site. But until the load balancer is configured we have no load balancing.

How did the cmdlets know what site the CAS are in? Well, I’m glad you asked because we get to break out everybody’s best friend AdsiEdit.msc and dig down into the Configuration partition of Active Directory to find the magic beans.

Figure 2: The msExchServerSite attribute of an Exchange 2010 server contains the Active Directory site the server resides in

Each Exchange server has an msExchServerSite attribute that contains the Active Directory site they currently reside in. In case you're wondering, yes it's dynamically updated if you move an Exchange server to a new site and the Microsoft Exchange Active Directory Topology service has a chance to run and update a few things. But the AutoDiscoverSiteScope attribute (Part of Get/Set-ClientAccessServer) will not be dynamically updated and you may have funky Autodiscover results until this is fixed – depending on your site, server, and client layout.

2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP

Let’s go back for a moment to what a CAS array object actually does. It populates the RpcClientAccessServer attribute of an Exchange 2010 mailbox database, which is then used to tell Outlook where it needs to connect when using RPC (over TCP). For Outlook Anywhere (HTTPS) clients, it indicates where the traffic that leaves the RPC-over-HTTP proxy needs to connect on the client’s behalf in order to reach their mailbox.

So what services does the Outlook client attempt to connect to when using RPC (over TCP)?

First Outlook connects to the CAS array object on TCP/135 to communicate with the RPC Endpoint Mapper in order to discover the TCP ports the following two services are listening on.

1. Microsoft Exchange RPC Client Access (aka MSExchangeRPC)
2. Microsoft Exchange Address Book (aka MSExchangeAB)

That’s it for RPC (over TCP) mode!

Outlook Anywhere (aka RPC over HTTP) clients connect to the RPC-over-HTTP proxy component on TCP/443 on a CAS by resolving the Outlook Anywhere external hostname, or what the Outlook profile calls the proxy server.

Interesting geeky side note for anyone interested, Outlook automagically and quietly adds /rpc/rpcproxy.dll to the server name specified, as that’s really what it needs to connect to, but if we asked people to type these names in, like we used to back in Outlook 2003 days, can you imagine how many would have missed it, or got it wrong?)

Figure 3: Specifying the RPC Proxy URL in Outlook 2003

Traffic is routed out of the RPC-over-HTTP proxy to the appropriate MAPI/RPC endpoint using a list of hard-coded, rather than dynamically assigned TCP ports, those being TCP 6001, TCP 6002, and TCP 6004. The Outlook Anywhere external hostname is purposefully not the same FQDN as the CAS array object and I’ll explain why later on.

A client may also make HTTPS connections to services such as Autodiscover, OAB downloads, EWS, POP, or IMAP, but these services are defined by entirely different methods such as virtual directory URLs or the AutoDiscoverServiceInternalUri value. None of these additional services are serviced by the CAS array object as none of them are using RPC, although it’s likely to be the same server they are connecting to. The CAS array object’s FQDN may share the same VIP as the other service’s URLs, but we strongly recommend the CAS array object FQDN not be the same as the other services’ URLs if split DNS is in use. More on that last recommendation later.

3. A CAS array object's FQDN does not need to be part of your SSL certificate name list

This is a very common misconception usually spawned due to the item directly above. SSL certificates in the realm of this article are only utilized when we want to do something like establish an SSL-protected HTTP session. Because RPC (over TCP) is not an HTTP session, it's not going to be protected with SSL and therefore, we don't need the CAS array object's FQDN to be included on the subject name list of the SSL certificate. Let's take a look at it.

Below is Outlook 2010 in MAPI/RPC mode connected to an Exchange 2010 CAS array object.

Figure 4: Outlook 2010 RPC (over TCP) connections to Exchange 2010 CAS

We can see it has made one directory and two mail connections. In the netstat output (overlayed above the screenshot) we see the machine has made one endpoint mapper connection (TCP 135) to the CAS array object as well as connections to TCP 59531 and TCP 59532 which represent the statically assigned TCP ports for the MSExchangRPC and MSExchangeAB services respectively in this lab.

From the server side we can see the services listening using the command netstat –n –b.

Figure 5: Services Outlook needs to connect to when using RPC (over TCP)

As expected, it shows that none of the services are being contacted over HTTP (to TCP 443). This is why you don't need the CAS array object FQDN on the SSL certificate.

Thinking you need the CAS array FQDN on the SSL certificate can sometimes be confused by the way Outlook displays connections while in HTTPS mode as seen below.

Figure 6:Outlook Anywhere connections

This time we see Outlook 2010 has made two mail connections and a Public Folder connection when the screen shot was taken and we can also see we are using HTTPS. From within Outlook it looks as if we are connected to outlook.lab.local and E2K10-MLT-01.lab.local, which we are sort of, but utilizing netstat once again we see we are actually connected to the RPC-over-HTTP proxy located at webmail.lab.local on TCP/443 (HTTPS). Outlook will always display what server is eventually connected to for data by itself or via RPC-over-HTTP proxy. If you're wondering why we see 6 connections via netstat instead of three, it's because HTTP is a half-duplex protocol and we therefore establish an RPC_DATA_IN and an RPC_DATA_OUT channel for each connection seen inside Outlook.

You may also be thinking, “Wait! Outlook 2007 and 2010 encrypt RPC sessions by default! We have to have the name on the cert!” Wrong-O my friends because the encryption setting you see below utilizes RPC encryption and has nothing to do with SSL. The communication is still happening over RPC and not over HTTPS.

Figure 7: When connecting using RPC (over TCP), Outlook uses RPC encryption

Simple isn’t it! If a CAS array object met a Certification Authority and the CA said: “Hey man you really need me! C’mon I’ll sell you a swanky wildcard cert on the cheap!” the CAS array object would simply reply “Honey badger don’t care!” and probably use the CA to crack open a pistachio. Now that's of course if you followed our recommendation to use a different FQDN for the CAS array object than you’re using for the other service FQDN(s). Yes, I’m getting to why…

I hope Part 1 of this article has been helpful to you so far in making sense of some common misunderstood issues with CAS array objects, and hope that you’ll tune in for Part 2 at a later time where we'll cover the remaining three common misconceptions about CAS array objects.

Brian Day
Premier Field Engineer, Messaging

Welcome back! In Demystifying the CAS Array Object - Part 1 we covered these three items to begin demystifying the CAS array object in Exchange Server 2010.

1. A CAS array object does not load balance your traffic
2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP
3. A CAS array object does not need to be part of your SSL certificate

Here in Part 2 we will cover the following three items, and once and for all lift the fog away from the CAS array object to help you correct existing deployments and/or plan more strategically for future deployments.

4. A CAS array object should not be resolvable via DNS by external clients
5. A CAS array object should not be configured or changed after creating Exchange Server 2010 mailbox databases and moving mailboxes into the databases
6. A CAS array object should be configured even if you only have one CAS or a single multi-role server.

4. A CAS array object should not be resolvable via DNS by external clients

As mentioned in Part 1 (at least twice, I stopped counting) your CAS array object FQDN should not be the same FQDN used for other services such as OWA, ECP, EWS, EAS, Autodiscover, or the Outlook Anywhere external hostname.

As mentioned in Part 1 (at least twice, I stopped counting) your CAS array object FQDN should not be the same FQDN used for other services such as OWA, ECP, EWS, EAS, Autodiscover, or the Outlook Anywhere external hostname.

The primary reason for this is Outlook Anywhere clients will first attempt to resolve the CAS array object FQDN via DNS so it knows if it should even bother to attempt a RPC (over TCP) connection or go right to HTTPS. Do you allow RPC (over TCP) connections directly in from the Internet to your Intranet? I hope you don’t, and if you do you’ll be getting a big red flag on your Exchange Risk and Health Assessment Program report. If the client does first attempt to connect via RPC (over TCP) due to being able to successfully resolve the CAS array object FQDN there could be a significant delay before the client falls back to attempt an HTTPS connection to the Outlook Anywhere proxy URL. This delay may result in higher helpdesk call generation if end users perceive this delay as degraded performance and/or the service being broken.

To avoid this situation simply make sure your internal CAS array object FQDN is something unique to internal DNS, perhaps like outlook.corp.contoso.com while your other non-RPC (over TCP) service URLs utilize something like mail.contoso.com internally and externally via split DNS.

If you haven't had the opportunity to utilize split DNS, it is when you have a set of internal AND external DNS servers handling requests for the same forward lookup zone, for example contoso.com. The two DNS infrastructures are completely isolated from each other. There are no zone transfers, nor are they utilizing each other as DNS forwarders. This configuration allows internal users utilizing the internal DNS infrastructure to resolve the host mail.contoso.com to an internal IP address (for example, 192.168.1.10) that goes to your load balancer VIP while external users resolve it to the public IP address which may point to your Internet-facing Forefront TMG/UAG infrastructure in your perimeter network. It's very common for the CAS array object IP address and the internal IP address of the non-RPC (over TCP) service URLs (OWA, ECP, EWS, etc…) to be the same load balancer VIP, but they may utilize different is-alive checks for proper service state detection.

A quick detour if we may to remind you not to forget to configure the proper service health monitors for your load balancing solution. For the best service monitoring results consult with your load balancing solution vendor. Check out Exchange Server 2010 Load Balancer Deployment for a list of the load-balancer vendors who've gone through Exchange 2010 solution testing and links to their relevant web pages (for Exchange 2010). Note, it's *not* a definitive list of supported load balancing vendors in any way. It's simply a list of vendors who've chosen to engage with Microsoft directly for solution testing and support.

A quick and dirty example may be that your HTTPS service based FQDNs have is-alive tests performed against TCP/443 responses and the load balancing solution stops sending new client traffic to any Client Access server which stops responding on TCP/443. The CAS array object RPC (over TCP) service FQDN may have is-alive tests performed on the RPC Endpoint Mapper on TCP/135 as well as the two static TCP ports you chose for RPC Client Access Service and the Address Book service. If any of those three ports stop responding on a particular Client Access server, the load balancing solution will not send new client traffic to that CAS for RPC (over TCP) until all of ports begin responding once again. If you don't configure static TCP ports then Exchange will choose a dynamic TCP port for each service at startup making is-alive testing more difficult if not impossible for some load balancing solutions.

5. A CAS array object should not be configured after creating Exchange Server 2010 databases

Many times we're all in a rush to install the Mailbox servers, have the mailbox databases created, and hopefully begin storage solution validation testing with Jetstress. May I suggest you slow your horses down for a moment and save yourself some trouble later? While Mailbox servers are considered by many to be the most important server role, it's no good to you if the front door is nailed shut because you can’t get to them through Client Access servers.

If you start creating mailbox databases before a CAS array object is in place you'll see a random Client Access server in the same Active Directory site stamped on the RpcClientAccessServer attribute of the each database.

Instead of looking like it should (use the CAS array object's FQDN)

It will look something like this:

Client profiles will look like the following…

Clients will connect like the following…

At first glance this may seem very innocuous and everything will work just fine, but you are setting yourself up for trouble later. If you start to move mailboxes to Exchange Server 2010 with this configuration in place Outlook will use the CAS name in the “Server” field of the user profile. It'll work, unless that Client Access server becomes unavailable or is perhaps decommissioned at a later date and replaced with a differently named server. Wouldn’t you rather be using a load-balanced pool of Client Access servers about the time that happens? ? Yes, you would!

You may think to yourself “Ok smarty pants, if that day ever comes I’ll create a CAS array object and fix RpcClientAccessServer on the databases and life will be good.” I’m here to tell you that will only work for mailboxes you move to Exchange 2010 after the fact. Any user with a pre-existing Outlook profile configured to point to a CAS name and not the CAS array object will continue to connect to the CAS name and it will not update itself to utilize the CAS array object FQDN.

The profile will not update itself because the client will not receive an ecWrongServer response from CAS. It will not receive this response because any CAS is a valid connection point for any mailbox database via RPC (over TCP) so clients can survive datacenter switchover/failover events without being reconfigured and all an admin has to do is flip the CAS array object DNS record to point to a surviving pool of CAS. Currently the only way to fix mailbox profiles would be a manual profile repair within Outlook, by publishing an Office PRF file via GPO (not going to work for non-domain joined machines), or by decommissioning the CAS server named in the users’ profiles so the endpoint is no longer available. This last option should (test test test!!) trigger a full profile repair by Autodiscover in Outlook 2007 or Outlook 2010. Outlook 2003 is only repairable with a profile repair or a PRF file. Autodiscover will not as of this article’s writing update a profile to a new server name as part of the normal Autodiscover process which updates the Outlook Anywhere configuration and discovers EWS URLs for other features such as OOF Management, Free/Busy, and Inbox Rules management.

This also means if you move a mailbox from a database in an AD Site-A that uses a CAS array object named Boston-CASArray to a database in AD Site-B which uses a CAS array object named Redmond-CASArray that the profile will not update and the server name field will remain the Boston-CASArray FQDN is. You may want to keep this in mind if you have a user population that migrates to different sites due to job changes or perform a massive internal mailbox move to another site at some time during the solution lifecycle. If you do find yourself creating Exchange 2010 databases before creating a CAS array object it is imperative that you go back and fix the databases’ RpcClientAccessServer attribute to use the CAS array object before moving mailboxes into the databases.

6. A CAS array object should be configured even if you only have one CAS server or one multi-role server.

Reflect for a moment about what was discussed in the prior item. A client will not update itself to use a CAS array object if you add one at a later time. Well what if you only have one CAS? You may think it doesn’t matter. I guess one could argue it doesn’t matter at that very moment, but why not future proof things if you can and save some cycles and frustration later? What if a year from now you find yourself in need of replacing that CAS? If you’re clients profiles are all pointing to a CAS name then you have no clean way to transition them without some kind of outage or manual work. You will have to repair their profiles with one of the means already mentioned after adding a new CAS, or you will have to decommission the existing CAS and introduce a new CAS with the same hostname which will require some downtime. To me none of those options are acceptable.

What if later on your business requirements change and then dictate you should have client access high availability? You can only achieve this goal by adding a second CAS and a load balancing solution. You will find yourself stuck in the same boat again having to repair everyone’s profile through one of the means already discussed. Again these are not acceptable options to me.

What I would suggest is you create a CAS array object from the very beginning. How do you do that if you have no load balancer and only a single CAS? Simple! Configure the CAS array object like you normally would. Give it a name, an AD site, a FQDN, and then simply point the DNS ‘A’ record to the IP as the only existing CAS or multi-role server you have at that time. You have just future-proofed yourself and if you ever have to replace the single CAS or multi-role server all you have to do is build the new server, and then change the DNS record IP address and everything keeps working without interruption. If you ever want to add high availability at a later time then all you have to do is get your load balancing solution operational and then change the CAS array object DNS record IP address to point at the VIP of the load balancing solution. Easy!

Hopefully this article has been helpful in addressing some of the CAS array object misconceptions and will go a long ways towards helping everyone move towards a healthy Exchange Server 2010 migration.

Brian Day Premier Field Engineer, Messaging

The Exchange team strives to improve our high availability functionality and improve redundancy, particularly in our Exchange Online datacenters. Check out a new episode of Geek Out with Perry where Perry explains how an interesting idea became a research effort and eventually new functionality that’s coming to the world of Exchange Online. We don’t often discuss product roadmap items when they are in the early phases but wanted to share some awesome early information with you all.

We’re excited to give you a sneak peek at new functionality that’s coming your way to help us improve our redundancy and contribute to our green datacenter commitments.

Please continue to Geek Out with Perry, read his blog, send us feedback and let us know if you have some good topics for Perry to geek out on.

Cheers!

Ann Vu

Deploying Exchange can be a challenge. Particularly when you are all ready to validate your servers & storage with Jetstress and you realize that even though we suggest that you should always run Jetstress prior to going into production, you discover that we don’t support running Jetstress in a virtual machine on that fancy new virtual platform you just deployed. Ouch. Now what?

First, some background. You might be wondering why we don’t support running Jetstress in a virtual machine. The reason is actually quite straightforward. Over the years as we have worked with customers and partners who were either deploying new hardware for Exchange or validating Exchange storage solutions in the Exchange Solution Reviewed Program (ESRP), we saw a number of examples of Jetstress test results where the reported IO latency numbers were wildly inaccurate. Given the lack of trust in the reported performance metrics, we had to ensure that Jetstress was not run in this configuration. This resulted in the guidance that customers deploying on virtual infrastructure should validate storage performance by running Jetstress in the root rather than in a guest virtual machine. While this was a feasible workaround with Hyper-V, it’s not a realistic solution for other hypervisors.

Just as the Exchange product has matured, the hypervisor products that some of our customers use to manage their Exchange infrastructure have matured as well, and we decided that the time had come to do some new testing and see if those strange performance results of the past would come to haunt us again. After weeks of automated testing with multiple hypervisors and well over 100 individual Jetstress tests completed in various configurations, we’ve reached a conclusion…

Effective immediately, we support running the Microsoft Exchange Server Jetstress 2010 tool in virtual guest instances which are deployed on one of the following hypervisors:

• Microsoft Windows Server 2008 R2 (or newer)
• Microsoft Hyper-V Server 2008 R2 (or newer)
• VMware ESX 4.1 (or newer)

Additionally, we are removing the restriction in the ESRP v3.0 program on using virtual machines, so from this point on our storage partners will be able to submit ESRP solutions for Exchange Server 2010 where the validation testing was performed on a virtual machine.

As a reminder, the best place to learn about supportability for Exchange Server 2010 virtualization is on TechNet in the Hardware Virtualization section of the System Requirements topic. Additionally, we have published a Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V whitepaper that contains many helpful deployment recommendations. The best resource for understanding how to properly use Jetstress for storage and solution validation is the Jetstress Field Guide, which has been recently updated to include this change to our support for guest virtual machines.

I hope this is good news for some of you and that this will result in simpler, easier, and more thorough pre-production validation of your Exchange deployments.

Jeff Mealiffe
Senior Program Manager
Exchange Customer Experience

I hope those of you who signed up for more information already saw the email about Microsoft Exchange Conference 2012 (MEC) registration. The lost conference is back, taking place September 24-26 in Orlando, Florida at the Gaylord Palms Resort & Convention Center. Kudos to Dan Bobke for narrowing the coordinates down to the lake in Kissimmee in the comments to my last post (see MEC is Back!). I think he may have gotten the closest.

This is the Exchange event you will not want to miss! This will be your best opportunity to go deep on the next major release of Exchange. Going into beta later this summer, Exchange 15 will bring a ton of new capability and value to the table and we’re pumped up to spend the week giving you the end-to-end story of this next release in the family.

At MEC 2012, you will:

• Get exclusive Exchange 15 content directly from the engineering team
• Get hands-on experience with Exchange 15
• Enjoy unparalleled access to Exchange team members, Masters and MVPs
• Preview amazing new products from select vendors
• Build personal relationships throughout the Exchange community

Visit MECisback.com and reserve your spot at MEC 2012 before the opportunity disappears. It is going to be epic!

Michael Atalla
Director, Exchange Product Management

Moving mailboxes is an important part of managing an email service. Check out the latest Geek Out with Perry blog and video to gain some deep insights on our approach to moving mailboxes with Mailbox Replication Service (MRS) and get Perry’s take on this topic and how it works. This technology is also incredibly important if you want to move mailboxes to the cloud on your terms with a hybrid deployment.

Want more details and info?

• Check out Ross’ past blog on mailbox moves and mailbox resiliency
• Read the TechNet info all about Understanding Move Requestswhich also includes information about the client experience during a move request.
• See Hybrid Deployments with the Hybrid Configuration Wizard on TechNet if you’d like to learn about setting up a hybrid deployment in order to move mailboxes to Exchange Online.

Need to Geek Out with Perry some more? Check out his blog and the playlist of videos on YouTube or from the MSN Video catalogue. He recently discussed immutability in Exchange which has been a really hot topic.

Keep on geeking out with us, send us your feedback and let us know if you have good questions for Perry to geek out on.

Ann Vu

In Exchange 2010, we built the Active Directory Rights Management Services (AD RMS) integration functionality introduced in Exchange 2007 into a suite of information protection features known as Information Rights Management (IRM). IRM requires that you have an AD RMS server deployed in your on-premises organization. See Understanding Information Rights Management for more details, including functionality offered by the different IRM features and requirements for each. You can also use IRM features in your Exchange Online organization or a hybrid deployment.

When you install AD RMS, it’s in Cryptographic Mode 1. Cryptographic Mode 1 supports 1024-bit encryption keys for RSA encryption and 160-bit keys for SHA-1 hashing algorithm. To learn more about encryption in AD RMS, see RMS Encryption and Keys.

Late last year the Windows Server team released a significant update to AD RMS that supports a new mode of encryption known as Cryptographic Mode 2. Mode 2 supports stronger encryption by allowing you to use 2048-bit keys for RSA and 256-bit keys for SHA-1. Additionally, Mode 2 enables you to use the SHA-2 hashing algorithm. For more information about cryptographic modes in AD RMS, see Active Directory Rights Management Services Cryptographic Modes.

Cryptographic Mode 2 fulfills cryptography requirements of United States federal government agencies, as recommended by the National Institute of Standards and Technology (NIST). See NIST publication SP 800-57 for details. Many other government and private organizations across the world also follow NIST recommendations. In Windows Server "8" Beta, Cryptographic Mode 2 is the default AD RMS cryptography mode.

We’re working on an update for Exchange 2010 that’ll enable the use of Cryptographic Mode 2 on AD RMS.

Bharat Suneja

Subscribe to the EHLO RSS feed and follow us on Twitter to get the latest announcements on Exchange software updates.

We've made several bug fixes based on community feedback.

Please go to our Mailbox Server Role Storage Requirements Calculator updates tracking page to see what is in this new version!

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

Comments welcome!

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

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

This update contains a number of customer-reported and internally found issues since the release of SP2 RU1. See KB2661854: Description of Update Rollup 2 for Exchange Server 2010 Service Pack 2 for more details.

Note: Some of the following KB articles may not be available at the time of publishing this post.

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

• KB2696913 You cannot log on to Outlook Web App when a proxy is set up in an Exchange Server 2010 environment
• KB2688667 High CPU in W3WP when processing recurrence items who fall on DST cutover
• KB2592398 PR_INTERNET_MESSAGE_ID is the same on messages resent by Outlook
• KB2630808 EwsAllowMacOutlook Setting Not Honored
• KB2661277 Android/Iphones stuck with 451 during Cross forest proxy in datacenter
• KB2678414  Contact name doesn't display company if name fields are left blank

Note that this fix will not cause the CAS to CAS OWA proxying incompatibility with Exchange 2007 as discussed here. No additional updates are required on Exchange 2007 for proxying to work once Exchange 2010 SP2 RU2 is installed.

General Notes:

For DST Changes: http://www.microsoft.com/time.

Note for Forefront Protection for Exchange users  For those of you running Forefront Protection 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.

Exchange Team

Earlier today the Exchange CXP team released Update Rollup 7 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 SP3 RU6. See KB2655203: Description of Update Rollup 7 for Exchange Server 2007 Service Pack 3 for more details.

Note: Some of the following KB articles may not be available at the time of publishing this post.

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

• KB2617514 Include updated version of Portuguese-Brazil speller.
• KB2696649 Exchange 2007sp3/2010 OWA CSRF via Cookie Tossing.
• KB2696628  Read Receipt is still duplicated when connecting IMAP.

Note that this fix will resolve the CAS to CAS OWA proxying incompatibility with Exchange 2010 SP2 RU1 as discussed here.

General Notes:

For DST Changes: http://www.microsoft.com/time.

Support lifecycle statement: This is the final release under standard support for Exchange 2007, as the Exchange 2007 Mainstream Support has now ended. Extended Support for Exchange 2007 SP3 will end on 4/11/2017. Please see the Microsoft Support Lifecycle page for more information about Microsoft Support Lifecycle for Exchange 2007. Got questions about Microsoft Support Lifecycle Policy? Head over to Microsoft Support Lifecycle Policy FAQ.

Note for Forefront Protection for Exchange users  For those of you running Forefront Protection 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.

Exchange Team

This post describes an update to the Facebook provider for the Outlook Social Connector and the related policy settings that are available for Administrators.

Outlook 2010 includes a feature called the Outlook Social Connector which can show social updates for the people your users email with, directly in Outlook. Earlier this year, the Outlook team made an update to enable continued access to Facebook information as Facebook has moved to a new authentication model called OAuth. While making this change the transport has also been updated to use SSL to better secure the information transmitted between Facebook and Outlook.

Note: You do not need to enable the Outlook Social Connector to display GAL Photos in Outlook 2010. For more details, see GAL Photos in Exchange 2010 and Outlook 2010.

Starting on May 1st, 2012, users will see notifications in Outlook to update the Facebook provider for the Outlook Social Connector. If users have a previous version of the Facebook provider installed, the notification will lead the user to the updated version of the Facebook provider on Microsoft Download Center.

Current users of the Facebook provider must install the updated Microsoft Outlook Social Connector Provider for Facebook to avoid errors connecting to Facebook.

Users who don't have the Facebook provider installed but do have the Outlook Social Connector enabled will see a one-time notification that a new social network provider is available.

You can use Group Policy settings to control your user’s experience. For example, you can:

• block the notifications in the People Pane
• block a specific social network provider
• turn off the Outlook Social Connector entirely

To learn more about the available Group Policy settings, see KB 2020103: How to manage the Outlook Social Connector by using Group Policy.

Note: The Outlook Social Connector is also available as a separate download for Outlook 2007 and Outlook 2003. The same notifications and policy settings apply to OSC for Outlook 2007 or Outlook 2003.

The OSC team worked to help protect users' privacy. More details about how data is protected in Learn more about Outlook Social Connector and privacy.

The Outlook team also is blogging about this update. You can read their blog here.

Adam Glick

When we perform network bandwidth planning for Exchange deployments we always ask “what is the size of your OAB?” This is important since if you have a large OAB file it can severely affect the amount of network bandwidth that you require.

One of the things that I noticed while creating and validating the Exchange Client Network Bandwidth Calculator was that many organizations did not know much about their OAB size or placement. This was tricky since I needed to know the size of the OAB so that we could predict how it might affect the network bandwidth requirements for that customer.

I decided that I would start this post to explain what the OABv4 files are, where to find them and how to determine the size of your OABv4 file J

Note: Before we dive in it is important to note here that I am concentrating on OABv4 – this was introduced with Exchange Server 2003 SP2 and Outlook 2003 SP2 (that was a long time ago!). I am hoping that everyone reading this is using OABv4 – if you’re not then it’s probably time you looked at how to upgrade since there are many benefits from OABv4 including additional stability and much better bandwidth usage.

Where is my OAB file?

The OAB file is generated on one of your Exchange Mailbox Servers, to find out which one, we need to take a quick look at the Offline Address Books.

Get-OfflineAddressBook | ft server,guid,AddressLists –AutoSize

In this example I am going to look at the Default Global Address List. The command returns two interesting values for each OAB;

• Server: This is the server that is currently generating the OAB files
• GUID: This is the name of the folder that contains this particular OAB file

To find the actual files, we need to take a look at the server that is generating the OAB file; on that server we need to look in the following folder;

C:\Program Files\Microsoft\Exchange Server\V14\ExchangeOAB\

Inside this folder we need to look for a folder with the name that matches our OAB GUID returned earlier. In this example we are looking for 2b525e9b-6030-428d-adb4-87c8d52df116

In my lab I only have a single OAB file, so it’s pretty easy.

This folder is where your OAB files are stored; if we take a look inside the folder, we can see the files that are used by clients to generate the OAB can be found….

What are all of these files inside my Offline Address Book Folder then?

Now, this is the interesting question! So, we know where our OAB files are, but which files are important?

Let’s take a look at the files we have…

The <sequence> number is iterated each time the OAB is regenerated. If there have been no changes since the last build, there will be no iteration of the sequence number and the clients will not download any patches. You can see from this that my lab has had 4 generations of the OAB.

So which bits do I need for the Exchange Client Network Bandwidth Calculator?

The bandwidth calc asks for two pieces of information about your OAB file:

• Offline Address Book Size
• %GAL Changes per Day

Offline Address Book size is simply the size of your *-DATA-<sequence>.LZX file.

%GAL Changes per Day is a little more complex. Essentially what we are trying to do with this value is determine how much bandwidth we need on a daily basis to keep Outlook’s OAB up to date. To do this we need to take a look at the size of our *-BINPATCH-<sequence>.LZX files;

To do this I have used the dir command from within the OAB directory

dir *binpatch*

This gives us a list of binpatch files; what we need from this is to determine the size of these as a % of the OAB file and then average the changes.

Note: In this example I use a script and or Loadgen to generate large quantities of mailboxes every week so the data is extremely unrepresentative, however the process remains the same for everyone J

For example;

• OAB Size : 984,994 bytes = ( 984994 / ( 1048576 ) ) = 0.93MB
• Patch1 Size: 636,276 = ( 636276 / 984994 ) x 100 = 65%
• Patch2 Size: 291,652 = ( 291652 / 984994 ) x 100 = 30%
• Patch3 Size: 52,748 = ( 52748 / 984994 ) x 100 = 5%
• Average Daily Changes = (65 + 30 + 5) / 3 = 33%

So, for my lab environment I would enter the following values into the network calc.

What about Exchange Server 2003?

Exchange Server 2003 stores its OAB files within public folders. If you are using OABv4 then the same files exist within your system public folders;

• Open Exchange System Manager
• Expand your Administrative Group
• Expand Folders
• Right Click on Public Folders and select View system Folders
• Expand OFFLINE ADDRESS BOOK
• Expand the OAB you are interested in
• Expand OAB version 4
• Click on the Content Tab

Write down the sizes of the OAB files

Once you have the sizes for your files you can follow the instructions for Exchange 2007 and Exchange 2010.

General Curiosities and other stuff…

I thought I would also include some interesting stuff about OAB files J

• OABv4 was introduced with Exchange Server 2003 SP2 and requires both Exchange 2003 SP2 and Outlook 2003 SP2.
• Dave Goldman introduced the new binpatch and OABv4 changes via an EHLO blog post on August 1^st 2005 (anyone else feeling old?)
• If your client MAPI profile is still in non-Unicode mode (MAPI profile hasn’t been re-created after migration from Exchange 5.5!) you will be using OABv2 regardless of what you configure elsewhere.
• The 1/8^th OAB full download rule does not apply to OABv4 – instead a full download due to excessive patch file size is 50% in OABv4
• OAB downloads can be throttled to reduce network bandwidth impact if you need to.

Hopefully this post will help remove some of the ambiguity regarding OAB sizes.

Neil Johnson
Senior Consultant, MCS UK

Properly calculating the SPECint 2006 rate value of your planned mailbox role processors is a critical step in the overall planning and design of your Exchange 2010 architecture. The SPECint 2006 rate value is used by the Mailbox Server Role Requirements Calculator to calculate the adjusted megacycles per processor core and the available per server megacycles of your planned mailbox role servers. This directly correlates to the required number of cores for mailbox, CAS, hub, and global catalog servers.

Today we are releasing version 1.1 of the Processor Query Tool. The PQT can assist you in determining your SPECint 2006 rate value by automating the manual process described in Mailbox Server Role Requirements calculator. The PQT allows you to quickly see the list of all servers that have been tested by the Standard Performance Evaluation Corporation (SPEC) with the same processor model you plan to deploy and the rate values produced by each of those tests.

If your particular server isn’t in the list it means the SPEC didn’t test your exact server model, however you can take advantage of the averaging feature of the PQT. The averaging feature will calculate the overall average SPECint rate value for all servers tested with your planned processor model and with the same number of cores per server that you plan to deploy in your environment.

The first release of the Processor Query Tool (PQT) allowed you to make these calculations for all physical server deployments of Exchange 2010. With the PQT 1.1 release we’re adding the ability to calculate SPECint 2006 rate values for virtualized workloads based on the calculated rate value of the physical host server. The process to determine the SPECint 2006 rate value of virtual Exchange 2010 mailbox role servers is to first calculate the rate value of the physical host server. Once you’ve determined the physical host rate value you’ll use that number to calculate the rate value for the virtual mailbox role servers. The virtual mailbox role rate value is based on the physical to virtual processor ratio you plan to use and the number of virtual CPU’s you plan to deploy in each mailbox server.

Whether you’re planning to deploy physical mailbox servers in your environment or virtual mailbox servers always enter the correct SPECint 2006 Rate Value and Processor Cores/Server count in the Mailbox Server Role Requirements calculator to properly plan your deployment.

Scott Alexander
Principal Consultant, MCS

We're happy to announce that the Exchange Server Deployment Assistant (ExDeploy) now includes support for configuring hybrid deployments using Exchange 2010 SP2 and Exchange 2007 on-premises organizations.

This newly added scenario is for Exchange 2007 organizations interested in maintaining some users on-premises and some users hosted in the cloud by Microsoft Office 365 for enterprises. Like the Exchange 2003 scenario released in March, this Exchange 2007 scenario uses the Hybrid Configuration wizard to streamline deployment.

Some things to know about this new Exchange 2007 scenario:

• Information is only available in English at this time.
• You’ll need to add at least one Exchange 2010 SP2 server to your current Exchange 2007 organization.
• If you have previously configured a hybrid deployment using ExDeploy and Exchange 2010 SP1 and still need guidance; don’t worry, we haven’t forgotten about you! For your convenience, checklists for configuring hybrid deployments with Exchange 2010 SP1 are in Office 365 Hybrid Deployments with Exchange 2010 SP1.

And, we’re not done yet with updating ExDeploy. Although limited, interim hybrid deployment configuration support for Exchange 2010 on-premises deployments is also included with this April update, complete hybrid deployment checklists for the 2010 on-premises scenario are in progress. Watch this space for announcements about the upcoming Exchange 2010 hybrid deployment scenario update.

Hybrid deployments offer organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. It provides the seamless look and feel of a single Exchange organization between an on-premises organization and an Exchange Online organization. In addition, hybrid deployments can serve as an intermediate step to moving completely to a cloud-based Exchange Online organization. This approach is different than the simple Exchange migration (“cutover migration”) and staged Exchange migration options currently offered by Office 365 outlined here.

About the Exchange Server Deployment Assistant

The Exchange Server Deployment Assistant (ExDeploy) is a web-based tool that helps you upgrade to Exchange 2010 on-premises, configure a hybrid deployment between an on-premises and Exchange Online organization or migrate to Exchange Online.

Figure 1:The Exchange Deployment Assistant generates customized instructions to help you upgrade to Exchange 2010 on-premises or in the cloud

It asks you a small set of simple questions, and then based on your answers, it provides a checklist with instructions to deploy or configure Exchange 2010 that are customized to your environment. These environments include:

• Stand-alone on-premises Exchange installations and upgrades
• Hybrid deployment configurations and
• Cloud-only Exchange deployment scenarios.

Besides getting the checklist online, you can also print instructions for individual tasks and download a PDF file of your complete configuration checklist.

Your feedback is very important for the continued improvement of this tool. We would love your feedback on this new scenario and any other area of the Deployment Assistant. Feel free to either post comments on this blog post, provide feedback in the Office 365 community Exchange Online migration and hybrid deployment forum, or send an email to edafdbk@microsoft.com via the Feedback link located in the header of every page of the Deployment Assistant.

Exchange Deployment Assistant Team

Recently, customers who use Outlook Web App (OWA) have been raising the topic of web app accessibility as a top priority. One reason for all the buzz about web application accessibility is due to a standard produced by the W3C called ARIA (Accessible Rich Internet Applications). While the standard has been around for a while now, ARIA support in the most commonly used web browsers has recently improved. We want to share our thoughts on this topic and let you know that ARIA support is coming to future versions of OWA!

Accessibility here refers to how users with limited vision, mobility, hearing etc. can be given access to all the functionality of an application through a user interface (UI) optimized for that user’s circumstances. For instance, many blind users interact with computers through screen readers, which read the UI text out loud. Another example is users with limited mobility who can’t use a computer mouse and instead rely on speech recognition for dictation and alternative keyboard designs which navigate the UI through keyboard input only.

Microsoft Office, including OWA’s companion Microsoft Outlook, has had strong accessibility support for many years through the Microsoft Active Accessibility (MSAA) technology and more recently the User Interface Automation (UIA) frameworks on the Windows platform. But accessibility has been more difficult for web-based email experiences because of the incompatibility between many accessibility technologies and new dynamic/complex web app behaviors. We’ve faced a tough choice between a) staying away from most dynamic, complex web app behaviors and ensuring great accessibility, or b) building modern Web 2.0 apps without top-notch accessibility support. For OWA 2007 and 2010, this was not a choice we could make, so our solution was to do both. We built OWA Premium which makes use of all that Web 2.0 has to offer, and OWA Light which is a very accessible UI built almost exclusively on HTML 4.0. When people access their Exchange mailboxes for the first time through OWA, they’re asked whether they’d like to use the OWA experience optimized for accessibility.

Over the years, the screen reader interoperability and keyboard navigation capabilities of OWA Light offered an accessibility solution few other modern web applications could match and have been appreciated by the people who rely on it every day. But, web standards are evolving. People are wondering if ARIA is mature enough for us to move beyond a two-UI solution and take OWA accessibility to the next level. After watching ARIA evolve and experimenting with it in recent version of web browsers we support, the answer is clear: we look forward to implementing ARIA in future versions of Outlook Web App.

Kristian Andaker
Microsoft Group Program Manager
on behalf of the OWA team

We’re pleased to announce that we have released the newest version of the Exchange 2010 language pack and that it is available for download here.

This language pack resolves three key issues some customers have experienced;

• Events being logged in the application log for any user not using en-us as their chosen language after installing SP2 RU1.
• A wording error in the German version of OWA
• A wording error in the Dutch version of OWA

Note that Exchange 2010 Service Pack 2 included the full language pack, and if you are not experiencing the problems or have not installed any language packs post SP2 you do not need to apply this language pack.

The Exchange Customer Experience Team

We're happy to announce that the Exchange Server Deployment Assistant (ExDeploy) now includes full checklist support for configuring hybrid deployments for Exchange 2010 SP2 organizations.

This newly added scenario is for Exchange 2010 SP2 organizations interested in maintaining some users on-premises and some users hosted in the cloud by Microsoft Office 365 for enterprises. Like the Exchange 2003 scenario released in March and the Exchange 2007 scenario released in April, this Exchange 2010 scenario also uses the Hybrid Configuration wizards to streamline deployment.

Important information to know about this new Exchange 2010 scenario:

• Information is only available in English at this time.
• You’ll not need to add any additional Exchange 2010 servers to your current Exchange organization. Your existing on-premises Exchange 2010 servers will be configured to support the hybrid deployment.
• If you have previously configured a hybrid deployment using ExDeploy and Exchange 2010 SP1 and still need guidance; don’t worry, we haven’t forgotten about you! For your convenience, checklists for configuring hybrid deployments with Exchange 2010 SP1 are here.

Hybrid deployments offer organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. It provides the seamless look and feel of a single Exchange organization between an on-premises organization and an Exchange Online organization. In addition, hybrid deployments can serve as an intermediate step to moving completely to a cloud-based Exchange Online organization. This approach is different than the simple Exchange migration (“cutover migration”) and staged Exchange migration options currently offered by Office 365 outlined in E-Mail Migration Overview.

About the Exchange Server Deployment Assistant

The Exchange Server Deployment Assistant (ExDeploy) is a web-based tool that helps you upgrade to Exchange 2010 on-premises, configure a hybrid deployment between an on-premises and Exchange Online organization or migrate to Exchange Online.

Figure 1:The Exchange Deployment Assistant generates customized instructions to help you upgrade to Exchange 2010 on-premises or in the cloud

It asks you a small set of simple questions, and then based on your answers, it provides a checklist with instructions to deploy or configure Exchange 2010 that are customized to your environment. These environments include:

• Stand-alone on-premises Exchange installations and upgrades
• Hybrid deployment configurations and
• Cloud-only Exchange deployment scenarios.

Besides getting the checklist online, you can also print instructions for individual tasks and download a PDF file of your complete configuration checklist.

Your feedback is very important for the continued improvement of this tool. We would love your feedback on this new scenario and any other area of the Deployment Assistant. Feel free to either post comments on this blog post, provide feedback in the Office 365 community Exchange Online migration and hybrid deployment forum, or send an email to edafdbk@microsoft.com via the Feedback link located in the header of every page of the Deployment Assistant.

Exchange Deployment Assistant Team

Earlier today, the Exchange CXP team released Update Rollup 3 for Exchange Server 2010 SP2 to the Download Center.

This update contains a number of customers reported and internally found issues. See KB2685289 Description of Update Rollup 3 for Exchange Server 2010 Service Pack 2 for more details.

Note: Some of the following KB articles may not be available at the time of publishing this post.

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

• KB2689810 Meeting Requests bodies get rendered in plain text in Outlook when created via Exchange Web Services.
• KB2674445 Need the function to check ACL consistency during moving mailbox.
• KB2700705 RpcClientAccess crashes with SocketException when UDP push notification is enabled.
• KB2705425 Memory Leak in UMWorkerProcess.exe.
• KB2698976 MRM Assistant doesnt process a mailbox with a contact created in other tenants.

General Notes:

For DST Changes: http://www.microsoft.com/time.

Note for Forefront Protection for Exchange users  For those of you running Forefront Protection 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.

Exchange Team

Nearly two years ago, I presented a session called High Availability Design Considerations at TechEd North America 2010. During my session I described the changes we were making around how MAPI connectivity should occur after mailbox moves and cross-site database *over events. Unfortunately, after I gave that presentation we cut the feature due to the complexity of the changes we needed to introduce and the lack of time for testing prior to Service Pack 1’s release. And though I tried hard to get the work prioritized, we were unable to ship these changes in Service Pack 2, either.

Sadly, not every feature cut can be performed in a surgical manner, and a portion of the code changes were actually left in SP1. For example, you may have noticed that the Set-DatabaseAvailabilityGroup cmdlet has a property called AllowCrossSiteRPCClientAccess. You can toggle this Boolean property to your heart’s content, sadly it will not affect any behavioral change in the product (I know…that’s why I think this image is oddly relevant):

Cross-Site RPC Client Access Connectivity Behavior (RTM, SP1, SP2 through SP2-RU2)

But I digress. First, let’s cover a few basics.

With Exchange 2010, a major change was instituted in the way clients connect and access mailbox related data. Unlike previous versions, clients no longer connect directly to the Information Store on the Mailbox server role to access mailbox data. Instead, clients connect to a set of services on the Client Access server (CAS) role and services within the CAS role access mailbox data using MAPI/RPC from the Mailbox server on behalf of the connecting user. Think of it as an abstraction layer.

Basically, one simple change was made such that all mailbox-related MAPI connectivity goes through the RPC Client Access service on the Client Access server role. To facilitate this abstraction layer, changes were made such that the database objects are no longer child objects of Mailbox servers. A new property was added to the Mailbox database, RPCClientAccessServer, which defines the legacyExchangeDN that should be used to access the particular database. This property takes a FQDN as its value. To ensure that you have high availability and fault tolerance in the event a CAS fails, this value should be the FQDN of a load-balanced CAS array. This load-balanced FQDN is what we refer to as an RPC Client Access Server array.

For more information, see Brian Day’s posts on Demystifying the CAS Array Object, Part 1 and Part 2.

Typical Outlook Experience

All Outlook versions behave in a consistent fashion in a single datacenter (or single Active Directory site) scenario. The Outlook profile’s RPC endpoint is the RPC Client Access Server array (or a specific CAS if for some reason you did not create an array, which you should have done, and if you don’t know why I will say again, read Brian’s posts). Whenever a failure occurs within the DAG (database failure, server failure, etc.), the RPC endpoint does not change, thus Outlook continues to connect to the same RPC Client Access Server array. Whenever a failure within the CAS array (CAS failure, load balancer failure, etc.) occurs, the RPC endpoint does not change, thus Outlook will continue to attempt to connect to the RPC Client Access Server array.

All Outlook versions behave consistently in a datacenter switchover scenario as well, assuming you follow our guidance. Why is that? Well, in a datacenter switchover, you change the primary datacenter RPC Client Access Server array DNS entry’s IP address to now point to the standby datacenter’s RPC Client Access Server array. Autodiscover continues to hand out the primary datacenter RPC Client Access Server array as the RPC endpoint. Existing Outlook clients do not need any reconfiguration; once the DNS cache on the client is updated, the client simply connects to the endpoint that now resides in the standby datacenter. In order to fully understand why this works you need to grasp that neither the client nor the CAS really care about the site in which the CAS exists, they simply accept that they are able to connect and that the CAS the client is connected to is able to provide access to the mailbox.

Cross-Site Database *over Behavior

To understand this scenario, it is important to understand that when you configure a multi-site DAG, the RPCClientAccessServer property for a given database is typically associated with the RPC Client Access Server array that is in the same AD site as the copy of the mailbox database with the lowest activation preference number. For example:

Figure 1: Database Availability Group stretched between two Active Directory Sites

In the event that a copy of the database is activated in the standby datacenter, the users will continue to leverage the RPC Client Access Server array from the AD site where the mailbox database with the lowest activation preference value resides as their connectivity endpoint.

Figure 2: MDB1 database has been activated in the Standby Active Directory Site

If you review the RPC Client Access logs on the source RPC Client Access Server array you will see:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

In the event the RPC Client Access Server array in the AD site where the mailbox database with the lowest activation preference value resides becomes inaccessible to the users, Outlook clients would be unable to connect to their mailbox that resides in the opposing datacenter. In other words, there is a datacenter outage event and the datacenter switchover process needs to be performed.

A simpler way to look at this behavior is that Outlook always connects to the configured RPC endpoint (assuming it is reachable) regardless of the database’s RPCClientAccessServer property value.

Can the system ever change the RPCClientAccessServer value automatically?

The only time the system changes RPCClientAccessServer value on the database is when the administrator changes the ActivationPreference number on the activated database copy such that it now has the lowest value (meaning it becomes the preferred copy), as seen in Figure 3.

Figure 3: MDB1 database has been activated in the Standby Active Directory Site and the RPCClientAccessServer property has changed

However, the Outlook clients with an existing Outlook profile would continue to use the old RPC endpoint rather than the new RPC endpoint (even though Autodiscover detected the change). This is because the old RPC endpoint does not return an ecWrongServer response to the client. The RPC endpoint accepts the connection; therefore, Outlook ignores the Autodiscover response because it has a working connection. In the event that the old RPC endpoint becomes inaccessible, Outlook 2007/2010 would update its settings (Outlook 2003, on the other hand, would not as it does not leverage Autodiscover). At any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

What happens if the administrator manually updates the RPCClientAccessServer value after a cross-site database *over event?

Going back to Figure 2, if the administrator manually updates the RPCClientAccessServer value to point to cas-sec.contoso.com for MDB1 after the mailbox database copy on MBX-C is activated (whose ActivationPreference value is greater than 1), then Outlook clients with an existing profile will continue to use the old RPC endpoint rather than the new RPC endpoint as long as the old RPC endpoint remains available (profile repairs will correct the issue). Outlook profiles created after the RPCClientAccessServer value change would use the new RPC endpoint.

Moving Mailboxes between Active Directory Sites

Prior to Exchange 2010, when you moved mailboxes across servers, the Outlook RPC endpoint would update to point to the Mailbox server (or clustered Mailbox server instance) hosting the database where the mailbox resides. After the mailbox move was completed, the Outlook client user would be prompted with the “The Exchange administrator has made a change that requires you quit and restart Outlook” dialog. After restarting Outlook, the client would be connected to the new RPC endpoint.

With Exchange 2010, you may have noticed that when you moved mailboxes between AD sites, users did not receive this dialog. Furthermore, you may have noticed that users also did not have their RPC endpoint updated to reflect the RPC Client Access Server array associated with the mailbox database in the AD site where the mailbox now resides. This is because the old RPC endpoint does not return an ecWrongServer response to the client. The RPC endpoint accepts the connection; therefore, Outlook ignores the Autodiscover response because it has a working connection. In the event that the old RPC endpoint becomes inaccessible, Outlook would update its settings (Outlook 2003, on the other hand would not as it does not leverage Autodiscover). At any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

Now I am sure you understand the above lolcat picture.

The Future…SP2 RU3 and beyond

I never gave up hope about addressing these issues. A few of us got bloodied, but the RPC Client Access development team, Exchange Servicing Team and I worked tirelessly to get the two required necessary changes into the product. The first being, fixing up Outlook’s profile when a mailbox is simply moved between databases in different AD sites, and the second when a cross-site database *over results in Outlook using a CAS that isn’t the most optimal choice for the location of the currently activated database.

Mailbox Moves

By default, once you have installed SP2 RU3, when you move mailboxes between AD sites, all versions of Outlook will get prompted to restart and the Outlook profile’s RPC endpoint will be updated.

If you review the RPC Client Access logs on the source RPC Client Access array you will see:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Notice that the RPC operation (ROP) is WrongServer (also known as ecWrongServer). This forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory. The profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

And since this question will be asked, what other conditions will warrant the “The Exchange administrator has made a change that requires you quit and restart Outlook” dialog?

1. When you specify the DoNotPreserveMailboxSignature property on New-MoveRequest.
2. When the source and target mailbox databases have a different public folder hierarchy store.
3. When you move your mailbox from a legacy version of Exchange to Exchange 2010.

Cross-Site Database *over Events

Cross-Site database *over event behavior will depend on the value of DAG property AllowCrossSiteRPCClientAccess.  If you set the AllowCrossSiteRPCClientAccess property value to $true, then the behavior I described in the previous section is the default behavior - in the event that the database is activated in the standby datacenter, the users will continue to leverage the RPC Client Access array in the AD site where the mailbox database with the lowest activation preference value resides as their connectivity endpoint.

If you set the AllowCrossSiteRPCClientAccess property value to $false (the default value for the property is $false), then the Outlook profile’s RPC endpoint will be updated to be the RPC Client Access Server array that is in the same AD site where the database is active and mounted. Note that the RPCClientAccessServer property is not updated as that defines the preferred site.

Figure 4: MDB1 database has been activated in the Standby Active Directory Site and Outlook profile has been updated automatically

If you review the RPC Client Access logs on the source RPC Client Access Server array you will see:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Like in the move mailbox scenario, the WrongServer ROP forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory. The profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

Conclusion

So there you have it – with SP2 RU3 (or later) you can ensure that mailboxes moved between AD sites will have their profile updated correctly. In addition, in the cross-site database *-over scenario, you can control whether to allow the cross-site RPC connectivity or to force the Outlook client to use the RPC Client Access Server array that is in the same AD site as the activated and mounted database (the default behavior). I think it is appropriate to end with this:

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Over the course of the last several months, we've received reports of excessive growth of the Recoverable Items folder (what many term Dumpster, although we no longer refer to it as such). There are two main scenarios that can contribute to this excessive growth.

1. Single Item Recovery and Litigation Hold versioning
2. Calendar Version Logging

Single Item Recovery and Litigation Hold

Single Item Recovery and Litigation Hold enable preservation of data within the mailbox. If you are unfamiliar with these features, see my previous post Single Item Recovery in Exchange 2010 for more information.

In addition to retaining data within the mailbox, both Single Item Recovery and Litigation Hold also enable versioning. Essentially, when an item is changed, a copy-on-write (COW) is performed to preserve the original version of the item. The original item is placed in the Recoverable Items\Versions folder. This folder is not exposed to users.

Given that Exchange 2010 includes a change in how clients connect and access mailbox related data, the copy-on-write activity occurs in the Exchange System Objects (XSO) layer on the Client Access server.

What triggers a copy-on-write?

• For messages and posts (IPM.Note* and IPM.Post*), copy-on-write captures changes in the subject, body, attachments, senders/recipients, and sent/received dates.
• For other types of items, copy-on-write captures any change to the item except for moves between folders and read/unread status changes.
• Drafts are exempt from copy-on-write to prevent excessive copies when they're auto-saved.

What can cause excessive growth in the Recoverable Items folder?

Copy-on-write behavior can lead to excessive growth. We discovered that the following scenario using Microsoft Outlook as a leading cause of excessive copy-on-write:

1. You create a calendar appointment.
2. You attach an Office document to the appointment and save it
3. Later, you decide to open the appointment to reference something in the Office document. You open the document.
4. Behind the scenes, Outlook begins auto-saving this open appointment and its corresponding open document (by default Outlook auto-saves every 3 minutes).
5. Each auto-save event triggers a copy-on-write. But because the auto-save is saving both the Office document and the appointment, there are two copy-on-write events. For each additional attachment, a subsequent copy-on-write version would also be created.

Ouch, is right.

Since attachments are part of the message, it doesn't make sense to create a copy for every attachment in the item. Essentially, when you save an item that has an attachment, Outlook performs the following:

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

The copy-on-write was taking place at both SaveAttachment and SaveMessage. Digging into the code, we found that the call to SaveAttachment ultimately calls the Flush method (a means by which the client syncs the state with the server) on the message it's associated with after the attachment is saved. It was this Flush call that was signaling the copy-on-write code to act.

After further analysis, we realized that the copy-on-write logic is triggered on any Flush call. This was a breakthrough finding because Flush can be initiated in many scenarios, potentially leading to the cause of the thousands of copy-on-write events that several customers saw in their environments.

Calendar Version Logging

Calendar Version Logging is the process by which calendar changes that occur within a mailbox are saved via copy-on-write. Calendar Version Logging was introduced in Exchange 2010 to help troubleshoot and repair calendar reliability issues.

The design of Calendar Version Logging is to create a log every time a calendar item has been changed. These logs provide a history of the meeting. You can use the Get-CalendarDiagnosticLog cmdlet to review the history and determine which clients performed a destructive action. The second use for Calendar Version Logging is by the Calendar Repair Assistant, which uses the logs when trying to determine the history of a given calendar item for inconsistency detection.

Calendar Version Logging is enabled by default on mailboxes in Exchange 2010. You can disable or enable this on a mailbox via the CalendarVersionStoreDisabled property. Note, the property name is CalendarVersionStoreDisabled, so the default value of $false means that Calendar Version Logging is enabled by default.  Depending on the mailbox configuration, a different process is followed for storing copies of the calendar items:

1. If the mailbox is not enabled for Single Item Recovery or Litigation Hold, then stripped versions of calendar items are maintained in the root of the Recoverable Items folder for 120 days. The stripped versions (body and non-first level or non-embedded message type attachments are removed) are created using copy-on-write.
2. If the mailbox is enabled for Single Item Recovery or Litigation Hold, full copies of the calendar items are maintained in the Recoverable Items\Deletions or Recoverable Items\Versions folders. A stripped version is created via the copy-on-write infrastructure whenever a hard delete operation is performed against the calendar item in the Recoverable Items\Deletions or Recoverable Items\Versions folders. This stripped version is placed in the root of the Recoverable Items folder and kept for 120 days. The only time a stripped version is not created is when the item's age in the Recoverable Items\Deletions or Recoverable Items\Versions folder is more than 134 days (120 + 14). This can happen if you change the retention period, if the Mailbox Folder Assistant hasn’t been executing, if Litigation Hold was disabled, etc.).

Due to the aforementioned issue with how the copy-on-write logic did not distinguish between Flush and Save operations, Calendar Version Logging, in some cases, could consume a large percentage of the Recoverable Items folder quota (and if you recall, the warning threshold is 20GB and the hard quota is 30GB).

If the folder size is greater than the RecoverableItemsWarningQuota, Calendar Version Logging is disabled for the mailbox. The RecoverableItemsWarningQuota value that is used depends on the mailbox’s settings:

1. If the mailbox has the UseDatabaseQuotaDefaults set to $true, then the mailbox database’s RecoverableItemsWarningQuota will be used.
2. If the mailbox has the UseDatabaseQuotaDefaults set to $false, then the mailbox’s RecoverableItemsWarningQuota will be used.

When Calendar Version Logging is disabled, the following event is generated in the Application event log on the Client Access server:

Event ID: 5003
Source: MSExchange Mid-Tier Storage
Task Category: CopyOnWrite
Level: Information
Description: User mailbox <legacyExchangeDN> has exceeded the dumpster warning quota. Calendar logging has been disabled for the mailbox.

And that's not all we're doing. I won’t go into specifics at this early stage of development, but we're working to further improve Calendar Version Logging to minimize the impact this feature has in your deployment. When I can share more, I will do so via this blog.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience