VMware Horizon Community
Liorab
Contributor
Contributor

Group Policy somtime is not working after recompose a pool

Hi,

We experience disturbers issue with user roaming profile,

After I recompose a pool , always there are  few users (randomly) that their profile is not upload to the new desktop, they get a clean default desktop,

and not all the GPO defines is working.

Sometimes it solved by log off an logon again, but always I have a user that I need to configure his profile from the beginning, the outlook software opened like a new application.

Is someone has advice or experience this issues too?

Liora

4 Replies
auhank
Enthusiast
Enthusiast

We've always had (relatively rare) problems where machine policy is not processed at startup.  Breakage of roaming is the main issue for us.  I'm uncertain if life is any better with persona, as our testing was superficial.  As a workaround, we force policy update at boot by repeatedly calling gpupdate until success.  Current environment is View 6.2 with 64-bit Windows 7 desktops, refresh on logoff.

Reply
0 Kudos
Liorab
Contributor
Contributor

Hi,

Thank for your reply,

When you recompose the pool , after make change on the golden image, is the option: reuse the name of computer is set?

How did you do it and where :"we force policy update at boot by repeatedly calling gpupdate until success"

Every time I run recompose I have problem in the morninig with few users.

Liora

Reply
0 Kudos
auhank
Enthusiast
Enthusiast

Our scenario is linked clones and we do not select "allow use of pre-existing".  Possibly we are talking about different issues. My reply is for the case that machine group policy fails to process at startup (as seen in event logs).  This failure is not necessarily from a recompose, and occurs often enough that we needed a workaround.  If all you care about from machine policy is the setting for roaming profile location, then MS describes other ways to set (user object, local profile) that might be acceptable.  We don't control the user object, and we have other machine policies we'd like from AD, so we force policy update at boot by "gpupdate /target:computer" until success.  Launch is from sched tasks, and we run only if join-domain has succeeded.

Reply
0 Kudos
TechMassey
Hot Shot
Hot Shot

Alrighty, roaming profiles. They are one of the more complicated setups and when you add Horizon View, well you have a lot of moving parts and it only takes one to stop it all.

The bigger problem then the actual behavior of the issue is identifying the potential causes due to the complexity. I'll list out some potential causes and also next steps.

  1. Possible Cause - GPO Processing Failure
    1. Potential Sources
      1. Mismatch on hostname and IP on DHCP/DNS
      2. Domain join issue and/or GPO processing
    2. Next Steps
      1. First, ensure that before troubleshooting to turn off "log off pool behavior" such as "refresh or delete at logoff"
      2. From your PC, do a DNS lookup on the hostname of the affected VM
        1. Then verify that the IP matches the IP on the VM
      3. Login to the VM through vsphere console
        1. Review system logs for any domain or group policy processing issues.
        2. Open Admin prompt, run: gpresult /h %userprofile%\desktop\gporesults.htm
        3. Review the created file and look for any processing issues.

My suspicion would be DNS/DHCP with the hostname not matching the IP which causes a cascade effect.

Also, in reference to setting a pool to "not use pre-existing computername." Bad news on that, it sounds like it would not use previous computer names like VM-01. However, it in fact looks for a pre-existing AD computer object with the same name and only then will it not reuse it, otherwise it will cheerfully reuse computer names.


Please help out! If you find this post helpful and/or the correct answer. Mark it! It helps recgonize contributions to the VMTN community and well me too 🙂