Quantcast
Channel: Practical 365
Viewing all 515 articles
Browse latest View live

Exchange Server 2010 to 2013 Migration – Configuring Mailbox Servers

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

After configuring the Client Access servers we can next turn our attention to configuring the Exchange 2013 Mailbox servers.

The Exchange Server Pro organization is planning to deploy a database availability group spanning two datacenters. However in this initial phase, only the DAG members in Datacenter1 will be provisioned. The DAG will be extended to Datacenter2 later.

exchange-2010-2013-mailbox-server-config-01

The server and storage layout has already been determined from the server sizing exercise. In particular, because we plan to use AutoReseed the correct database storage layout has been configured.

The DAG has been provisioned and the database copies have been configured. For more information on these steps see the following resources:

In the next article in this series we’ll look at configuring Transport services.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Configuring Mailbox Servers is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com


Test-ExchangeServerHealth.ps1 v1.08 is Now Available

$
0
0

I’m pleased to announce the availability of v1.08 of the Test-ExchangeServerHealth.ps1 script.

This version of the script contains one minor bug fix for database availability group health checks in mixed Exchange 2010/2013 organizations.

Existing Exchange Server Pro Insiders can download the script here. If you are not already a member you can join for free here.


This article Test-ExchangeServerHealth.ps1 v1.08 is Now Available is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 to 2013 Migration – Configuring Transport

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

With the Exchange 2013 servers deployed in the new Datacenter1 location we can also configure Transport. For the Exchange Server Pro organization there are two elements to this:

  • Inbound/outbound email
  • Internal/external SMTP relay

Let’s take a look at each of these.

Inbound/Outbound Email

Currently the Exchange Server Pro organization has inbound/outbound email flowing via an Exchange 2010 Edge Transport server in the Head Office site.

exchange-2010-2013-transport-config-01

The Exchange 2013 servers in DataCenter1 will send and receive internet email directly, without the use of an Edge Transport server. The routing topology during the co-existence period will look like this.

exchange-2010-2013-transport-config-02

The outbound mail flow from Datacenter1 is established by creating a send connector.

Note that inbound mail flow does not go to Datacenter1 until the MX records are updated. However, with the send connector in place some production email will possibly flow out via Datacenter1. So with the send connector in place the Exchange 2013 servers can be considered to be in production, however as long as the Head Office servers are functioning there should be two routes for outbound email, so the Exchange 2013 servers are not yet of critical importance.

Internal/External SMTP Relay

The existing Head Office Exchange 2010 servers have relay connectors configured for a variety of systems and applications to use as an SMTP service. These are currently load balanced. The load balancer will be moved to Datacenter1 later, so the change to that traffic can be made on the load balancer itself. Otherwise the change would be made in DNS, to point the SMTP alias to the new server(s).

First, the new servers require relay connectors to be created with matching configurations. The default Frontend connector on Exchange 2013 servers permits sending email to internal recipients, so only those that require external relay need to use the relay connectors. However, like many organizations, the Exchange Server Pro organization uses one SMTP alias for both internal and external relay needs.

In the next part of this series we’ll look at some more preparation tasks for the co-existence period, before the cutover of services can begin.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Configuring Transport is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 to 2013 Migration – Preparing for Co-Existence

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

Before the Exchange 2013 migration project moves into the co-existence phase, where production services are provided from both the Exchange 2010 and 2013 servers, there are some final checks and configurations that should be performed.

General Health Check

Before any migration or cutover of services it pays to verify that the current Exchange Server 2010 environment is in good health. This avoids potential support confusion if a service is cutover to Exchange 2013, is found to be not working, and then it is unknown whether the service was already faulty or whether it was the cutover that caused the fault to occur.

Here are a few suggestions:

  • Run Test-ExchangeServerHealth.ps1 to perform a health check of the servers
  • Use the ExRCA tools to test external access
    • Note that the ActiveSync test may fail on the final step if your ActiveSync mailbox policy does not allow non-provisionable devices. Either use a different mailbox policy for the test user you use for ExRCA, or use a mobile device to perform the testing instead.
  • Confirm that backups for Exchange 2010 are functioning correctly
  • Review the Exchange 2010 server event logs for any unusual errors
  • Launch Outlook for a new test user and verify that Autodiscover works correctly
  • Test Exchange Web Services by doing free/busy lookups
  • Verify that mail flow between existing servers is healthy. If you have a large/complex environment you can use my mail flow heat map script for this.

Configure Outlook Anywhere

During co-existence all Outlook connections to mailboxes are via the Exchange 2013 Client Access servers using RPC-over-HTTPS (Outlook Anywhere), even internal connections.

If Outlook Anywhere was not previously used in your Exchange 2010 organization it needs to be enabled and configured.

If Outlook Anywhere was already enabled and configured, it needs to be checked to confirm that the correct authentication settings are in place to allow Exchange 2013 to proxy connections to Exchange 2010 for users who have not yet been moved to Exchange 2013.

For the Exchange Server Pro organization the servers are configured as follows:

[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and $_.IsClientAccessServer} | Get-OutlookAnywhere | fl servername,externalhostname,*auth*
ServerName                 : HO-EX2010-MB1
ExternalHostname           : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic}
ServerName                 : HO-EX2010-MB2
ExternalHostname           : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic}
ServerName                 : BR-EX2010-MB
ExternalHostname           : mail.exchangeserverpro.net
ClientAuthenticationMethod : Basic
IISAuthenticationMethods   : {Basic}

The IISAuthenticationMethods need to be updated to include NTLM.

[PS] C:\>Get-ExchangeServer | Where {$_.AdminDisplayVersion -like "*14.*" -and $_.IsClientAccessServer} | %{Set-OutlookAnywhere "$_\RPC (Default Web Site)" -IISAuthenticationMethods Basic,NTLM}

Configure Virtual Directories

The Exchange 2013 Client Access server virtual directories should be checked to ensure they are configured correctly for your environment.

The Exchange Server Pro organization has OWA and ECP virtual directories configured for Basic and Integrated authentication, and uses Forefront TMG to publish them to the internet with Forms-based Authentication. Therefore, the OWA/ECP virtual directories for Exchange 2013 also need to be configured the same way so that the TMG publishing can continue to work.

exchange-2013-co-existence-vdirs-01

This is particularly important for TMG authentication delegation to continue working. Using a different authentication type for Exchange 2013 potentially means the TMG configuration also needs to be re-assessed.

For more information on publishing Exchange 2013 with TMG see the following article:

For organizations that are simply NATing port TCP 443 (HTTPS) to the Client Access servers then this is less of an issue and changing authentication types likely has no other significant technical considerations.

Communicate Changes to Users

This may seem obvious but communicating the upcoming changes to end users is important. Particularly for OWA, which will present the Exchange 2013 OWA logon to Exchange 2010 users once the OWA namespace is pointed at the Exchange 2013 CAS and it is pre-authenticating and proxying connections to Exchange 2010. Naturally the OWA interface itself is new in Exchange 2013, so some training or documentation updates for end users may be wise.

Other than that, as long as you’re re-using the same namespaces as the existing Exchange organization there is not likely to be any other user-visible changes that need communicating.

In the next part of this series we’ll begin cutting over the Client Access namespaces to Exchange 2013.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Preparing for Co-Existence is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 to 2013 Migration – Cut Over Namespaces

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

With all co-existence preparations complete we can now cut over the namespaces to Exchange Server 2013.

First, let’s be clear that this is a significant change and should be approached with due care. Although the changes themselves are quite simple (mostly DNS changes), they are best performed during a window of time when they will have the least impact on your end users, with enough time for you to test the outcome and roll back if there is a problem.

On the topic of rolling back, your changes should be well planned and well documented as you go along, so that you can easily reverse them if you need to.

Cut Over External Namespaces

For the Exchange Server Pro organization the external namespaces are:

  • autodiscover.exchangeserverpro.net
  • mail.exchangeserverpro.net

In a scenario where the external IP addresses are staying the same the cut over would occur on the edge router or firewall that performs NATing for the network. However in this case the internet-facing Exchange 2010 servers are in the Head Office site, while the new internet-facing Exchange 2013 servers are in the Datacenter1 site which has its own internet connection and a new public IP range.

exchange-2010-2013-public-dns-before-01

Therefore the change is made in public DNS, updating the records to the new IP addresses. Depending on the TTL (time-to-live) on those DNS records this change may take anywhere from several minutes to several hours to take effect. It is recommended before making planned DNS changes to lower the TTL to a short timespan (eg 5 minutes) at least a day or two in advance of the change so that it will take effect faster, as well as allowing faster roll back.

Note that for the Exchange Server Pro organization this change will impact Client Access services (such as OWA, ActiveSync, Outlook Anywhere), as well as Transport services (ie MX records, mail flow), because the MX record for the domain points to mail.exchangeserverpro.net as well. If the MX record pointed to a different DNS name, or the IP addresses weren’t actually changing, then services on different ports could be cut over at different times.

For more on managing changes to MX records see the following article:

After making the changes to public DNS and/or your firewall NATing repeat the testing and health checks performed earlier to verify that services are working as expected.

exchange-2010-2013-public-dns-after-01

The outcome of the external DNS changes is that external access (eg Outlook Anywhere, ActiveSync, OWA, and inbound SMTP) will go via the Exchange 2013 servers and be proxied/routed internally as required.

Cut Over Internal Namespaces

For the Exchange Server Pro organization the external namespaces are:

  • autodiscover.exchangeserverpro.net
  • mail.exchangeserverpro.net
  • imap.exchangeserverpro.net
  • pop.exchangeserverpro.net
  • smtp.exchangeserverpro.net

High availability for Exchange 2013 Client Access services in Datacenter1 will initially be handled by DNS round robin. So the DNS records for the above namespaces (except SMTP) are updated in the internal DNS zones with two A records, which point to each of the Exchange 2013 IP addresses.

exchange-2010-2013-internal-dns-after-01

SMTP is a little different. SMTP doesn’t work well with DNS round robin, because many SMTP clients (such as printers) will simply fail a connection if the IP they attempt to connect to doesn’t respond, rather than retry with a different IP as most modern HTTP clients do (including Outlook).

For now the Exchange Server Pro organization is retaining a load balancer for SMTP, so the cut over for SMTP is performed on the load balancer configuration itself. If this cost wasn’t practical or high availability for SMTP wasn’t important then pointing the SMTP namespace at just one Exchange 2013 server IP address would be a reasonable solution.

After making the changes to internal DNS repeat the testing and health checks performed earlier to verify that services are working as expected.

What About Internal Outlook Users?

At this point you may be wondering what are the real impacts to internal Outlook users when you make the internal namespace changes in DNS.

Exchange 2010 mailbox users will continue to connect to the RPCClientAccessServer as before. Their Outlook profiles do not change. However, their connectivity for the namespaces that have been pointed to Exchange 2013 (ie Autodiscover, EWS, etc) will go to the Exchange 2013 CAS where they are then proxied to Exchange 2010 as necessary to fulfil the requests.

exchange-2010-2013-internal-dns-after-02

It is only after moving mailboxes to Exchange 2013 that Outlook MAPI/RPC connectivity for those users will switch over to the Outlook Anywhere namespace for Exchange 2013 (mail.exchangeserverpro.net in this example scenario).

In the next part of this series we’ll begin looking at the mailbox migration tasks.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Cut Over Namespaces is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Test-ExchangeServerHealth.ps1 v1.09 is Now Available

$
0
0

I’m pleased to announce the availability of v1.09 of the Test-ExchangeServerHealth.ps1 script.

This version of the script contains one minor bug fix for database availability group member replication health reporting in mixed Exchange 2010/2013 organizations.

Existing Exchange Server Pro Insiders can download the script here. If you are not already a member you can join for free here.

The issue that is fixed was an error when running Test-ReplicationHealth from an Exchange 2013 server against an Exchange 2010 server. Little bugs like this have appeared before in the Test-* cmdlets that ship with Exchange 2013. I fix them as best I can but there is clearly going to be more long term benefit in leveraging Managed Availability in future scripts, as I mentioned here. Still, as long as I am able to I will keep patching the scripts to work in as many on-premises organizations as possible.

Here is an example of Test-Replicationhealth run against an Exchange 2013 server and then an Exchange 2010 server.

[PS] C:\>Test-ReplicationHealth ex2013srv1
Server          Check                      Result     Error
------          -----                      ------     -----
EX2013SRV1      ClusterService             Passed
EX2013SRV1      ReplayService              Passed
EX2013SRV1      ActiveManager              Passed
EX2013SRV1      TasksRpcListener           Passed
EX2013SRV1      TcpListener                Passed
EX2013SRV1      ServerLocatorService       Passed
EX2013SRV1      DagMembersUp               Passed
EX2013SRV1      ClusterNetwork             Passed
EX2013SRV1      QuorumGroup                Passed
EX2013SRV1      DatabaseRedundancy         Passed
EX2013SRV1      DatabaseAvailability       Passed
EX2013SRV1      DBCopySuspended            Passed
EX2013SRV1      DBCopyFailed               Passed
EX2013SRV1      DBInitializing             Passed
EX2013SRV1      DBDisconnected             Passed
EX2013SRV1      DBLogCopyKeepingUp         Passed
EX2013SRV1      DBLogReplayKeepingUp       Passed
[PS] C:\>Test-ReplicationHealth ho-ex2010-mb1
Could not load file or assembly 'Microsoft.Exchange.Data, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
    + CategoryInfo          : NotSpecified: (:) [Test-ReplicationHealth], FileNotFoundException
    + FullyQualifiedErrorId : [Server=EX2013SRV1,RequestId=a14edcd8-cd42-4cb3-9af7-0140d97babef,TimeStamp=7/07/2014 12
   :52:02 PM] [FailureCategory=Cmdlet-FileNotFoundException] 864218C8,Microsoft.Exchange.Monitoring.TestReplicationHe
  alth
    + PSComputerName        : ex2013srv1.exchangeserverpro.net

To work around this issue I’ve added a function to the script that will detect the error and create a PSSession to an Exchange 2010 CAS in the same site as the mailbox server that Test-ReplicationHealth is being run against. The test can then be performed by the Exchange 2010 server instead.

[PS] C:\Scripts\TestReplicationHealth>.\Test-E14ReplicationHealth.ps1 ho-ex2010-mb1 -Verbose
VERBOSE: Get replication health for ho-ex2010-mb1
VERBOSE: Error, trying workaround
VERBOSE: Creating PSSession for HO-EX2010-MB1.exchangeserverpro.net
VERBOSE: Using URL http://ho-ex2010-mb1.exchangeserverpro.net/powershell
VERBOSE: Running replication health test on ho-ex2010-mb1
VERBOSE: Removing PSSession
VERBOSE: ClusterService Passed
VERBOSE: ReplayService Passed
VERBOSE: ActiveManager Passed
VERBOSE: TasksRpcListener Passed
VERBOSE: TcpListener Passed
VERBOSE: ServerLocatorService Passed
VERBOSE: DagMembersUp Passed
VERBOSE: ClusterNetwork Passed
VERBOSE: QuorumGroup Passed
VERBOSE: FileShareQuorum Passed
VERBOSE: DBCopySuspended Passed
VERBOSE: DBCopyFailed Passed
VERBOSE: DBInitializing Passed
VERBOSE: DBDisconnected Passed
VERBOSE: DBLogCopyKeepingUp Passed
VERBOSE: DBLogReplayKeepingUp Passed

Here is the sample code. Note that this is for demonstration purposes and is not intended to be a working script. The function has been incorporated into Test-ExchangeServerHealth.ps1.

#requires -version 2
[CmdletBinding()]
param (
    [Parameter( Mandatory=$true)]
	[string]$Server
)
#This function is used to test replication health for Exchange 2010 DAG members in mixed 2010/2013 organizations
Function Test-E14ReplicationHealth()
{
	param ( $e14mailboxserver )
	$e14replicationhealth = $null
    $ADSite = (Get-ExchangeServer $e14mailboxserver).Site
    $e14cas = (Get-ExchangeServer | where {$_.IsClientAccessServer -and $_.AdminDisplayVersion -match "Version 14" -and $_.Site -eq $ADSite} | select -first 1).FQDN
	Write-Verbose "Creating PSSession for $e14cas"
    $url = (Get-PowerShellVirtualDirectory -Server $e14cas -AdPropertiesOnly | Where {$_.Name -eq "Powershell (Default Web Site)"}).InternalURL.AbsoluteUri
    if ($url -eq $null)
    {
        $url = "http://$e14cas/powershell"
    }
    Write-Verbose "Using URL $url"
	try
	{
	    $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $url -ErrorAction STOP
	}
	catch
	{
	    Write-Verbose "Something went wrong"
		if ($Log) {Write-Log $_.Exception.Message}
    	Write-Warning $_.Exception.Message
	}
	try
	{
	    Write-Verbose "Running replication health test on $e14mailboxserver"
	    $e14replicationhealth = Invoke-Command -Session $session {Test-ReplicationHealth} -ErrorAction STOP
	}
	catch
	{
	    Write-Verbose "An error occurred"
		if ($Log) {Write-Log $_.Exception.Message}
	    Write-Warning $_.Exception.Message
	}
	Write-Verbose "Removing PSSession"
	Remove-PSSession $session.Id
	return $e14replicationhealth
}
try
{
    Write-Verbose "Get replication health for $server"
    $replicationhealth = $server | Invoke-Command {Test-ReplicationHealth -ErrorAction STOP}
}
catch
{
    Write-Verbose "Error, trying workaround"
    $replicationhealth = Test-E14ReplicationHealth $server
}
foreach ($healthitem in $replicationhealth)
{
    $tmpstring = "$($healthitem.Check) $($healthitem.Result)"
	Write-Verbose $tmpstring
	if ($Log) {Write-Logfile $tmpstring}
}

This article Test-ExchangeServerHealth.ps1 v1.09 is Now Available is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Moving Exchange Server 2013 Mailboxes

$
0
0

In Exchange Server 2013 mailbox moves are performed using move requests.

There are a variety of ways that move requests can be used to move mailboxes in an Exchange 2013 organization, with such options as:

  • Moving individual mailboxes or batches of mailboxes
  • Moving primary mailboxes with archive mailboxes or moving them seperately
  • Completing moves immediately or suspending them for later completion
  • How many bad (corrupt) mailbox items are able to be discarded before the migration fails
  • Moving to a specific database or allowing Exchange to automatically choose a database

The Exchange 2013 servers will also apply their own intelligence to mailbox moves, slowing down or even halting a move if the server health is at risk (for example high CPU utilization).

Let’s take a look at some examples of mailbox moves using move requests in Exchange 2013.

Using the Exchange Admin Center to Move Mailboxes

For a single mailbox move you can begin the process from the mailboxes view. In the Exchange Admin Center navigate to Recipients -> Mailboxes and choose a mailbox that you wish to move. At the bottom of the right-hand side click the link to move mailbox to another database.

exchange-2013-mailbox-move-01

Alternatively, select the Migration view and start a new “Move to a different database”.

exchange-2013-mailbox-move-00

Select one or more mailboxes to be moved and click Next.

exchange-2013-mailbox-move-00b

Give the migration batch a name, and choose the target database to move to. If no database is selected Exchange 2013 will automatically choose a target database for the move. Notice also that you can choose whether to move only the primary mailbox, archive mailbox, or both together. Click Next to continue.

exchange-2013-mailbox-move-02

Select a user to receive the email report for the move.

exchange-2013-mailbox-move-03

Choose whether to start the batch immediately or manually start it later. This option allows you to prepare your migration batches ahead of time and then manually start them when you are ready.

exchange-2013-mailbox-move-04

Finally, choose whether the move should automatically complete or should suspend when ready to complete, which requires you to manually complete it. When mailbox moves are processing the user can continue to access their mailbox right up to the point where the completion occurs, when they are disconnected briefly, so this option lets you control the timing of the completion to occur when it will be least disruptive to the end user.

exchange-2013-mailbox-move-05

Click New to begin the move request.

You can observe the progress of the migration batch in the Migration view in EAC.

exchange-2013-mailbox-move-06

When the migration is complete there may be a delay of several minutes due to Active Director replication between sites before the end user can reconnect to their mailbox, depending on where they are located relative to the Exchange servers.

Using Exchange Management Shell to Move Mailboxes

Here is an example of using PowerShell to manage mailbox move requests. In this case the mailboxes hosted on database MB-BR-01 are moved as a batch named “Branch Office Batch 1″. No target database is set so that Exchange 2013 can automatically distribute them between available databases. Also, SuspendWhenReadyToComplete is used to prevent automatic completion, so that it can be initiated at a later time outside of business hours.

[PS] C:\>Get-Mailbox -Database MB-BR-01 | New-MoveRequest -BatchName "Branch Office Batch 1" -SuspendWhenReadyToComplete
DisplayName               StatusDetail              TotalMailboxSize          TotalArchiveSize         PercentComplete
-----------               ------------              ----------------          ----------------         ---------------
Wendy Fyson               Queued                    54.07 MB (56,698,964 b...                          0
John Williams             Queued                    52.35 MB (54,889,436 b...                          0
Alex Heyne                Queued                    90.71 MB (95,115,943 b... 955.9 KB (978,796 bytes) 0
Katherine Phipps          Queued                    54.63 MB (57,281,147 b...                          0
Judith Rodrigues          Queued                    57.11 MB (59,880,427 b...                          0
Olive Weeks               Queued                    53.52 MB (56,123,602 b...                          0
Sonia Smith               Queued                    54.26 MB (56,894,534 b...                          0
Sunset Room               Queued                    36.35 MB (38,113,922 b...                          0
TestMB BR                 Queued                    59.37 MB (62,256,579 b...                          0
Joanne Rigby              Queued                    84.95 MB (89,079,670 b...                          0

You can view the distribution of mailboxes across target databases using Get-MoveRequest.

[PS] C:\>Get-MoveRequest -BatchName "Branch Office Batch 1"
DisplayName                                    Status                    TargetDatabase
-----------                                    ------                    --------------
Wendy Fyson                                    InProgress                DB01
John Williams                                  InProgress                DB02
Alex Heyne                                     InProgress                DB02
Katherine Phipps                               InProgress                DB02
Judith Rodrigues                               InProgress                DB02
Olive Weeks                                    InProgress                DB02
Sonia Smith                                    Queued                    DB02
Sunset Room                                    Queued                    DB01
TestMB BR                                      Queued                    DB02
Joanne Rigby                                   Queued                    DB02

Progress can be monitored using the Get-MoveRequestStatistics cmdlet.

[PS] C:\>Get-MoveRequest -BatchName "Branch Office Batch 1" | Get-MoveRequestStatistics
DisplayName               StatusDetail              TotalMailboxSize          TotalArchiveSize         PercentComplete
-----------               ------------              ----------------          ----------------         ---------------
Wendy Fyson               CopyingMessages           54.07 MB (56,698,964 b...                          29
John Williams             CopyingMessages           52.35 MB (54,889,436 b...                          29
Alex Heyne                CopyingMessages           90.71 MB (95,115,943 b... 955.9 KB (978,796 bytes) 25
Katherine Phipps          CopyingMessages           54.63 MB (57,281,147 b...                          25
Judith Rodrigues          LoadingMessages           57.11 MB (59,880,427 b...                          20
Olive Weeks               LoadingMessages           53.52 MB (56,123,602 b...                          20
Sonia Smith               Queued                    54.26 MB (56,894,534 b...                          0
Sunset Room               Queued                    36.35 MB (38,113,922 b...                          0
TestMB BR                 Queued                    59.37 MB (62,256,579 b...                          0
Joanne Rigby              Queued                    84.95 MB (89,079,670 b...                          0

When the move requests reach 95% completed they will display a status of AutoSuspended. The end user can continue to use their mailbox at this time, and you can complete the moves at the desired time.

First remove the autosuspend flag from the move requests, so that they will resume all the way to completion.

[PS] C:\>Get-MoveRequest -BatchName "Branch Office Batch 1" | Set-MoveRequest -SuspendWhenReadyToComplete:$false

Next, issue a Resume-MoveRequest command.

[PS] C:\>Get-MoveRequest -BatchName "Branch Office Batch 1" | Resume-MoveRequest

Monitor the move requests until completion.

[PS] C:\>Get-MoveRequest -BatchName "Branch Office Batch 1" | Get-MoveRequestStatistics
DisplayName               StatusDetail              TotalMailboxSize          TotalArchiveSize         PercentComplete
-----------               ------------              ----------------          ----------------         ---------------
Wendy Fyson               Completed                 54.07 MB (56,698,964 b...                          100
John Williams             Completed                 52.35 MB (54,889,436 b...                          100
Alex Heyne                Completed                 90.71 MB (95,114,080 b... 957.7 KB (980,659 bytes) 100
Katherine Phipps          Completed                 54.63 MB (57,281,147 b...                          100
Judith Rodrigues          Completed                 57.11 MB (59,880,427 b...                          100
Olive Weeks               Completed                 53.52 MB (56,123,602 b...                          100
Sonia Smith               Completed                 54.26 MB (56,894,534 b...                          100
Sunset Room               Completed                 36.35 MB (38,113,922 b...                          100
TestMB BR                 Completed                 59.37 MB (62,256,579 b...                          100
Joanne Rigby              Completed                 84.95 MB (89,079,670 b...                          100

Moving Mailboxes using Migration Batches

In the previous example we looked at using move requests to move multiple mailboxes. The move requests were added to a “batch” for ease of management. This is basically the same approach that could be used in Exchange 2010 to manage move requests.

Exchange 2013 has a new approach to migration batches with a whole new set of PowerShell cmdlets to create and manage them. I prefer PowerShell, but if you’d rather use the EAC you’ll notice that the first example in this article demonstrates how to create a migration batch. All you would need to do is manually add multiple users or import a CSV file. Let’s take a look at those CSV file requirements, which apply for either the PowerShell or EAC method.

To use Exchange 2013 migration batches we first need to create a CSV file containing the details of the mailboxes to move. The only required attribute to be included in the CSV file is the email address of the mailbox.

[PS] C:\admin\migration>Get-Mailbox -Database MB-HO-01 | Select PrimarySMTPAddress | Export-CSV -NoTypeInformation headofficebatch1.csv

Open the CSV file and change the header to “EmailAddress”.

exchange-2013-migration-batch-01

Next, create the migration batch with New-MigrationBatch.

[PS] C:\admin\migration>New-MigrationBatch -Name "Head Office Batch 1" -CSVData ([System.IO.File]::ReadAllBytes("c:\admin\migration\headofficebatch1.csv")) -Local
Identity                        Status                    Type                           TotalCount
--------                        ------                    ----                           ----------
Head Office Batch 1             Created                   ExchangeLocalMove              141

I didn’t set a notification email for the migration batch, but it has used the email address of the account that I was logged in with to submit the move request.

[PS] C:\admin\migration>Get-MigrationBatch "Head Office Batch 1" | fl submittedbyuser,ownerid,notificationemails
SubmittedByUser    : E15Admin@exchangeserverpro.net
OwnerId            : exchangeserverpro.net/Users/E15Admin
NotificationEmails : {E15Admin@exchangeserverpro.net}

We could add more email addresses for notification if we need to.

[PS] C:\admin\migration>Get-MigrationBatch "Head Office Batch 1" | Set-MigrationBatch -NotificationEmails e15admin@exchangeserverpro.net,administrator@exchangeserverpro.net
[PS] C:\admin\migration>Get-MigrationBatch "Head Office Batch 1" | fl submittedbyuser,ownerid,notificationemails
SubmittedByUser    : E15Admin@exchangeserverpro.net
OwnerId            : exchangeserverpro.net/Users/E15Admin
NotificationEmails : {E15Admin@exchangeserverpro.net, administrator@exchangeserverpro.net}

At this stage the migration batch hasn’t started. To start it use the Start-MigrationBatch cmdlet. Alternatively, use the -AutoStart parameter when creating the migration batch.

[PS] C:\admin\migration>Start-MigrationBatch "Head Office Batch 1"

To see the progress of the migration batch run Get-MigrationUser and Get-MigrationUserStatistics.

You can do this for a single user, such as Aisha Bhari that was moved in an earlier example in this article.

[PS] C:\admin\migration>Get-MigrationUser aisha.bhari@exchangeserverpro.net
Identity                                 Batch                          Status                    LastSyncTime
--------                                 -----                          ------                    ------------
Aisha.Bhari@exchangeserverpro.net        Move Aisha Bari                Completed                 8/07/2014 10:27:05 PM
[PS] C:\admin\migration>Get-MigrationUser aisha.bhari@exchangeserverpro.net | Get-MigrationUserStatistics
Identity                                 Batch                          Status                    Items Synced     Item
                                                                                                                   s Sk
                                                                                                                   ippe
                                                                                                                   d
--------                                 -----                          ------                    ------------     ----
Aisha.Bhari@exchangeserverpro.net        Move Aisha Bari                Completed                 7090             0

Or do it for all users being migrated.

[PS] C:\admin\migration>Get-MigrationUser | Get-MigrationUserStatistics
Identity                                 Batch                          Status                    Items Synced     Item
                                                                                                                   s Sk
                                                                                                                   ippe
                                                                                                                   d
--------                                 -----                          ------                    ------------     ----
Aisha.Bhari@exchangeserverpro.net        Move Aisha Bari                Completed                 7090             0
bob.winder@exchangeserverpro.net         Head Office Batch 1            Queued                    0                0
DiscoverySearchMailbox{D919BA05-46A6-... Head Office Batch 1            Queued                    0                0
extest_0bcca07661e94@exchangeserverpr... Head Office Batch 1            Queued                    0                0
Famida.Ghtoray@exchangeserverpro.net     Head Office Batch 1            Syncing                   0                0
Ferzana.King@exchangeserverpro.net       Head Office Batch 1            Syncing                   0                0
Frank.Warboys@exchangeserverpro.net      Head Office Batch 1            Syncing                   0                0
Garth.Gibbons@exchangeserverpro.net      Head Office Batch 1            Syncing                   0                0
Gary.Hopkins@exchangeserverpro.net       Head Office Batch 1            Syncing                   0                0
Gavin.Welch@exchangeserverpro.net        Head Office Batch 1            Syncing                   0                0

When you’re ready to complete the migration batch, which will cause short outages for each user, use Complete-MigrationBatch. Alternatively, use the -AutoComplete switch when creating the migration batch and it will automatically occur, which may disrupt your end users at an undesirable time.

[PS] C:\admin\migration>Complete-MigrationBatch "Head Office Batch 1"

Summary

As you can see there are multiple ways to manage mailbox moves in Exchange Server 2013. Move requests will already be familiar to those who have run mailbox migrations on Exchange 2010 before, whereas the new Exchange 2013 migration batches offer some improved features such as notification emails.


This article Moving Exchange Server 2013 Mailboxes is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 to 2013 Migration – Moving Mailboxes

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

With co-existence established and the Client Access namespaces cut over to Exchange Server 2013 we can begin the mailbox migrations.

When you’re planning a mailbox migration it helps to know what you’re dealing with in terms of number of mailboxes, their sizes, and the number of items they contain. To gather this information I recommend using the Get-MailboxReport.ps1 script.

mailbox-report

In earlier versions of Exchange such as 2003 and 2007 the mailbox migration process was an interactive task that required the administrator to test how much mailbox data they could move per hour, break up the mailboxes into migration groups, time the moves to occur out of business hours, and communicate to end users that their mailbox would be unavailable for what was often a several hour period.

In addition to this, care had to be taken not to move so much data in one period that the transaction log volumes on the destination Exchange server ran out of disk space.

Exchange Server 2010 improved on this with the introduction of move requests. Exchange Server 2013 improves on this even further with new enhancements.

Exchange Server 2013 will apply self-management of its resources when processing mailbox moves, backing off when required due to server load or to allow log replication to catch up. Move requests can be issued and allowed to run without the administrator needing to micro-manage the process, with only occasional monitoring required and some intervention at the end to complete the moves.

And in a scenario where mailboxes are being migrated from Exchange 2010 to 2013 the moves are processed as online moves, which do not require the user’s mailbox to be offline for the whole move process, only the final completion stage.

For the Exchange Server Pro organization the migration follows this process:

  1. Run the Get-MailboxReport.ps1 script
  2. Choose a sample of pilot users, with the rest of the mailboxes assigned to a small number of batches that increase in size from first to last
  3. Migrate the pilot mailboxes
  4. Migrate each subsequent batch

You can learn more about the migration process here:

In each case the administrator running the migration only needs to:

  1. Create and start each migration batch
  2. Monitor the progress of the migration batch
  3. When ready, notify end users of a brief outage for that evening and then complete the migration batch
  4. Repeat for the next batch

With the mailbox migrations complete the next step is to look at public folder migration.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Moving Mailboxes is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com


Exchange Server 2010 to 2013 Migration – Moving Public Folders

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

After moving all mailboxes from Exchange Server 2010 to 2013 we can turn our attention to the public folder migration.

exchange-2013-public-folders-01

Although Exchange Server 2013 provides support for public folders with the new modern public folders, you may wish to take this opportunity to review whether your organization needs to retain public folders at all. If they are no longer needed then removing them entirely from the Exchange organization would be simpler. However if that decision can’t be made, or they are still required for some reason, then a migration to Exchange 2013 can be performed.

The process to move public folders to Exchange 2013 is documented on TechNet:

At a high level the process involves:

  1. Downloading the migration scripts
  2. Preparing for the migration
  3. Generating the CSV files
  4. Creating the public folder mailboxes in Exchange 2013
  5. Starting the migration
  6. Lock the public folders for final migration (which requires some downtime)
  7. Finalize the migration (downtime still required)
  8. Test and unlock the public folder migration

Of course the reality is that there are many caveats and ways for a public folder migration to go wrong. Generally speaking you should always refer to the TechNet article as it will document the latest requirements and limitations for a public folder migration. However you can also refer to the following resources for some additional real-world advice:

Here is an example migration for the Exchange Server Pro organization, to show you what the end to end process looks like.

Download Scripts and Prepare Organization

The public folder migration scripts have been downloaded and saved to a server that has the Exchange 2010 management tools installed.

A snapshot of the existing public folder structure, statistics, and permissions is taken. These commands are run from the Exchange 2010 management shell.

[PS] C:\PFMigration>Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
[PS] C:\PFMigration>Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
[PS] C:\PFMigration>Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

Any public folders that have a backslash in the name need to be renamed to remove the backslash. To identity those folders run the following command in the Exchange 2010 management shell.

[PS] C:\PFMigration>Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Verify that no record exists of a previous public folder migration. The values returned here should be $false.

[PS] C:\PFMigration>Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete
PublicFoldersLockedForMigration : False
PublicFolderMigrationComplete   : False

In the Exchange 2013 management shell run the following commands to verify that there are no existing public folder migration requests, and no existing modern public folders.

[PS] C:\PFMigration>Get-PublicFolderMigrationRequest
[PS] C:\PFMigration>Get-Mailbox -PublicFolder
[PS] C:\PFMigration>Get-PublicFolder

Generate CSV Files and Create Public Folder Mailboxes

With the preparation completed we can now generate the CSV files that will be used to create the new public folder mailboxes on Exchange 2013. Run the following command in the Exchange 2010 management shell. Replace the server name HO-EX2010-PF with the name of one of your public folder servers.

[PS] C:\PFMigration>.\Export-PublicFolderStatistics.ps1 C:\PFMigration\PFSizeMap.csv HO-EX2010-PF
[7/25/2014 11:06:10 AM] Enumerating folders under NON_IPM_SUBTREE...
[7/25/2014 11:06:14 AM] Enumerating folders under NON_IPM_SUBTREE completed...44 folders found.
[7/25/2014 11:06:14 AM] Retrieving statistics from server BR-EX2010-MB
[7/25/2014 11:06:15 AM] Retrieving statistics from server BR-EX2010-MB complete...22 folders found.
[7/25/2014 11:06:15 AM] Total unique folders found : 22.
[7/25/2014 11:06:15 AM] Retrieving statistics from server HO-EX2010-PF
[7/25/2014 11:06:16 AM] Retrieving statistics from server HO-EX2010-PF complete...58 folders found.
[7/25/2014 11:06:16 AM] Total unique folders found : 58.
[7/25/2014 11:06:16 AM] Exporting statistics for 58 folders
[7/25/2014 11:06:16 AM] Exporting folders to a CSV file

Review the folder sizes in the CSV file and make a decision for how big each public folder mailbox will be. This will determine the number of public folder mailboxes created to store all of the public folder data in Exchange 2013. For example, if you have 20Gb of public folder data, and choose a maximum mailbox size of 1Gb, you will end up with 20 public folder mailboxes.

The Exchange Server Pro organization has very little public folder data, so a maximum size of 10Gb will result in a single public folder mailbox.

exchange-2013-public-folders-02

[PS] C:\PFMigration>.\PublicFolderToMailboxMapGenerator.ps1 10000000 C:\PFMigration\PFSizeMap.csv C:\PFMigration\PFMailboxMap.csv
[7/25/2014 11:11:25 AM] Reading public folder list...
[7/25/2014 11:11:25 AM] Loading folder hierarchy...
[7/25/2014 11:11:25 AM] Allocating folders to mailboxes...
[7/25/2014 11:11:25 AM] Trying to accomodate folders with their parent...
[7/25/2014 11:11:25 AM] Exporting folder mapping...

exchange-2013-public-folders-03

On an Exchange 2013 server create a public folder mailbox to be the master hierarchy mailbox.

[PS] C:\>New-Mailbox -PublicFolder PFHierarchy -HoldForMigration:$true
Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
PFHierarchy               PFHierarchy          ex2013srv2       Unlimited

Run the following command to create the additional public folder mailboxes to host the public folder content. The number of mailboxes is determined by the PF mailbox map generated in the previous step. In the case of the Exchange Server Pro organization only one mailbox is required.

[PS] C:\>for($index =1 ; $index -le $numberOfMailboxes ; $index++)
>> {
>>     $PFMailboxName = "Mailbox"+$index;  if($index -eq 1) {New-Mailbox -PublicFolder $PFMailboxName -HoldForMigration:$true -IsExcludedFromServingHierarchy:$true;}else{New-Mailbox -PublicFolder $PFMailboxName -IsExcludedFromServingHierarchy:$true}
>> }
>>
Name                      Alias                ServerName       ProhibitSendQuota
----                      -----                ----------       -----------------
Mailbox1                  Mailbox1             ex2013srv2       Unlimited

Migrating the Public Folders

With the new mailboxes created in Exchange 2013 we can proceed with the migration.

Note that you need the CSV file containing the PF mailbox map generated earlier, so copy that to a server with the Exchange 2013 management tools where you are running this command.

[PS] C:\>New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server HO-EX2010-PF) -CSVData (Get-Content C:\PFMigration\PFMailboxMap.csv -Encoding Byte)
Name                                           SourceDatabase                                 Status
----                                           --------------                                 ------
PublicFolderMigration                          PF-HO-01                                       Queued

Monitor the progress of the public folder moves until they reach an AutoSuspended state.

[PS] C:\>Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics | ft -auto
Name                  StatusDetail  SourceDatabase PercentComplete
----                  ------------  -------------- ---------------
PublicFolderMigration AutoSuspended PF-HO-01       95

If you encounter a failed migration request you can look closer at the reasons for the failure.

[PS] C:\>Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics | fl failure*

For example, if the migration has failed due to bad items, you can set a higher bad item limit on the request and then resume it.

[PS] C:\>Get-PublicFolderMigrationRequest | Set-PublicFolderMigrationRequest -BadItemLimit 10
WARNING: When an item can't be read from the source database or it can't be written to the destination database, it
will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting Exchange not copy such items to
 the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox.

When the AutoSuspended state has been reached the legacy public folders can be locked for the final migration. This requires downtime, the length of which depends on how much new content has been generated in public folders since the AutoSuspended state was reached and will still need to be migrated.

In the Exchange 2010 management shell run the following command.

[PS] C:\>Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

With the public folders locked we can complete the migration request. In the Exchange 2013 management shell run the following commands.

[PS] C:\>Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false
[PS] C:\>Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

A test mailbox is set to use the Exchange 2013 public folder mailbox and used to test public folder functionality.

[PS] C:\>Set-Mailbox ex2013test -DefaultPublicFolderMailbox PFHierarchy

exchange-2013-public-folders-04

With the test successful the organization config is updated to indicate that the migration of public folders is complete. This command is run from the Exchange 2010 management shell.

[PS] C:\>Set-OrganizationConfig -PublicFolderMigrationComplete:$true

During the final migration phase when public folders were locked, regular users were unable to access the public folders in Outlook. After the migration completion flag is set above, and the users restart Outlook, they should be able to access public folders again. Any new items created by the test user should be visible as well.

exchange-2013-public-folders-05

In the next part of this article series we’ll look at decommissioning the legacy Exchange servers from the organization.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Moving Public Folders is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server 2010 to 2013 Migration – Removing Legacy Servers

$
0
0

This article is part of a series on migrating from Exchange Server 2010 to 2013.

With all of the services and data migrated to Exchange Server 2013 we can begin the removal of the legacy Exchange servers from the organization.

Exchange servers must be correctly uninstalled from an organization to avoid future issues due to orphaned objects. It is not enough to simply shut down the server.

Aside from your own regular server decommissioning steps such as taking a final backup, removing from monitoring systems, disposing of hardware etc, the Exchange Server application itself needs to go through a few simple decommissioning steps. These will depend on the server roles that were installed, but can generally be broken down as follows.

Note: When you remove the last Exchange 2010 server from the organization any Exchange 2010 management tools (eg on admin workstations) will stop working (although the management shell may still connect to Exchange 2013 servers). This may seem obvious, but I have seen people be surprised by this. By the time you are removing the last Exchange 2010 server all of your administrators should be using the Exchange 2013 management tools.

Edge Transport Servers

To decommission an Exchange 2010 Edge Transport server verify that no more mail is flowing through the server. This is achieved by configuring transport and cutting over SMTP namespaces. You can use protocol logs and message tracking logs to verify this.

In a typical case you may still see some traffic hitting the server. This could be due to incoming SMTP connections still hitting the server, eg spammers hitting an open firewall port that still allows access to that server. Or it may be due to the occasional outbound email still routing over that Edge subscription. Review any evidence of ongoing email traffic and either address it or choose to ignore it and proceed with the decommissioning anyway.

Before an Edge Transport server can be uninstalled the Edge Subscription must be removed, which can be done from the Exchange Management Console.

exchange-2010-2013-migration-edge-removal-01

And from the Exchange Management Shell on the Edge Transport server run Remove-EdgeSubscription.

[PS] C:\>Get-EdgeSubscription
Name            Site                 Domain
----            ----                 ------
HO-EX2010-EDGE                       exchangeserverpro...
[PS] C:\>Remove-EdgeSubscription HO-EX2010-EDGE
Confirm
Are you sure you want to perform this action?
Removing Edge Subscription "HO-EX2010-EDGE".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Confirm
Do you want to remove recipients? You don't need to remove the recipients that have already synchronized to this Edge
server if you will re-subscribe it to the same organization. This would improve the performance of Edge synchronization
 when you re-subscribe.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Launch the uninstall from Programs and Features in the Control Panel. If the readiness check passes you can click Uninstall to complete the process.

exchange-2010-2013-migration-edge-removal-02

Client Access Servers

Client Access servers can be removed when they are no longer serving any client requests. This is achieved by completing the cutover of the client access namespaces to Exchange Server 2013.

You can verify that no more traffic is hitting the Client Access server by reviewing the IIS logs on the server. Note that you will likely see continued hits in the logs from the Exchange 2013 servers themselves, or from any connections to the /PowerShell virtual directory by administrators.

exchange-2010-2013-migration-cas-removal-01

If there is too much log data to analyse visually you can use Log Parser to determine which users (if any) are still making connections to the server. For example:

C:\Program Files (x86)\Log Parser 2.2>logparser "select Count(cs-username) as Count, cs-username as Username from 'C:\inetpub\logs\logfiles\w3svc1\*.*' group by Username order by Count(Username)" -i:IISW3C
Count Username
----- --------------------
0     -
598   ESPNET\Administrator
Statistics:
-----------
Elements processed: 100861
Elements output:    2
Execution time:     0.27 seconds

Just be aware that querying a wildcard like ‘C:\inetpub\logs\logfiles\w3svc1\*.*’ will return results from any log file in that directory, which may be months or even years worth of log data. You can refine the search by removing older log files from the directory, or changing the query to only search file names of a smaller date range, eg ‘C:\inetpub\logs\logfiles\w3svc1\u_ex1407*.*’.

If the server is a dedicated Client Access server then you can launch the uninstall from Programs and Features in Control Panel and uninstall it. If it is a multi-role server you may wish to wait until you’ve verified all roles are ready to be uninstalled before doing them all together.

Hub Transport Servers

Hub Transport servers can be removed when there is no more email traffic passing through them, and they are not the source Transport server for any Send Connectors. As with the Edge Transport role you can use protocol logs and message tracking logs to verify this.

Because internal traffic may still be traversing the server you may still see some hits, particularly larger organizations where multiple routes exist between internal sites. The presence of a relay connector on the server could also be an indication that it is still in use by production systems that require SMTP.

But generally speaking, if there are no mailboxes or public folders still in the site, and no DNS aliases still pointing at the site for internal SMTP usage, then you can proceed with the uninstallation.

As a precaution you may consider pausing or stopping the Microsoft Exchange Transport service on the server for a period of time to verify that the server removal will have no impact on production services.

If the server is a dedicated Hub Transport server then you can launch the uninstall from Programs and Features in Control Panel and uninstall it. If it is a multi-role server you may wish to wait until you’ve verified all roles are ready to be uninstalled before doing them all together.

Mailbox Servers

Mailbox servers an be uninstalled when they no longer host mailboxes or public folders, are not members of DAGs, and are not responsible for generating offline address books.

The legacy offline address books can be removed from the organization when there are no more Exchange 2010 mailbox users. Exchange 2013 mailbox users will be using the new OAB created by Exchange 2013 setup.

exchange-2010-2013-migration-oab-removal

Public folder databases can be removed if the migration of public folders to Exchange 2013 is complete. You can remove the databases using PowerShell, for example:

[PS] C:\>Get-PublicFolderDatabase -Server BR-EX2010-MB | Remove-PublicFolderDatabase
Confirm
Are you sure you want to perform this action?
Removing public folder database "PF-BR-01".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file located in C:\Program
Files\Microsoft\Exchange Server\V14\Mailbox\PF-BR-01\PF-BR-01.edb from your computer manually if it exists. Specified
database: PF-BR-01

Mailbox databases can be removed if the mailbox migration to Exchange 2013 has been complete. Again, you can use PowerShell to remove them.

[PS] C:\>Get-MailboxDatabase -Server BR-EX2010-MB
Name                           Server          Recovery        ReplicationType
----                           ------          --------        ---------------
MB-BR-01                       BR-EX2010-MB    False           None
MB-BR-02                       BR-EX2010-MB    False           None
[PS] C:\>Remove-MailboxDatabase MB-BR-01
Confirm
Are you sure you want to perform this action?
Removing mailbox database "MB-BR-01".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file located in
F:\Data\MB-BR-01\MB-BR-01.edb from your computer manually if it exists. Specified database: MB-BR-01
[PS] C:\>Remove-MailboxDatabase MB-BR-02
Confirm
Are you sure you want to perform this action?
Removing mailbox database "MB-BR-02".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
WARNING: The specified database has been removed. You must remove the database file located in
F:\Data\MB-BR-02\MB-BR-02.edb from your computer manually if it exists. Specified database: MB-BR-02

For DAG members the approach is a little different. The process involves:

  1. Removing database copies from the server (unless it is the last DAG member hosting the single copy of the databases)
  2. Removing the server from DAG membership
  3. Removing the databases from the standalone server
  4. Uninstalling Exchange from the standalone server
  5. Removing the DAG object from the organization

For example, removing database copies from HO-EX2010-MB2, first move any active database copies to another DAG member.

[PS] C:\>Move-ActiveMailboxDatabase -Server HO-EX2010-MB2

Verify that the server only hosts passive database copies. You should see no “Mounted” status in this output.

[PS] C:\>Get-MailboxDatabaseCopyStatus -Server HO-EX2010-MB2
Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                                              Length    Length                             State
----                                          ------          --------- ----------- --------------------   ------------
MB-HO-01\HO-EX2010-MB2                        Healthy         0         0           7/25/2014 10:35:27 AM  Healthy
MB-HO-04\HO-EX2010-MB2                        Healthy         0         0           7/25/2014 10:35:21 AM  Healthy
MB-HO-02\HO-EX2010-MB2                        Healthy         0         0           7/25/2014 3:08:47 PM   Healthy

Remove the database copies from the server.

[PS] C:\>Get-MailboxDatabaseCopyStatus -Server HO-EX2010-MB2 | Remove-MailboxDatabaseCopy

If you are removing the second last DAG member you’ll first need to turn off DAC mode.

[PS] C:\>Set-DatabaseAvailabilityGroup -Identity dag-headoffice -DatacenterActivationMode Off

Remove the server from the DAG.

[PS] C:\>Remove-DatabaseAvailabilityGroupServer -Identity dag-headoffice -MailboxServer HO-EX2010-MB2

You can then proceed with the uninstall.

exchange-2010-2013-migration-edge-removal-02

When all members have been removed from the DAG you can also remove the DAG object itself.

[PS] C:\>Remove-DatabaseAvailabilityGroup dag-headoffice

Wish all Exchange 2010 servers uninstalled the migration from Exchange 2010 to Exchange 2013 is complete.

Return to the Exchange 2010 to 2013 migration series index page.


This article Exchange Server 2010 to 2013 Migration – Removing Legacy Servers is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Fix Available for Exchange Server 2013 Hybrid Connectivity Wizard Issue

$
0
0

Microsoft has announced an important update is available to resolve an issue with the Hybrid Connectivity Wizard in Exchange Server 2013.

For Exchange 2013 organizations creating new or managing an existing hybrid configuration with the HCW, the following HCW error message indicates you are experiencing the issue this update addresses:

Subtask CheckPrereqs execution failed: Check Tenant Prerequisites Deserialization fails due to one SerializationException: Microsoft.Exchange.Compliance.Serialization.Formatters.BlockedTypeException: The type to be (de)serialized is not allowed: Microsoft.Exchange.Data.Directory.DirectoryBackendType

If you experience this issue, contact Microsoft support to obtain the fix as documented in KB2988229. This fix requires Exchange Server 2013 Service Pack 1 (SP1) or Cumulative Update 5 (CU5).

The fix is not required if you already have a hybrid deployment and do not have a need to run the HCW again.

If you currently have an Exchange 2013-based hybrid deployment configured, you will not notice any issues unless you rerun the HCW as part of updating or managing your existing hybrid features. Unless you need to reconfigure your hybrid deployment, you can simply wait for the next update of Exchange Server 2013 (Cumulative Update 6) to correct this issue with the HCW.

Microsoft also provides an FAQ here which should cover any concerns or confusion people may have about this issue.

If for some reason you are unable to acquire the fix from Microsoft Support you could use the steps documented by Steve Goodman here to manually set up a hybrid configuration. However please pay attention to Steve’s warnings and caveats about this approach.


This article Fix Available for Exchange Server 2013 Hybrid Connectivity Wizard Issue is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

What Else Do You Want to Know About Migrating to Exchange Server 2013?

$
0
0

Over the past few weeks I’ve published a series of articles here on Exchange Server Pro about migrating to Exchange Server 2013.

You can see the entire series here.

These articles will soon be available as a single PDF to download for free (yes, a free migration guide!)

A lot of Exchange Server Pro readers have emailed me asking for an Exchange 2013 migration guide, and I’d love to make this free migration guide as useful as possible for the community, so I’m asking you for a quick favour.

Please click the link below to fill out a very short survey to let me know your top two questions, problems or challenges for migrating to Exchange Server 2013.

>> Click Here <<

Nothing is too big or small, and it will all help to create a highly useful guide for the Exchange Server community.

PS – if you’re wondering when this free guide will be available, my current estimate is sometime around October/November. I’ll be putting it all together when I get back from Exchange Connections.


This article What Else Do You Want to Know About Migrating to Exchange Server 2013? is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Azure Active Directory Sync Report Script

$
0
0

One of the best things about the Exchange Server community is the sharing of PowerShell code samples and scripts that occurs. I’m sure many of us can honestly say that we’ve saved hours or even days of time thanks to a script that someone else published online.

Perfect example, I’m running up a hybrid Exchange deployment and had just finished setting up DirSync, and wanted to verify a few things. My immediate thought was that there should be a fast way to do this via PowerShell.

And there is, thanks to Exchange MVP Mike Crowley who has published this DirSync report script.

I downloaded it, ran it on my DirSync server, and it worked perfectly first time. A great community contribution by Mike, and one that I’m sure many people will find useful.

dirsync-report-script

Read Mike’s blog post here or download the script from the TechNet script repository.

 


This article Azure Active Directory Sync Report Script is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Getting Started with the Exchange Server 2013 Edge Transport Server Role

$
0
0

Exchange Server 2013 Service Pack 1 saw the return of the Edge Transport role, which was missing in the RTM release.

The Edge Transport role is involved in SMTP communications (email transport), and one or more Edge Transport servers are typically placed in a DMZ to satisfy the needs of organizations who require no direct connectivity between the internal network and the internet. Edge Transport can also serve this role for hybrid deployments with Office 365, so that mail flow between the on-premises organization and the cloud passes through the Edge server.

exchange-2013-edge-transport

Edge Transport also contains some additional transport agents that are not installed on Mailbox servers. Here is the complete list of transport agents for Edge Transport:

[PS] C:\>Get-TransportAgent
Identity                                           Enabled         Priority
--------                                           -------         --------
Connection Filtering Agent                         True            1
Address Rewriting Inbound Agent                    True            2
Edge Rule Agent                                    True            3
Content Filter Agent                               True            4
Sender Id Agent                                    True            5
Sender Filter Agent                                True            6
Recipient Filter Agent                             True            7
Protocol Analysis Agent                            True            8
Attachment Filtering Agent                         True            9
Address Rewriting Outbound Agent                   True            10

In comparison, here is the list for the Mailbox server role:

Identity                                           Enabled         Priority
--------                                           -------         --------
Transport Rule Agent                               True            1
Malware Agent                                      True            2
Text Messaging Routing Agent                       True            3
Text Messaging Delivery Agent                      True            4

For more on the Edge Transport server role in Exchange Server 2013 see the following articles:


This article Getting Started with the Exchange Server 2013 Edge Transport Server Role is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Installing an Exchange Server 2013 Edge Transport Server

$
0
0

The Exchange Server 2013 Edge Transport role can be installed on the same server operating systems as other Exchange 2013 server roles – Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

For this demonstration I will be installing on a Windows Server 2012 R2 server.

Preparing to Install Exchange Server 2013 Edge Transport

After installing the operating system configure an IP address, any static routes that may be required, and give the server a name (as well as a DNS suffix).

exchange-2013-edge-transport-pre-requisites-01

The server does not need to be a domain member.

There are two important DNS requirements:

  1. The Edge Transport server must be able to resolve the Mailbox server names in DNS. An easy way to achieve this is to point the DNS client configuration on the Edge server to your internal DNS servers (this may require opening a firewall port).
  2. The internal Mailbox servers must be able to resolve the Edge Transport server in DNS. You may need to manually register a DNS record on your internal DNS servers for this.

There are also some firewall ports to open:

  • Port TCP 25 (SMTP) inbound/outbound between the internet and the Edge Transport server
  • Port TCP 25 (SMTP) inbound/outbound between the Edge Transport server and the internal network
  • Port TCP 50636 from the internal network to the Edge Transport server for EdgeSync

The only pre-requisite feature/role is the Active Directory Lightweight Directory Service.

PS C:\> Install-WindowsFeature ADLDS
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Active Directory Lightweight Directory Se...
WARNING: To create a new AD LDS instance on server, log on to the destination server and then run the Active Directory
Lightweight Directory Services Setup Wizard. For more information, see http://go.microsoft.com/fwlink/?LinkId=224859.

Installing Exchange Server 2013 Edge Transport Role

Download the Exchange Server 2013 setup files (Service Pack 1 or later) to the server and run the following command from an elevated command prompt to perform the install.

C:\Admin\ex2013cu5>setup /m:install /r:et /IAcceptExchangeServerLicenseTerms
Welcome to Microsoft Exchange Server 2013 Cumulative Update 5 Unattended Setup
Copying Files...
File copy complete. Setup will now collect additional information needed for
installation.
Languages
Management tools
Edge Transport Role
Performing Microsoft Exchange Server Prerequisite Check
    Configuring Prerequisites                                 COMPLETED
    Prerequisite Analysis                                     COMPLETED
Configuring Microsoft Exchange Server
    Preparing Setup                                           COMPLETED
    Stopping Services                                         COMPLETED
    Copying Exchange Files                                    COMPLETED
    Language Files                                            COMPLETED
    Restoring Services                                        COMPLETED
    Language Configuration                                    COMPLETED
    Exchange Management Tools                                 COMPLETED
    Edge Transport Role                                       COMPLETED
    Finalizing Setup                                          COMPLETED
The Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to
take effect. Please reboot this server prior to placing it into production.

A reboot is required after setup completes.

After installing the Edge Transport server you can configure an Edge Subscription to establish inbound and outbound mail flow.


This article Installing an Exchange Server 2013 Edge Transport Server is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com


Configuring an Edge Subscription for Exchange Server 2013

$
0
0

An Edge Subscription subscribes an Exchange Server 2013 Edge Transport server to an Active Directory site. This automatically creates the required connectors for internet mail flow to occur inbound and outbound via the Edge Transport server and the Mailbox servers in that Active Directory site.

On the Edge Transport server create an Edge Subscription file.

[PS] C:\>New-EdgeSubscription -FileName C:\Admin\Edge.xml
Confirm
If you create an Edge Subscription, this Edge Transport server will be managed via EdgeSync replication. As a result,
any of the following objects that were created manually will be deleted: accepted domains, message classifications,
remote domains, and Send connectors. After creating the Edge Subscription, you must manage these objects from inside
the organization and allow EdgeSync to update the Edge Transport server. Also, the InternalSMTPServers list of the
TransportConfig object will be overwritten during the synchronization process.
 EdgeSync requires that this Edge Transport server is able to resolve the FQDN of the Mailbox servers in the Active
Directory site to which the Edge Transport server is being subscribed, and those Mailbox servers be able to resolve the
 FQDN of this Edge Transport server. You should complete the Edge Subscription inside the organization in the next
"1440" minutes before the bootstrap account expires.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Copy the Edge Subscription file to a Mailbox server in the organization Import the Edge Subscription file by running the following command.

[PS] C:\>New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path "C:\Admin\Edge.xml" -Encoding Byte -ReadCount 0)) -Site "DataCenter1"

In my example “DataCenter1″ is the name of the Active Directory site that hosts the Mailbox servers that I want to participate in EdgeSync with the Edge Transport server. If you have multiple Edge Transport servers (for high availability) you simply repeat the process of creating the Edge Subscription file on each Edge Transport server and then subscribing it to the Active Directory site.

Note: If you add a new Mailbox server to the site it will not participate in EdgeSync until you resubscribe the Edge Transport server to the site.

Removing Other Send Connectors

If you’ve previously configured send connectors for outbound email you may need to take additional steps to remove them after you’ve deployed your Edge Transport server.

For example, here you can see the two EdgeSync connectors that were automatically created, and the existing “Internet Email” send connector as well. At the moment outbound email will still go out via the “Internet Email” connector.

[PS] C:\>Get-SendConnector
Identity                                AddressSpaces                           Enabled
--------                                -------------                           -------
Internet Email                          {SMTP:*;1}                              True
EdgeSync - DataCenter1 to Internet      {smtp:*;100}                            True
EdgeSync - Inbound to DataCenter1       {smtp:--;100}                           True

Remove any unnecessary send connectors so that mail will flow via the Edge Transport server.

[PS] C:\>Remove-SendConnector "Internet Email"
Confirm
Are you sure you want to perform this action?
Removing Send connector "Internet Email".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Verify Outbound Email

You can verify that outbound email is flowing via the Edge Transport server by sending an outbound message, then copying the message headers from the received message into a header analyzer such as MXToolbox or ExRCA.

exchange-2013-edge-transport-message-headers

Verify Inbound Email

For inbound email you will need to ensure that your MX records point to the public IP address for your Edge Transport server (which may be a NATed IP address behind a firewall or other network device). To verify inbound mail flow send an email from an external address or use the inbound SMTP test on ExRCA.


This article Configuring an Edge Subscription for Exchange Server 2013 is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Add an IP Block List Provider to Exchange Server 2013 Edge Transport

$
0
0

One of the transport agents that is installed on the Exchange 2013 Edge Transport server is the connection filter agent.

[PS] C:\>Get-TransportAgent
Identity                                           Enabled         Priority
--------                                           -------         --------
Connection Filtering Agent                         True            1
Address Rewriting Inbound Agent                    True            2
Edge Rule Agent                                    True            3
Content Filter Agent                               True            4
Sender Id Agent                                    True            5
Sender Filter Agent                                True            6
Recipient Filter Agent                             True            7
Protocol Analysis Agent                            True            8
Attachment Filtering Agent                         True            9
Address Rewriting Outbound Agent                   True            10

The connection filter agent looks at the IP address of a server that is making an SMTP connection to the Edge Transport server and decides whether to block or allow the connection. It makes the decision by looking up the IP address in a block list, allow list, or by querying a block/allow list provider.

When your Exchange organization is receiving spam you can add the IP addresses of the spammers to an IP block list on the Edge Transport server. However this is quite inefficient, as you’ll constantly be adding new IP addresses to the list.

A more effective approach is to use one or more IP block list providers, such as Spamhaus (my personal favourite) or SpamCop.

To add Spamhaus to your connection filter agent run the follow Exchange Management Shell command on the Edge Transport server.

[PS] C:\>Add-IPBlockListProvider -Name Spamhaus -LookupDomain zen.spamhaus.org -AnyMatch $true -Enabled $true -RejectionResponse "IP address is listed by Spamhaus"

Note you can change the rejection message that it sent back to the sender.

[PS] C:\>Set-IPBlockListProvider Spamhaus -RejectionResponse "IP address is listed by Spamhaus Zen."

You can add multiple providers, just make sure you check their guidance on whether there are issues adding multiple lookup domains from the same provider. Also make sure you check their terms and conditions and comply with any commercial usage policies they have.

[PS] C:\>Get-IPBlockListProvider
Name                                    LookupDomain                            Priority
----                                    ------------                            --------
Spamhaus                                zen.spamhaus.org                        1
SpamCop                                 bl.spamcopy.net                         2

After the block list provider has been in place for a day or two you can see the results by running the Get-AntispamTopRBLProviders.ps1 script that ships with Exchange.

[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\get-AntispamTopRBLProviders.ps1
Name     Value
----     -----
Spamhaus    12

This article Add an IP Block List Provider to Exchange Server 2013 Edge Transport is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Retrieving the Move History for an Exchange Server 2010/2013 Mailbox

$
0
0

Jim asks about a situation where a mailbox restore is needed but the database hosting the mailbox is unknown.

If I need to restore a mailbox, and if Exchange is randomly provisioning the mailboxes to any of the allowed databases, how does one know which database needs to be restored to recover the data? Do we need to get more granular and regulary run scripts which somehow sorts the mailboxes into specific databases based upon attributes? Say DB1 is lastnames beginning with A-F, DB2 is G-M…etc?

I see two potential scenarios here:

  1. The mailbox has been entirely deleted from the organization, so we can’t simply use Get-Mailbox to look at attributes such as which database it is hosted on
  2. The mailbox has been moved around for general maintenance reasons or due to migration, and so a restore requires us to know which database it was on at the time frame that the data restore is targeting

In neither of those scenarios would I recommend a database layout scheme where specific databases are used based on surname or department or anything like that. Quite frankly such schemes are too unreliable (what if someone mistakenly places the mailbox on the wrong database?) and cause performance and capacity management issues (eg database grow at different rates).

Instead I would recommend the following.

For deleted mailboxes, your deletion process must include a mechanism to capture the database it is currently on, plus the move history of the mailbox.

For existing mailboxes, I recommend using the move history to determine where the mailbox was at the time of interest. You can view the move history for a mailbox using Get-MailboxStatistics and the -IncludeMoveHistory switch. For example:

[PS] C:\>(Get-MailboxStatistics alan.reid -IncludeMoveHistory).MoveHistory | select CompletionTimestamp,SourceDatabase,TargetDatabase | ft -auto
CompletionTimestamp    SourceDatabase TargetDatabase
-------------------    -------------- --------------
14/07/2014 5:41:27 AM  MB-HO-04       DB01
8/01/2014 11:35:55 AM  MB-HO-03       MB-HO-04
11/09/2013 11:35:24 PM MB-HO-01       MB-HO-03

The number of moves retained in the move history will depend on the version of Exchange Server and whether you’ve customized the MRS configuration.

  • For Exchange Server 2010, the move history is 2 by default
  • For Exchange Server 2013, the move history is 5 by default

You can customize the MRS configuration and change that value anywhere between 0 and 100. The MRS configuration is stored in the MsExchangeMailboxReplication.exe.config file found in the \bin folder of the Exchange installation, for example C:\Program Files\Microsoft\Exchange Server\V15\Bin.

You’ll find it on Exchange 2010 Client Access servers or Exchange 2013 Mailbox servers.

Look for the section in the file under MRSConfiguration.

exchange-mailbox-move-history

A value of 5 is probably fine for most organizations, but if you have a high rate of mailbox moves in your org then increasing it may be wise.

Any changes you make to this value need to be changed on all other servers in your organization for consistency, otherwise you will not get the desired results. Also you will need to reapply the change after each cumulative update or service pack you install on the server.

For more information on using the move history and move reports see Tony’s post here:


This article Retrieving the Move History for an Exchange Server 2010/2013 Mailbox is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

What Does DatabaseCopyActivationDisabledAndMoveNow Do?

$
0
0

One of the steps when applying updates to Exchange 2013 servers that are members of a database availability group is to set a property called DatabaseCopyActivationDisabledAndMoveNow to $true.

For example:

[PS] C:\>Set-MailboxServer sydex1 -DatabaseCopyActivationDisabledAndMoveNow $true

So what actually happens when you do that?

As TechNet explains:

The DatabaseCopyActivationDisabledAndMoveNow parameter specifies whether to prevent databases from being mounted on this server if there are other healthy copies of the databases on other servers. It will also immediately move any mounted databases on the server to other servers if copies exist and are healthy. Setting this parameter won’t cause databases to move to a server that has the DatabaseCopyAutoActivationPolicy parameter set to Blocked.

So the first thing that happens is any active mailbox database copies on the server are moved to another DAG member, as long as:

  • Another healthy copy exists to activate
  • The DAG member that is hosting the copy does not have an auto activation policy of “Blocked”

Then what? Well, the DatabaseCopyActivationDisabledAndMoveNow property doesn’t prevent database copies being activated on that server again. But if you activate one you’ll see a message like this:

[PS] C:\>Move-ActiveMailboxDatabase -Identity DB01 -ActivateOnServer SYDEX1
WARNING: Server "SYDEX1.exchange2013demo.com" is enabled for DatabaseCopyActivationDisabledAndMoveNow. Moving databases
 to such servers may be ineffective because the system will automatically attempt to move again as soon as a healthy
copy is detected.

In my tests it took only a few minutes for the activate database copy to be moved elsewhere again.

Hopefully that makes it clearer why we perform that step during Exchange 2013 maintenance, and why it is important at the end of the maintenance to set the property back to $false.

[PS] C:\>Set-MailboxServer SYDEX1 -DatabaseCopyActivationDisabledAndMoveNow $false

This article What Does DatabaseCopyActivationDisabledAndMoveNow Do? is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Test-ExchangeServerHealth.ps1 v1.10 is Now Available, Plus an Announcement

$
0
0

I’m pleased to announce the availability of v1.10 of the Test-ExchangeServerHealth.ps1 script.

This version of the script contains one minor bug fix for testing DAG member replication health in mixed Exchange 2010/2013 organizations.

Existing Exchange Server Pro Insiders can download the script here. If you are not already a member you can join for free here.

I am also announcing that development of a new V2.0 of Test-ExchangeServerHealth.ps1 is under way. Planned features include:

  • Support for Exchange Server 2013 only (the V1.x script will still be available for Exchange 2010 environments)
  • Complete review and overhaul of code (some of it is close to 4 years old now, and was written in Exchange 2007/PowerShell 1.0 era)
  • A more user-friendly configuration and customization method (as demonstrated here)
  • Use of Managed Availability cmdlets (as discussed here)
  • More report items that people have been asking for (where possible)

As always I want to thank everyone who has downloaded the script (literally tens of thousands of you), used it, reported bugs, requested features, or just given general feedback over the years.

If you have anything you’d like to see added or improved in the V2.0 script please feel free to leave a comment below.


This article Test-ExchangeServerHealth.ps1 v1.10 is Now Available, Plus an Announcement is © 2014 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

Viewing all 515 articles
Browse latest View live