I had an issue recently with Rapid Recovery I wanted to detail for you guys in case you run into the same issue. I noticed that Exchange logs were not getting truncated appropriately on the Exchange server. Upon checking Rapid Recovery, I noticed the normal “Exchange” dropdown in the Summary window was gone. This is an issue where Rapid Recovery no longer detects Exchange.
Rapid Recovery no longer detects Exchange
The typical agent Summary in Rapid Recovery when it detects the Exchange server database on a server looks like the following:
As you can see, you have the “Exchange” dropdown that contains the Force Log truncation and set credentials options having to do with the Exchange database. However, upon looking at my Exchange server summary, the drop down menu was now gone:
As you can tell, the menu is no longer there with the normal Exchange server options. This is definitely the reason my logs have not been truncating.
The solution was rather simple and involved the restarting of services.
- First, restart the WMI service on the Exchange server
- Next, restart the Agent service on the Exchange server
- Finally, refresh the agent inside of the Rapid Recovery console
I know most of you know how to restart services, so not going to bore you with those details. However, to refresh the agent status, you simply look in the Summary window and click the Refresh option.
Evidently, the issue arises where the Core server loses connectivity with the agent and is unable to determine the server has Exchange loaded. It can no longer communicate with the Exchange server database. So then you have to make sure WMI is in a good state, as well as the Agent service. If you are running the AppAssure version of the agent, which Rapid Recovery is backwards compatible with, this will be under “AppAssure” in the services, and if running the Rapid Recovery version of the agent, this will be listed under “Dell Data Protection | Rapid Recovery” service.
I have found that issues like Rapid Recovery no longer detects Exchange often relates to some quirkiness between the agent on the protected server and the Core service on the Rapid Recovery server. A quick bounce of services many times will resolve issues such as the one described here.