Thanks @JunasButtram it worked for me as well.
same services I previously had to run as serviceaccount, now all runs as local system, and I can login remotely with whoever I assign.
Great troubleshooting share @JunasButtram .
Thanks for sharing this @JunasButtram hopefully it helps others.
Hey everyone, I just encountered this issue on a customers system and was able to determine the cause:
Last week someone from our team updated the client’s Veeam to V12.2. Apparently so, the original installation of Veeam took place with the local Administrator Account of the server, the update however was done with a seperate domain administrator account. This seems to have caused a few SPNs I will list down below to be registered with the admin user account instead of the computer account. After deleting them from the user and re-registering them with the server (you can either do this with PowerShell or inside of ADUC under advanced features) I was able to start the Backup Job. It’s still at 0%, but atleast it didn’t fail instantly again.
The affected SPNs were:
VeeamCdpSvc/HOSTNAME
VeeamCdpSvc/HOSTNAME.DOMAIN
VeeamCloudConnectSvc/HOSTNAME
VeeamCloudConnectSvc/HOSTNAME.DOMAIN
VeeamCatalogSvc/HOSTNAME
VeeamCatalogSvc/HOSTNAME.DOMAIN
VeeamBackupSvc/HOSTNAME
VeeamBackupSvc/HOSTNAME.DOMAIN
Hope this will help someone out there!
EDIT: Backup Job now at 2%, so this definetly fixed it for me.
Just upgraded from 12.1 to 12.2 and having the same issue with the remote console. Removing/Readding to the domain did not fix the issue. Opened case # 07408776
Update: Removed my user from the Active Directory Protected Users group and I was able to successfully use the remote console. Did something change/revert during the upgrade because we didnt have this problem before the upgrade?
same issue here.
but if several of the Veeam service are run as a service account and not local system, remote console actually works with that same account.
adding a new AD user as Veeam administrator, does not help, only the account that runs the services can login from remote.
Just upgraded from 12.1 to 12.2 and having the same issue with the remote console. Removing/Readding to the domain did not fix the issue. Opened case # 07408776
Update: Removed my user from the Active Directory Protected Users group and I was able to successfully use the remote console. Did something change/revert during the upgrade because we didnt have this problem before the upgrade?
I so hoped this will be solved in 12.1.1.56 :-(
Wow really not fixed. 20yr enterprise customer here saying “shame”.
I so hoped this will be solved in 12.1.1.56 :-(
Glad to hear you issue is resolved
100% a Veeam upgrade issue, no changes here pre-upgrade and I'm having this issue too.
Every VBRC has this across all of our clients that we manage via VSPC.
One we notice, is regardless if you upgrade via VSPC or local, it installs a local server backup and causes VSPC to fail loading.
Now, once we spent 24 hours fixing this garbage, none of our servers will connect to vSPC. No cert issues.
Yeah, I’m beyond pissed, and the fact I can’t just call someone for support, and nothing is updated in forums about all these issues.
Yeah, maybe you can tell I’m pissed off.
This is not the place to take this attitude or language. If you have a complaint then post it on the forums as there is no one here from the Veeam Product management team!
100% a Veeam upgrade issue, no changes here pre-upgrade and I'm having this issue too.
Every VBRC has this across all of our clients that we manage via VSPC.
One we notice, is regardless if you upgrade via VSPC or local, it installs a local server backup and causes VSPC to fail loading.
Now, once we spent 24 hours fixing this garbage, none of our servers will connect to vSPC. No cert issues.
Yeah, I’m beyond pissed, and the fact I can’t just call someone for support, and nothing is updated in forums about all these issues.
Yeah, maybe you can tell I’m pissed off.
Had this problem immediately, and can reproduce on fresh installs. Un joining and rejoing a backup server in a production environment as a solution is problematic to say the least.
I agree. At the moment I’m living with it as-is and had to reconnect my handful of desktop clients to point by IP instead of FQDN. I’ll probably end up doing a fresh install and migrate the server off the domain per best practices, but that will take some time to plan out properly.
Had this problem immediately, and can reproduce on fresh installs. Un joining and rejoing a backup server in a production environment as a solution is problematic to say the least.
Glad to hear you resolved the issue as well as sharing what the solution was. It is too bad you had to rejoin the domain again.
Nice! Glad to hear you got it sorted, & thanks for providing an update.
SOLVED
Hi, just to update on my particular case.
We tried the remove and re-add to the Domain this morning. This seems to have solved the issue. I can now log in via the console using the server name, as well as the IP.
Thanks to everyone for the advice on this issue. Much appreciated. 
100% a Veeam upgrade issue, no changes here pre-upgrade and I'm having this issue too.
worth mentioning that i said “no changes here pre-upgrade” when there was the enterprise manager upgrade prior on the same server.
100% a Veeam upgrade issue, no changes here pre-upgrade and I'm having this issue too.
@sosinfo1767 -
Yeah..curious what Support finds. Let us know what the solution is when you can.
This happened to us aswell. only change in our enviroment was that we upgraded to latest service pack for Veeam. I have a feeling that in the upgrade there is a FQDN issue. I am going to open a call. I forsee a hotfix to fix the issue
Here is hoping the fix is easy as they already released CP1 - 12.1.1.56. 
Hope those affected don’t have to wait until CP2.
I am on 10.1.1.56, that is the update that caused my issue.
Oh darn. 
Well hopefully Support can get it worked out or fixed.
This happened to us aswell. only change in our enviroment was that we upgraded to latest service pack for Veeam. I have a feeling that in the upgrade there is a FQDN issue. I am going to open a call. I forsee a hotfix to fix the issue
Here is hoping the fix is easy as they already released CP1 - 12.1.1.56.
Hope those affected don’t have to wait until CP2.
I am on 10.1.1.56, that is the update that caused my issue.
This happened to us aswell. only change in our enviroment was that we upgraded to latest service pack for Veeam. I have a feeling that in the upgrade there is a FQDN issue. I am going to open a call. I forsee a hotfix to fix the issue
Here is hoping the fix is easy as they already released CP1 - 12.1.1.56.
Hope those affected don’t have to wait until CP2.
This happened to us aswell. only change in our enviroment was that we upgraded to latest service pack for Veeam. I have a feeling that in the upgrade there is a FQDN issue. I am going to open a call. I forsee a hotfix to fix the issue
we are small, so I’m not really concerned about workgroups in a practical sense… I’ll be the only one with the login credentials with a “break glass” access for one other person in case I’m “hit by a bus”. What is an issue with workgroups is that it definitely puts a hiccup in our eventual CMMC 2.0 lvl2 aspirations.
@NZ_BenThomas Thanks for that. I had come across that in the past and some of the weaknesses of the workgroup only held me off, but we are a small shop and doing a management domain isn’t much better than a single domain because… what is backing that up and running that when everything is dead? I started looking at figuring out if a one-way trust between on-site AD and Azure is possible so we can use MS Entra for the identity management for the management devices.
In small scenarios, workgroup makes sense. I’d say if you’ve got a password management solution, see if it’s got an ability to rotate local credentials for you, so that you can change the local user password at a regular interval automatically, or see if it’s got an API for you to script that.
The main issue with local users on workgroup is shared accounts with passwords that don’t change often.
