We we are seeing exactly the same issue, pretty much down to the letter too. Except we are using Linked Clones.
Did you find an answer to this? Is it a bug in 2.14.0?
There might be something that you could try.
You could try to add a reverse replication delays in the client machine.
- In the base image, open regedit and go to this path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Parameters
- create a DWORD value DelayRegistryReverseReplication and set it to 180
- Shutdown and use this image as base image for the clones
1 person found this helpful
i managed to find a solution for this issue.
The issue, well - it isn't really an issue at all if the think long enough about it, App Volumes is just doing what it is told to do; its not App Vols fault that your capturing heavy apps :-). Whenever you capture apps in an appstack you also capture their security profile as well. if you have a large appstack, like i did, circa 100GB. Then each application contributes to the size of the Appstack firewall profile. When you go to login as a user to a desktop App Volumes first visualises the OS, then imports the security profile from the appstack to the local desktop. This import/export process can stall logon for up to 40-50 seconds.
If you are in a position where your internal Linked or Instant Clones have their domain firewalls down by default then i see this as being a cumbersome task.
To stop the delay i did the following:
1) update and mount the problematic Appstack on your App Volumes provisioning machine (Use the VMware Console to do this not RDP as connections with drop later)
2) Open an elevated command prompt and run "netsh advfirewall reset" (this blows all the security config away from the firewall and returns it to default)
3) run "netsh advfirewall set allprofiles state off" (this takes all the firewalls down)
4) close the capture and return the Appstack back to the App Volumes Manager.
5) Delete the user existing writable volume (if they had one) and recreate fresh
6) Assign a user to the new Appstack and login (remember to unassign the original appstack before logging in with the new one)
I hope it works for you guys. If however you need to have your firewalls on internally then you need to live with this delay as it needs to copy down to the desktop somehow.
I'm experiencing the exact same thing and have been troubleshooting for the last 2 days however, I don't have a large AppStack like you do.
One thing I did do during my troubleshooting was unassign an AppStack so that the user would only have the Writable being attached but I still saw the logon times increase.
Perhaps the writable was still retaining the data from the AppStack?
I'll have to give your resolution a try in my environment and see how it works for me.
- ESXi 6.5
- App Volumes 2.14
- VMware Horizon 7.5 (Instant Clones)
- VMware UEM 9.5
- Windows 10 Pro Build 1709
Seems that I'm getting this even without an AppStack assigned to a user.
We see the exact same issue but ours is related to the writable. What happens is that the logon goes quite well until it should release the desktop. Then you see the VMLM in the bottom left corner waiting for the logon to finish correctly. When removing the writable volume or recreating it the problem is instantly fixed. Off course this isn;t an option for this. We should be possible to remove the firewall rules in some way. I will raise a call with VMware to see if they can help.
Logging of svservice shows this
[2019-01-08 13:19:43.781 UTC] [svservice:P1728:T3364] RunCommandLineFromService: Launching CommandLine C:\Windows\system32\cmd.exe /c del /q /f "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" 2>NUL && netsh advfirewall export "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" && netsh advfirewall import "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" (CreationFlag 134217760, wait -1 ms)
[2019-01-08 13:19:43.782 UTC] [svservice:P1728:T2636] User has not configured for checking of Windows Update Service status
[2019-01-08 13:19:43.789 UTC] [svservice:P1728:T3364] Successfully launched: C:\Windows\system32\cmd.exe /c del /q /f "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" 2>NUL && netsh advfirewall export "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" && netsh advfirewall import "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" (wait -1 ms)
[2019-01-08 13:21:26.692 UTC] [svservice:P1728:T3364] ExitCode 0. Finished waiting for "C:\Windows\system32\cmd.exe /c del /q /f "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" 2>NUL && netsh advfirewall export "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg" && netsh advfirewall import "C:\Program Files (x86)\CloudVolumes\Agent\Logs\cvfirewall.cfg"" (WaitStatus 0)
[2019-01-08 13:24:34.203 UTC] [svservice:P1728:T1824] Received SERVICE_CONTROL_INTERROGATE
As you can see the command takes about 2 minutes to complete. In this time the user only sees a black screen and that's it.
If anyone has a solution please feel free to share ..
While I don't use writeable to test, I have been testing pulling vlmn from our images, and logon times have improved. This is with 7.4, to do it correctly you need to remove the vlmn helper from the userinit registry key.
Thanks for your reply. We do see that VMLM is waiting for the logon proces to end but is it not the actual culprit of the issue. Everyone has VMLM enabled here but just a few users have the black screen error. We once did remove VMLM and it did help a few seconds but that was about it. Also, we really like the information we receive from it and because we only have 1 image this would mean noone would have it anymore.,
I have raised a call with VMware and am waiting response.
We had a similar issue when attaching a writable it would take 2 to 4 mins to log in.
We also couldn't have more than 13 app stacks assigned to the user without appvol going into melt down and not assigning any stacks to the users really annoying if they have more than 13 app stacks anyway.
Solution for us was to remove
Devices.hotplug false from from the VM issue resolved but now people can remove nic etc so trying to work that one out.
Hope that helps you.
What are your logon times with 13 appstacks now? I'm just curious because we are designing ours to limit to 5 at the most. Its a byproduct of an older bug, I'm just hesitant to try using that many appstacks.
We don't have 13, a max of 10 but to be honest logon times are pretty decent. What I commonly see is that it adds up 1 to 2 seconds to the logontime per appstack because of the processing of the batch files stored on it.
And with W10 logon times are that long that it doesn't matter that much if you have more appstacks. Also when logged in we don;t seem to notice a lot of slowdowns due to a bunch of appstacks attached.
I do believe though that 10 is still a best practice as stated in official documentation right?