Configuring Database Availability Groups in Exchange Server 2013 Preview

Disclaimer:

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 192.168.20.110

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:

image_thumb[1]

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 http://support.microsoft.com/kb/324949 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:

    image

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

    image

  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: http://technet.microsoft.com/en-us/library/ff367878.aspx

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 192.168.20.110,192.168.30.110,192.168.40.110

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

Disclaimer:

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.

History

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
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
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.

image

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

image

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)

Disclaimer:

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:

https://servername/ECP

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?

image

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

image

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

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!

http://social.technet.microsoft.com/wiki/contents/articles/4741.powershell-v3-featured-articles-en-us.aspx

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:

Redirect-Message

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):

Add-GlobalMonitoringOverride
Add-ResubmitRequest
Add-ServerMonitoringOverride
Clear-MobileDevice
Complete-MigrationBatch
Disable-App
Disable-MailboxQuarantine
Disable-UMCallAnsweringRule
Dump-ProvisioningCache
Enable-App
Enable-MailboxQuarantine
Enable-UMCallAnsweringRule
Export-DlpPolicyCollection
Export-MigrationReport
Get-ActiveSyncDeviceAutoblockThreshold
Get-App
Get-AuthConfig
Get-AuthServer
Get-CalendarDiagnosticAnalysis
Get-ClassificationRuleCollection
Get-DataClassification
Get-DlpPolicy
Get-DlpPolicyTemplate
Get-ExchangeServerAccessLicense
Get-ExchangeServerAccessLicenseUser
Get-FrontendTransportServer
Get-FrontendTransportService
Get-GlobalMonitoringOverride
Get-HealthReport
Get-InterceptorRule
Get-MailboxSearch
Get-MailboxTransportService
Get-MalwareFilteringServer
Get-MalwareFilterPolicy
Get-MalwareFilterRecoveryItem
Get-MigrationBatch
Get-MigrationConfig
Get-MigrationEndpoint
Get-MigrationStatistics
Get-MigrationUser
Get-MigrationUserStatistics
Get-MobileDevice
Get-MobileDeviceMailboxPolicy
Get-MobileDeviceStatistics
Get-MonitoringItemHelp
Get-MonitoringItemIdentity
Get-Notification
Get-PartnerApplication
Get-PendingFederatedDomain
Get-PolicyTipConfig
Get-PublicFolderMailboxDiagnostics
Get-PublicFolderMigrationRequest
Get-PublicFolderMigrationRequestStatistics
Get-PublicFolderMoveRequest
Get-PublicFolderMoveRequestStatistics
Get-QueueDigest
Get-ResourcePolicy
Get-ResubmitRequest
Get-ServerComponentState
Get-ServerHealth
Get-ServerMonitoringOverride
Get-SiteMailbox
Get-SiteMailboxDiagnostics
Get-SiteMailboxProvisioningPolicy
Get-TeamMailbox
Get-TeamMailboxDiagnostics
Get-TeamMailboxProvisioningPolicy
Get-TransportService
Get-UMCallAnsweringRule
Get-UMCallRouterSettings
Get-UMMailboxConfiguration
Get-UMPhoneSession
Get-UserPhoto
Get-WorkloadManagementPolicy
Get-WorkloadPolicy
Import-DlpPolicyCollection
Import-DlpPolicyTemplate
Invoke-MonitoringProbe
New-App
New-AuthServer
New-ClassificationRuleCollection
New-DlpPolicy
New-InterceptorRule
New-MailboxSearch
New-MalwareFilterPolicy
New-MigrationBatch
New-MigrationEndpoint
New-MobileDeviceMailboxPolicy
New-PartnerApplication
New-PolicyTipConfig
New-PowerShellVirtualDirectory
New-PublicFolderMigrationRequest
New-PublicFolderMoveRequest
New-ResourcePolicy
New-SiteMailbox
New-SiteMailboxProvisioningPolicy
New-TeamMailbox
New-TeamMailboxProvisioningPolicy
New-UMCallAnsweringRule
New-WorkloadManagementPolicy
New-WorkloadPolicy
Redirect-Message
Remove-App
Remove-AuthServer
Remove-ClassificationRuleCollection
Remove-DlpPolicy
Remove-DlpPolicyTemplate
Remove-GlobalMonitoringOverride
Remove-HybridConfiguration
Remove-InterceptorRule
Remove-MailboxSearch
Remove-MalwareFilterPolicy
Remove-MalwareFilterRecoveryItem
Remove-MigrationBatch
Remove-MigrationEndpoint
Remove-MigrationUser
Remove-MobileDevice
Remove-MobileDeviceMailboxPolicy
Remove-PartnerApplication
Remove-PolicyTipConfig
Remove-PowerShellVirtualDirectory
Remove-PublicFolderMigrationRequest
Remove-PublicFolderMoveRequest
Remove-ResourcePolicy
Remove-ResubmitRequest
Remove-ServerMonitoringOverride
Remove-SiteMailboxProvisioningPolicy
Remove-TeamMailboxProvisioningPolicy
Remove-UMCallAnsweringRule
Remove-UserPhoto
Remove-WorkloadManagementPolicy
Remove-WorkloadPolicy
Reset-ProvisioningCache
Resume-MalwareFilterRecoveryItem
Resume-PublicFolderMigrationRequest
Resume-PublicFolderMoveRequest
Send-MapiSubmitSystemProbe
Set-ActiveSyncDeviceAutoblockThreshold
Set-App
Set-AuthConfig
Set-AuthServer
Set-ClassificationRuleCollection
Set-DlpPolicy
Set-FrontendTransportServer
Set-FrontendTransportService
Set-InterceptorRule
Set-MailboxSearch
Set-MailboxTransportService
Set-MalwareFilteringServer
Set-MalwareFilterPolicy
Set-MigrationBatch
Set-MigrationConfig
Set-MigrationEndpoint
Set-MobileDeviceMailboxPolicy
Set-Notification
Set-PartnerApplication
Set-PendingFederatedDomain
Set-PolicyTipConfig
Set-PublicFolderMigrationRequest
Set-PublicFolderMoveRequest
Set-ResourcePolicy
Set-ResubmitRequest
Set-ServerComponentState
Set-ServerMonitor
Set-SiteMailbox
Set-SiteMailboxProvisioningPolicy
Set-TeamMailbox
Set-TeamMailboxProvisioningPolicy
Set-TransportService
Set-UMCallAnsweringRule
Set-UMCallRouterSettings
Set-UMMailboxConfiguration
Set-UserPhoto
Set-WorkloadPolicy
Start-MigrationBatch
Start-UMPhoneSession
Stop-MigrationBatch
Stop-UMPhoneSession
Suspend-PublicFolderMigrationRequest
Suspend-PublicFolderMoveRequest
Test-MigrationServerAvailability
Test-OAuthConnectivity
Test-SiteMailbox
Test-TeamMailbox
Update-PublicFolderMailbox
Update-SiteMailbox
Update-TeamMailbox

Conclusion

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

Disclaimer:

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. Setup.com (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:

image

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):

C:\ExchangeSetupLogs

image

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

My first impressions of Office 365

Today, Microsoft announced an entire battery of new products from their range of Office products, including the new Lync, Exchange and Sharepoint Server. Along with these new products, they also announced an upgrade to Office 365 which will now be based on the newer version of the aforementioned products.

Along with the improvements that come along with the newer versions, Office 365 itself seems to have matured as well. Not only does the new UI look clean, but Microsoft seems to have done a pretty good job listening to the feedback from its customers.

One of the things that immediately caught my attention, for example, is the ability to turn on/off downloads for your end-users. Before, you couldn’t do this which left the possibility for your end users to download Office from the portal. A 850MB which – if you’re running low on bandwidth – was not really something you liked:

image

Of course new features in Exchange, Lync and SharePoint will also contribute to a much richer experience. I look forward playing a bit with Office 365 in the upcoming weeks.

Make sure to check back as I will be regularly posting updates on my findings!

Until later!

Screenshot of the new admin portal:

image

Office 365

Active Directory Requirements for Exchange Server 2013 Preview

Disclaimer:

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

Installing Exchange Server 2013 Preview Prerequisites

Disclaimer:

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 will have a first look at the different system prerequisites for installing Exchange Server 2013.

Supported Platforms

You can install Exchange Server 2013 either on Windows Server 2008 R2 or Windows Server 2012. Just as with Exchange Server 2010, you will need the enterprise edition of Windows Server 2008 R2 if you are going to deploy a Database Availability Group (DAG).

As recently announced, Windows Server 2012 does not include an Enterprise Edition anymore. The Standard Edition now also covers all product features. The number of licenses you need depends on the number of physical processors your system will have.

For a nice and clear overview of the licensing changes, please have a look at Aidan Finn’s blog post.

Preparing Active Directory

On the computer you are going to use to prepare Active Directory, you need at least the Remote Server Administration Tools for Active Directory installed. To install the tools, open up PowerShell and type in the following commands:

Import-Module ServerManager

Add-WindowsFeature RSAT-ADDS (if you’re running WS2008R2)

Install-WindowsFeature RSAT-ADDS (if you’re running WS2012)

You will also need the Microsoft .NET Framework 4.5 and Windows Management Framework 3.0. They are both already included on a system running Windows Server 2012.

Note  make sure that you have appropriate permissions to execute the tasks listed below. Permissions include membership of the Schema Admins and Enterprise Admins group.

Just as with Exchange Server 2010 – the following tasks need to be execute to prepare the Active Directory:

  • Update Schema
  • Prepare AD
  • Prepare Domains
    To update the schema, launch a PowerShell console and type in the following:

./setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

Note the use of “setup.exe”. Setup.com which was used before has been deprecated. There is also a new switch “/IAcceptExchangeServerLicenseTerms”. It will prevent the mandatory time-out which displays the warning that by waiting you agree with the license terms.

    Next, you’re up for preparing the AD:

./setup.exe /PrepareAD /ON:<exchange organization name>

This command will prepare Active Directory and amongst others configure the appropriate permissions. This includes the creation of the Microsoft Exchange Security Groups (if they do not exist yet).

Lastly, you need to prepare the domain(s). As part of this task, setup will create/update the Microsoft Exchange System Objects container, update the objectVersion attribute and create a domain local group in the targeted domain called “Exchange Install Domain Servers”.

System Prerequisites for Mailbox Server or Mailbox/Client Access Server (combined):

First, on the computer you are going to install Exchange Server 2013, run the following commands (PowerShell) to install the required Roles and Features:

For Windows Server 2012:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For Windows Server 2008 R2:

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

After you installed the operating system roles and features, you should install the following items:

Windows Server 2008 R2 Windows Server 2012
Microsoft .NET Framework 4.5 Microsoft Office 2010 Filter Pack 64 bit (Mailbox Server Role)
Windows Management Framework 3.0 Microsoft Office 2010 Filter Pack SP1 64 bit (Mailbox Server Role)
Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Microsoft Office 2010 Filter Pack 64 bit (Mailbox Server Role)
Microsoft Office 2010 Filter Pack SP1 64 bit (Mailbox Server Role)
Microsoft KB974405 (Windows Identity Foundation)
Microsoft KB2619234
Microsoft KB2533623

Once you installed the required prerequisites, execute the following steps:

  • Uninstall Microsoft Visual C++ 11 Beta Redistributable (x64)
    • Open Control Panel > Programs and Features.
    • Select Visual C++ 11 Beta Redistributable (x64) – 11.0.50531 and then click Uninstall.
    • In Microsoft Visual C++ 11 Beta setup, click Uninstall.
    • When Microsoft Visual C++ 11 Beta is uninstalled, click Close.

If you are running Windows Server 2008 R2, you should also execute the following step. Please note that you should execute this step afterhaving uninstalled Microsoft Visual C++ 11 Beta Redistributable (x64) and before you install Exchange Server 2013:

  • Register ASP.Net with .NET Framework 4.5 in IIS.

Open Command Prompt and type in the following commands:

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

IISReset

System Prerequisites Client Access Server only:

First, on the computer you are going to install Exchange Server 2013, run the following commands (PowerShell) to install the required Roles and Features:

For Windows Server 2012:

Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

For Windows Server 2008 R2:

Import-Module ServerManager

Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI

After you installed the operating system roles and features, you should install the following items:

Windows Server 2008 R2 Windows Server 2012
Microsoft .NET Framework 4.5 Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Windows Management Framework 3.0
Microsoft Unified Communications Managed API 4.0n Core Runtime 64bit
Microsoft KB974405 (Windows Identity Foundation)
Microsoft KB2619234
Microsoft KB2533623

Once you installed the required prerequisites, execute the following steps:

  • Uninstall Microsoft Visual C++ 11 Beta Redistributable (x64)
    • Open Control Panel > Programs and Features.
    • Select Visual C++ 11 Beta Redistributable (x64) – 11.0.50531 and then click Uninstall.
    • In Microsoft Visual C++ 11 Beta setup, click Uninstall.
    • When Microsoft Visual C++ 11 Beta is uninstalled, click Close.

If you are running Windows Server 2012, you should manually create a firewall rule. This rule will allow the Mailbox Server(s) to access the Client Access Servers’ registry:

    • Open Control Panel > Windows Firewall.
    • Click Advanced Settings.
    • In Windows Firewall with Advanced Security, click Inbound Rules and then click New Rule.
    • Select Port and then click Next.
    • Select TCP, and in Specify local ports, type 139. Click Next.
    • Select Allow the connection and then click Next.
    • Make sure Domain, Private, and Public are selected and then click Next.
    • Enter a name and description for the new rule and then click Finish.

If you are running Windows Server 2008 R2, you should also execute the following step. Please note that you should execute this step afterhaving uninstalled Microsoft Visual C++ 11 Beta Redistributable (x64) and before you install Exchange Server 2013:

  • Register ASP.Net with .NET Framework 4.5 in IIS.

Open Command Prompt and type in the following commands:

%SystemDrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -ir -enable

IISReset

Once you’ve completed the steps above, you are ready for deploying Exchange Server 2013 Preview!

Exchange 2013 How-To's