Let’s begin with a quick question! Why would you need to reboot your Exchange Server? Well! There can be several reasons.
- It could be an office routine to install monthly OS and server updates, which need rebooting
- Several hardware issues require you to turn off and restart the Exchange server
- Updating a virtual machine would require rebooting the server
- You may have to add new resources to your Exchange server
What’s the catch?
All these reasons are fine, but why do you need to follow a safe reboot approach? Why can’t you just restart the Exchange Server without turning it off? This is due to the multiple services running in the Exchange Server in parallel.
- Some of these services might depend on others
- Some others may differ according to the version of Exchange Server
- Several services may be running or updating currently that you need to stop before restarting the server
These instances can delay the server restart or even stop it from restarting completely, making you restless with the sight of the blue screen. Switching off the Server properly and safely will avert such obstructions, and you can carry on with your intended tasks unperturbed.
Here, you may ask another question, “How to reboot an Exchange Server safely”, or you may further improvise it to enquire about the “Safe Procedures for Rebooting an Exchange Server”. In this blog, we will discuss these methods in detail.
However, at times, your reboot results in a system crash, mounting errors, or database corruption. To deal with such issues, we will also discuss the role of Exchange Server software, such as Stellar Repair for Exchange.
Rebooting an Exchange Server
Here are several methods that can help to restart your Exchange Server but you cannot call them safe.
Stop Exchange Service from the Services Console
This method requires you to stop the MSExchangeADTopology Service and then restart the server. However, it may not stop all the services reliably. Instead, it will stop dependent services, and you can do it through the Service Manager window.
- Press Windows Keys + R to open the Run dialog box
- Type services.msc to open the Services window
- Search for the Exchange Server services
- Right-click to stop all the manual or automatic services.
You can restart the server. However, stopping one or more services will not drain the exchange workloads in entirety. This is the reason why Microsoft does not approve stopping any Exchange services manually, including the ADTopology, unless instructed by an expert.
Stop Exchange Service automatically through PowerShell
To stop all the services automatically, you will need to run the script below in the Exchange Management Shell as Admin.
Get-service | ?{$_.Name -ilike “MSexch*”} | stop-service
This will automate the process and stop the services that start with MSexch. Once done, you can now reboot the standalone Exchange Server. Like the previous method, Microsoft does not recommend this manual method as well, unless suggested by an Engineer.
Rebooting the Exchange server in a Database Availability Group (DAG): A Safe Method
This is perhaps an ideal and safe procedure. Rebooting a server in the DAG will need you to put it in Maintenance mode. This will shift the Exchange database, mailboxes, and the client connections to a different DAG server or a node in a cluster, keeping them safe from any sort of adverse rebooting impact.
- Before these tasks, you will also have to drain the Hub Transport service to commit the uncommitted transactions and stop accepting new tasks, such as sending or receiving emails.
Here is the PowerShell command to empty the transport queues:
Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance
- If the Exchange Server is a member of the Database Availability Group (DAG), suspend the cluster node. Here is the command.
Suspend-ClusterNode “YourServerName-01”
- Finally, put the server in maintenance mode. Here is the command for the same
Set-ServerComponentState -Identity <server name> – Component ServerWideOffline -State Inactive -Requester Maintenance
Running these commands will shift the Exchange Server services to another DAG Server, allowing you to stop the services and then reboot the server.
What should be the backup plan if the Server Reboot does not work?
Rebooting the server through the safe procedures can work effectively. However, there is always the scope for error. You may face several issues:
- An update did not work as intended
- A third-party tool or service is creating problems
- A service remained stuck during reboot
Any such event can bar the Operating System or the Exchange Server from restarting. The integrity of the Exchange Server data can also be at stake.
Admins often try ESEUTIL to deal with issues that lead to database mounting errors. However, even ESEUTIL will fail to resolve a corrupt OS or a rebooting problem in the Exchange Server. To deal with such hassles, you can:
- Seek assistance from Microsoft
- Approach an experienced engineer to restore the server
Both these methods are time-consuming, require considerable administrative permissions, and can cause immense data loss.
In such situations, Exchange server recovery software, such as Stellar Repair for Exchange, can come to your rescue.
How can Stellar Repair for Exchange help?
Though not a rebooting application, this third-party tool works actively in several cases:
- Database corruption or mounting issues resulting from a server shutdown, crash, or reboot.
- When you get no help from ESEUTIL
- Exchange Server fails to start or work as usual due to Error 550, Error 327, Event ID 447, and Error C1041739.
- Failed CU/SU updates lead to Exchange database corruption
Here is how it assists in performing your Exchange Server operations without obstacles:
- Stellar Repair for Exchange reduced the EDB recovery time with no data loss
- Allows opening of a corrupt EDB file from an Exchange Server version, without installing an Exchange Server
- Enables exporting the recovered database to PST and other formats, live Exchange, or Office 365
You can try the free demo version of the Exchange Recovery software to assess its functionality. It scans the database to look for corrupt EDB files and lets you preview the recoverable items. To get full functionality, the company offers Corporate, Technician, and Toolkit versions of Stellar Repair for Exchange software.
Conclusion
Several reasons may prompt the need to reboot the Exchange Server. For example, you may have to correct hardware issues, install a new CU/SU update, add new resources to the server, and more. You can simply restart the server, but it could affect the currently active services. This necessitates the need to reboot the server before starting it again.
You can stop the Exchange Server services using Services Console or through PowerShell commands in the Exchange Management Shell. But, Microsoft does not recommend both these procedures, as they do not drain the Exchange services gracefully.
A better and safer alternative is to reboot the Exchange server in the Database Availability Group (DAG). Nevertheless, despite being safe, it may lead to mounting issues, database corruption, etc. Hence, it is always better to have plan B to activate in case these methods do not work.
In case you fail to handle the corruption, inconsistencies, and mounting errors in the Exchange database while rebooting, Stellar Repair for Exchange can help you out. The widely embraced Exchange server recovery software works actively in recovering the EDB files and the mailboxes, allowing you to resume your tasks with ease. The paid versions of the Exchange Server recovery software are available at the Stellar Info website. To start with, you may also try the free demo version of Stellar Repair for Exchange with limited functionality.
