VMware Horizon Community
khamilton2
Contributor
Contributor
Jump to solution

AppStack not attaching everytime (1-5%), no manager configuration found on affected machines

I am using AppVolumes 2.13 with a 100 machine instant clone pool.  Windows 10 1607 LTSB.  Attaching 1 appstack via OU group assignment on boot.

I have noticed that after heavy use each day there will be 1-5 machines that have rebuilt and show available but do not have the appstack attached.  After looking at the logs on the machines that didn't get the appstack it shows it failed to attached b/c it could not find any appvolume manager configuration under HKLM\System\CurrentControl\Services\svservice\Parameters.

This is strange since they all use the same template and the manager configuration value is present on the template and works majority of the time.  I do not understand how this value can be somehow missing on a few random machines.  I have a screenshot below showing 2 machines that should be identical but one is somehow missing this value and then didn't get the appstack.

Any ideas where to start to correct this issue?

1 Solution

Accepted Solutions
jeffrobinson85
Enthusiast
Enthusiast
Jump to solution

I believe your issue might have been resolved in App Volumes 2.14. The Manager1 key gets removed from the VM.

VMware App Volumes 2.14 Release Notes

Resolved Issues

  • Deep Security Agent status is unknown or unreachable when attaching a Writable Volume.
  • Unable to provision Instant Clones when AppStacks were assigned to a computer Organizational Unit (OU).
  • Manager1 registry gets removed post-VM cloning processes resulting in failed AppStack attachments.
  • No pop-up dialog observed if a Writable Volume failed to attach in VHD configuration.
  • Failure to delete the Appstacks when the name contains high-ASCII characters.
  • BSOD due to kernel stack overflow when attaching Writable Volumes.
  • Windows Search does not work when an AppStack is attached without a Writable Volume.
  • Template volumes were uploaded to datastore even without ESX credentials/ESX host selection.

View solution in original post

3 Replies
jeffrobinson85
Enthusiast
Enthusiast
Jump to solution

I believe your issue might have been resolved in App Volumes 2.14. The Manager1 key gets removed from the VM.

VMware App Volumes 2.14 Release Notes

Resolved Issues

  • Deep Security Agent status is unknown or unreachable when attaching a Writable Volume.
  • Unable to provision Instant Clones when AppStacks were assigned to a computer Organizational Unit (OU).
  • Manager1 registry gets removed post-VM cloning processes resulting in failed AppStack attachments.
  • No pop-up dialog observed if a Writable Volume failed to attach in VHD configuration.
  • Failure to delete the Appstacks when the name contains high-ASCII characters.
  • BSOD due to kernel stack overflow when attaching Writable Volumes.
  • Windows Search does not work when an AppStack is attached without a Writable Volume.
  • Template volumes were uploaded to datastore even without ESX credentials/ESX host selection.
khamilton2
Contributor
Contributor
Jump to solution

Thank you for the reply.  We will plan an upgrade to 2.14 and I will report back and confirm this fixes the issue.

Reply
0 Kudos
khamilton2
Contributor
Contributor
Jump to solution

I have updated Appvolumes manager and agents to 2.14.  This does appear to correct the issue.  Have refreshed over 1000 machines since the update and have not seen a single machine not get the appstack.

2.14 did introduce a new bug where scripts in the startup folder were now not running all the time.  The smaller appstack's scripts would fail about 90% of the time, while the larger appstack was only failing to run its startup scripts about 10% of the time.  I was short on time for troubleshooting and testing but from what I could tell the scripts where running but some of the stuff they would reference in the appstack was maybe not copied over yet so they would fail.  I seen suggestions to add a regedit to delay the login until the appstack was completely attached, but I did not want to increase login times.  I was able to get the scripts to run 100% of the time by adding a few seconds sleep timer to the very start of the script giving it a slight delay after getting the desktop.

Reply
0 Kudos