I'd say this was invoked by the apps running on it. This VM is used for analytics and reporting, it's got Visual Studio, Power Bi and SQL server running on it. The vendor must've been doing some shit on it.
So, because Veeam reapplied the old snapshot, everything between then and now was lost.
If I keep the old snaphot as current, all the systems have domain trust failure.
I have a backup and there is only a single shared folder on here that will need restored.
Because this site is only 20 Windows computers, and I wanted to stop wasting time after 2 hours, I went brute force.
I disjoined everything from the domain and rejoined them.
With that resolved, I restored the C:\shares folder on the DC from the last Veeam backup.
Site is now working again.
Veeam's replication is now also in the correct state to fall back the replica to the main hyper-v server.
Not fucking touching that tonight.. I R DUN.
Edit: Maybe not the perfectly correct answer, but the answer I went with.
@wrx7m Is that a computer configuration or user configuration policy? Try applying the rules to only non-admins groups.
Yeah, it is at the computer level. I would like to do it via user config but I only want them to apply to users on the RD servers. I need to figure out the proper way to structure AD/GPOs to not screw up everything else.
I am guessing creating another OU as a sub container and move the RD servers into.
Edit: Since it isn't GPP, there isn't any item level targeting, so I can't do it that way.
If you can make those changes directly in the registry, maybe can allow you to use GPP and item level targeting.