2 Issues: Error during provisioning: Insufficient disk space. Desktops not customizing.

[g0dMAn]

Horizon 7.11 Conn server and agents

vCenter 6.7

Windows 10 pro

I've created an automated FULL CLONE pool.  The datastore has plenty of space.  1TB datastore, looking to create 31 desktops at 50GB each.  I can't even create 10 desktops without it barking at me.  I have to constantly turn on provisioning and let it do as many desktops as it can, it fails, then I remove the bad desktops and try again, over and over.  I've been doing Horizon VDI for years now, and this 7.11 has been total junk.

The other issue is the sysprep completion is random.  It fails about 60-70% of the time.  I have to remove desktops from the pool and try again. Eventually, they work, but it's gruesome!!  I can't make sense of it.

Again, been doing this for years, since Windows XP.  I'll be honest, Windows 10 sysprep has been the worst experience ever of all, but right now I cannot figure out why Horizon is being so random.  There are no datastore overcommit options for full clone pools, so I really don't know why it cares about storage space.

[g0dMAn]

Update:

I could not figure out what the issue was with Horizon.  First time using 7.11.  My last deployments were 7.5, 7.6, and 7.7... all without issues.

Well, I got sick of using the automated full clone pool, so I created a manual full clone pool, used PowerCLI to spin up my desktops, and NOT A SINGLE ISSUE!  I used the same customization spec and same template.  Not making much sense.

What gives?  I'm really eager to understand why the desktops go into "error", "agent unreachable" and sysprep/customization failing the majority of the time when spinning up from Horizon.  I even went as far as changing the Horizon service account to admin roles in vCenter (the account horizon connects to vcenter with)... it was the only thing I thought could be a problem.

I'm thinking it's an issue with 7.11.  Not going to rebuild the conn server now that the desktops are spun up.  Has anyone else had a similar issue or understand what was going on?

[jonathanjabez]

Hi,

Could you upload the sysprep logs by copying them from one of the VDIs in Error state?

• C:\Windows\Panther
• C:\Windows\Panther\UnattendGC
• C:\Windows\System32\sysprep\Panther

/Jon

[g0dMAn]

Darn.

I should have grabbed it while I had the chance!

I got so sick of it that I dumped the automatic pool and created a manual pool. I instead used PowerCLI to spin up the VMs.  I used the same template, same naming scheme, same customization spec.  Lord knows what Horizon was doing... I thought of Horizon automated full clone pools just as orchestrators for the vcenter cloning part.  I still don't understand what the difference is except that Horizon has it's own account to connect to vCenter (and as I've previously stated, I decided to change the role to full-blown admin and it still didn't make a difference).

[jonathanjabez]

Hi,

I agree with you. Provisioning full clone desktops from Horizon is pretty much straight forward. This only involves cloning a template from vCenter and customizing the clone using sysprep using the customization spec template created in vCenter. To isolate the issue, did you try to clone the golden image directly from vCenter using the same custom spec? Does it work proper?

[g0dMAn]

Yes, it did work fine directly from vCenter with the same customization spec.  That's why I ended up using PowerCLI, so I could do all 30 desktops without having to do it 30 times from vCenter.

[jonathanjabez]

Hi,

To test and troubleshoot the issue, could you create a new Full clone VDI Pool with 1 instance and after it errors out, keep the VDI in maintenance mode, go to vSphere Web client console and check the below:

1. Check if the VM acquired IP Address

2. Check if  the VM is booted to Windows. If so, try to login to the VM using the local administrator account and check it is joined to domain and the host name is changed as per the VDI naming pattern given.

3. Collect the sysprep panther logs and upload it here.

/Jon

[g0dMAn]

Sure. I will try to find time tomorrow to do this, but...

1. Yes, it does grab an IP

2. Yes, it sits in windows

3. Will do

Basically, the sysprep folder remains on the C: drive.  Only way I can run sysprep with the ESXi included sysprep.xml file is trying to hack the rearm settings of Windows.  For example, if I recall correctly, when I ran this command, absolutely nothing would come up to show sysprep running:

c:\windows\system32\sysprep\

sysprep /generalize /oobe /reboot /unattend:c:\sysprep\sysprep.xml

^Doesn't work without trying the regedit changes for rearm.  I think it was this one...

HKEY_LOCAL_MACHINE\System\Setup\Status\SysprepStatus

CleanupState - change to 2

I'll collect logs and submit when I can and then it'll click again.  Thanks.

[g0dMAn]

Attached setupact.log from C:\windows\system32\sysprep\panther

It was the only one with date modified as of last night (this morning) when I created the pool.

I can grab any other ones if you'd like, but they're all older modified dates.

Thanks!

P.S.

I never know that the unattend.xml file in C:\Windows\Panther actually leaves the domain join account password unencrypted.  The one in C:\sysprep is encrypted.  I'm certain it's part of cleanup, but good to see on a malfunctioning desktop (to make sure the password is correct).

[g0dMAn]

jonathanjabez​

Did you want to take a look out of curiosity?

[RobinPlomp01]

Hi Jonathan Jabez,

What would be your troubleshoot move if the VM did not get an IP. This does not happens to all the VM's. It happens to 2/3 of the pool. On one host two vm's from desktop pool, one with and one without IP.

R

[g0dMAn]

Robin, Jonathan disappeared after he asked for my logs.