Thank you for the clarification. In this case a list of necessary permissions is present on our website, and it contains administrative-level permissions. https://helpcenter.nakivo.com/User-Guide/Content/Deployment/System-Requirements/Supported-Platforms.htm#Physical Our QA team hasn't specifically tested which permissions can be safely removed, so we don't have official guidance on a minimal permission set at this time. That said, you're welcome to test this in your own environment — remove permissions gradually and verify that your backup jobs continue to run as expected. If everything works after removing certain permissions, it should be safe to keep that configuration. One thing worth keeping in mind: if you update NAKIVO or the transporter on the physical machine in the future, additional permissions may be required for the update process itself. Day-to-day job execution generally needs fewer permissions than installation or upgrade operations, so it's worth re-checking after any update.   At the moment, NAKIVO does offer an option to disable certain types of errors and warnings directly in the web UI. However, please keep in mind that doing so would suppress all events of that type — meaning important notifications could potentially be missed alongside the ones you want to filter out. To proceed, please do the following: 1. Take screenshot of the error(s)/warning(s) that need to be skipped 2. Generate and send us support bundle, attaching above screenshot(s) 3. We will check internal event number and send you steps how to skip it We would be happy to submit a feature request to our Product Team on your behalf to improve how errors and warnings are handled for physical machines—for example, by introducing more granular filtering, scheduled reporting, or other options that give you better control without risking missed critical alerts.

Okay, I think we're misunderstanding each other. I've already added the workstations to the Nakivo console. I used an account with domain-level administrator privileges for this. Now I need to limit this account to communication between the Nakivo server and the workstations. Thanks for the tip that the account must have "Log on as a batch job" permissions. My question was more about best practices for configuring such an account for communication between the Nakivo server and a workstation running the "transporter" backup agent. Is there any way to prevent Nakivo from treating workstation unavailability as a problem? The point is that workstations are only available during office hours on workdays. And the console shows hundreds of host unavailability issues after the weekend. While this is generally correct, it's a bit irritating and blurs the picture of the network situation?

Hi @zsere86, Please double-check that all requirements for adding a physical machine from the following article are met: https://helpcenter.nakivo.com/User-Guide/Content/Deployment/System-Requirements/Supported-Platforms.htm#Physical We suggest double-checking that the following permission is available for the user: "Log on as a batch job". Then, try to add one of the physical machines to the NAKIVO inventory and let us know the result. In case some error is still present, please do the following: - For test purposes, try to use the local (built-in) administrator account - Send us a screenshot of the error - Generate a support bundle and send it to us, we will check the details then.  

I'm currently implementing NAKIVO Backup & Replication for Physical Workstations on Windows. I'm looking for a user configuration solution for installing and managing the NAKIVO agent on a Windows workstation.   I've implemented a solution that involves creating a "nakivo" account in the Active Directory domain with minimal privileges and a 25-character password based on a generator consisting of lowercase and uppercase letters, numbers, and special characters. Cyclic password changes have been disabled in accordance with the policy for this account. Using Group Policy, I've granted local administrator privileges on workstations for this account and disabled the ability to log in via Terminal Services and locally.   Is there another configuration option based on a more secure solution, such as a gMSA account?

Are they indipendent to VM Versionon proxmo: example: i run proxmox 9.11 my vm are configured on 9.1 hardware version  could this cause issue?   thank you in advance, best regards.