AD Issues? GPOs not being applied.

[pbastiaans]

We are seeing intermittent issues with our instant clones, there appears to be a delay with GPOs being applied, app stacks being attached, can't get to C$...and other just plain 'weirdness', some clones in the same pool can get to C$ others no .

Clients can work in VDI for several days and then out of the blue, Office is requesting activation (KMS activation), autodiscovery is not working, can't get to admin share.

I have tested with different reference images, made sure SMB was set 2.0, different pools, no UEM , no app stacks...it's always intermittent.

Seeing netlogon errors on both windows clients and the domain controller:

Client - This computer was not able to set up a secure connection with the domain controller...there are currently no logon servers available to service the logon request.

DC - The session setup from the computer  failed to authenticate. The following error occured: Access is denied.

DC - The session setup from the computer failed because the security database does not contain a trust account referenced by the specified computer.

At this point, I'm thinking something outside of VDI. Has anyone experienced AD getting pissed because of instant clones creating AD accounts, deleting, creating accounts, deleting and creating them again and again?

Thank you!

[sjesse]

What version are you using, and do you have a large AD infrastructure. There have been issues in the past where slow ad replication has caused some issues, like this one

VMware Knowledge Base

[HussamRabaya]

yes,

the shared KB should solve your issues , however to automatically have the GPO’s applied on the cloned VM’s,  try to place the pools VMs (AD object(s) )in the same OU as the Master VM’s. In other words, the same OU where the GPO’s are applied on. This should be sufficient for most environments.

If this is still not working, there is an easy workaround which you can also use.

When editing the desktop pool, click Advanced Properties, you have the field “Run Once Script”

It’s here you can fill in the command line: C:\Windows\System32\gpupdate /force

This command line will force the user and machine GPO settings immediately after the VM clone process is completed.

[pbastiaans · Accepted solution]

Not a large AD infrastructure, one site, 3 DCs.

Additional info:

• Self inflicted wound - I found a local GPO set to 'Disable wait for network', this was conflicting with the domaIn 'enable wait for network' or ppreempting it if there was any delay I am supposing.

After correcting this, I am still seeing instant clones requiring a gpupdate /force.

[pbastiaans]

I am not seeing the 'advanced properties', can you elaborate. Do you mean here:

[sjesse]

If you wanted to you could put the C:\Windows\System32\gpupdate /force part in the post-syncronization script part as a work around. That should run gpupdate right before the clone is done being customized.

[pbastiaans]

Thank you, this is a good suggestion.

I'm hoping to find out why this is suddenly occurring. My gut tells me there is a DNS/AD change that is affecting my instant clones...or there is something wrong with the reference image.

If there is something wrong with the reference image, I do not understand intermittency, I would expect all my instant clone users to experience this all the time.

[sjesse]

Are you doing one snapshot on the parent and then reusing that. I found that was a problem, during the process a template is made, and it creates its own ad object that starts with it(something like it135412352135). That object gets gpos from what ou that object is. The clones are copies from that which may be related. I now clone our parent images to seperate ones per pool, then use a snapshot on that one for the parent of the pool. This makes sure that template is in the correct ou to get the inital gpos correctly.

[pbastiaans]

Thanks again, the it1234567890 template is in the same OU.

Good suggestion, keep em' coming.

[pbastiaans]

The issue appears to have stemmed from reference image misconfigurations:

• SMB disabled completely
  • Fix: Enabled SMB 2
• Local policy set to 'disable wait for network'
  • Fix: Set local policy to match domain 'enable wait for network'

Going to let this bake in, before marking as correct as I still see the following:

• Cannot get to C$ from machines outside of the VDI network (phys to vdi) using name or IP
  • VDI to VDI no issue

[pbastiaans]

sjesse - I did see what you were talking about during other testing! Thank you.

[sjesse]

Cannot get to C$ from machines outside of the VDI network (phys to vdi) using name or IP

• VDI to VDI no issue

Firewall issue?

[pbastiaans]

I guess, have checked everywhere I know to look on the client...work in progress, getting closer. Thanks again.

[mkm2416]

Have you thought about using VMware User Environment Manager? I have had these issues in the past with GPO. With UEM, a lot of them have disappeared.

[sjesse]

I'm thinking about using something like ansible or puppet, to completely get rid of GPO reliance. The only things we are doing with GPOs are things that need to be configured pre-login, or some specific machine level apps. Everything else is in UEM, including the UEM config, I much prefer the no ad mod and I'm hoping at one point it becomes default UEMdev​

GPOs are to unreliable in my opinion, not a good fit for non peristent desktops, and in general are terrible.

[pbastiaans]

We are using UEM, no-ad mode. These are machine policies that are not applying. It's beginning to look like we shot ourselves in the foot with this:

Local policy set to 'disable wait for network'

• Fix: Set local policy to match domain 'enable wait for network'

[sjesse]

Its not just you , I just noticed the same thing is happening on mine, but we don't use GPOs enough to really notice. Its also not in here either

Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop | VMware

which I would think it would be since most people I think are using the gpo method.

[sjesse]

Did you do anything else, because this didn't work for me. If I run gpupdate -force the policies then fully apply

[pbastiaans]

sjesse - Good link

I don't ever recall setting the 'disable wait for network' local policy...maybe it was the the Optimization Tool...maybe. We are not hearing reports at this time from our DEV users regarding slowness, pop ups, no drives, etc.

The only other thing we have done is enable SMB1, we think this may be related. We needed it to fix something else, worth a mention:

sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

sc.exe config mrxsmb10 start= auto

[sjesse]

Yeah my security team wouldn't like me much if I turned on smb1. I do think its something in the optimization tool, which I'm not trusting any of the profiles anymore and will probably just do it the old way manually