Agentless Exchange log truncation - is this working for anyone?

Question

This has not yet worked even once for me. Working with Quest support who, after a lot of time & effort, is recommending agent based protection. 
 I have Exchange 2016 Enterprise CU19 on Server 2016 Standard. VMware tools full installation. ESXI and vCenter are 6.7 U2. 
 Server is fairly new thanks to the Exchange hack earlier this year. We built all new servers and decom'd the old ones. I believe the old one was agent based protection. I only recently got involved with managing Rapid Recovery, mainly because of the log files situation. 
 I followed steps in this article, even going beyond and just disabling the firewall completely: https://support.quest.com/rapid-recovery/kb/252578/agentless-protection-with-application-support 
 I just ran diskshadow as per my quest support person's recommendation. Over 1TB of log files finally disappeared. 
 I really hope I can get this to work. 
 Thanks Danny

phuff · Answer

There's many layers to this, so forgive me, this prompts A LOT of questions. 
 Assuming you have not turned off Guest Quiescing off inside of Rapid Recovery (it is on by default), when the backup job runs with log truncation (manually forced or on schedule) when you open up your VMware console does the snapshot succeed? Or is there indeed a failure with the snapshot? Regardless if it works or fails take note of the time, then once the backup/snapshots are finished, go to the Exchange node and open up MS event logs and look at the application and system view for that time and see if there are any errors. 
 Again, sorry as you may have gone through sum or most of this, however modern agent-less backups with log truncation have a number of 'moving' parts. Windows Firewall/UAC and all that jazz hasn't made anyone's life easier. At least with an agent the agent is already 'on' the OS thus it basically never sees this 'outside entity' (in this case VMware acting on your backup vendor (Rapid Recovery's) behalf. That's not a plug for agent, just dialog. 
 The credential that you're using to truncate the logs generally has to be log admin or above for the OS and an account that has Exchange admin permissions. 
 I mentioned that RR defaults to Guest Quiescing for their VMware snapshots, this is s MUST for any agent-less log truncation, if this is turned off it'll never work. 
 Again, if you are aware, forgive me, but when you take a quiesced snapshot you get 2 VMware snapshots and you get 1 local OS VSS snapshot, so yeah, a few more moving parts. 
 Also to start with, does the RR GUI say under the summary page that it did truncate the logs? Like does the date/time for last log truncation change within the RR GUI when you manually truncate the logs or they automatically run? If the date changes then MS is telling RR it did it, which narrows down the issue. If it doesn't, then you know that successful exist code isn't being sent to RR. 
 Only for conversation, as far as RR is concerned it shouldn't affect your license either way if you go agent or agent-less. The short answer though is yes, not a knock on RR at all.... ANY agent-less backup system has the same problems with log truncation, the more and more that the OS and domains try to lock down their systems, the more hoops you have to jump through.