When you are running an Exchange 2013 database availability group in your environment you may have a need to remove one of the servers from the DAG, for example during decommissioning of server hardware.

If you were to try and simply uninstall Exchange 2013 from the server you would encounter an error during the readiness checks.

This computer is a member of a database availability group (DAG). It must be removed from the DAG before you can uninstall Exchange.

Following that advice if you were to try and remove the server from the DAG you may encounter this error.

Mailbox server ‘E15MB3′ cannot be removed from the database availability group because mailbox database ‘Mailbox Database 1′ has multiple copies. Use Remove-MailboxDatabaseCopy either to remove the copy from this server or to remove the copies from other servers in the database availability group.

By now I’m sure you realise that there is a process that needs to be followed before you can uninstall Exchange 2013 from the DAG member.

1. Removing database copies
2. Removing the Exchange server from the DAG

Let’s take a look at those steps in more detail.

Removing Database Copies

The first part of the process is the removal of database copies. There are actually two approaches here.

1. If you are planning to remove the server from the DAG but keep it as a standalone server hosting databases, then any copies of those databases must be removed from other DAG members first.
2. If you are planning to completely uninstall Exchange 2013 from the server then any database copies should be removed from the server that is being uninstalled.

Technically you could use the first approach even if you plan to completely uninstall the server, but even after removing the server from the DAG you won’t be able to uninstall Exchange 2013 if it still hosts databases that contain mailboxes.

See Exchange 2013 Database Removal Error: “This mailbox database contains one or more mailboxes” for more information.

So it makes sense to use the second approach for a server that is being completely decommissioned, which is the scenario I will be using for the rest of this tutorial.

In the Exchange Admin Center navigate to Servers -> Databases and select a database that has a copy on the server you are removing from the DAG.

If it happens to be the active database copy you would see an error and you must first switchover the database to another DAG member.

The database “Mailbox Database 3″ is currently hosted on server “E15MB3″. Use Move-ActiveMailboxDatabase to move the active copy of the database to a different server.

Click the Remove link for the database copy.

If you have multiple database copies to remove you can use this PowerShell command to remove them all. Again, this command won’t work if the database copy is active or if it is the only copy of the database.

[PS] C:\>Get-MailboxDatabaseCopyStatus -Server E15MB3 | Remove-MailboxDatabaseCopy

Removing the Server from the Database Availability Group

After removing all database copies from the DAG member the next step is to remove it from the DAG itself.

In the Exchange Admin Center navigate to Servers -> Database Availability Groups. Select the DAG and click the Manage DAG Membership button.

Highlight the server name and click the Remove button.

Click Save to complete the removal process.

You can also remove the DAG member using PowerShell.

[PS] C:\>Remove-DatabaseAvailabilityGroupServer -Identity E15DAG -MailboxServer E15MB3

Removing Exchange Server 2013

Now that the Mailbox server has no databases and has been removed from the DAG, and assuming the server performs no other roles in your organization, you can uninstall Exchange 2013.

This article How to Remove a DAG Member in Exchange Server 2013 is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

When you’re running an Exchange 2013 database availability group you will eventually need to deal with a failed database copy that needs to be reseeded.

Database copies may be in a failed state due to a variety of reasons, such as a hardware failure on the underlying storage system. After resolving the root cause of a failed database copy you then need to reseed the copy, which is a process that creates a new copy of the database by replicating the data from another DAG member that hosts a healthy copy.

To demonstrate how to reseed a failed database copy I’ve first caused a failure of one of my databases, which can be seen here in the output of the Get-MailboxDatabaseCopyStatus cmdlet.

[PS] C:\>Get-MailboxDatabaseCopyStatus *

Name                      Status
----                      ------
Mailbox Database 1\E15MB1 Healthy
Mailbox Database 2\E15MB1 FailedAndSuspended
Mailbox Database 1\E15MB2 Mounted
Mailbox Database 2\E15MB2 Mounted

If you’re looking for guidance to resolve failed content indexes in your database availability group, see PowerShell Tip: Fix All Failed Exchange Database Content Indexes.

The reseed operation can be started using either the Exchange Admin Center or the Exchange Management Shell (PowerShell).

Preparing to Reseed a Database Copy

There are a number of considerations when reseeding a database copy.

First, the time required for the reseed to complete will depend on the size of the database and the network performance between the source and destination servers.

By default the reseed will use the DAG member hosting the active database copy as the source.

If the database is 500Gb in size, that is 500Gb of database that needs to be copied across the network, plus the transaction log files and the content index for that database. This can add up to a lot of data that needs to travel across your network.

If the DAG members exist only within a single site connected by high speed LAN then this will not likely be a concern.

However if the DAG members exist in multiple sites across a WAN then it may be more of an issue.

Fortunately, you can specify a source server for the database reseed, which allows you to select a server that has better connectivity to reseed from, such as another DAG member within the same site as the server with the failed database copy.

The options for selecting a reseed source will be demonstrated below.

Reseeding a Database Copy Using the Exchange Admin Center

Open the Exchange Admin Center and navigate to Servers -> Databases. Select the database that has the failed copy.

On the database copy that is shown as failed click the Update link.

You can click Browse and specify a source server if necessary, otherwise click Save to reseed from the server that hosts the active database copy.

Wait for the reseed operation to complete.

When the reseed operation has finished the database copy should now be healthy.

Reseeding a Database Copy using the Exchange Management Shell

We can also perform reseeds using the Update-MailboxDatabaseCopy cmdlet.

The database to reseed is entered in the format “Database Name\Server Name”, for example:

[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1"

To specify a source server for the reseed use the -SourceServer parameter as well.

[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -SourceServer EXMB3

If you receive an error message that log files already exist in the transaction log path for the database you can use the -DeleteExistingFiles parameter to tell the Exchange server to remove those files before beginning the reseed.

[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -DeleteExistingFiles

Finally, for long reseeds where you do not want to leave your Exchange Management Shell open, or when scripting a reseed and you don’t want the script to have to wait for the reseed to complete, you can use the -BeginSeed parameter.

[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -BeginSeed

Of course those parameters can be used in conjunction with each other, for example:

[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -DeleteExistingFiles -BeginSeed -SourceServer E15MB3

Monitoring Database Copy Health

If you do not already have a monitoring solution in place for your Exchange 2013 DAG I encourage you to try my Get-DAGHealth.ps1 or Test-ExchangeServerHealth.ps1 scripts.

This article How to Reseed a Failed Database Copy in Exchange Server 2013 is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

The high availability feature for Exchange Server 2013 Mailbox servers is the Database Availability Group.

Exchange 2013 Database Availability Groups (DAGs) are very similar to Exchange 2010 DAGs, but also deliver a series of improvements and new features for customers.

In this series of articles we will walk through an overview of Database Availability Group concepts, demonstrate how to deploy a new Database Availability Group, and explore some of the operational tasks associated with running and maintaining a DAG.

See also:

• Installing an Exchange Server 2013 Database Availability Group
• Configuring Database Copies in an Exchange Server 2013 Database Availability Group
• Managing Database Switchovers for Exchange Server 2013 Database Availability Groups
• Improving Resilience of Exchange 2013 DAGs with Windows Server 2012 Cluster Dynamic Quorum
• How to Remove a DAG Member in Exchange Server 2013
• How to Reseed a Failed Database Copy in Exchange Server 2013

Overview of Exchange Server 2013 Database Availability Groups

A Database Availability Group consists of up to 16 Exchange 2013 Mailbox servers, and optionally one or more additional non-Exchange servers that may be required to act as a File Share Witness (more on this shortly).

The Mailbox servers within a DAG are capable of hosting a copy of a mailbox database from another DAG member; up to the Exchange 2013 limit of 50 mailbox databases per server (that includes both active and passive database copies).

A simple example of a Database Availability Group would be as follows.

A simple example of an Exchange 2013 Database Availability Group

In the example above the server EXMB1 hosts the active copy of database DB1, and the other DAG members EXMB2 and EXMB3 host passive copies of the database.

The DAG members work together to maintain the availability of the mailbox database. If the server that hosts the active database copy experiences a problem, for example a hardware failure, one of the remaining DAG members is able (under the right conditions) to make it’s copy of the database active so clients are still able to connect to their mailbox data.

DAG member EXMB1 has failed causing database to become active on EXMB2

A Mailbox server that is a member of a DAG can host a mixture of active and passive database copies for which it participates in replication. Whether a given database is active or passive on a particular DAG member is independent of the active/passive status of other databases that are also hosted on that DAG member.

Multiple databases within an Exchange 2013 DAG

In the above example a DAG with three members and three mailbox databases is shown with the active database copies evenly distributed across the available DAG members.

Continuous Replication in Exchange Server 2013 Database Availability Groups

Each DAG member hosting a copy of a given mailbox database participates in a process of continuous replication to keep the copies consistent.

Database replication occurs between Exchange Server 2013 DAG members using two different methods:

File Mode replication – each transaction log is fully written (a 1MB log file) and then then copied from the DAG member hosting the active database copy to each DAG member that host a passive database copy of that database. The other DAG members then replay the transaction log file into their own passive copy of the database to update it.

File mode replication has an obvious downside in that a transaction log that hasn’t already been copied to the other DAG members may be lost if the DAG member hosting the active database copy becomes unavailable. Although there are other recovery mechanisms to minimise the impact of this scenario, this is a reason why file mode replication is used only during the initial seeding of a database copy.

After seeding is complete the database switches automatically to block mode replication.

Block mode replication – as each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database. As the log buffer becomes full member of the DAG is then able to build their own transaction log file for replay into their passive database copy.

Block mode replication has advantages compared to file mode replication when there is a failure in the DAG, because less transaction log data is likely to be lost.

Quorum for Exchange Server 2013 Database Availability Groups

An Exchange 2013 DAG utilizes Windows Failover Clustering and the quorum model. This underlying cluster is managed automatically for you by Exchange, so you don’t need to worry about it much other than to be aware of how quorum works.

If the concept of quorum is new to you just think of it as a voting process in which a majority of voting members must be present to make a decision. The decision in the case of a DAG is basically whether the DAG should be online of offline.

Because a majority of votes is required for quorum there are two different quorum models used depending on how many DAG members you have.

For a DAG with an odd number of members the Node Majority quorum mode is used.

Impact of failures in Exchange 2013 DAG using Node Majority quorum mode

In the above example a three member DAG is able to maintain quorum during a single server failure, but quorum is lost when two servers are unavailable.

For a DAG with an even number of members the Node and File Share Majority quorum mode is used. This mode involves an additional server referred to as the File Share Witness. It is typically another Exchange server located in the same site as the DAG members.

Impact of failures in Exchange 2013 DAG using Node and File Share Majority quorum mode

In the above example a four member DAG is using an additional server as the File Share Witness (FSW). The DAG is able to maintain quorum with up to two server failures, but quorum is lost when three servers are down.

DAGs deployed on Windows Server 2012 can be more resilient to multiple node failures thanks to a new feature called dynamic quorum. For more information see Improving Resilience of Exchange Server 2013 Database Availability Groups with Windows Server 2012 Cluster Dynamic Quorum

Database Availability Networks

A DAG network refers to a collection of one or more IP subnets that the DAG members are connected to and are used for client and replication traffic.

Exchange 2013 DAG with a single network

Every DAG has one network for client traffic, and then it can also optionally have a number of networks dedicated to replication traffic.

Exchange 2013 DAG with multiple networks

Dedicated replication networks can help reduce bandwidth utilization on the client-facing network which may prevent network-related performance issues for the clients.

Exchange Server 2013 will attempt to auto-configure DAG networks but may not be able to if the network adapter configurations are not correct. For more info see Misconfigured Subnets Appear in Exchange Server 2013 DAG Network

High Availability and Site Resilience

Exchange Server 2013 Database Availability Groups can be deployed to provide both high availability and site resilience.

A DAG deployed for high availability will typically exist within a single Active Directory Site, or datacenter.

Exchange 2013 DAG in a single datacenter

A DAG deployed for site resilience will span multiple datacenters. The objectives of a Database Availability Group deployed for site resilience are usually to provide availability of mailbox services after the complete failure of the primary datacenter. In other words, a true disaster.

Exchange 2013 DAG in multiple datacenters

As such there are a lot more technical and business considerations for a site resilient Database Availability Group. There is also less automation and more administrator attention required for a full site failover scenario.

For the purposes of this article series we’ll be focusing on Database Availability Groups deployed within a single datacenter for high availability.

Installing an Exchange Server 2013 Database Availability Group

The next article in this series will begin demonstrating the deployment of a Database Availability Group in Exchange Server 2013.

• Installing an Exchange Server 2013 Database Availability Group

This article Exchange Server 2013 Database Availability Groups is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Since I released the Test-ExchangeServerHealth.ps1 script one of the most common feature requests has been to add health checks for Database Availability Groups.

So today I am pleased to announce the availability of Get-DAGHealth.ps1, a Database Availability Group health check PowerShell script.

This is the first release to your feedback and bug reports are welcome in the comments below. I hope to eventually merge this with the Test-ExchangeServerHealth.ps1 script to provide a single, daily health check script that you can use for your Exchange environments.

Please read the usage instructions in below or in the script help info.

This script is available for download by Exchange Server Pro Insiders. Join here it’s free.

Running Get-DAGHealth.ps1

The script is written and tested for Exchange Server 2010 and Exchange Server 2013 CU1.

The script requires the Exchange Management Tools to run. You can execute it from the Exchange Management Shell, or a regular PowerShell session and it will add the Exchange snapin if not already loaded.

You can also execute it as a scheduled task. I use the follow settings in my scheduled task to make it work:

• Run whether user is logged on or not
• Run with highest privileges
• Action:
  • Start a program: powershell.exe
  • Arguments: -command “c:\scripts\daghealth\get-daghealth.ps1 -Detailed -SendEmail”
• You may need to modify your script execution policy to run this script as it is not signed
• You may need to open the Properties of the downloaded file and “unblock” it before it will run

Use Get-Help to see more usage details and examples.

PS C:\Scripts\DAGHealth> get-help .\Get-DAGHealth.ps1 -Examples

NAME
    C:\Scripts\DAGHealth\Get-DAGHealth.ps1

SYNOPSIS
    Get-DAGHealth.ps1 - Exchange Server 2010 Database Availability Group Health Check Script.

    -------------------------- EXAMPLE 1 --------------------------

    C:\PS>.\Get-DAGHealth.ps1

    Checks all DAGs in the organization and outputs a health summary to the PowerShell window.

    -------------------------- EXAMPLE 2 --------------------------

    C:\PS>.\Get-DAGHealth.ps1 -Detailed

    Checks all DAGs in the organization and outputs a detailed health report to the PowerShell
    window. Due to the amount of detail the full report may get cut off in your window. I recommend
    detailed reports be output to HTML file or email instead.

    -------------------------- EXAMPLE 3 --------------------------

    C:\PS>.\Get-DAGHealth.ps1 -Detailed -SendEmail

    Checks all DAGs in the organization and outputs a detailed health report via email using
    the SMTP settings you configure in the script.

I generally recommend using the HTML file or email output to get the best results. The HTML output gives a color-coded health report to bring to your attention any potential health issues such as databases not active on their first preference server, unhealthy copies or queues, unhealthy content indexes, and other things that can sometimes go unnoticed with DAGs.

The report is indicative only. You should investigate and validate any issues that it flags to determine what if any action is required to resolve them.

This script is available for download by Exchange Server Pro Insiders. Join here it’s free.

Change Log:

• V1.0 – 14/02/2013 – Initial release
• V1.1 – 24/04/2013 – Bug fixes, Exchange 2013 compatibility

Feedback and bug reports welcome in the comments below. If you like this script please feel free to share this article with your friends and colleagues on Twitter, Facebook, LinkedIn, Google+ etc. You might also be interested in some of my other PowerShell scripts.

This article Get-DAGHealth.ps1 – Database Availability Group Health Check Script is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Databases that are being replicated within an Exchange Server 2013 database availability group can generally be considered to be either active or passive at any given time.

There are also other states that the database may be in, such as seeding, or due to health problems, but for the purposes of this article we’re going to be looking only at healthy database copies.

The active database copy is the one that is mounted on a DAG member and is being used to serve clients. The passive database copies (up to 15 of them) are those that reside on other mailbox servers within the DAG. Changes are replicated from the active database copy to the passive database copies.

The active database copy can be “moved” between DAG members that host a copy of that database. Although some people consider this to be an actual “move” of the data from one server to the other, in actual fact what is occurring is the active database copy is dismounted, and one of the passive database copies is then mounted.

There are two ways that the active database copy can be moved to another DAG member:

• Failover – this is an unplanned event, such as a failure of the server hosting the active copy
• Switchover – this is a deliberate, administrator-driven event, such as during server maintenance

In this article we’ll look specifically at the database switchover.

Consider a two-member DAG with two databases. Each server hosts one active and one passive database copy.

To move Mailbox Database 1 to E15MB2 we can simply highlight it and then review the status of the database copies. Note that in this case the passive copy on E15MB2 is healthy, with no copy queue length issues and a healthy content index state as well.

Under those conditions we can proceed with the switchover by clicking the link to Activate the database copy.

You’ll be prompted to confirm the action, and then a progress bar let’s you know when the operation is complete.

Click Close when it is finished. In this case we can see that the database is now active on server E15MB2.

This article Managing Database Switchovers for Exchange Server 2013 Database Availability Groups is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

With an Exchange Server 2013 database availability group you may encounter misconfigured subnets in the DAG network configuration.

These will be noticeable in the output of the Get-DatabaseAvailabilityGroupNetwork cmdlet.

This can occur when the database availability group automatic network configuration is not able to correctly determine how to configure each network.

Exchange Server 2013 Automatic DAG Network Configuration

Automatic network configuration is a new feature of database availability groups in Exchange 2013. In Exchange 2010 although DAG networks were automatically created they were usually not configured correctly by default, especially when multiple subnets were being used.

As a result Exchange 2010 administrators had to manually reconfigure and collapse the DAG networks for the best DAG network performance and to avoid some problem scenarios.

Automatic network configuration in Exchange 2013 seeks to relieve some of that burden, however it can have problems when it is not able to clearly determine which subnets should be configured on which networks.

To make those decisions Exchange 2013 follows a few basic rules of DAG network interface configuration.

1. The MAPI, or client-facing network interface should be configured with
   • a default gateway
   • at least one DNS server
   • “Register this connection’s addresses in DNS” enabled
2. The replication network interfaces, if there are any, should be configured with:
   • no default gateway
   • no DNS servers
   • “Register this connection’s address in DNS” disabled
   • static routes if the network will span multiple IP subnets

If those conditions are not met then DAG network automatic configuration may not produce a good result.

Example Scenario

For example, in this three member DAG the server E15MB3 is located in a different subnet to the other two servers.

The “Register this connection’s address in DNS” checkbox has been inadvertently left ticked.

Before the server E15MB3 is added as a DAG member the networks appear like this:

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | select Name,Subnets,Interfaces

Name               : MapiDagNetwork
Subnets            : {{192.168.0.0/24,Up}}
Interfaces         : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}}

Name               : ReplicationDagNetwork01
Subnets            : {{10.1.100.0/24,Up}}
Interfaces         : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}}

After the server is added as a DAG member the networks appear like this:

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | fl

Name               : MapiDagNetwork
Subnets            : {{192.168.0.0/24,Misconfigured}, {192.168.1.0/24,Misconfigured}, {10.1.101.0/24,Misconfigured}}
Interfaces         : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}, {E15MB3,Up,192.168.1.190},
                     {E15MB3,Up,10.1.101.2}}

Name               : ReplicationDagNetwork01
Subnets            : {{10.1.100.0/24,Up}}
Interfaces         : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}}

Correcting the Misconfigured Subnets

Once the misconfiguration is present in the DAG networks you can take a few steps to correct it.

The first is to review the network interface configurations and adjust them to align with the conditions outlined earlier. In this case this means disabling DNS registration on the replication network interface of E15MB3.

The Set-DatabaseAvailabilityGroup cmdlet has a -ManualDagNetworkConfiguration parameter that can be enabled to allow manual network configuration.

[PS] C:\>Set-DatabaseAvailabilityGroup E15DAG -ManualDagNetworkConfiguration $true

Simply running that command appears to force the DAG to reassess the network configuration, and in my own testing this resulted in a correct DAG network configuration without me actually having to perform any manual configuration.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork | select Name,Subnets,Interfaces

Name       : MapiDagNetwork
Subnets    : {{192.168.0.0/24,Up}, {192.168.1.0/24,Up}}
Interfaces : {{E15MB1,Up,192.168.0.187}, {E15MB2,Up,192.168.0.188}, {E15MB3,Up,192.168.1.190}}

Name       : ReplicationDagNetwork01
Subnets    : {{10.1.100.0/24,Up}, {10.1.101.0/24,Up}}
Interfaces : {{E15MB1,Up,10.1.100.2}, {E15MB2,Up,10.1.100.3}, {E15MB3,Up,10.1.101.2}}

With the networks now correctly configured you can set the DAG back to automatic network configuration if you wish.

[PS] C:\>Set-DatabaseAvailabilityGroup E15DAG -ManualDagNetworkConfiguration $false

The DAG networks should remain correctly configured.

Summary

As you can see automatic network configuration in Exchange Server 2013 database availability groups makes our lives a bit easier by reducing the amount of manual configuration required in more complex DAGs.

However, it relies heavily on correct underlying network interface configurations, so you need to ensure those are configured properly before you begin adding servers to your DAG.

This article Misconfigured Subnets Appear in Exchange Server 2013 DAG Network is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

I’ve just updated the Get-DAGHealth.ps1 PowerShell script to version 1.1. The new version fixes some bugs with how the replication queues for lagged copies are handled, which seemed to be causing incorrect report results.

As an additional update I am pleased to announce that the script is now tested and working for Exchange Server 2013 database availability groups as well. I have not yet tested a mixed 2010/2013 org though.

You can download the new version here.

Please continue to report bugs and make feature requests in the comments on that post.

This article V1.1 of Get-DAGHealth.ps1 is Available is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

I have just uploaded version 1.2 of the Test-ExchangeServerHealth.ps1 script.

This version includes a number of important bug fixes, as well as adding the DAG health check (from Get-DAGHealth.ps1).

You can download the new version here.

Please continue to report bugs and make feature requests in the comments on that post.

This article Test-ExchangeServerHealth.ps1 v1.2 Released is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2013 can be installed on either Windows Server 2008 R2 or Windows Server 2012.

Some organizations may decide to install on Windows Server 2008 R2 because that is their standard server build and to remain consistent with the rest of their server fleet. However, doing that will mean they miss out on the new features of Windows Server 2012.

One of those new features is a cluster quorum management option known as dynamic quorum.

As TechNet explains:

When this option is enabled, the cluster dynamically manages the vote assignment to nodes, based on the state of each node. Votes are automatically removed from nodes that leave active cluster membership, and a vote is automatically assigned when a node rejoins the cluster.

With dynamic quorum management, it is also possible for a cluster to run on the last surviving cluster node. By dynamically adjusting the quorum majority requirement, the cluster can sustain sequential node shutdowns to a single node.

In an Exchange context, dynamic quorum can make database availability groups more resilient to multiple node failures.

To demonstrate this, here is what happens to an Exchange Server 2010 DAG when it suffers multiple node failures.

To begin with the DAG is healthy and all nodes and resources are online.

[PS] C:\>Get-Cluster | Get-ClusterNode

Name          State
----          -----
ho-ex2010-mb1    Up
ho-ex2010-mb2    Up

[PS] C:\>Get-MailboxDatabase | Test-MAPIConnectivity

MailboxServer      Database           Result    Error
-------------      --------           ------    -----
HO-EX2010-MB1      MB-HO-01           Success
HO-EX2010-MB1      MB-HO-02           Success
BR-EX2010-MB       MB-BR-01           Success
HO-EX2010-MB1      MB-HO-03           Success
HO-EX2010-PF       MB-HO-Archive      Success

Next, I take down the file share witness, and then a short time later one of the DAG members as well.

[PS] C:\>Get-Cluster | Get-ClusterNode

Name          State
----          -----
ho-ex2010-mb1    Up
ho-ex2010-mb2  Down

After a few moments the cluster determines that quorum has been lost, and the remaining node stops as well.

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Date: 5/27/2013 8:12:22 PM
Event ID: 1177
Task Category: Quorum Manager
Level: Critical
Keywords:
User: SYSTEM
Computer: HO-EX2010-MB1.exchangeserverpro.net
Description:
The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk.

The entire cluster is now down, taking the mailbox databases with it, even though a single DAG member was still online.

[PS] C:\>Get-MailboxDatabase | Test-MAPIConnectivity

MailboxServer      Database           Result    Error
-------------      --------           ------    -----
HO-EX2010-MB1      MB-HO-01           *FAILURE* Database is dismounted.
HO-EX2010-MB1      MB-HO-02           *FAILURE* Database is dismounted.
BR-EX2010-MB       MB-BR-01           Success
HO-EX2010-MB1      MB-HO-03           *FAILURE* Database is dismounted.
HO-EX2010-PF       MB-HO-Archive      Success

Now let’s take a look at what happens to an Exchange 2013 DAG running on Windows Server 2012 with dynamic quorum enabled (which is the default setting). This Exchange 2013 DAG in my lab happens to have more Mailbox servers as members than my Exchange 2010 DAG, but that does not impact the demonstration.

Again, to begin with the cluster resources are all healthy and online.

[PS] C:\>Get-MailboxDatabase | Test-MAPIConnectivity
Creating a new session for implicit remoting of "Get-

MailboxServer      Database           Result    Error
-------------      --------           ------    -----
E15MB1             Mailbox Database 1 Success
E15MB1             Mailbox Database 2 Success

[PS] C:\>Get-Cluster | Get-ClusterNode | Select Name,DynamicWeight,NodeWeight,Id,State

Name   DynamicWeight NodeWeight Id State
----   ------------- ---------- -- -----
E15MB1             1          1 1     Up
E15MB2             1          1 2     Up
E15MB3             1          1 3     Up

Each node currently has 1 vote (shown as DynamicWeight in the output above). Two of three votes (a majority) is required to achieve quorum, which the cluster has.

First I’ll shut down one of the DAG members. Now let’s take another look at the nodes.

[PS] C:\>Get-Cluster | Get-ClusterNode | Select Name,DynamicWeight,NodeWeight,Id,State

Name   DynamicWeight NodeWeight Id State
----   ------------- ---------- -- -----
E15MB1             0          1 1     Up
E15MB2             1          1 2     Up
E15MB3             0          1 3   Down

As this article explains, dynamic quorum kicks in and removes the vote from one of the remaining cluster nodes. Now only one node has a vote, and quorum is maintained.

If this were a Windows Server 2008 R2 cluster quorum would also be maintained, however the difference is in what happens on the next node failure.

Next I take down another DAG member. With one remaining DAG member the Exchange 2010 cluster and databases went offline. However the Exchange 2013 DAG stays online thanks to dynamic quorum.

[PS] C:\>Get-Cluster | Get-ClusterNode | Select Name,DynamicWeight,NodeWeight,Id,State

Name   DynamicWeight NodeWeight Id State
----   ------------- ---------- -- -----
E15MB1             1          1 1     Up
E15MB2             0          1 2   Down
E15MB3             0          1 3   Down

[PS] C:\>Get-MailboxDatabase | Test-MAPIConnectivity

MailboxServer      Database           Result    Error
-------------      --------           ------    -----
E15MB1             Mailbox Database 1 Success
E15MB1             Mailbox Database 2 Success

While this is only a simple demonstration it does show the potential of dynamic quorum for making Exchange 2013 database availability groups more resilient.

Although there are other failure scenarios that may still cause the DAG to go offline (eg multiple simultaneous server failures), with the right cluster design and operational procedures for managing the cluster you can achieve a good outcome.

For more on dynamic quorum in Windows Server 2012:

• Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster
  
• Windows Server 2012 Failover Clustering Dynamic Quorum

This article Improving Resilience of Exchange Server 2013 Database Availability Groups with Windows Server 2012 Cluster Dynamic Quorum is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

The Test-ReplicationHealth PowerShell cmdlet can be run on an Exchange Server 2013 Mailbox server that is a member of a database availability group.

[PS] C:\>Test-ReplicationHealth

Server          Check                      Result     Error
------          -----                      ------     -----
E15MB2          ClusterService             Passed
E15MB2          ReplayService              Passed
E15MB2          ActiveManager              Passed
E15MB2          TasksRpcListener           Passed
E15MB2          TcpListener                Passed
E15MB2          ServerLocatorService       Passed
E15MB2          DagMembersUp               Passed
E15MB2          ClusterNetwork             Passed
E15MB2          QuorumGroup                Passed
E15MB2          DatabaseRedundancy         Passed
E15MB2          DatabaseAvailability       Passed
E15MB2          DBCopySuspended            Passed
E15MB2          DBCopyFailed               Passed
E15MB2          DBInitializing             Passed
E15MB2          DBDisconnected             Passed
E15MB2          DBLogCopyKeepingUp         Passed
E15MB2          DBLogReplayKeepingUp       Passed

You can also run the cmdlet against a remote server.

[PS] C:\>Test-ReplicationHealth -Identity E15MB2

Server          Check                      Result     Error
------          -----                      ------     -----
E15MB2          ClusterService             Passed
E15MB2          ReplayService              Passed
E15MB2          ActiveManager              Passed
E15MB2          TasksRpcListener           Passed
E15MB2          TcpListener                Passed
E15MB2          ServerLocatorService       Passed
E15MB2          DagMembersUp               Passed
E15MB2          ClusterNetwork             Passed
E15MB2          QuorumGroup                Passed
E15MB2          DatabaseRedundancy         Passed
E15MB2          DatabaseAvailability       Passed

The cmdlet also accepts pipeline input, however if you were to simply pipe Get-MailboxServer into it and you have Mailbox servers in the organization that are not DAG members then you risk seeing errors in your results.

Instead you can pipe only the members of a database availability group into Test-ReplicationHealth using the following method:

[PS] C:\>Get-DatabaseAvailabilityGroup | select -ExpandProperty:Servers | Test-ReplicationHealth

Note: The number of tests shown in the output of Test-ReplicationHealth will vary depending on whether the DAG member has only active or passive databases on it at the time. Not all tests are relevant if the server has only active, or only passive databases on it.

This article Exchange Server 2013: Using Test-ReplicationHealth to Test Database Availability Group Members is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

In a comment on my article about installing updates on Exchange 2010 DAG members Greg asks:

I would like to know how many Exchange admins [ahem] server admins actually follow these steps when they patch, we have a lab where we just patch Server A in a two multi role server DAG reboot it, then patch Server B and reboot it, then balance out the databases evenly among them and call it an evening, no problems so far

To be fair we didn’t go to Exchange 2010 until SP3 so maybe things are more better with SP 3 but we don’t bother with any of the procedures above and use Exchanges built in intelligence.

Now Greg does say that this is how they patch their lab servers, so it isn’t clear whether this is how they treat their production servers. However it is still a topic worth discussing.

The short answer, from my point of view, is that running the DAG maintenance scripts is the wisest course of action. And I’m sure that anyone who has experienced a scenario where those scripts fail to switchover a database due to some other underlying condition at the time would agree with me.

For anyone else who is just running them because it looks like “the way it is done”, and is curious why this is the wisest course of action, let’s look briefly at the possible consequences of not running the DAG maintenance scripts during server maintenance.

Consider that Exchange Server is an application running on a Windows server. When someone tells that server to shut down or restart, Windows is going to shut down or restart. In most situations the Exchange Server gets little say in the matter.

In the process of Windows Server stopping Exchange services, the Primary Active Manager will try to switchover any active mailbox database copies to another DAG member. In a simple two-member DAG it is pretty obvious where the active database copy will end up. In larger DAGs there is a little more to it. If you want to dive into the full details read up on the Best Copy Selection process here.

If you do read that then you might notice the term “lossy failover”.

A lossy failover is a potential data loss scenario. And the default AutoDatabaseMountDial setting of “GoodAvailability” allows lossy failovers to occur. And even with Exchange Server’s ability to automatically attempt to recover data lost in a lossy failover, it is not a guarantee.

For a test lab this is not likely to be a concern, and most of the time I allow my own test lab servers to automatically patch and restart (on separate schedules) without my manual intervention.

From time to time there is a problem as a result of that, which requires me to apply a little bruce force and occasionally accept some data loss to bring all databases online again.

In a production environment I would really hate to put myself in that situation, or know that others are putting themselves in that situation simply because they can’t be bothered running the DAG maintenance scripts. My recommendation is to always use the DAG maintenance scripts during patching or other server maintenance on your DAG members.

This article Why Bother Running DAG Server Maintenance Mode Scripts? is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

When activating a database copy in an Exchange Server 2010 Database Availability Group it may fail with an error message that catalog index files are in a failed state.

——————————————————–
Microsoft Exchange Error
——————————————————–
Cannot activate database copy ‘Activate Database Copy…’.

Activate Database Copy…
Failed
Error:
An Active Manager operation failed. Error The database action failed. Error: An error occurred while trying to validate the specified database copy for possible activation. Error: Database copy ‘MB-HO-03′ on server ‘HO-EX2010-MB2.exchangeserverpro.net’ has content index catalog files in the following state: ‘Failed’.. [Database: MB-HO-03, Server: HO-EX2010-MB1.exchangeserverpro.net]

An Active Manager operation failed. Error An error occurred while trying to validate the specified database copy for possible activation. Error: Database copy ‘MB-HO-03′ on server ‘HO-EX2010-MB2.exchangeserverpro.net’ has content index catalog files in the following state: ‘Failed’..

When you view the copy status of the mailbox database the content index is in a failed state.

[PS] C:\>Get-MailboxDatabaseCopyStatus | fl name, contentindexstate

Name              : MB-HO-01\HO-EX2010-MB1
ContentIndexState : Healthy

Name              : MB-HO-04\HO-EX2010-MB1
ContentIndexState : Healthy

Name              : MB-HO-03\HO-EX2010-MB1
ContentIndexState : Failed

Name              : MB-HO-02\HO-EX2010-MB1
ContentIndexState : Healthy

There are two likely causes of this issue.

1. The content index has failed due some error or fault occurring
2. Indexing has been disabled for that database (a common configuration for databases hosting journal mailboxes)

Fixing Failed Content Indexes

To resolve the issue update the content index on the server on which it has failed.

[PS] C:\>Update-MailboxDatabaseCopy "MB-HO-03\HO-EX2010-MB1" -CatalogOnly

The content index should now be in a healthy state.

[PS] C:\>Get-MailboxDatabaseCopyStatus | fl name, contentindexstate

Name              : MB-HO-01\HO-EX2010-MB1
ContentIndexState : Healthy

Name              : MB-HO-04\HO-EX2010-MB1
ContentIndexState : Healthy

Name              : MB-HO-03\HO-EX2010-MB1
ContentIndexState : Healthy

Name              : MB-HO-02\HO-EX2010-MB1
ContentIndexState : Healthy

After the content index is healthy you can attempt to activate the database copy again.

Performing Database Switchovers When Indexing is Disabled

If indexing has been intentionally disabled you can still perform a database switchover using the Exchange Management Shell, by running Move-ActiveMailboxDatabase with the -SkipClientExperienceChecks switch.

[PS] C:\>Move-ActiveMailboxDatabase MB-HO-03 -ActivateOnServer HO-EX2010-MB2 -SkipClientExperienceChecks

Assuming no other issues exist with the database the move should complete successfully.

This article Cannot Activate Database Copy: Content Index Catalog Files in Failed State is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

In this article we’ll look at how to use Windows Server Backup on Windows Server 2012 to backup the databases on an Exchange Server 2013 Mailbox server.

For this demonstration a standalone Mailbox server (one that is not a member of a database availability group) hosts a single mailbox database.

[PS] C:\>Get-MailboxDatabase -Server E15MB3
Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
Mailbox Database 3             E15MB3          False           None

Installing Windows Server Backup

Before we can back up the database of course we need to install Windows Server Backup. You can install this using PowerShell.

PS C:\> Install-WindowsFeature Windows-Server-Backup
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Windows Server Backup}

Configuring a Scheduled Backup

The next step is to configure a scheduled backup job. Open Windows Server Backup on the server.

In the Local Backup area of the console launch the Backup Schedule… wizard.

Click Next to move to the backup configuration selection. A full server backup is recommended, but if for some reason you only want to back up the Exchange database you can choose Custom instead.

If you’ve chosen a custom configuration you will then need to click Add Items and add the volumes that contain the Exchange mailbox database and log files. If you have chosen Full Server then this step will not be required.

Next, click Advanced Settings and on the VSS Settings tab make sure VSS full backup is chosen. If you have chosen a Full Server backup then this step will not be required.

Continue through the wizard and choose a backup schedule, either once per day or multiple times per day.

Choose the backup destination. For this demonstration I’m using the recommended method of a local hard disk that is dedicated for backups.

You may need to click Show All Available Disks if you do not immediately see the disk you wish to use as a backup destination.

The disk will be reformatted for use by Windows Server Backup, which will erase any previous data stored on it.

Review your selections and click Finish to create the scheduled backup job.

Manually Running a Backup

You can manually run a backup by launching the Backup Once… wizard.

This gives you the choice of using the same settings that are configured for the scheduled backup job, or running through the same wizard shown above to choose settings for a one-off backup job.

Checking Backup Status

The status of backup jobs is reported in the Windows Server Backup console.

You can also check the last backup time stamp on the mailbox database itself.

[PS] C:\>Get-MailboxDatabase -Server E15MB3 -Status | fl name,last*backup
Name                   : Mailbox Database 3
LastFullBackup         : 11/18/2013 10:51:41 PM
LastIncrementalBackup  :
LastDifferentialBackup :
LastCopyBackup         :

This article How to Backup Exchange Server 2013 Databases Using Windows Server Backup is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

     

It often comes as a surprise to people that the guy from the Exchange Server Pro website would use Google Apps as his email provider, but the fact is I’ve been a Google Apps user for many, many years. In fact, as far as I can tell I started using Google Apps sometime in 2008.

There were a few reasons I went with Google Apps at the time.

• It was free (it no longer is)
• It had a decent user interface
• No need to mess about with email clients on my various computers
• It had some handy features for managing different sender addresses
• The spam filtering was very effective

Basically it did the job, and there were few if any alternatives out there worth looking at.

In 2011 Microsoft launched Office 365. I’d had some less than impressive experiences with their BPOS service before that, so I didn’t think too much of it at the time. All my work continued to be on-premises deployments of Exchange Server, and the thought of moving from a free Google Apps service I was happy with to a paid Office 365 service was not all that appealing.

In 2012 I was awarded as a Microsoft MVP for the first time. One of the benefits offered was a 1 year Office 365 subscription for a small number of licenses, that we can use for testing etc. Not having much free time I didn’t give it more than a quick look. Again all the local work I was doing was on-premises, though I was well aware that Office 365 was a big focus for Microsoft and my fellow MVPs in other parts of the world were doing quite a lot of work with it.

In the last few months I’ve been increasingly frustrated with some of the moves Google is making in various areas, and their email service in particular. They’re all little things, but they add up over time, and the last straw was an update to the Gmail app for iOS that turned a perfectly functional user interface into a horrible experience.

I decided to make the move to Office 365.

This was not just about getting away from Google Apps, there were several positive drivers for this decision as well.

• At $60/yr for the single user license I needed, it was on par with $50/yr for a Google Apps service only Office 365 also has Lync
• The “Wave 15″ service is actually very good, running on Exchange 2013 and having an excellent Outlook Web App interface
• A small business I look after will be moving from SBS 2008 to Office 365 soon, so this lets me kick the tyres a bit
• I am a Microsoft IT pro, and as much as possible I like to stay in the Microsoft space despite all the ups and downs of this year (*cough*TechNet*cough*)

Now you might be wondering why price comes into if I get a free Office 365 subscription as an MVP.

Basically I want to own the license, purchased properly through the local channel, and not run into any problems later with my email sitting in a “trial” subscription in the wrong part of the world. $60/yr is no big deal when you look at it from that perspective.

I had a few false starts signing up due to an expired 30 day trial still attached to my account with Telstra (the Australian reseller for Office 365). After that was cleared up signup was quick and easy.

Adding and verifying a domain is done via the usual methods, such as adding a TXT record with a value that Microsoft provides to you. It was interesting to see that Office 365 can host your DNS for you. I really should have chosen that option as I then ran into problems adding all of the required SRV records to DNS using my DNS host’s admin interface. Eventually I found a solution for that though, and after changing my MX records to point each of my domains at Office 365 I started looking at my options for migrating all my email across.

There were three migrations options I considered:

1. Using a Connected Account (basically pulls the mail across using POP or IMAP)
2. Using the Office 365 migration tool (I did not end up trying this)
3. Using MigrationWiz, a third party service (they have not paid me to mention them here)

First I tried the Connected Account method. This seemed to be working okay at first. Everything was being downloaded to the Inbox, which was going to mean a bit of tidy up afterwards, but that was not a concern.

Unfortunately after about 24 hours and only about half my email being migrated the process got stuck and nothing more came across. I thought perhaps I had run into one of the daily download limits that Google Apps enforces, but even after a couple more days it still wasn’t working.

Since I was considering MigrationWiz for the upcoming small business migration I decided to give that a try instead. At $11.99 for a “Premium” license it seemed like a good deal to me. An added bonus was the option to convert Gmail labels into folders, rather than everything go into one single folder. This can mean some duplicate items in the destination mailbox, but since most of my mail was either given a single label or none at all I didn’t see any serious problem there.

MigrationWiz has been a pleasant surprise. The process is not flawless, and some folks have mentioned a few caveats to me for certain scenarios, but for my needs it has done the job quite well. There has been a bit of tuning required to increase things like error limits, which will be of no surprise to anyone who has had to migrate an Exchange mailbox with a lot of bad items in it. In the end it did exactly what I needed it to do, brought across all of my email (minus a few errors) and turning labels into folders which has let me tidy up a lot faster than having everything dumped into one folder.

With the migration finished I am now settling in to my new Office 365 mailbox and doing a little fine tuning of spam settings and inbox rules. I’m using Outlook Web App most of the time, as well as the OWA app for iOS on my iPhone and iPad. As I get my mailbox organization back under control I will probably start using Outlook 2013 on my main computer as well.

As a side benefit of the move I also split out my personal domain name and attached that to Outlook.com, so my business and personal emails are now separate again.

Overall I am very happy. For all the drama lately with the perception that Microsoft is pushing everyone to the cloud, and that the cloud has too many cons to offset the benefits, I have to say that Office 365 is an excellent service and well worth considering.

This article My Move From Google Apps to Office 365 is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Get-EASDeviceReport.ps1 Script to Report on ActiveSync Devices

 

The Microsoft Exchange Server team has announced the upcoming availability of Service Pack 1 for Exchange Server 2013, scheduled for release in “early 2014″.

Among the changes and improvements planned for Service Pack 1:

• Support for running Exchange Server 2013 on Windows Server 2012 R2
• The return of the Edge Transport server role
• S/MIME support for Outlook Web App
• Many more fixes and improvements

The team also said that Service Pack 1 is essentially CU4. Considering we are at CU2 right now that leaves open the question of when CU3 will be released.

UC Architect Dave Stork noticed in the last few days a number of KB articles were published that listed fixes that were included in CU3, however those KB articles have since been removed. The publishing of specific KBs like that usually coincides with the release of an update or service pack. In their blog post about SP1 Microsoft did hint that more info about CU3 is “imminent”, so perhaps the KB articles were accidentally published too soon, and were removed until CU3 is formally released. I’m sure we’ll find out soon.

This article Exchange Server 2013 Service Pack 1 Announced is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Exchange Server 2013 Cumulative Update 3 Released
• Exchange Server 2013 Database Backup using Windows Server Backup Completed with Warnings

 

Version 1.07 of the Test-ExchangeServerHealth.ps1 script has been released.

This version fixes one issue with the handling of content indexes on databases that have been intentionally disabled by administrators (eg because the database hosts journal mailboxes). Those content indexes will now be reported as “Disabled” instead of “Failed”.

The script is available to download from the Insiders member area. If you’re not already a member you can join for free here.

This article Test-ExchangeServerHealth.ps1 V1.07 Released is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Get-MailboxReport.ps1 v1.02 Released
• Test-ExchangeServerHealth.ps1 v1.06 is Now Available
• How to Rename a Room Mailbox Using PowerShell

 

A common request of Exchange Server administrators is granting a person access to another mailbox. The Add-MailboxPermission cmdlet lets you grant permissions to a mailbox. There are three parameters to use:

• Identity – the mailbox you are adding the permissions to
• User – the user you are granting the permissions to
• AccessRights – the level of access you are granting

For example, to grant Sarah Jones full access to Alan Reid’s mailbox we would run this command.

[PS] C:\>Add-MailboxPermission -Identity Alan.Reid -User Sarah.Jones -AccessRights FullAccess

To remove the access we would use Remove-MailboxPermission instead.

[PS] C:\>Remove-MailboxPermission -Identity Alan.Reid -User Sarah.Jones -AccessRights FullAccess

Handling Auto-Mapping for Full Access to Mailboxes

When you grant full access to a mailbox you may notice that the mailbox automatically appears in the user’s Outlook, either immediately or after a short wait. This is due to a feature called auto-mapping. In some cases this auto-mapping behaviour is not desirable. To prevent auto-mapping we need to add -AutoMapping:$false to the Add-MailboxPermission command. If access has already been granted you must first remove it. Then run Add-MailboxPermission again with auto-mapping disabled.

[PS] C:\>Add-MailboxPermission -Identity Alan.Reid -User Sarah.Jones -AccessRights FullAccess -AutoMapping:$false

If you only want to grant read-only access to the mailbox refer to this article: How to Grant Read-Only Access to an Exchange Mailbox

This article How to Grant Full Mailbox Access for a User in Exchange Server 2013 is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• How to Configure a Relay Connector in Exchange Server 2013
• Are You Interested in an Exchange Server 2013 Boot Camp?
• Exchange Server 2013 Service Pack 1 Announced

 

Recently I was asked whether I had any PowerShell scripts available for producing a simple report of the ActiveSync devices for an Exchange organization. I didn’t have a script at the time but was able to quickly put one together that did the job, though it was a little rough.

I had planned to tidy the script up and release it but hadn’t gotten around to it until today when I had a reason to produce that same report for a customer.

So here is v1.00 of Get-EASDeviceStatsReport.ps1. This is still early code with little error handling or other features, but it will handle multiple devices per-user and work for most simple organizations at the moment.

Download: Get-EASDeviceReport.ps1 (79 downloads)

Simply run the script in the Exchange Management Shell to produce the report.

[PS] C:\Scripts>.\Get-EASDeviceStatsReport.ps1

The report is written to a CSV file in the same folder that the script is located.

Questions and feedback are welcome in the comments below.

This article Get-EASDeviceReport.ps1 Script to Report on ActiveSync Devices is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Get-MailboxReport.ps1 v1.02 Released
• Test-ExchangeServerHealth.ps1 v1.06 is Now Available
• Test-ExchangeServerHealth.ps1 V1.07 Released

 

Microsoft has released Update Rollup 3 for Exchange Server 2010 Service Pack 3.

This update includes a number of fixes that are listed in KB2891587.

Deploying Exchange Server 2010 SP3 Update Rollup 3

The standard order of deployment for Exchange Server updates applies.

1. Client Access servers, starting with the internet-facing ones. See this article for how to patch a CAS array.
2. Hub Transport and Edge Transport servers
3. Mailbox servers. See this article for how to patch a Database Availability Group.
4. Unified Messaging servers

This article Exchange 2010 Service Pack 3 Update Rollup 3 Released is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Get-MailboxReport.ps1 v1.02 Released
• Test-ExchangeServerHealth.ps1 v1.06 is Now Available
• Test-ExchangeServerHealth.ps1 V1.07 Released

 

Microsoft has released Cumulative Update 3 for Exchange Server 2013.

From the Microsoft Exchange Team blog:

We would like to call attention to an important fix in Exchange Server 2013 Cumulative Update 3 which impacts customers who rely upon Backup and Recovery mechanisms to protect Exchange data. Cumulative Update 3 includes a fix for an issue which may randomly prevent a backup dataset taken from Exchange Server 2013 from restoring correctly. Customers who rely on Backup and Recovery in their day-to-day operations are encouraged to deploy Cumulative Update 3 and initiate backups of their data to ensure that data contained in backups may be restored correctly. More information on this fix is available in KB2888315.

In addition to the customer reported fixes in Cumulative Update 3, the following new enhancements and improvements to existing functionality have also been added for Exchange Server 2013 customers:

• Usability improvements when adding members to new and existing groups in the Exchange Administration Console
• Online RMS available for use by non-cloud based Exchange deployments
• Improved admin audit log experience
• Windows 8.1/IE11 no longer require the use of OWA Light

More information on these topics can be found in our What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Cumulative Update 3 includes Exchange related updates to Active Directory schema and configuration. For information on extending schema and configuring the active directory please review the appropriate TechNet documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Cumulative Update 3 is available for download here.

For deployment steps refer to this guide to installing cumulative updates for Exchange Server 2013.

This article Exchange Server 2013 Cumulative Update 3 Released is © 2013 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

    

Related Stories

• Exchange Server 2013 Service Pack 1 Announced
• Exchange Server 2013 Database Backup using Windows Server Backup Completed with Warnings