March 2013 Entries
Exchange 2013: A new look…

The Exchange Server product line experienced a few changes with the introduction of Microsoft Exchange Server 2013. Exchange Server 2013 brings with it a whole new set of services, technologies and features all aimed at enhancing user experience. With the aim to helping businesses and individuals succeed in their collaboration efforts, the new Exchanger Server 2013 drastically lowers the overall cost of ownership. Delving into the core functionality of Exchange 2013 exposes some new features.

Basically, the new Exchange 2013 integrates a multigenerational workforce. The use of smart search ensures that user experience is enhanced; so as to prioritize search results. Users can now merge their contacts from multiple sources such that only a single view of a particular contact is provided. This it does efficiently by linking contact information got across multiple locations.

The new look and feel of Exchange 2013 is a refreshing change. In addition to changing the looks of Exchange 2013, Microsoft also does the same with Outlook Web App. Both now offer an interface that allows users to make use of touch especially with mobile devices.

Integration with Microsoft SharePoint 2013 and Microsoft Lync 2013 is now easier and seamless in Exchange 2013. This was efficiently handled through site mailboxes as well as In-Place eDiscovery. All goes together in a suite and offers the possibility of collaboration and enterprise eDiscovery using mailboxes.

Exchange 2013 means that users are able to meet up with compliance needs. Since compliance can quickly become challenging for many organizations, it is now possible for organizations to find and search data across the organization and not be limited to Exchange. This means in effect that it is now possible and easier to perform a search across Lync 2013, Exchange 2013, Windows file servers and SharePoint 2013 because of the improved search and indexing. Furthermore, there is the introduction of data loss prevention (DLP) which can help prevent users from erroneously sending sensitive data to people who are not signatories to that information. With DLP, it is possible to protect, identify, and monitor sensitive data through the process of content analysis.

The provision of offline support makes it possible for emails and actions to be synced automatically upon the restoration of connectivity. With Site Mailboxes, it is possible to bring Exchange emails and SharePoint documents together to work seamlessly.

The UI layout of Outlook Web App is differently optimized for phone browsers, desktop and slate. Customization of Outlook and OWA is easier with the integration of apps from Office marketplace. For developers this means they will be able to utilize the new ‘Napa’ tools and HTML5 for the customization process.

The Exchange Management Console has been replaced by the new Web-based Exchange Administrative center (EAC). It can also support multiple databases per disk (as to one database and its log files in Exchange 2010); this is made possible through changes to the ESE database engine providing a “sequentialish” IO performance.

Built-in anti-virus protection can be configured and managed from the Exchange Administration Centre (No more console! All is done through powershell or the EAC, which is a webpage). This feature can also be turned off or replaced if the administrator so desires. It is entirely possible to pair this feature with paid services like the Exchange Online Protection; this helps to add an extra layer of protection to the new system.

Administrators no longer has to grapple with multiple roles as they have been reduced to just two which are the Mail Server and the Client Access Server (whilst the hub transport still exists it is now tightly integrated in to the mailbox role). This reduction means loosely coupled roles. The entire traditional server components as is found in Exchange 2010 are present in the 2013 Mailbox server. This includes the Client, Hub Transport service, Unified messaging, Access protocols, and Mailbox databases. The function of the Client Access server is to provide authentication, proxy services as well as redirection. When it comes to data rendering, the Client Access doesn’t play any major role as it is a thin and stateless server. Nothing is queued or stored in this server. All the previous access protocols such as HTTP, POP, IMAP and SMTP are present in this new system.

Add Comment Filed Under [ Exchange ]
Exchange 2013: The Client Access Server

We've been beaten to death with it at this point: "Exchange 2013 introduces fundamental changes in roles and architecture compared to earlier versions." But what does this mean? Today we are going to have a look at the Client Access Server Role (or CAS for short) and what role it serves in Exchange 2013.

Fundamentals

Before talking about anything else we have to keep in mind that the "new" CAS Exchange role does 3 things and only those things:

1. The CAS authenticates the connection made by the user so that it can determine who is trying to connect.

2. Once authenticated it will locate the user's mailbox and find out on which mailbox server that mailbox is currently active

3. It then proxies the connection from that user to his or hers mailbox on the mailbox server and maintains that connection or redirects it to the appropriate CAS server.

Superficially that doesn't look at all to different from Exchange 2010, but under the hood we can see that the CAS role got significantly "dumbed down".

Autodiscover (external clients)

When an external client opens his mailbox and establishes a connection to the Exchange 2013 CAS server through autodiscover.contoso.com it will authenticate, the CAS will look up where the mailbox is stored and build the connection accordingly.

If the mailbox is local on an Exchange 2013 mailbox server, nothing much special happens. The CAS proxies the connection to the 2013 mailbox sever. If the mailbox would be on an Exchange 2010 mailbox server the connection will be proxied to an Exchange 2010 CAS server in the same site to handle the request.

If the Exchange 2010 mailbox server is in another, non-internet facing, site the Exchange 2013 CAS server will proxy to the 2010 CAS server to handle the request.

In the case of coexistence with Exchange 2007 things are slightly different… Once the traffic hits the 2013 CAS box it will forward the 2013 mailbox will answer the AutoDiscover request and will proxy the authentication to the outlook anywhere enabled 2007 CAS in either a local or remote site.

Autodiscover (internal clients)

Internal clients in an Exchange 2010 coexistence scenario will behave in a similar fashion to external clients. The main difference is that, like before, the SCP records will be looked up in the almighty triangle (Active Directory) and the client will make the connection to the CAS server or the load balanced namespace if you decided to deploy in this fashion (which really is the recommended way to go to be honest!)

In the case of a 2007 coexistence scenario the same is true. Lookup would occur in Active Directory which points to the load balanced namespace (or a single CAS server) and from the Exchange 2013 Mailbox server would handle the rest, just like in the external scenario.

Outlook connectivity

Internally and externally Outlook uses Outlook Anywhere (Https) traffic to connect to the Exchange 2013 environment. The big difference in regards to earlier versions is that 2 connection strings are offered to clients depending their location, internal or external.

Load balancing

In Exchange 2010 load balancing had the requirement to be performed on layer 7. This requirement was due to the simple fact that session state was tied to a specific server in 2010. In 2013 stateless sessions for outlook connectivity was introduced and, as such, the requirement for a layer 7 load balancer is no longer needed and we can revert to using a layer 4 capable device. Good news if you are deploying a new environment or just moving to 2013 from 2007, bit of a pain if you invested in a layer 7 load balancer for a 2010 environment.

That being said, there is still a use for a layer 7 load balancer… Since layer 4 load balancer have no idea what the actual target URL (like /owa or /ews) it could pose a problem for the health probes in Exchange 2013…

When performing health probes with a layer 4 load balancer the result of the test will determine the health of the server, not of the protocol on that server.

On the other hand, when a layer 7 load balancer is used the SSL terminiation will reveal the full URL and the health probes will be able to determine health checks on a per protocol level (yes that means that, if for example, the OWA was not working properly only owa traffic will be directed away from that server.)

There is a way around all of this though as the above is true when a single namespace is used (mail.contoso.com). If you were to set up a namespace per protocol (owa.contoso.com, ecp.contoso.com, etc) you would be able to use a layer 4 load balancer and have health check on a per protocol level

Exchange 2013: The store process

Exchange 2013, the end of the store as we know it… In the years leading up to the development of Exchange 2013 we had a process called store.exe. Many an administrator cursed at this process for taking up so much memory but yet, things were good. But they could be better!

The store.exe prior to exchange 2013 was used to run all databases and keep reads and writes in the memory as much as possible. Exchange 2013 sees a continuation of keeping reads and writes in the memory (for obvious performance reasons) but some structural changes were made to address the lack of scale and to remove the single point of failure the "old" store.exe was.

The new store.exe

First of all, exchange 2013 introduces managed code in to the store process. This allows for more optimizations and easier debugging when needed. It also allows to scale out over more processors (in Exchange 2010 you would not see much performance increase when going over 8 cores and even a decrease when going over 12 cores. This was due to crosstalk…) and use process isolation, aka one store process per database.

The managed store actually has 2 or more processes running at all times! One global overseeing store.server.exe process and one store.worker.exe process for each database on the exchange server.
Now that global mast (store.server.exe) is a supervisor for each store.worker.exe process. It deals with lifetime management of those processes, deals with worker crashes and the worker processes absolutely depend on the store.server.exe process.

The store.server.exe process also manages the ESE cache memory allocation and the biggest change for exchange 2013 (on top of all other changes) in memory management is definitely that there is a maximum limit to the memory used by the store process. Only 25% of the total memory in a server can be allocated to the ESE cache based on the active and maximum active databases values. Do note that passive databases get only 20% of the memory allocated compared to an active database.

I already mentioned that there will be one store.worker.exe for each database on a server so let's skip repeating that… The worker processes (if you have more than one database on a server) manage client request sand are responsible for registering an RPC endpoint for its Database GUID. Other than that they don't have much responsibility or decision power, this is all overseen by the global store server process.

Performance improvements

Throughout the different versions of exchange (2003 up to 2013) the exchange product group have made significant efforts to reduce the IOPS footprint of databases. Now, in Exchange 2013, there is a 97% reduction in IOPS compared to Exchange 2003! Now there is a massive number to throw around!!

How would be the obvious question to ask here! In Exchange 2013 (and 2010 for that matter) the focus was to replace as many random IO with sequential IO to squeeze every bit of performance from the storage.

On the physical contiguity level there was a redesign of the leaf pages in the databases resulting in fewer and larger sized IO spanning multiple pages.

For the logical contiguity a folder, message and attachments table was introduced on a per mailbox level. Each of the message tables consists of physical columns and property blobs. Having a high level of messages per page resulted in fewer large IO to retrieve large number of messages for views.

Lastly the temporal contiguity was improved by updating the views and indexes only when they were being accessed by a user. This resulted in fewer and larger sized IO being performed together.

Overall the result of all these optimizations is a "sequentialish" IOPS pattern with massive improvements gains over older versions.

Scheduled maintenance

Mainly a leftover of the past, scheduled maintenance has been removed from exchange 2013. Maintenance is still recurring, but is now implemented within a time-based assistant infrastructure. Not only that, but background ESE database scanning has been throttled even further compared to exchange 2010. It is now targeted to complete only once every 4 weeks compared to Exchange 2010.

Support for large mailboxes

Yes, Exchange 2013 includes support for large mailboxes… Up to 100 Gb+ in size and over 1 million item counts. For the record, 1 million is the highest number which was tested with so it might be sustainable over that number.

Now large mailboxes introduce a possible problem for cached outlook users. Imagine having a 60 Gig + OST file… Hell, I'm certain that would kill your disk performance on your client! It is for that reason that a new feature was introduced in Outlook 2013 to control the amount of mail to keep offline, thus mitigating the effect of performance issues on your clients if large mailboxes are implemented.

4 Comments Filed Under [ Exchange ]
Exchange 2013: Managing exchange
Much has changed with Exchange 2013 and the new way of administering the service is what we will be discussing in this article.
Add Comment Filed Under [ Exchange ]