https://support.quest.com/appassure/kb/117518
I've found the above KB article that describes the problem I'm having, but it doesn't look like it's relevant to Rapid Recovery. Is there an updated version of this for Rapid Recovery?
https://support.quest.com/appassure/kb/117518
I've found the above KB article that describes the problem I'm having, but it doesn't look like it's relevant to Rapid Recovery. Is there an updated version of this for Rapid Recovery?
Hi thalsey:
The KB mentioned by Emte is less radical than the one you mention and it has better chances to take you to a solution.
However, before doing anything else, I would suggest to make sure that your core is still a member of the domain. To make a long story short, I had recently a case where the mongodb service on a Windows 2016 core was losing contact with the database (and was reported as not being able to start despite running). When checking any permissions on any file or folder on the Core Service, the domain accounts were shown as SIDs only. However, domain users were able to log on due to cached credentials. Adding back the machine to the domain solved the issue (which returned after 7 days). This was perplexing as the default life of machine credentials should be 30 days.
If all is well domain wise, check the KB suggested by Emte. Please note that in most cases it is not necessary stopping the core service; disabling the mongod service and shutting it down would do (even if it logs an error, it will still stop). To start it back, enable it and start it the usual way.
The first thing I would try after stopping the mongod service would be renaming C:\ProgramData\AppRecovery\EventsDatabase to C:\ProgramData\AppRecovery\EventsDatabase.old, create an empty folder C:\ProgramData\AppRecovery\EventsDatabase and enable and start the mongod service. In quite a few cases this solves the issue (at the cost of the logged data).
Hope that this helps.
Hi thalsey:
The KB mentioned by Emte is less radical than the one you mention and it has better chances to take you to a solution.
However, before doing anything else, I would suggest to make sure that your core is still a member of the domain. To make a long story short, I had recently a case where the mongodb service on a Windows 2016 core was losing contact with the database (and was reported as not being able to start despite running). When checking any permissions on any file or folder on the Core Service, the domain accounts were shown as SIDs only. However, domain users were able to log on due to cached credentials. Adding back the machine to the domain solved the issue (which returned after 7 days). This was perplexing as the default life of machine credentials should be 30 days.
If all is well domain wise, check the KB suggested by Emte. Please note that in most cases it is not necessary stopping the core service; disabling the mongod service and shutting it down would do (even if it logs an error, it will still stop). To start it back, enable it and start it the usual way.
The first thing I would try after stopping the mongod service would be renaming C:\ProgramData\AppRecovery\EventsDatabase to C:\ProgramData\AppRecovery\EventsDatabase.old, create an empty folder C:\ProgramData\AppRecovery\EventsDatabase and enable and start the mongod service. In quite a few cases this solves the issue (at the cost of the logged data).
Hope that this helps.