Powershell

We will start by setting the Hub Transport Service to Draining to stop it accepting any more messages.

Set-ServerComponentState EXCH1 –Component HubTransport –State Draining –Requester Maintenance

Now we will redirect any queued messages to EXCH2.

Redirect-Message -Server EXCH1 -Target EXCH2

And suspend EXCH1 from the DAG.

Suspend-ClusterNode –Name EXCH1

Next step is to disable Database Copy Auto Activation and initiate the move of any active databases on EXCH1 over to EXCH2.

Set-MailboxServer EXCH1 –DatabaseCopyActivationDisabledAndMoveNow $true

We want to confirm that the DatabaseCopyAutoActivationPolicy setting is set to Unrestricted.

Get-MailboxServer EXCH1 | Select DatabaseCopyAutoActivationPolicy

And now set it to Blocked to prevent any of the Databases from becoming Active.

Set-MailboxServer EXCH1 –DatabaseCopyAutoActivationPolicy Blocked

We will now check that all of the Active Databases on EXCH1 have moved to EXCH2.

Get-MailboxDatabaseCopyStatus -Server EXCH1 | Where {$_.Status -eq "Mounted"}

It may take a while for the Active databases to move, you can always log into the Exchange Admin Centre and manually move them if you are in a hurry.

Once the Active databases have all been moved we will put EXCH1 into maintenance mode.

Set-ServerComponentState EXCH1 –Component ServerWideOffline –State InActive –Requester Maintenance

At this point I usually like to reboot the server to free up resources and clear any pending reboot statuses.

After the reboot, log back in and reopen the Exchange Management Shell as Administrator.

Check the status of the PowerShell Execution Policy by running the following:

get-executionpolicy –list

Ensure that the MachinePolicy and UserPolicy are set to Undefined (Refer to KB981474 to fix if they aren’t).

You are now free to install any required Windows Updates or apply the latest Exchange CU. Always review the accompanying ReadMe notes to ensure there will be no issues in your environment.

After you have finished the updates and performed a reboot it is time to get things up and running again.

Log back in and reopen the Exchange Management Shell as Administrator.

Remove the server from Maintenance mode.

Set-ServerComponentState EXCH1 –Component ServerWideOffline –State Active –Requester Maintenance

Resume the server in the DAG.

Resume-ClusterNode –Name EXCH1

Reset the DatabaseCopyAutoActivationPolicy setting to Unrestricted.

Set-MailboxServer EXCH1 –DatabaseCopyAutoActivationPolicy Unrestricted

Reset the DatabaseCopyActivationDisabledAndMoveNow setting.

Set-MailboxServer EXCH1 –DatabaseCopyActivationDisabledAndMoveNow $false

Set the Hub Transport service to accept email messages.

Set-ServerComponentState EXCH1 –Component HubTransport –State Active –Requester Maintenance

Log back into your Load Balancer and re-enable the virtual services for EXCH1 that you disabled previously.

Now we will repeat the process for EXCH2.

Log into your load balancer and set any virtual services you have for the DAG to drainstop and disable any connections to EXCH2 (Typically there would be SMTP and HTTPS virtual services). This will force any future connections to EXCH1.

Log into EXCH2 and open the Exchange Management Shell as Administrator.

We will start by setting the Hub Transport Service to Draining to stop it accepting any more messages.

Set-ServerComponentState EXCH2 –Component HubTransport –State Draining –Requester Maintenance

Now we will redirect any queued messages to EXCH1.

Redirect-Message -Server EXCH2 -Target EXCH1

And suspend EXCH1 from the DAG.

Suspend-ClusterNode –Name EXCH2

Next step is to disable Database Copy Auto Activation and initiate the move of any active databases on EXCH1 over to EXCH2.

Set-MailboxServer EXCH2 –DatabaseCopyActivationDisabledAndMoveNow $true

We want to confirm that the DatabaseCopyAutoActivationPolicy setting is set to Unrestricted.

Get-MailboxServer EXCH2 | Select DatabaseCopyAutoActivationPolicy

And now set it to Blocked to prevent any of the Databases from becoming Active.

Set-MailboxServer EXCH2 –DatabaseCopyAutoActivationPolicy Blocked

We will now check that all of the Active Databases on EXCH1 have moved to EXCH2.

Get-MailboxDatabaseCopyStatus -Server EXCH2 | Where {$_.Status -eq "Mounted"}

It may take a while for the Active databases to move, you can always log into the Exchange Admin Centre and manually move them if you are in a hurry.

Once the Active databases have all been moved we will put EXCH2 into maintenance mode.

Set-ServerComponentState EXCH2 –Component ServerWideOffline –State InActive –Requester Maintenance

At this point I usually like to reboot the server to free up resources and clear any pending reboot statuses.

After the reboot, log back in and reopen the Exchange Management Shell as Administrator.

Check the status of the PowerShell Execution Policy by running the following:

get-executionpolicy –list

Ensure that the MachinePolicy and UserPolicy are set to Undefined (Refer to KB981474 to fix if they aren’t).

You are now free to install any required Windows Updates or apply the latest Exchange CU. Always review the accompanying ReadMe notes to ensure there will be no issues in your environment.

After you have finished the updates and performed a reboot it is time to get things up and running again.

Log back in and reopen the Exchange Management Shell as Administrator.

Remove the server from Maintenance mode.

Set-ServerComponentState EXCH2 –Component ServerWideOffline –State Active –Requester Maintenance

Resume the server in the DAG.

Resume-ClusterNode –Name EXCH2

Reset the DatabaseCopyAutoActivationPolicy setting to Unrestricted.

Set-MailboxServer EXCH2 –DatabaseCopyAutoActivationPolicy Unrestricted

Reset the DatabaseCopyActivationDisabledAndMoveNow setting.

Set-MailboxServer EXCH2 –DatabaseCopyActivationDisabledAndMoveNow $false

Set the Hub Transport service to accept email messages.

Set-ServerComponentState EXCH2 –Component HubTransport –State Active –Requester Maintenance

You can run some tests to ensure that everything has started up OK.

Check that the cluster nodes have all come up OK.

Get-ClusterNode

Check that all of the required services are running OK.

Test-ServiceHealth

Test MAPI connectivity to each server that is hosting an active database.

Test-MAPIConnectivity –Server exch1

Test-MAPIConnectivity –Server exch2

Check the DAG Copy Status Health.

Get-MailboxDatabaseCopyStatus * | sort name | Select name,status,contentindexstate

Check Replication Health.

Get-DatabaseAvailabilityGroup | select -ExpandProperty:Servers | Test-ReplicationHealth

Check the Database Activation Policy is set to Unrestricted.

Get-MailboxServer EXCH1 | Select DatabaseCopyAutoActivationPolicy

Get-MailboxServer EXCH2 | Select DatabaseCopyAutoActivationPolicy

Check that the Server Component states are set to Active.

(Get-ServerComponentState -Identity EXCH1 -Component ServerWideOffline).LocalStates

(Get-ServerComponentState -Identity EXCH2 -Component ServerWideOffline).LocalStates

From

http://www.hospitableit.com/howto/gracefully-patching-exchange-2016/

If you have the following error:
——————————————————– Microsoft Exchange Error ——————————————————– Cannot activate database copy ‘Activate Database Copy…’. Activate Database Copy… Failed Error: An Active Manager operation failed. Error The database action failed. Error: An error occurred while trying to validate the specified database copy for possible activation. Error: Database copy ‘db1′ on server ‘dag1′ has content index catalog files in the following state: ‘Failed’.. [Database: db1, Server: dag1] An Active Manager operation failed. Error An error occurred while trying to validate the specified database copy for possible activation. Error: Database copy ‘db1′ on server ‘dag1′ has content index catalog files in the following state: ‘Failed’..
First view / verify the copy status.
Get-MailboxDatabaseCopyStatus | fl name, contentindexstate
Update the catalog
Update-MailboxDatabaseCopy "db1/dag1" -CatalogOnly