User settings not applying in some virtual machines from instant clone desktop pools

[Rotoi]

Hi,

We deploy various user and computer settings with GPO in virtual machines created in instant clone desktop pools. The issue is that on some virtual machines, all user settings don't apply like folder redirection.

On virtual machines having the issue, gpresult command gives error "The user does not have RSoP data".

However, with gpresult /r /scope:computer, there's no rsop error and we see that computer settings are applied. The command also shows the security groups in which the virtual machine is, and we noticed that when there is the issue, the computer is not correct but instead is "IT*************$", that is the name of the guest os in the cp-template generated in the provisioning process. On virtual machines with no issue, the computer name is correct in that command.

Is the issue related to a provisioning issue and is there any way to force the application of user settings all the time ?

Thanks

[Gerard Strouth]

So is the actual computer name wrong then or just in the logs? Sounds like ClonePrep isn't running or completing.

[robryan]

If it's not related to ClonePrep not finishing correctly, it's likely related to <insert any number of traditional GPO application problems here>

Unfortunately, there are 25 years of reasons for user GPOs not getting applied - most of which related to communication to or between the domain controllers themselves. Just a quick search on that generic error will pull up pages of various similar issues.

That being said, there's a couple takes on this:

• There's a lot more error digging necessary to diagnose what might be going on, between GroupPolicy* events in the event log (being sure to pay attention to date/times to differentiate between what might be errors from the gold image if you don't clear logs before deployment, and/or the it******** template running, to looking at domain controllers for replication errors, validating machines are connecting to the correct AD Sites, etc.
• GPOs are not a great way to apply policies to VDI in general, especially to non-persistent desktops, and "especially especially" to Instant Clones due to the hybrid way they run/fork. At a minimum you're licensed for DEM standard, but really any other profile management solution handle user policies better than native GPOs do because of how they run/merge at login time. A lot of the time you're looking at the difference between troubleshooting just the VDI environment vs. having to troubleshoot your entire Active Directory forest.

I would really encourage looking at the latter, but in the meantime, start with a wider gpresult net, pay attention to where GP is being applied from, what the slow link threshold is set at, look for any read failures, etc. You'll likely need to extend that search out to the Domain Controllers themselves, validating every subnet's assigned to a site, checking replication across the forest - depending on how old your domain is, there's a host of things that could be at that level, least of which even being the switch from FRS to DFS (which was never automatic and still surprises me how many domains I've seen the old methods still active in the last 10 years)

[Rotoi]

To Gerard Strouth, the name is wrong in the result of the command gpresult /r /scope:computer in the the security groups in which the virtual machine is part. But actual name is correct. In which logs is clone prep process ?

Also I see this error in the event viewer, in "Group Policy" log : Error: Computer determined to be not in a site. Error code 0x77F.

The machines with the issue are in the same subnet as the ones which do not have the issue. It is random.

[Victor León]

Hello, most likely the computer account was not created successfully in AD, or some other AD-related issue such as replication across the domain controllers. 

I am guessing the computer renaming logic for Instant Clones failed, and it kept the cp-template computer name. 

 

 

 

[Rotoi]

I checked the Horizon agent logs debug-2024-xx-xx.txt, log-2024-xx-xx.txt, there are no errors that are specific to the virtual machines with the issue, that do not appear on virtual machines with no issue.