Jump to content
Welcome to our new Citrix community!
  • 0

19.11 Update and VMware Horizon


David Thacker

Question

What the heck did you guys do in this update? Seriously? We have a reasonably fast hyper-converged ESXi 6.7U2 cluster with all-flash storage, and this update has now made the updating process exponentially faster! It's not just the Offload Compositing, it's that combined with the (finally!) reasonable ability to use thin-provisioning that makes the whole App Layering processes lightning-fast. I can't speak to the issues others are having, but as a VMware-only VDI shop, it is a quantum leap in operation speeds.

 

Probably doesn't hurt that our HCI solution does block-level compression and de-dupe at the storage level, so it doesn't care if a VM is thick or thin provisioned, it ends up the same. Yay to App Layering no longer attempting to expand a VMDK to "full" size, which is essentially just calling a vCenter operation that is a waste of time, but I understand the origin of needing to expand the VMDKs because the composited VMs are using a 'fixed' disk size and VMware historically required the VMDK storage to be pre-allocated, especially on VMFS stores. 

 

Horizon just works with the VM as-is in vCenter, so it assumes it's ready to go. So far, I love it, other than Win10 still won't sysprep, which I'm wondering if it's related to VMware's unattend sequence they use.

Link to comment

3 answers to this question

Recommended Posts

  • 0

Can confirm it's a huge speed boost all the way around for VMware. Quickprep now works OK, albeit a little awkwardly. The VMs customize, generate errors about being unable to activate (I consoled in and ran slmgr /ato and activation worked fine), reboots, runs customization again, and then works perfectly. The only downside is that it goes through the disk digest creation process twice, which slows pool compose/recompose ops to 2x length of time. The disk digest creation is always the slowest portion, but highly useful for VMware.

 

Once the pool (linked clones, not licensed for IC) is up and running, performance is excellent. I did run into an issue where using Win 10 1903, some layers I had captured several months ago exhibit the crashing start menu bug and are unable to be updated. I attribute this to the stupid 1903 bug; I just delete and re-create the app layer, not a big deal. Elastic Layering and User Layers are working perfectly with O365. I let it cache my OST, which is a couple GB, so I could bump up my profile size and test load times, and they remain reasonable along with four elastic layers.

 

The one issue I have is that the GPO linked to the OU where the VMs are published does not appear to be applying. I ran GP modeling against my account and a VM, and it says the GPO should be applied, but it's not. This one is puzzling, since GPO refresh should happen roughly every 15min, and once the VMs are spun up they should actually process the GPO on domain join, but they're not. It could be a permissions issue, we just did a full domain migration and discovered the consultant screwed several things up, so I'm suspecting something simple like that. If I can resolve that problem, I'll be extremely happy.

Link to comment
  • 0

So after a year+ of this "can't compose sysprep images" issue, I have finally found the 2 culprits:

 

1. If you create a Windows 10 image, don't remove all of the provisioned apps, then delete the account and create a new one, sysprep will *never* work. This is a MS bug, and it's taken digging through hundreds of threads over the past year to find one that called this issue out specifically. There are also some AppX apps that have to be present, so the R/R scripts that target everything aren't good. I found one that tracks (by release) which packages are required/not required, and only removes the correct packages. This bug, however, forced me to create a brand new base OS image. Not a big deal, few days to recapture some apps.

 

2. When Elastic Layering is enabled, it makes a whole bunch of services dependent on it to start, including State Repository which affects the AppX Services. During sysprep /generalize, it attempts to query State Repository and determine if there are any packages that could interfere. Well, since it's during sysprep, and the Uniservice.exe is set to Disabled, all the linked services fail to start, and sysprep fails on the generalize phase. I tested this by creating a clean OS base layer + platform layer, exported the composite image, and then powered it on one time to set Uniservice to Automatic, then powered off the VM and took a snapshot. It composed perfectly via sysprep, since when it needed to call the State Repository service and then AppX Services, Uniservice.exe was allowed to start. I understand that there is a helper service that normally starts Uniservice and all the dependent services, but why on earth is State Repository now dependent on an App Layering service, which is Disabled by default? Why not set the registry keys to prevent the re-installation of removed packages and forced upgrades instead?

 

I've had a ticket open with support for 2.5 weeks, and they are absolutely zero help. Some of the questions they've asked me don't even make sense, and I've already had to escalate the ticket once because it was stuck in Awaiting Customer Contact, and in fact we already did a remote session, and the support agent got the info he needed. I may have my own fix rolled before support even figures out what is going on. I'm testing removing the Uniservice.exe dependency from State Repository, but it has to be done after composition and output, so I'll see if there's an easy way to fix it.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...