Current setup is new Veeam B&R 12.2 Advanced with Veeam One
vCenter 8.03b
3 Esxi Host 8.03b
Synology Nas for backup

vCenter Server and Veeam Server not on the domain

I have tried to setup vm backups but getting (veeam error 3004 AM Failed Connecting to guest OS via VIX Error: Cannot connect to host over web services. Login: . Guest Login: Failed to execute Pwdkey Could not run program error )

RCP protocal and everthing else passes

The vCenter account that I connnect it to inside veeam is a local admin account like admin@vphere.local do I add this somewhere to get it to work??

Vmware tools is up to date vm is connected to domain

How do I get this to work?

1 Spice up

one VM failing, or all?

What OS is the guest?

Out of 20 vm half are failing

Os ranges from 2012 to 2016

Also have you upgrade vCenter to 8.03.0400 d production

@Rod-IT

Yes

For your Veeam issue, confirm the following.

VMware tools is installed, running and the latest version. (12.5 is the current latest).

Are your hosts running lock down mode or any other permissions that may cause issues with the API?

Confirm all your VCSA services are started and your VM has enough resources.

Try rebooting the guests that are failing.

Yes all are on 12.5

Not sure if they are how do I check these 2 things?

All are started and running except for these do I need to start any of them?

Also on the vcenter update to 8.03d can do I have to put the host in maintenance mode since there in a cluster or can I do it fomr vCenter AM?

Will I have to updat the host as well?

If you don’t know how to check for lockdown mode, they’re likely not in lockdown mode.

Updating VCSA does not require hosts to be in maintenance mode.

Hosts will need updating if they are not the latest, lifecycle manager can help here.

You do not need to start the manual or deactivated services.

If you are running this from your Veeam box - try activating windows, that may help.

In The Veeam Job - Storage check if VMWare Quiesence is ticked. If it is try without it and vice versa.

Under Guest processing, if you have the option enabled for Application Aware processing then you will need a suitable user account you can use for the backup stored under credentials - This should be tested. If this currently fails then thats likely your culprit.

Ok I am confuse the veeam server is a windows 2022 server so I need to add a license key it on trial mode is what your saying?

Thank you for your help as well as @Rod-IT

When you say a suitible user account does it need to be a domain account ? The account being used is the admin@vsphere.local account from vCenter

In your screenshot it is showing as not activated.

Unless you are going to tear this box down, you shouldn’t use trial licenses that will become production.

1 Spice up

This is only good to access the VMs.

In order to do guest processing or application aware processing (SQL, Exchange, AD, Oracle, SharePoint or PostgreSQL) you need to supply respective credentials.

DA for your domain, but any other local admin for the others will do.

Yes you need a windows/domain account that has the ability to locally administer the server for the backup. See this discussion below.

https://forums.veeam.com/veeam-backup-replication-f2/an-ad-veeam-service-account-what-privilege-t43585.html

Ok I will put in license key and try again do you think that is the issue?

The veeam server is on the domain I just checked thought it wasnt and the domain login account is a domain admin account but the vCenter account is not I guess in credential I need to add this domain account ?

Negative.

To connect Veeam to your vCentre, you need vCentre credentials.

To backup application specific files on your guests, you need to provide in-Veeam guest credentials. Those would be either local machine accounts or a domain account with respective rights.

Ideally, Veeam should not be domain joined.

2 Spice ups

It depends on your recovery method…coz VBR have instant recovery where you can create a synthetic VM to copy out files etc to the VMs or another server…

It is a different school of thought that

  • Backup Server OS should not be in Domain
  • Backup Server’s GUI login user should not be a Domain User
  • Only the backup job needs Domain User or Domain Admin creds

For me, I create a Backup_Admin which is in the Backup Admin Group of the Domain and Domain Machines.

Can post some of the errors here ?? They are usually 1 liners…

@adrian_ych

Feel free to configure yours how you like, but best practise recommends that the Veeam BR server is off the domain, or at least, not in the production domain.

In Veeam 12 you can see this, and where your box is in terms of security by clicking the Security & Compliance icon on the home screen.

For reference, here are the recommendations.

  • Remote Desktop Service (TermService) should be disabled
  • Remote Registry service (RemoteRegistry) should be disabled
  • Windows Remote Management (WinRM) service should be disabled
  • Windows Firewall should be enabled
  • MFA for the backup console should be enabled
  • Immutable or offline (air gapped) media should be used
  • Password loss protection should be enabled
  • Email notifications should be enabled
  • Configuration backup should be enabled and use encryption
  • Backup server should not be a part of the production domain
  • All backups should have at least one copy (the 3-2-1 backup rule)
  • Reverse incremental backup mode is deprecated and should be avoided
  • Backup jobs to cloud repositories should use encryption
  • Unknown Linux servers should not be trusted automatically
  • The configuration backup must not be stored on the backup server
  • Host to proxy traffic encryption should be enabled for the Network transport mode
  • SMBv3 signing and encryption should be enabled
  • WDigest credentials caching should be disabled
  • Web Proxy Auto-Discovery service (WinHttpAutoProxySvc) should be disabled
  • Hardened repositories should not be hosted in virtual machines
  • Deprecated versions of SSL and TLS should be disabled
  • Network traffic encryption should be enabled in the backup network
  • Linux servers should have password-based authentication disabled
  • Windows Script Host should be disabled
  • SMBv1 protocol should be disabled
  • Link-Local Multicast Name Resolution (LLMNR) should be disabled
  • Backup services should be running under the LocalSystem account
  • Credentials and encryption passwords should be rotated at least annually
  • Hardened repositories should have the SSH Server disabled
  • S3 Object Lock in the Governance mode does not provide true immutability
  • Latest product updates should be installed
  • Hardened repositories should not be used as backup proxy servers due to expanded attack surface
  • Local Security Authority Server Service (LSASS) should be set to run as a protected process
  • NetBIOS protocol should be disabled on all network interfaces

May I know and understand how you configure your VBR 12.x servers ?

Then the focus should be on troubleshooting @WarKraft issues, then tidying up the best practices later as this is a backup solution and not a 1st level mission critical server ?

I have been using VBR since v9.x and had so many tests for troubleshooting…till we can solve most issues (especially if there are credentials issues), there are some basic steps…unless you are still using backup tapes and moving the backup tapes around the offices, then maybe there are some “best practices” to follow as well as some security practices…

Are you running 1 VM per job (recommended) or a few VMs per job ?
Do you need guest processing for those VMs (what are those VMs running) ?
Are those VMs in the Domain ?