What version are you running? I believe this is a known issue in the recent version of Explorer . The fix is planned for 6.2.2 but I would contact Support for guidance as they may be able to provide you with an older build that does not exhibit the issue.

I think you would be better served by contacting Support as they can review logs to see what might be causing the slower than normal restore speed. I can say that the new backup format was designed to improve performance of backups and we have some major restore speed improvements coming later this quarter. But if you're using the legacy format, I think Support would be able to provide the best analysis and guidance on how to get you restored more quickly.

Support got back to me, and it's a known issue. Two options: Download the latest version of the product which I think is 7.4 and try the install again. Or, if you want to keep using that older version you can follow these directions to get the missing binary and then you can run the install.

1. Download msvcr100.dll from our website: [url=http://1. Download msvcr100.dll from our website: https://download.msp360.com/mscpp2010sp1/msvcr100.dll 2. Copy it to %SystemRoot%/system32 (usually C:\Windows\System32) 3. Run the installer again]https://download.msp360.com/mscpp2010sp1/msvcr100.dll[/url]

2. Copy it to %SystemRoot%/system32 (usually C:\Windows\System32)

3. Run the installer again

What drive is mounting though? Is it the source of the files that the custom service is going to copy to the Drive folder?

I opened an internal case, but if there is not a known issue in the system, I can guarantee Support will ask me to ask you to send the logs. You're welcome to wait for the team to get back to me (maybe they will today), but since you're a Managed Backup customer and have Support, I just thought that going direct to Support would be the easiest way for a swift resolution.

Are you saying that if you run that script, everything works fine that was your workaround for the issue? Or are you saying that the script works, but you still have access issues?

My concern would be that if you are not starting Drive until the transfer is needed, it can take some time to mount and get ready. So putting in a delay between the pre-script and any access to the files in the share might help.

Again, though, I think this might be better sent to Support for best resolution. Even if it's not currently supported or working properly, they can raise the requirement to try to have it addressed in a future release after an analysis of the logs.

I'm not sure what you're trying to do is supported. Drive is exposing the cloud as a network share and you're trying to access that share from another service. Unlike a user account that is accessing the share when logged in, I do not know if services have that same level of access. What you might try doing is ensuring the Drive service starts up immediately on Windows boot and setting the other service on a delay to ensure Drive is fully started first. I don't know if the custom service is trying to access the share before it's ready to be shared.

I'm not seeing any open issues with the symptoms you are describing. I'd recommend you open a Support case to submit the logs, as they will reveal more about the actual issue and what may be causing it.

What Windows OS version are you running?

Cloud vendor? Drive version?

You can send the logs to support if you want through the tools diagnostic function, but please do not post them here. If you submit, please let me know, so I can let support know.

No bother. I'm here to help.

Are you sure the service has stopped on the remote endpoint or are you just not seeing it as active in the management console?

Either way, neither should be occurring and I'd recommend you open a support case that include the logs from the remote system for the team to review.

If the service is not running, I'd hate for you to have to create a scheduled task in Windows that starts the RMM service on some schedule as a work-around. If you want to reply here with more details, that's fine, but I cannot work the case the way Support can and I'd like for you to have this resolved and analyzed by a support tech.

Thanks.

Unattended access has been in the product for a long time. i assume you possibly have some specific features in mind, so can you elaborate? We currently support logging into a remote system using Windows Credentials to support unattended administration / use of a remote system when no one is at the remote end.

There are 32 and 64-bit versions of the installer on that Microsoft page. Please make sure both are installed. We may install as 32 or 64 bit based on OS platform. I would also recommend an uninstall / reboot / reinstall to ensure the installation is correct.

I am checking with Support. I will update the case with your recent notes.

I think the message is incorrect. Follow the link in the Help article I posted above to download the 2013 version of the C++ library and let me know if that solves the issue. I will let the team know about the message.

What version of the product are you using?

Where are you seeing that requirement? I do not think that's correct. The closest I have to that requirement is that some old versions may require Microsoft Visual C++ 2013 Redist x64.

https://help.msp360.com/cloudberry-backup/installation/system-requirements

I do not think you can use Drive with Minio. What are you trying to accomplish? Do you want to be able to browse your Minio cloud storage? If so, I think you'll be better served by using our Explorer product (Minio is S3 compatible).

They are only in native format because you are not compressing or encrypting or using block-level backups. There is no guarantee that in every case you will be able to do what you want in Advanced Mode. So, I would be cautious if you continue to use Advanced Mode in that way.