Items filtered by date: July 2017

Recently I observed this issue during the migration of Exchange 2010 to Exchange 2016. Following are the symptoms noticed not for all but for very few users (less than 1%).

1. Unable to do Deep search on Outlook Address Book (Cached mode), such as with phone number, department etc.
2. Unable to succeed “Test E-mail AutoConfiguration” test from Outlook
3. Availability information were not displaying
4. Outlook returns following error while configuring profile,
"An encrypted connection to your mail server is not available.
Click next to attempt using an unencrypted connection."

Outlook New Profile Error

And similar other symptoms which occurs due to inadequate autodiscover information.

Suspected Reason and Solution

As you may aware, the mailbox move disconnects the Exchange 2010 mailboxes and connects the Exchange 2016 mailbox during the “Completing” stage if migration/move process. Which means, following stale information are present in the infra,

1. Mailbox Move for each user in the Migration batch
2. Disconnected Mailboxes at Exchange 2010 infra

The issue happens (I assume) because of the incomplete replication of information, and possibly due to the conflicts between connected and disconnected mailboxes. The solution in my case was fairly simple,

1. Remove the “Completed” move request against the user
        2. Restart "MSExchangeAutodiscoverAppPool" WebappPool on all Exchange 2016 servers "Restart-WebAppPool MSExchangeAutodiscoverAppPool"
3. Wait for 10 – 20 minutes, and try to test the autodiscover

The above helped me to restore the services back for the user who impacted. Share your experience in the form of comments.




Published in Solutions

Since the introduction of DAG into Exchange Server architecture, the DR situations became more easy and comfortable to deal with. On this article I have tried to pen down a simple and straight forward process on how to deal with DR scenario.

My LAB Servers:

Exchange Servers (4 nos): EX16-01, EX16-02, EX16-03, EX16-Dr1

AD Servers: 2010adc1 & 2010adc2 (both work as Witness/Alternate Witness servers respectively)

DAG Name: DAG02 (Please note I have configured Exchange Server 2016 DAG without cluster object)

Witness Server Information:

WitnessServer             :

WitnessDirectory         : c:\DAG02

Alt Witness Server       :

Alt Witness Dir            : c:\DAG02

Scenario: 2 Servers in Primary Datacenter & 2 Servers in Secondary datacenter. I plan to bring down 2 servers EX16-02 & EX16-03 and restore the DAG with EX16-01 & EX16-dr1 server.


  1. Database Auto activation has been blocked on all copies on both EX16-01 & EX16-dr1 to safe guard from auto mount operations.
  2. DAG is configured in DAC mode (DagOnly), this is a must to ensure smooth DR operations (Data Center Switchover).
  3. Alternate Witness Server is Configured

Datacenter Switchover Procedure

Step1: Bring down Servers as planned (Or assume both the server are crashed due to some unforeseen issues at the Primary Datacenter, and we expect these servers to come up after restoring the services at Primary data center).

Shutdown EX16-02

Shutdown EX16-03

Check the cluster node status,


Get clusternode 1

Step2: Terminate the partially or failed Servers (in our case the server which are OFF)

[PS]>Stop-DatabaseAvailabilityGroup -Identity DAG02 -MailboxServer EX16-02 –ConfigurationOnly

[PS]>Stop-DatabaseAvailabilityGroup -Identity DAG02 -MailboxServer EX16-03 –ConfigurationOnly

Stop DAG Member

You may verify the DAG statistics by executing the following command.

[PS]>Get-DatabaseAvailabilityGroup dag02 | fl Name,st*,prima*,oper*,*wit*

DAG Status with stopstart servers

Step3: Stop the cluster service on all the nodes which are currently running and will be part of the cluster during the DR operations. It is important to terminate/switch off all failed partially failed servers in the DAG before we proceed to next step.

[PS]>Stop-Service clussvc

Note: Run the above command on all the running members, in our case EX16-01 & EX16-dr1.

Step4: Restore the DAG using Restore-DatabaseAvailabilityGroup command

[PS]>Restore-DatabaseAvailabilityGroup -Identity DAG02

Restore DAG

Note: if you have not configured the DAG with alternate witness server prior to this operations, you may provide the alternate witness server values along with the Restore DAG command.

The restore DAG operation may take extended period of time depends on the server resources and network latencies. Please do patient until it returns the results.

Step5: Remove the restriction on DB activation

With the above command, we have finished activating the DR mailbox servers. Now we can remove the activation restriction on the databases, so that the database will start mounting automatically.

[PS]>Get-MailboxDatabaseCopyStatus | Resume-MailboxDatabaseCopy

Satus check

Validate the status, you should find mailbox databases gets mounted automatically in a while.

You may also verify the cluster node status, by now only the nodes which are active will be listed.

ClusterNode AfterRemoval

Failback Procedure (Restoring Services to Primary Datacenter)

Let’s assume both the failed servers are now back online. Please verify that the cluster services are in disabled & stopped status on both these servers. BTW, restoring services is more easy and quick than failover/switchover procedure.

Step1: Put the Mailbox servers in the restored primary datacenter into a started state.

[PS]>Start-DatabaseAvailabilitygroup -Identity DAG02 -mailboxServer EX16-02

[PS]>Start-DatabaseAvailabilitygroup -Identity DAG02 -mailboxServer EX16-03

Start DAGMember

The warnings can be ignored safely.

Step2: Run Set-DatabaseAvailabilityGroup to commit the members back to cluster.

[PS] >Set-DatabaseAvailabilityGroup -Identity DAG02

During the course of this operation, the default settings of clusters will be brought back such as witness server, directory and other site settings if any. After the Mailbox servers in the primary datacenter have been incorporated into the DAG, it will take some time to synchronize the database copies.

With that we finished fail back procedure, as the database will be mounted automatically to the primary datacenters as we have not changed its activation preferences.

Final Status

You may also force to mount database by activating it through EMC or EAC.

Please share you experience in the form of comments, if any.


Published in Solutions
theme by reviewshub