After much await Microsoft has decided to release the Role Requirements Calculator for Exchange Server 2019.
However unlike other versions, Microsoft has decided to make getting this extremely difficult. How? By including the file only inside the Exchange Server 2019 CU2 update. Yes, now you have to download a 5GB+ file just to get a 761KB file. Well that’s a bummer indeed.
Anyhow, if anyone wants to give a try, you can get the Exchange Server 2019 CU 4 Role Requirements Calculator here..
In this scenario we are going to take an on-premise environment with a Windows Server 2012 R2 Active Directory and an Exchange Server 2016 environment. In our case, a user was accidentally deleted from the OU itself. (NOTE: It is always a best practice to enable ‘Protect object from accidental deletion‘ for your AD Objects.
You can also recover a deleted mailbox using backups. However, note that backups are not current. This will lead to restoring but will not give you the latest data once recovered.
Connect-Mailbox -Identity "Jude Perera" -Database DB01 -User "Jude Perera" -Alias jude
NOTE: The Identity parameter specifies the display name of the deleted mailbox retained in the mailbox database provided. The User parameter specifies the Active Directory user account to connect the mailbox to. Alias is what the users email alias is.
Now we must get the identity and user attributes from the noted in steps 3 and 6 which is as below;
Connect-Mailbox -Identity "Jude Perera" -Database DB01 -User "Jude Perera" -Alias jude
Tip: In case you receive an error ‘Property expression “jude” isn’t valid. Valid values are: Strings that includes ‘@’, where ‘@’ cannot be the last character.’ Navigate to the AD user properties, select the ‘Account’ tab and verify that the User logon name has the domain selected properly.
If you have a Domain Controller environment that’s Windows server 2003, 2008 or 2008 R2 it is high time to get your environment upgraded to the latest Windows Server environment. However, if you are currently using an above operating system OR if you previously upgraded from a legacy domain controller environment such as 2003, you might want to perform some extra steps prior upgrading or migrating to the new Windows Server 2016+ domain controllers.
Here’s the background of the story.
File Replication Service (FRS) came into the picture with Windows Server 2000. Microsoft was using FRS to replicate the SYSVOL between its domain controller members. Later on with Windows Server 2008, Microsoft introduced Distributed File System Replication (DFSR) that was able to replicate SYSVOL.
However, environments which got migrated from legacy 2003 domain controllers tend to utilize FRS. However when an upgrade is in place for your domain controllers, one thing you need to consider is raising your Forest and Domain functional levels.
For an example, a Windows server 2008 R2 with a Windows Server 2003 Forest and Domain functional level may still be using FRS as the default SYSVOL replication method. In this environment if you are to upgrade your domain controllers to Windows Server 2016 you will come into issues with FRS.
Windows Server version 1709 can no longer be added as an Active Directory domain controller (DC) to an existing domain that is still using File Replication Service (FRS) for replication of the SYSVOL share.
When you try to add a Windows Server version 1709-based server as a DC to the domain, you receive the following error message:
How to overcome this? Well, there is only one way and that is to migrate the replication method of the SYSVOL to DFSR. Let’s see steps to perform the migration.
First thing you might want to do is to check what SYSVOL replication is used in your environment. To do this, open up the command prompt using administrator and run the below command;
dfsrmig /GetGlobalState
dfsrmig /GetMigrationState
What you need to focus on the result is the state mentioned Global state (‘<State>’).
This is a very important stage. Why? Well you are dealing with your SYSVOL and its better to start the migration process knowing that your domain environment is running in a healthy state.
In this document I will be taking you through the process of what we call a ‘Quick Migration’. This involves migrating in a slow, phase by phase method where you will have the option to roll back. This is always preferred.
The migration will take you through migrating to below levels step by step;
0 Start State
1 Prepared State
2 Redirected State
3 Eliminated State
For the next few steps, we will be using the command ‘dfsrmig /SetGlobalState <state>’ where the state can be chosen from the above numerical value 0-3.
As we saw earlier, you will be shown to be in the ‘Start State’. Our task is to migrate the DFSR state to ‘Prepared’. For this, open the command prompt as administrator and run the below command;
dfsrmig /SetGlobalState 1
What happens is that the initiated domain controller will start the migration task for the given state and will inform the rest of the servers. Therefore this will take time and depending on your links, the time to complete on each server may vary. Once the command is executed, wait for 15mins and run the below command to view the status of the migration process.
dfsrmig /GetMigrationState
As you can see, the state is still ‘Start’ in three of my servers. What you can do to speed up the process is;
Once the migration is complete, you will receive the below message; Note that it says the state is now ‘Prepared‘
Also notice that you will have a new folder inside the NTDS for SYSVOL;
As we saw earlier, you will be shown to be in the ‘Start State’. Our task is to migrate the DFSR state to ‘Prepared’. For this, open the command prompt as administrator and run the below command;
dfsrmig /SetGlobalState 2
Once the command is executed, wait for 15mins and run the below command to view the status of the migration process.
dfsrmig /GetMigrationState
As you can see, the state is still ‘Start’ in three of my servers. What you can do to speed up the process is;
Once the migration is complete, you will receive the below message; Note that it says the state is now ‘Redirected‘
After the above task, you will be shown to be in the ‘Redirected State’. The next task would be the final task which is to migrate the DFSR state to ‘Eliminated’. For this, open the command prompt as administrator and run the below command;
dfsrmig /SetGlobalState 3
Once the command is executed, wait for a few mins and run the below command to view the status of the migration process.
dfsrmig /GetMigrationState
As you can see, the state is still ‘Start’ in three of my servers. What you can do to speed up the process is;
Once the migration is complete, you will receive the below message; Note that it says the state is now ‘Eliminated’
With this, we conclude the migration of the SYSVOL to DFSR. You can monitor for awhile and check for any errors using DCDIAG and REPADMIN.
Really appreciate all your comments, especially if i have missed anything or made a mistake regarding the installation. 🙂
(c) Copyrights Reserved! Do not share or use any content in any way without approval from poster!
The following section describes a step-by-step guide for the installation of Microsoft® Exchange Server 2019 Preview. The installation considers a single server deployment of Exchange Server 2019. Additional details of the topology and architecture of the lab environment which was used in the installation is described here;
| Active Directory Domain Controller(s) | |
| Operating System | Windows Server 2019 preview |
| Forest Functional Level | Windows Server 2019 preview |
| Domain Functional Level | Windows Server 2019 preview |
| Exchange 2019 server(s) | |
| Operating System | Windows Server 2019 preview |
| .Net Framework Version | 4.7.2 (default) |
The following Active Directory writable Domain Controller(s) are supported;
The first task in the installation of any version of Exchange is to prepare the Active Directory environment where the Exchange Server will be placed. However, prior to the preparation, it should be checked against the above Domain Controller support prerequisites mentioned earlier. Once the above requirements are verified for consistency, proceed with the following preparation tasks on the server/computer which will be used to prepare the Active Directory.
We will be using the Exchange Server itself to prepare the Active Directory.
Note: .Net Framework 4.7.2 is already included and is not required to download or install with Windows Server 2019 preview
Install-WindowsFeature RSAT-ADDS
Install-WindowsFeature NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS
To prepare the active Directory and the Domains for Exchange 2019, follow the following steps. To execute the commands, the commands should be run using the Schema Admins group and the Enterprise Admins group membership.
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /OrganizationName:”<organization name>” /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms
Now that your Active Directory forest and the domains are prepared, we can finally get running the Exchange Installation Wizard
If you’re installing the first Exchange 2019 Preview server in the organization, and the Active Directory preparation steps have not been performed, the account you use must have membership in the Enterprise Administrators group. If you haven’t previously prepared the Active Directory Schema, the account must also be a member of the Schema Admins group.
Once all the above tasks are performed, proceed with the below steps to verify the installation using the Exchange 2019 Administrative Center and PowerShell.
The Exchange Administration Center (EAC) is the web-based management console in Microsoft Exchange Server 2019 Preview that allows for ease of use and is optimized for on-premises, online, or hybrid Exchange deployments. To navigate to the Exchange Admin Center;
There you go. Time to play! Hope this guide helped you. Don’t forget to keep on checking for some exiting new posts on how to play around with the all new Admin Center as well as a step by step guide for installing Skype for Business Server 2019 preview in the next couple of days.
Really appreciate all your comments, especially if i have missed anything or made a mistake regarding the installation. 🙂
(c) Copyrights Reserved! Do not share or use any content in any way without approval from poster!
In terms of sizing an Exchange Server environment, it is always advised and recommended to follow the Microsoft Sizing guides, this specifically means that you need to go through the Exchange Sizing Calculator. The tool gives you estimated values of how your databases, logs and transport queues are going to grow. So, if you do not properly plan these sizes, you might end up getting your disks full.
The scenario which I’m going to talk about is such situation where the free space of the C Drive almost got full. While digging in what’s being eating up the storage, we found out that the Exchange Transport queue, or Mail.que file is the culprit.
Exchange Transport Queue
A queue is a temporary holding location for messages that are waiting to enter the next stage of processing or delivery to a destination. Each queue represents a logical set of messages that the Exchange server processes in a specific order. In Exchange 2016, queues hold messages before, during and after delivery. Queues exist in the Transport service on Mailbox servers and on Edge Transport servers.
| File | Description |
| Mail.que | This queue database file stores all the queued messages. |
| Tmp.edb | This temporary database file is used to verify the queue database schema on startup. |
| Trn*.log | Transaction logs record all changes to the queue database. Changes to the database are first written to the transaction log and then committed to the database. Trn.log is the current active transaction log file. Trntmp.log is the next provisioned transaction log file that’s created in advance. If the existing Trn.log transaction log file reaches its maximum size, Trn.log is renamed to Trn nnnn.log, where nnnn is a sequence number. Trntmp.log is then renamed Trn.log and becomes the current active transaction log file. |
| Trn.chk | This checkpoint file tracks the transaction log entries that have been committed to the database. This file is always in the same location as the mail.que file. |
| Trnres00001.jrs Trnres00002.jrs |
These reserve transaction log files act as placeholders. They’re only used when the hard disk that contains the transaction log runs out of space to stop the queue database cleanly. |
In simple, we can move the Mail.que database and log files associated to a different location. The below step by step guide will take you through how you can achieve this.
Before going ahead, here are some tips when it comes to moving your queue database.
%ExchangeInstallPath%TransportRoles\data\Queue
Once you have the disk and the downtime planned, we can start the procedure.
"F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue"
%ExchangeInstallPath%Bin\
<add key="QueueDatabasePath" value="<CurrentLocation>" /> <add key="QueueDatabaseLoggingPath" value="<CurrentLocation>" />
<add key="QueueDatabasePath" value="F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue" /> <add key="QueueDatabaseLoggingPath" value="F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue" />
%ExchangeInstallPath%TransportRoles\data\Queue
The environment was running Exchange Server 2016 (n-1)CU with Office 365 in a hybrid mode. The issue came up when users on-prem noticed that they are unable to receive emails from their own O365 cloud users. Looking more into this, figured out the following user mail flow scenarios;
So obviously, this had to do something with the hybrid connector since that’s the tunnel that bridges the two environments.
So back to the basics, lets trace down the error messages and see if we can get a clue. In order to see where our mails are stuck, you need to first check the delivery reports. Log in to the O365 Exchange ECP as administrator and navigate to Message Tracing. On the message tracing log, you will see something like below;
We’re almost there now. The above indicates that why O365 is not delivering the mails to on-prem environment is because as on the first item, we have configured to use TLS between the hybrid environments. Thus due to whatever reason, the certificate presented from the on-prem public IP does not match the certificate that is been binded in the Hybrid Configuration. Now in order to validate this, we need to look at two points;
Get-HybridConfiguration
Now as you can see, the Hybrid configuration is configured with the correct certificate. So nothing to worry on that.
Get-ReceiveConnector -Identity “<ExchangeServerName>\Default Frontend <ExchangeServerName>” | fl
In my case, the certificate was all fine and is set for the one as expected.
So, the certificate itself, exchange setup and office 365 hybrid setup is all configured as expected. Yet somehow, Office 365 is telling me that the certificate is not correct.
This is where we would need to properly test TLS in a more informative manner. We will now see how we can use a method where we can see the TLS communication that is made to our on-premises.
Enter CheckTLS web testing provider. The provider has many tools to check TLS mechanisms but in our case, we are looking at the receiving part. Thus we will head over here.
https://www.checktls.com/TestReceiver
What it does?
TestReceiver performs all the steps that Internet email systems go through to send email. It records every command and byte of data it sends and every answer and byte of data that the other email system sends. TestReceiver never actually sends an email, it just gets as close as possible, learning as much about the remote system as it can.
Because CheckTLS focuses on security, TestReceiver tries to establish a secure (TLS) connection with the recipient’s system. Along with recording everything, it looks at the security of the recipient’s system for things like: certificate contents and signers, encryption algorithms, key lengths, hostname mis-matches, incorrect wild-card usage, weak cyphers, etc.
So is this safe? absolutely. Since it only checks whatever is already published by your organization. It doesn’t grab your email ID, username or passwords.
And we have found the culprit. Just have a closer look at the above image. You can see that the TLS authentication does start however the certificate validation fails. The reason is that the issuing certificate is not our Exchange Certificate, but a self signed certificate by the barracuda appliance which is front-ending to external connections.
When Office 365 tries to initiate a TLS session, it is getting this self signed certificate thus the required URLs are not found (mail.domain.com) hence it drops the connection and throws out;
450 4.7.320 Certificate validation failed.
If this is your case, bump up your network team and ask them to bind the correct certificate from the appliance. Once its configured properly, run the below tests again to validate that everything is all good.
If everything is successful, send out couple of emails and you will see that mailflow is working as expected. For the mails that were queued, give some time and it’ll start flowing.
Got any inputs? Please feel free to let me know your ideas.
Cheers..
So here’s the case, during the last two weeks we’ve identified quite a few scenarios where the Domain Controllers kept on restarting out of nowhere. Here are the symptoms;
Upon going through the dump analysis of those cases and digging in more, the root cause was related to a SRV.SYS windows driver. Apparently this is a driver that handles SMBv1 connections. The restarting is due to a memory overflow in the system.
BugCheck 50, {ffffe00171aad000, 1, fffff80004652c20, 0}
Probably caused by : srv.sys ( srv!SrvOs2FeaToNt+48 )
Followup: MachineOwner
---------
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: ffffe00171aad000, memory referenced.
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation.
Arg3: fffff80004652c20, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
STACK_TEXT:
ffffe001`71aad000 00000000`00000001 ffffd000`208c8700 : nt!KeBugCheckEx
ffffe001`6c82a040 ffffd000`208c8700 fffff800`276e5c76 : nt! ?? ::FNODOBFM::`string'+0x26b6e
ffffe001`71aad000 ffffc000`320d2000 fffff800`27754445 : nt!MmAccessFault+0x769
fffff800`04652b52 00000000`00000010 00000000`00000246 : nt!KiPageFault+0x12f
ffffe001`71aacff8 5c725c6e`5c725c36 ffffc000`320c2138 : srv!SrvOs2FeaToNt+0x48
00000000`00000000 ffffc000`320b2010 00000000`00000002 : srv!SrvOs2FeaListToNt+0x125
fffff800`00010fe8 ffffe001`71a9c010 ffffe001`70d56010 : srv!SrvSmbOpen2+0xc3
ffffe001`70d56010 ffffc000`320b2010 00000000`00000002 : srv!ExecuteTransaction+0x2ca
00000000`00000000 ffffe001`00000035 ffffe001`0000f3d0 : srv!SrvSmbTransactionSecondary+0x40b
ffffe001`6ef9c388 ffffe001`70d56a80 fffff800`0461b010 : srv!SrvProcessSmb+0x237
ffffe001`70d56010 00000000`00000000 ffffe001`70d56020 : srv!SrvRestartReceive+0x114
ffffc000`329656f0 ffffe001`6ef9c340 00000000`00000080 : srv!WorkerThread+0xffffffff`ffffbda5
ffffe001`72281040 ffffd001`8b5e9180 ffffe001`71ef7040 : nt!IopThreadStart+0x26
ffffe001`72281040 ffffe001`6dbc6880 ffffd000`208c8c90 : nt!PspSystemThreadStartup+0x58
ffffd000`208c3000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16
Check your Updates!!!!! Well, in all our cases the client servers were not patched. The BSOD was due to the SMBv1 memory overflow.
In order to fix the issue, head over to the Microsoft Security Bulletin MS17-010 – Critical website, look for your Operating System, patch it ASAP.
Pretty strange why it was all good until now. Anyhow, whatever said and done another good reminder for everyone who’s lazy on updating their systems.
I’m pretty sure you know it already. There’s a serious Ransom-ware spreading across the globe and this one is again I repeat. Pretty darn serious!
Behold! “WannaCrypt” is here. This is so severe, that it has been reported that more than 95k PC’s are already infected.
The problem is that the ransom-ware if hit, will lock (encrypt) your files. So that you have no way of opening it without unlocking (decrypt). To unlock, the makes of the malware is demanding a ransom. And we never know if they will give you the key as well.
Apart from that this can spread across to other computers. Which makes things worse. The spread is using something called a Remote code execution that existed in Microsoft Server Message Block 1.0 (SMBv1) component.
Individual user
Windows XP SP2 x64
Windows XP SP3 x86 Windows XP Embedded SP3 x86
Windows 8 x86
Windows 8 x64
Corporate/Enterprise/ IT Admins
Oh and Windows 10 users, you’re all good. ^_^
There was a scenario where it was noticed that outbound mails were not getting delivered. The environment had 2 Edge Servers together with 2 CAS/Mailbox servers, both being Exchange 2013. Upon checking the mailbox queue on the internal servers, it was noticed that the mails were stuck in the queue on the Send connector that was responsible for outbound mail delivery with Edge Server.
The Error reported the following.
451 4.4.0 Primary target IP address responded with: “454 4.7.0 Temporary authentication failure.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts”
Additionally, the following tests were done.
| Network interface | Open port | Protocol | Note |
| Inbound from and outbound to the internal network | 25/TCP | SMTP | This port is required for mail flow to and from the Exchange organization. |
| Local only | 50389/TCP | LDAP | This port is used to make a local connection to AD LDS. |
| Inbound from the internal network | 50636/TCP | Secure LDAP | This port is required for EdgeSync synchronization. |
| Inbound from the internal network | 3389/TCP | RDP | Opening this port is optional. It provides more flexibility in managing the Edge Transport servers from inside the internal network by letting you use a remote desktop connection to manage the Edge Transport server. |
EdgeSync service cannot connect to this subscription because of error “No EdgeSync credentials were found for Edge transport server ED01.contoso.com on the local Hub Transport server. Remove the Edge subscription and re-subscribe the Edge Transport server.”
Microsoft Exchange EdgeSync can’t find the replication credential on %1 to synchronize with Edge server %2. This may happen if %1 joined the current Active Directory site after subscription for %2 was established. To have this Hub Transport server participate in EdgeSync, re-subscribe %2 to the current Active Directory site.
So basically, we see that the Edge Sync is not working as it should be. At the same time, we see that there’s a certificate issue as well. Upon checking the certificate, we identified that it’s from a local CA. So the next steps we would do is to;
However, upon doing the service re-assigning to the existing services, the following error was thrown.
The internal transport certificate for the local server was damaged or missing in Active Directory. The problem has been fixed. However, if you have existing Edge Subscriptions, you must subscribe all Edge Transport servers again by using the New-EdgeSubscription cmdlet in the Shell.
Though it said the problem has been fixed, we were still unable to get Edge Sync working. So the final thought was to;
Viola!!! No more errors!!
The guide will cover upgrading an Exchange Server 2013 CU8 into Exchange 2013 CU15.
In a nutshell, this is the procedure:
When you are performing an Upgrade, you can go ahead and install the latest Cumulative Update (CU). You DO NOT, need to install all previous CU’s one by one in an incremental way. This is because a CU is a full installation of Exchange Server plus a collection of all the updates, patches and changes that has been made available so far.
For an Example, if you are on Exchange Server 2016 RTM, you can straight away install CU4. Because CU4 will contain all changes made in each of the CU’s previously released.
Exchange 2016
| Version | Blog post |
| Exchange 2016 CU4 | Released: December 2016 Quarterly Exchange Updates |
| Exchange 2016 CU3 | Released: September 2016 Quarterly Exchange Updates |
| Exchange 2016 CU2 | Released: June 2016 Quarterly Exchange Updates |
| Exchange 2016 CU1 | Released: March 2016 Quarterly Exchange Updates |
| Exchange 2016 RTM | Exchange Server 2016: Forged in the cloud. Now available on-premises |
Exchange 2013
Now that you have downloaded the binaries, you need to get rid of the Interim Updates that may have been installed in your environment. In some cases, if an Interim Update is installed, Microsoft Exchange Server CU’s or SP’s cannot be installed. Therefore, before installing the binaries, read the release notes for any information on removal of interim updates. Below steps will guide for that;
If you have standalone servers in your environment, then an upgrade will require you to go in for a downtime. Why? Because the services needs to be stopped during the upgrade process. In such a scenario, skip to the Upgrade section.
However, if your environment consists multiple servers in terms of 2xCAS or 2xMBX or 2x(CAS+MBX) or any of a combined scenario, it is highly advised that you perform upgrading of the servers one by one. This will ensure that your environment will stay online using the rest of the high available servers taking the downtime away.
There’s a catch in here. Let’s say we have a 2 Mailbox Server scenario: Server A and B. You decide to mount all databases into ServerA and upgrade Server B. Although this seems an okay way to do, it is not the case. Reason is that the Active Manager and other Exchange backend workers doesn’t know that you are doing a planned maintenance. Thus, the workers will think that the server is in a failed state. Can we fix this? Absolutely. You have to take the services on Server B or the server that you are about to do the upgrade into ‘Maintenance Mode’.
Below steps will guide you to do so;
Set-ServerComponentState <SERVER> -Component HubTransport -State Draining -Requester Maintenance
Suspend-ClusterNode <SERVER>
Set-MailboxServer <server> -DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer <server> -DatabaseCopyAutoActivationPolicy Blocked
Set-ServerComponentState <server> -Component ServerWideOffline -State Inactive -Requester Maintenance
Now that the server has been put to maintenance mode and you are ready to proceed with the Upgrade process. First thing we need to do is, update the schema. This is critical because without the required schema updates, the setup will not proceed.
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAllDomains/IAcceptExchangeServerLicenseTerms OR Setup.exe /PrepareDomain/IAcceptExchangeServerLicenseTerms
Now that the server has been upgraded successfully we can resume Exchange services back to normal mode. Follow the below steps.
Set-ServerComponentState <SERVER> -Component HubTransport -State Active -Requester Maintenance
Resume-ClusterNode <SERVER>
Set-MailboxServer <server> -DatabaseCopyActivationDisabledAndMoveNow $false
Set-MailboxServer <server> -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState <server> -Component ServerWideOffline -State Active -Requester Maintenance
Now that your server is back in the game. It’s time to upgrade the second server. Perform the steps above from the beginning to do so.
Happy Upgrading!! J
Jude's Blog 