Configuring Database Availability Groups in Exchange Server 2013 Preview


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

The process of creating a Database Availability Group (DAG) in Exchange Server 2013 (Preview) is largely the same as in Exchange Server 2010. You can choose to create a DAG via either the Exchange Administrative Center (GUI) or through the Exchange Management Shell (PowerShell).

I prefer using the Exchange Management Shell over EAC as it provides you more information over the process.

Exchange Management Shell

To configure a Database Availability Group using the EMS, type in the following commands. Replace the example values with the ones that suit your environment:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer SRV01 –WitnessDirectory “C:\FSW” – DatabaseAvailabilityGroupIPAddresses

This command will create the DAG. As part of this process, a computer object, also known as the Cluster Name Object, will automatically be created:


Note   In order for this process to complete successfully, you need to have the appropriate permissions on the container in which the object is created. By default this will be the “Computers”-container. However, it is possible that your Active Directory has been reconfigured to use another container/OU as default location for new computer accounts. Have a look at for more information.

Another way to get around the possible issue of permissions, is to create the Cluster Name Object (CNO) upfront. This process is also called “pre-staging”. Doing so will allow you to create the object up-front with another account (that has the appropriate rights) so that you don’t run into any issues when configuring your DAG.

To pre-stage the CNO, complete the following tasks:

  1. Open Active Directory Users & Computers, navigate to the OU in which you want to create the object, right-click and select New > Computer:


  2. Enter a Computer Name and click OKto create the account:


  3. Right-click the new account and select Properties. Open the Security tab and add the following permissions:- Exchange Trusted Subsystem – Full Control
    – First DAG Node (Computer Account) – Full Control

image     image

More information on how to pre-stage the CNO can be found here:

Note   if your DAG has multiple nodes across different subnets, you will need to assign an IP address in each subnet to the DAG. To do so, you can separate the IP addresses using a comma:

New-DatabaseAvailabilityGroup –Name DAG01 –WitnessServer SRV01 –WitnessDirectory “C:\FSW” – DatabaseAvailabilityGroupIPAddresses,,

Once the command executed successfully, you can now add mailbox servers to the DAG. You will need to run this command for each server you want to add to the DAG:

Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer EX01
Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer EX02

Alternatively, you can also add all/multiple mailbox servers at once to the DAG:

Get-MailboxServer | %{Add-DatabaseAvailabilityGroupServer –Identity DAG01 –MailboxServer $_.Name}

Adding Database Copies

Now that your DAG has been created, you can add copies of mailbox databases to other mailbox servers. For example, to add a copy of DB1 to server EX02, you would run the following command:

Add-MailboxDatabaseCopy –Identity DB1 –MailboxServer EX02

Stay tuned! In an upcoming article, I will be talking about configuring high availability for the Client Access infrastructure in Exchange Server 2013 as well as a topic on high availability (more general).

Exchange 2013 How-To's

A closer look at the “new” Public Folders in Exchange Server 2013


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

In addition to some of the existing blogs and information out there, I wanted to take the time and explain the “new” Public Folders in Exchange Server 2013 a bit more in detail.


Ever since Exchange Server 2007 was released, Microsoft proclaimed Public Folders would eventually disappear. At that time, it was said Public Folders would stop to exist in “future versions” and consultants were given the advice to evangelize SharePoint as being thé replacement for Public Folders. It seemed, however, that these statements provoked quite some comments from the field: companies world-wide would still be using Public Folders and were not planning on giving that up so easily. Knowing what a migration to SharePoint could potentially cost, it’s quite understandable that some companies were rather reluctant to immediately jump on the SharePoint-train.

In fact, I cannot blame them. Even through today, there’s no real solution that offers the same functionality and ease of use as Public Folders.

Over time, Microsoft seems to have recognized that killing Public Folders might not be such a great idea after all and changed it’s attitude little at a time. Nevertheless, they’ve always deemphasized using Public Folders.

…At least until NOW.

To better understand at what the changes in Exchange Server 2013 are, let’s first have a look at how things were in Exchange Server 2010.

Public Folders in Exchange 2010 (and before)

In Exchange Server 2010 (and before), Public Folders were stored in their own database(s).

Basically speaking, Public Folders consists of two elements:

    • Hierarchy which contains the properties of the public folders and also  includes the tree-structure in which the Public Folders are organized. This tree structure contains Public- and System Public Folders.
    • Content which is the actual data (e.g. messages) in a Public Folder. Each Public Folder database contains a copy of the hierarchy, however not every database contained the same content:

image: a simplified graphical view of a public folder database

It was up to the administrator to define what content would be replicated across one (or more) servers. When a public folder was setup to have multiple copies, a process called “Public Folder replication” ensured that data was replicated across these “replicas” (= other public folder databases).

This replication is in no way comparable to how a DAG replicates data though: SMTP messages are sent between the different Mailbox Servers that hosted a Public Folder database:

image:a simplified overview of the PF replication model

Although from a data point-of-view having multiple writeable copies of Public Folders highly available: it is not. At least not when it comes to the end-user experience during a failover. Each Mailbox database is configured with a default (“preferred”) Public Folder database. Mailboxes within that mailbox database would automatically connect to their preconfigured “preferred” Public Folder database.

    • If – for some reason – the server hosting the Public Folder database would be unavailable entirely (e.g. offline), a timeout (+/- 60 seconds) would occur and clients would be redirected to another Public Folder database.
    • If, however, the server would still be online but the database would e.g. be dismounted, there would be no redirection and clients would end up with no Public Folders.

As you can imagine, not really a nice user experience, is it?

From a design point of view, Public Folders allowed you to easily spread data across multiple locations and have people make changes to the data in different locations. These changes are then replicated amongst the different replicas. In fact, Public Folders (in Exchange 2010 and before) are implemented in a sort of multi-master model:  all public folder replicas in a PF database are writeable.

Changes in Exchange Server 2013

Exchange Server 2013 entirely changes how Public Folders operate (from a technical point-of-view). From an end user’s perspective, everything remains as it used to be.

The main architectural changes that are introduced are:

    • Public folders are now stored in a mailbox database
    • Public folders now leverage a DAG for high-availability

Public Folder Mailboxes

Public folders are now also mailboxes, but their type is “Public Folder” (just like a Room Mailbox is a Mailbox with type “Room”). In a way, Public Folders still exist of two main elements mentioned above: the hierarchy and contents.

  • The hierarchy is represented by what is called the Master Hierarchy Public Folder Mailbox. This PF Mailbox contains a writeable copy of your public folder hierarchy. There is only a single Master Hierarchy PF mailbox in the organization.
  • Contents (in Public Folders) are now stored in one or more Public Folder mailboxes. These Public Folder mailboxes usually contain one or more Public Folders. Next to the contents, each PF Mailbox also contains a read-only copy of the hierarchy.


Note   because Public Folders are now stored in mailboxes, mailbox quota’s apply to them. For instance, this means that if a PF Mailbox would grow too large, you’d have to move Public Folders to another PF Mailbox (or increase the quota).

PF Mailboxes can grow quite large without really suffering from performance issues, just like regular mailboxes. Although real-world experience will have to tell us what the performance of Public Folders would be with a large amount of numbers, I’m confident that most companies won’t have a problem fitting a Public Folders in one (or more) PF Mailboxes. Nonetheless, you should carefully plan your Public Folder deployment, especially If you’re company heavily relies on them.

How do these “new” Public Folders work?

The process of connecting to and performing actions on a Public Folder could be summarized as follows:

    1. A user connects to a Public Folder (Mailbox).
    2. Any operation to the Public Folder is recorded in the PF mailbox
    3. If the data is located in another Public Folder Mailbox, the operation is redirected to the appropriate PF mailbox (which contains the Public Folder against which the action was performed)
    4. Hierarchy changes (e.g. adding or removing folders) are redirected to the Master Hierarchy PF Mailbox from where they are in turn replicated to all other PF Mailboxes (5).

Note   Hierarchy changes are never recorded through a regular PF Mailbox


High Availability.

Because Public Folders now reside in regular mailbox databases, they can benefit from the High Availability model that a Database Availability Group offers. Since you can store Public Folder mailboxes in any database, there’s no difference as to how they are treated in case of a failover.

The implications of changes

Because of these changes, the way we will implement Public Folders will also change. Foremost, placement for Public Folders will require a bit more planning from now on.There can only be a single active copy of a mailbox database at any given time, so we can no longer “benefit” from the multi-master model that existed previously.

This means that you should – preferably – place your Public Folder Mailboxes as close to your users as possible. If, however, to different groups need to work on the same set of folders but at opposite sites of the globe; you might be in for a challenge… Of course, one might start to wonder if Public Folders would be the right choice in such a scenario after all.

It’s not only good news

Unfortunately, every upside also has a downside: due to all the changes that were introduced, it seems that Microsoft isn’t able to get everything finished in time. At RTM we won’t have Public Folders in OWA. Perhaps this is something we’ll see added in SP1 (just like with Exchange 2010)…

Migration and coexistence

I will keep the migration and coexistence part for a future article. At the moment, Exchange Server 2013 Preview only support greenfield installs… On the other hand, if you’re interested in reading more on the migration stuff, you might want to take a look at a fellow-UC Architect Mahmoud Magdy’s blog about the new Public Folders.

Blog Exchange 2013

Management options in Exchange Server 2013 (Preview)


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

Chances are that, by now, you’ve already got Exchange Server 2013 Preview installed in your lab. High time to take a closer look at some of the things that have changed. In this article we’ll zoom in on some of the changes with regards to management of your Exchange Server 2013 (Preview).

Exchange Administrative Console (EAC)

One of the first things that will catch your eye will undeniably be the fact that the Exchange Management Console is missing. Indeed, the EMC has been replaced by a Web-Based GUI called Exchange Administrative Center (EAC). In fact, the EAC is kind of the successor of the Exchange Control Panel in Exchange 2010.

Right after you installed your server, you haven’t configured any URLs yet. The EAC will then typically be available at the following URL:


Note   Because you haven’t installed any certificates yet, a certificate warning will be thrown when navigating to the page. At this point, it’s still okay and you can safely ignore the warning.

Next, you’ll hit the login page. Did you notice how “clean” the metro-style interface looks?


After logging in, you will be taken to the EAC:


From there you will be able to execute quite a lot of tasks. The EAC has been build to replace the EMC without having to bind in on the possibilities you, as an admin, have. It will allow you to perform most of the tasks you were able to do with EMC and has been equipped with some new possibilities. Amongst these common tasks are, for example, the management of:

  • Recipients
  • Connectors
  • Certificates
  • High Availability (DAGs)
  • Role-Based Access Control (RBAC)
  • Compliance features (In-Place Hold, DLP, Retention Policies, …)

As you can see, most Administrators who are used to working with the EMC won’t have too much trouble getting along with EAC, as long as you don’t forget to turn of that pop-up blocker!Navigating the EAC is easy and pretty intuitive. Next to the trusted items like “Recipients”, “Organization” and “Servers”, you now have a single point of management for e.g. ActiveSync policies, RBAC management etc. In Exchange Server 2010 not all of these items were available from the EMC and required you to login to the Exchange Control Panel.

I encourage you to take a look around and play a bit with the EAC. In the upcoming weeks, I’ll be posting some how-to’s regarding some of the management tasks and I will be regularly referring to the EAC.


PowerShell still rocks the Exchange world. The Exchange Management Shell is your one-stop management interface from where you can do virtually anything with your Exchange environment. While junior admins might revert to the comfort the EAC offers, more seasoned administrators will certainly love PowerShell: Exchange Server 2013 uses the Management Framework 3.0 and therefore it relies on the power of PowerShell v3.

If you haven’t checked out what PowerShell v3 can do for you, I suggest that you have a look at the following page. It contains a list of articles that might prove useful!

Taking a look at one of many improvements to be found in PowerShell v3; I’m pretty sure the one-liners amongst us will just love the simplified syntax and what possibilities it offers.

For example, you could do something like the following:

 Get-Mailbox | where name –like “*partial*” 

Prior to v3 (e.g. in Exchange Server 2010), the same query would have looked like this:

Get-Mailbox | Where {$_.Name –like “*partial*”}

Pretty cool, isn’t it? Although I still find that when writing bigger scripts the latter seems more orderly, the first example comes in pretty handy when doing some quick searches or some rough filtering.

Note   these improvements are a general feature of PowerShell v3 and can be used anywhere with PowerShell.

New Exchange 2013 Cmdlets

Exchange 2013 (Preview) brings along a bunch of new PowerShell commands. Although most of them are related to new features like e.g. Site Mailboxes, there are also some new test commands and some existing cmdlet ‘sets’ have been extended. For example, one of the commands that was added to the Mail Flow cmdlets is:


Note   The help files are already available online! A quick search revealed the true purpose of this command:

Get-Help Redirect-Message –Online

For your reference, I’ve added a list of new cmdlets that can be found in Exchange 2013 (Preview):



As you can see, Office 2013 (Preview) commits to greater flexibility for the Administrator. I’m pretty excited to see the first scripts to pop up in the next few weeks and I’m sure there will be plenty to talk about in the future.

It’s also interesting to see how Exchange Server 2013 tends more to the cloud than ever before. Given that nowadays it’s all about BYOD, being mobile and being to work where and when you want, I believe that these improvements are for the better. The fact that you will be able to manage both Exchange on-premises as in the cloud from within a single Web-Interface, from virtually anywhere and almost every device is a HUGE leap forward.

Make sure to check back regularly as I will be posting more updates on Exchange Server 2013 in the upcoming days and weeks!

Blog Exchange 2013

How To: Deploy Exchange Server 2013


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

In this article, we’ll have a closer look at how to install Exchange Server 2013.

Before continuing, please make sure that you have fulfilled all the required prerequisites and that you have prepared your Active Directory. For more information, take a look at my other article:

For those who have already been working with Exchange Server 2010, you’ll notice that the process itself is pretty similar and as straightforward as it was before.

To start the setup of Exchange Server 2013, open PowerShell on the server you want to install and type in the following commands:

For the the Mailbox Server role only:

./setup.exe /mode:install /role:m /IAcceptExchangeServerLicenseTerms

For the Client Access Server role only:

./setup.exe /mode:install /role:c /IAcceptExchangeServerLicenseTerms

For both Mailbox Server & Client Access Server role:

./setup.exe /mode:install /role:m,c /IAcceptExchangeServerLicenseTerms

Note   Note the use of setup.exe and the /IAcceptExchangeServerLicenseTerms switch. (which was used before) is now deprecated and has been replaced by setup.exe.The licensing-switch is also new in Exchange Server 2013 and is required to launch the setup. Many admins will welcome the latter as it will generally save you some time with each deployment, now that you don’t have to wait for the licensing-message to display and time-out!

After you launch one of the commands from above, setup will kick off. Depending on what you are installing, the output might look like this:


Once setup completes successfully, restart the computer and you’re good to go!

Installation Logs

Setup creates a log file “ExchangeSetup.txt” under the root (as was the case in Exchange Server 2010):



I recommend that you take a look at the log after the installation file to check whether everything completed successfully. In case you encounter any issues, this is probably also the first place to go looking for more information.

Exchange 2013 How-To's

Active Directory Requirements for Exchange Server 2013 Preview


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

With Exchange Server 2013 Preview, it seems that Microsoft is “pushing” customers towards using Server 2008 or later. Not that I think that that is a bad thing, in the contrary! However, I still see customers that have Windows Server 2003 deployed and are using them as main Domain Controllers/Global Catalogs.

As per documentation, it seems no longer supported for Exchange Server 2013 Preview. You need at least one DC/GC running Windows Server 2008 or higher.

Although the Schema Master can still be Windows Server 2003, it seems logical to me that you’d rather standardize entirely on Server 2008, perhaps shortly even on Server 2012.

Below is an overview of the requirements for Active Directory:

Active Directory Forest Level: at least Windows Server 2003 or higher.

Schema Master: required for updating the AD schema for Exchange Server 2013 Preview

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise
  • Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)
  • Windows Server 2003 Standard Edition with Service Pack 2 (SP2) or later (32-bit or 64-bit)
  • Windows Server 2003 Enterprise Edition with SP2 or later (32-bit or 64-bit)

Global Catalog: each AD site that has a Exchange Server 2013 Preview installed, requires at least one server running:

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise
  • Windows Server 2008 R2 Datacenter RTM or later
  • Windows Server 2008 Standard or Enterprise (32-bit or 64-bit)
  • Windows Server 2008 Datacenter RTM or later

Domain Controller: each AD site that has an Exchange Server 2013 Preview installed, requires at least one server running:

  • Windows Server 2012
  • Windows Server 2008 R2 Standard or Enterprise SP1 or later
  • Windows Server 2008 R2 Datacenter RTM or later
  • Windows Server 2008 Standard or Enterprise SP1 or later (32-bit or 64-bit)
  • Windows Server 2008 Datacenter RTM or later
Blog Exchange 2013

A first look at what’s new in Exchange Server 2013 (and what’s still the same)?


All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

Over the past few months there have been quite some speculations about how Exchange Server 2013 would look like and what changes would be included.

Today, we can finally start taking a look at the latest member of Microsoft’s messaging platform: Exchange Server 2013.

This article only touches a subset of the things that changed. Over the upcoming days and week, I’ll be releasing more information so don’t forget to check back regularly!


Back in the days when Exchange Server 2007 was released, Microsoft “split” Exchange Server functionalities into multiple roles because – at that time – hardware was a limiting factor: you didn’t always have as much processing power as you could possibly need (at least not in an relative affordable way).

At first, this recommendation has been transferred over to Exchange Server 2010 only to be changed somewhere mid-lifecycle, simply because hardware now was powerful enough.

Now, In Exchange Server 2013 the number of available roles has drastically been reduced. There’s only a Client Access Server and a Mailbox Server role. The Client Access Server acts purely as a proxy (which means that it doesn’t process data!) while the latter is more like a combination of all the other roles (MBX, CAS, HT, UM). In a way you are now always deploying multi-role servers.

Because of these changes, the affinity between the Client Access Server and the Mailbox Server becomes less important whereas before, some protocols required you to connect through the same CAS. Because of some limitations that would still exist with the RPC protocol, it has been dropped entirely for all direct client connectivity. Yes, this means that your clients will only be connecting using HTTP (RPC over HTTP).

This change in behavior introduces some additional benefits:

  • You’re not necessarily required to deploy Hardware Load Balancers. DNS Round-Robin could do the trick.
  • The number of required namespaces is drastically reduced
    In particular, I especially like the reduction of the amount of namespaces that is required. Will make deployments a lot easier!

Store improvements

It seems that the store has been rewritten, AGAIN. Only this time, it has been rewritten in C# making it entirely future-proof Winking smileAlong with the new source code comes a new name: “Managed Store”. It’s designed to allow more granular management. In contrast to what some have been saying (perhaps even hoping), it continues to leverage ESE as the underlying engine. Why? Well, to quote Ross Smith IV on this topic: “SQL squeels like a pig where ESE is easy”… My guess is that he means that ESE still outperforms SQL when it comes to the typical transactions that are performed against an Exchange Database.Also new is that each database now runs within it’s own dedicated worker process: each mount-request will create a new worker process which exits when a database is successfully dismounted. This means that the process of one database does not necessarily impact another process/database when e.g. it hangs.

Indexing & Searching

As expected, and predicted: FAST is now integrated with the Managed Store to provide a better search & indexing experience.

High Availability

The Database Availability Group (DAG) is still responsible for providing high availability. However, some “under the hood”-changes like code improvements and a deeper checkpoint on passive nodes allow for faster fail-over times.


The Exchange Management Console is no more. It has been replaced by the Exchange Administrative Console (EAC), a web-based management interface that allows you to perform most of the common management tasks. Since the EAC resides on the server, it’s pretty much accessible from virtually anywhere and doesn’t require you to install the Management Tools like before. As with OWA, Safari, Firefox and Internet Explorer will be supported.

(Modern) Public Folders

For years, Microsoft has been deemphasizing the use of Public Folders. However, companies still continue to use them. Let’s forget some of the issues for a moment: they’re relatively easy to setup and are very easy to use.

That’s also one of the reasons why a lot of companies are still using them. One of the problems with Public Folders though, is that they cannot benefit from the Database Availability Group and therefore lack any real form of High Availability.

This changes to the better! Public Folders are now transferred into Public Folder mailboxes. This means that they reside in regular mailbox databases and therefore can benefit from a DAG’s protection. Look at it like this. Public Folders are now a new type of mailbox. To setup a new Public Folder, you’d use New-Mailbox –PublicFolder.

Of course there’s much more to it than this. For starters, I find the migration process – as it currently exists – a bit too complicated and am curious to see whether that will change. Check back over the upcoming days/weeks as I will be going more into detail about the new features and changes!

Site Mailboxes

Team Mailboxes are a great example of how the different products within the Office Suite come together. The idea behind Site Mailboxes is simple: it’s a “joint-venture” between SharePoint and Exchange Server allowing you to store and access items in SharePoint directly from Outlook, OWA or SharePoint itself.

This feature is huge but will require you to deploy Exchange 2013, SharePoint 2013 in combination with Outlook 2013.

Outlook Web App

A lot of effort has been put in OWA. It has completely been redesigned (and rewritten). The GUI is now entirely according the Metro-style you find anywhere else throughout Microsoft’s products and is available in different flavors. For each type of device there’s a different presentation: 1-column (smart phones), 2-column (tablets) or 3-column (mouse-based UI).

Along with the graphical changes & improvements, some features have been added as well:

  • Offline Access which will allow you to store a limited number of items in the browser’s offline cache.
  • People-centric: pretty similar to the “People Hub“ in Windows Phone
  • OWA Extensibility will allow 3rd-party applications to integrate with OWA, therefore enhancing the experience within.

What about ActiveSync?

ActiveSync is very popular: almost every device that’s out there supports the use of it. Unfortunately, the quality of the implementation depended on the licensee rather than the protocol itself. This could cause quite a lot of confusion and doesn’t improve either an administrator’s or end user’s experience: some devices would not support all A/S policies or “behave” badly.

Compliance & Discovery

That compliancy has become an important part of Exchange Server shouldn’t come as a surprise. Recent licensing changes already announced that multi-mailbox searches would no longer required an Enterprise CAL.

The importance of compliancy and discovery certainly shines through in the many changes and improvements that have been made:

  • You can now perform searches across the primary mailbox and archives in OWA
  • You can apply personal tags to default folders in OWA
  • Improved Discovery (e.g. exporting to PST is now possible from the eDiscovery Console; messages can now be previewed in the console)
  • “Federated Discovery” allowing to search through Exchange, Lync and SharePoint using a eDiscovery Console in SharePoint 15.
  • Improvements to litigation hold feature: you can now place a mailbox on hold using a query (query-based hold) or a defined timeframe (time-based hold).

So, what’s still the same?

Basically, almost everything that wasn’t mentioned above. They haven’t changed in that the way how these features work did not change. However, you should keep in mind that now the Exchange Management Console has been removed, they might be managed differently (either using EAC or EMS):

For example:

  • Address Book Policies,
  • Information Rights Management (IRM)
  • Personal Archives,
  • Federated Sharing

My personal thoughts…

To me, Exchange Server 2013 feels like a natural evolution of its predecessor Exchange Server 2010: there are no groundbreaking features, at least none that you couldn’t expect. It has already been predicted a long time ago that the management of Exchange would shift from the Exchange Management Console (EMC) and PowerShell (EMS) to a more web-based management portal (EAC) and EMS.

It seems that Microsoft has aligned the product more with what we see in the real world and I look forward experiencing how these changes will have a positive impact on both deployment and management of your Exchange server environment.

However, if there were a single item I had to choose from that I welcome the most, then I would most probably not be something in the Exchange Server’s architecture, but rather the unified end-user experience. I think this feature will be one of the key reasons that will drive the deployment of Exchange Server 2013 along with it’s deep(er) integration with products like SharePoint and Lync.


Please note that the information in the blog post is based on the current available build (public beta). The final version (RTM) might be different from the current one in that Microsoft can decided to add or remove certain features between now and RTM.

For more information, have a look at the Exchange Server 2013 Preview Documentation

Blog Exchange 2013