I am trying to improve the security of my on-prem active directory domain, including stopping use of the default/well-known (built-in) domain admin account and using even less privileged accounts for normal management of servers.
In the course of this process, I have learned that only the built-in domain admin account that originally deployed the remote desktop virtual desktop infrastructure (VDI) managed pools from my remote desktop connection broker (RDCB) in my remote desktop services (RDS) deployment can redeploy the VDI pools. That is to say that newly created domain admin accounts fail to redeploy the existing VDI pools; I am not sure if a newly created domain admin account can create new VDI pools or not. As previously mentioned, I would prefer to use an account that isn't even a domain admin, so I have gone straight to trying to deploy new VDI pools that way, and in trying to do that, I have gathered instruction on what I should do to make that possible, but it hasn't worked.
If I log in as a domain user that happens to be an administrator on my RDCB and try to deploy a new pool, when I click next after choosing an organizational unit (OU) while manually specifying unattended installation settings, I am first prompted with: "The RD Connection Broker server does not have access to add the virtual desktops to the Active Directory domain. Configure access by using the Active Directory page of Deployment Properties."
When I follow those directions (Overview -> Deployment Overview Tasks -> Edit Deployment Properties -> Active Directory -> choose the OU), there is a warning that states "The specified Active Directory Domain Services organizational unit is not configured with the appropriate permissions to automatically create virtual desktops. To configure the appropriate permissions, click Apply." Clicking apply obviously won't work as I am not using a domain admin account (the message provided is: "Could not save the settings for Active Directory. Error: Could not configure Active Directory Domain Services."), but the previous message about permissions is not even presented if I am using a domain admin account, and clicking apply with a domain admin account, or even the built-in domain admin account doesn't resolve the message or previous warning for the server administrator account. In fact, if I go to the same section again as any domain administrator after clicking apply with the OU selected and closing the window, the OU is no longer selected.
I have also tried using the Generate Script button since the configuration page in question specifically says: "If you do not have sufficient permissions, you can generate a script to run on the Active Directory domain controller." I get the generated script, and running it as a domain admin on the domain controller says it was successful, but the previously mentioned behaviors don't change.
This deployment includes a physical remote desktop virtualization host cluster, a virtual machine (VM) running Internet Information Services (IIS) for the remote desktop gateway and web access services, and the RDCB, which is also a VM. I have modified the script to also apply the same delegations to the other servers mentioned here (by adding them to $CBList even though they aren't connection brokers), but once again, with no change in behavior. The RDCB and IIS VMs have been rebooted since all of this was done, so to the extent that only the RDCB even needs the delegated permissions, it should have reauthenticated, and they still won't work.
In addition to all of the above, I just tried the Q&A Assist AI advice and tried to manually delegate control to the RDCB computer account, choosing computer objects, create, delete, and full control on the final page (which it didn't cover) and the wizard said it was successful, but all behaviors are still the same as previously described even after an additional RDCB reboot. It appears I can see all of the RDCB delegations in Active Directory Users and Computers, but even if I give it full control to the OU and all descendants and reboot it, the behaviors are still consistent, so I've got to believe the issue isn't actually what the various messages say it is. I've cleaned up the OU permissions since trying all of this (deleted all of the computer objects from the security tab) and then rerun the script with just the RDCB to make sure permissions are where they are supposed to be.
Can anyone help me figure out what I need to do in order to get my RDCB to be able to deploy and redeploy RDS VDI pools in the relevant OU?