For MBS clients this is the expected behavior since everything is configured via the web dashboard.

That's a known limitation, but we're already working on an update that will allow you to launch force update from the portal based not only on the version number, but the build parameters as well.

Currently there are 2 options:
1) Either user workaround posted eirlier in the thread.
2) Change service account to the one that was used to encrypt the files.

We're already working on a solution to back up such files regardless of encryption settings.

There seems to be an issue with Firebird databases. It's impossible to use VSS to back up relational databases, so I wouldn't recommend to include them in your backup plan, these error messages are unavoidable in your case.

Scenarios 1 and 2 would work fine as long as VM edition is installed on both of the machines and you're logged in as the same user account. More info on remote backup/restore plan creation can be found here: https://mspbackups.com/Admin/Help/backup-and-restore/backup-plans/virtual-backup

Note that repositories on both machines are not updated automatically, so you either need to sync it manually(RMM > Remote management > Gear button > Edit Options> Repository) or use restore only mode which is only available via the software UI to restore the data that was backed up by a different machine.

Scenario 3 can currently only be performed via the backup agent by right-clicking on the backed up item on the backup storage tab and selecting "file-level restore".

That also applies to file transfer. I can't recommend anything if you're using a version of Windows that's not even been tested on by our devs/QA due to it's legacy status. As mentioned before, software's functionality is not guaranteed in this case, so use it at your own discretion.

|Just checked, and this feature has been moved to version 6.4, currently there's no ETA, sorry.

One log file is usually not enough, but I can say a couple of things based on it:
1) You're using a version that is way outdated, so it's better to update the software. Note that due to the age of this version it's better to uninstall it first and then install the latest one.

2) I see a lot of Disk I/O errors, which can point to 2 things:

a. Your HDD is in a bad shape, so it's better to run disk health check either via native Windows means or using 3rd-party software

b. If the database is pretty big in size most likely you have NTFS Compression enabled for that volume, which prevents it from growing/syncing, so it's better to disable it.

Thanks for the feedback!

Regarding your questions:

1) and 2) We just introduced meetings, and soon there will also be an option to invite an additional user to a 1 on 1 session, but I don't have an ETA yet.

3) Currently it is used automatically if the option is enabled and the machines are in one network environment, but improvements will, of course, be made in the future.

Currently, no workaround, but this is being investigated by the developers.Have no further info on that, sorry.

That's a known problem with UAC. Currently being investigated by our R&D.

Yes, we're aware of these issue, please refer to this thread. R&D is already working on a solution.

After service restart the queue will be empty, so you need to re-upload your data.

Update:
The issue is under investigation by our R&D.
If any other customers experience the same problem with high RAM consumption during Wasabi uploads, please send us the logs(tools > diagnostic) so we can transfer them to the developers.

By default they are in C:\ProgramData\Remote Assistant\Logs
There should be 2 files there, we need both of them.

Is gather logs from the log folder an option? Sending them as an archive would help.

Not now, I'll wait for the logs to arrive to our ticket system.

Please send the logs to us via tools > diagnostic menu. Don't forget to mention this thread in the issue description. I'll check the logs.

Yes, that would be the best course of action. As mentioned in another thread, these RA cases are exceptions, they are sent to product management, so if you send the logs without mentioning a particular forum thread you'll be forwarded to forum.

Please send the logs to us via tools > diagnostic menu. Don't forget to mention this thread in the issue description. I'll check the logs.

Currently it's not possible to check which files the software refers to during this operation.