It is a supported path yes based on the Veeam documentation and as long as the resources you assign align with what is required for VBR you should be good.

Now if we follow Best Practice guidelines then you should not use a client OS for software that is meant to run as a server environment.  

@Chris.Childerhose  right, I see the support is there and the resources will be identical.  As you said, the best practice guidelines suggest using a server OS…  but if my option is (1) use server OS in a workgroup environment or (2) use Client OS using Entra ID.  Do I pick option (1) or option (2)….  I need to research option (2) a bit more, but I’m leaning that direction because at least that adds some centralized management that is independent of our on-site infrastructure.

Of course, the management domain within the forest would be better, but I can’t see a path to implement that reasonably in a full lights-out DR situation.  So, I have the BR infrastructure on the mgt domain backing up production along with one (or two) AD servers… what is backing up that AD setup and BR server and where is that located?

I would opt for Option 1 as it is not recommended to have Veeam in a domain unless it is a separate one from your primary domain that can access the main domain for backing up servers.  This is a Best Practice as well.

For DR you need to have a plan to make a Backup Copy Job or some form of replication to a DR site where you have another BR server to recover with.

Hi @ablbgd -

We discussed this topic a bit a few mos ago. Here is the post from the discussion. Review and see if this of help:

@coolsport00 thanks for that.  I tried searching for this topic, but didn’t include “workstation”.  Density isn’t an issue for us and while the licensing concern is something to consider, I’m inclined to think we are in compliance with the client OS given that we aren’t hosting commercially or having multiple users remotely access the system and given the fact that Veeam supports the OS and MS and Veeam are partners for solutions I think we are covered.

@Chris.Childerhose My only concern with workgroup is that we are attempting to implement CMMC2.0 and workgroups definitely add a challenge to that.  I’m looking to see if Using MS Entra Joined devices might be the workaround to that provides that DR authentication independence from our local AD infrastructure without losing our security identify controls and auditing capabilities needed for CMMC.  the management domain is an option, but we are so small, that the overhead there is significant.  I still need to work out if replication of that primary BR server is the way for DR or if we need a 2nd BR server, to address when everything at the primary site goes offline at once.  We have the off-site repository covered with a copy job which keeps our information redundant, but that doesn’t really help in a recovery when all we have is that repository and nothing else.

Sure...glad to help out 

I wasn’t saying don’t do a domain just ensure to follow best practices for it if you do.  Workgroups are safe but do cause more headache for access management amongst other things.  Ensure to research and check the best practice guides, then decide what suits your environment best.

Also, for DR purposes I would suggest a second BR server in your other DR site and configuration backups from your primary site sent to something like Wasabi so you can recover if the main site goes offline completely.

how does that work for licensing?  Do I just keep the server up-to-date for OS and veeam patches and keep it off otherwise only to load the backup config when the DR issue occurs?  Since this is assume it is just a workgroup computer… should that server have the same name as the active server or should it carry a unique name?

Actually, what I do @ablbgd is use a 2nd VBR server at a DR site for a different purpose - Veeam Replication. It has its own hostname and different job types (Replication, vs Backup). If you have hardware/networking to house your primary site VM servers….in my opinion, that is the way to go. I do also take a backup of my CO site VBR server and replicate it to our DR site as a last resort to use, as long as my CO site is still online in the event of a disaster.

As far as licensing goes for Replication, Veeam doesn’t license target Hosts, just the source, so you should be good there.

Licensing is for your workloads you are protecting at the main site.  Only if you had a disaster and moved to the DR site then it would start charging you for backups there.  You can have a completely different named server and a workgroup is good.  You need to keep it patched for sure and maintain the same Veeam versions at both sites and load your configuration backup to the DR site if or when necessary to continue working to restore and get your environment up.

I’d avoid desktop, even if it works.

Microsoft Windows Desktop really likes to go out to the internet with information about you, and there are also a ton of services and features running you will not need.  Similar to the opposite, I wouldn't recommend Server2022 for your next gaming rig on a desktop.

I’d go against a Domain joined Veeam environment too. If you MUST, create a secure admin account with MFA, store that somewhere extremely safe, and use MFA for the accounts. Turning on 4-Eyes Authorization is important too

https://helpcenter.veeam.com/docs/backup/vsphere/mfa.html?ver=120

https://helpcenter.veeam.com/docs/backup/vsphere/four_eyes_authorization.html?ver=120

The most common way is to stack up new Veeam servers on a separate VLAN and use MAK license keys. Don’t worry about the “workgroup” terminology. It doesn’t really matter. Use local accounts with MFA and keep them only for people who require them. Open only the necessary ports to that VLAN as well.  If you have a DNS entry to the VBR server, install the console on your desktop and away you go. Limit that access to a jump box, or specific desktop or IT. 

For a DR server, you may require a Windows license, but Veeam will sit running without it. All you need to do is export then import the config backup and you are up and ready to rock. 

@coolsport00 @Chris.Childerhose  have good advice too.   If you are going to use VBR, it’s best to run that at DR. If your main site fails, you can control it from over there.   If you have servers you want to fail the other way you could run a VBR replication server at both sites so you can fail from DR to the main site as well. 

The main VBR server can run anywhere, but I am considering moving mine to DR. Think of the VBR server as the schedule manager. It tells the proxy’s and repo’s what to do. The data does not hit this server. If it’s at the other site, it would tell the proxy at the main site to use the repo at the main site for your production data. 

Hi @ablbgd -

Just following up here. Anything further we can provide to assist, or have we answered your question?

@coolsport00 thanks for the follow-up.  You all provided a lot of good information to consider.  I’m taking my time before I actually make a move to try and make sure I have all the benefits/costs worked out.  The existing setup has been working great in general for RPO/RTO for everything up until a complete lights-out DR situation and that has opened up a bit of a can of worms both for how we thought about DR planning from a VBR perspective as well as from a networking perspective which also has some catch22 items we need to work out.  Couple that with a desire to implement a more formal cyber security framework with CMMC2.0, and I think this is just going to take a bit of time to work out our final plan.  in the meantime, I know my DR risks and how that RTO is currently in the 2+ hour range instead of the <20 min range it could/should be.

Hi @ablbgd - ok...thanks for the info. Keep us posted if you have further questions.

Thanks for the update @ablbgd.  We are here to assist further if needed.