DanVM99 Tracker

Re: External User Not Redirecting from UAG to VC using HTML Access

DanVM99 — Tue, 13 Dec 2022 16:39:52 GMT

Not sure if this is relevant to your issue but might be worth checking:

https://carlstalhood.com/vmware-unified-access-gateway/#horizonedge

Do a find on page and look for 'HTML Access' until you come across the section that starts 'f. HTML Access probably won't work...'

Re: Microsoft Teams on Non-Persistent - UEM + App Vols

DanVM99 — Fri, 05 Jun 2020 14:04:20 GMT

For anyone stumbling across this thread there's now a proper way to install the full Teams client for the machine context rather than user profile. It will install into Program Files if you download the setup MSI and use a command line switch provided my MS for non persistent VDI environments.

Teams for Virtualized Desktop Infrastructure - Microsoft Teams | Microsoft Docs

Re: Performance problems in linked clone VMs with any AppStacks attached

DanVM99 — Fri, 14 Feb 2020 10:24:38 GMT

Thanks Ray, at least we know this behaviour is "by design". What I can't quite understand is why those registry hives contain so much data. When we export them they end up being several hundred MB and contain around 2 million lines of registry in exported form. The result of this seems to be that operations that "parse" the registry such as eventvwr or printing seems to take much longer than they do without any AppStacks attached. Printing a basic one word test doc from MS Word takes around 45 seconds to the point it spools. Without appstacks this process takes just 19s.

We always believed that the capture process would be intelligent enough to only capture changes to the registry during the app install and not capture what appears to be essentially an entire copy of the registry minus a couple of arbitrary exceptions.

Out of interest what's your printing/event viewer performance like?

Re: Performance problems in linked clone VMs with any AppStacks attached

DanVM99 — Thu, 13 Feb 2020 14:53:46 GMT

Thanks sjesse

We were thinking the same to be honest. We've also noticed that there always tends to be an extra 'SnapVolumes-####' hive mounted in the registry on our clones. For example, if we have one single App assignment/attachment there will be 2 x 'SnapVolumes-###' Reg keys under HKLM. If we had three stacks assigned then there would be 4 of these reg keys. There seems to be a large amount of sub keys and data within them too as when exported they tend to be several hundred MB. Are you able to comment on if your environment looks like this at all?

Re: Performance problems in linked clone VMs with any AppStacks attached

DanVM99 — Thu, 13 Feb 2020 14:41:31 GMT

For anyone out there who might see this we've also now found that removing the "virtualize registry" lines from the snapvol.cfg in any of our AppStacks has produced noticeable improvements in both the speed of sending print jobs and using the event viewer. Not sure this is a viable configuration though, or even what the virtualize registry lines are responsible for...

Performance problems in linked clone VMs with any AppStacks attached

DanVM99 — Fri, 24 Jan 2020 12:10:57 GMT

For some time now we've been finding that certain tasks in our linked clones seem to be taking longer than they should.

Printing is the biggest issue. Sending print jobs takes much longer with an AppStack attached than without. Some of our users are finding that printing from apps such as Word or Adobe Reader (both installed in our Gold Image) to our Canon MFDs or HP printers can take over a minute for the job to be spooled. Print queues are shared out from a printer server and delivered via UEM printer mappings to the non persistent linked clones. Drivers are added to the Gold Image by adding the print queues and then subsequently removing them (leaving the driver behind). If we remove any AppStack assignments then printing is snappy and takes around 15 seconds from clicking 'print', choosing the printer and pressing 'OK' to the job being spooled. This issue occurs with all of our AppStacks. We're using AppVols v2.18 and our apps have been captured using the latest 2.18 template.

We also see terrible performance when trying to browse event logs in event viewer on the clones. Clicking the 'System' results in a busy icon appearing at the top log level and a wait of around 5 minutes before the resulting events are populated in the window. Again, removing AppStacks from the user results in the event viewer behaving normally, listing events within about 15 seconds.

I can't help but feel that overall performance is being degraded by AppVolumes in our environment. Everything "feels" that bit more responsive when we don't have any AppStack attachments. We're using Windows 10 1903 x64 with 6GB RAM and 2CPUs assigned to our clones. I've logged a ticket with Support but if we can't improve things then we're likely to have to look at putting all our Apps in the Gold Image and drop AppVols.

Is anybody else out there seeing behavior like this??

Re: Getting provisioning error as View Composer Fault: Unexpected VC fault from View Composer (Unknown) - Unknown -
DanVM99 — Tue, 01 Oct 2019 09:56:59 GMT

For anyone out there that might stumble across this...
We recently added an additional two ESX hosts to our VDI cluster and were scratching our heads as to why we were seeing the above error during provisioning operations. We later realised that we were using the VAAI Clone Offload feature in our desktop pools but had forgotten to add our storage provider's (Tintri) VAAI ESXi plugin to the new hosts. Installing the relevant plugin and rebooting the new hosts resolved this issue for us.

Re: Visio 2016 - Keeps running Office 2016 configuration

DanVM99 — Fri, 02 Aug 2019 14:36:07 GMT

Have you tried disabling the Office Software Protection Platform service in your capture machine? This prevents Office from performing any inadvertent reevaluation of your Office license and configuration status during the capture process of other applications. You keep the service enabled in your Gold Image, just disable on your capture VM. This solved a similar issue for us.

Office 2019 Skype for Business Address Book Search Broken with AppVols

DanVM99 — Fri, 02 Aug 2019 14:31:24 GMT

Rather a strange/annoying issue this one......

Recently it was discovered that the Skype for Business address book search was not working in our latest Windows 10 1903 VDI desktop pool.

Initially it was thought that a change we made in our gold image was the cause. The address book search was working perfectly while we were using Office 2019 (with Visio Standard) 64 bit. We later uninstalled the 64bit edition and installed the 32 bit version of Office 2019 (for compatibility reasons) and to be in keeping with our intended physical desktop rollout. While it is definitely a factor, it is not the whole story.

After a bit of investigation the issue seems to arise when any AppStack is attached. NOTE: AppStacks are assigned to the user not the computer.

If the user has no App Stacks assigned or the App Volumes Agent is uninstalled, then the contacts search works as expected.

My guess is some kind of snapvol.cfg configuration needs to happen but that is beyond my expertise with App Volumes. I've had a look in the snapvol.cfg and compared registry and file locations for the respective 64 and 32 bit installations of Office 2019 and they all seem to point to locations that are the same regardless of 64/32 bit version.

Obviously I understand that this may not be something a lot of people can test as you will require a functioning Skype infrastructure in order to test the address book search functionality works so any suggestions (apart from going back to the 64bit version of Office!) would be welcome.

Visio seems to play no part in the issue as uninstalling it and testing again revealed the same problem. We also tried removing Office from the capture machine and recaptured an app, which we then used as a test deploying it to our VM, but the issue persisted.

I've included some brief information below which I think is relevant but if there is anything else you need to know, feel free to ask.

Tests can be carried out against the Gold Image.

Gold Image configuration

O/S Windows 10 1903 64 bit

Installed Apps Office 2019 Pro Plus VL 32 bit

App Volumes configuration

Version 2.16

Template 2.16

Capture VM Clone of Gold Image

Changes snapvol.cfg entries tried

exclude_path=\Program Files (x86)\Microsoft Office\PackageManifests

exclude_path=\Program Files (x86)\Microsoft Office\root

exclude_path=\Program Files (x86)\Microsoft Office\AppXManifest.xml

exclude_path=\Program Files (x86)\Microsoft Office\Updates

exclude_path=\Program Files\Common Files\Microsoft Shared\ClickToRun

exclude_registry=\REGISTRY\MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY < this was already added to the template to fix an issue with Visio loading slowly when AppStacks are attached.

Re: Strange issue with AppStacks failing to attach

DanVM99 — Fri, 21 Jun 2019 10:10:17 GMT

Thanks for your input but I think our issue differs from yours in so much as our VMs seem to be connecting to the manager rather than re-attempting connection like yours. They just don't get the AppStacks for some reason. I've included a lager chunck of our example fail log in case anyone notices any commonality with their own. It begins from the point a user first logs on to a VM. I've not included the prior section where the VM is originally provisioned and connects successfully to the AppVols Manager.

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1128] *** Started

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1128] Running from: C:\Program Files\CloudVolumes\Agent\svservice.exe (release build)

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] Checking agent version from "C:\Program Files\CloudVolumes\Agent\VERSION32.txt"

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] Build: "Release-Agent-Build-32-2_16_0" (letter U)

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] Build version: "2.16.0.23U"

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] CheckOfflineVHDMode: dwResetWritableDays was set to (0) days, turn off offline mode!

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] VHD offline mode was off!

[2019-06-03 07:41:10.961 UTC] [svservice:P1124:T1208] ServiceInit starting

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Running on Windows 6.1 build 7601 (service pack 1.0)

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] OS is a workstation

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Architecture: x86 (2 processors)

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Running as: DOMAIN\WINDOWS7-099$ (NameSamCompatible)

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Setting status to SERVICE_START_PENDING

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] MachineSID is "S-1-5-21-3842748544-3961479084-860730781"

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Hypervisor configured as: vcenter

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Successfully created RunKey event

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] CleanUpSystemDrive: Flag CleanSystemWritable was configured, auto cleanup the system writable directories...

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] Moving C:\SnapVolumesTemp to C:\SnapVolumesTemp.old

[2019-06-03 07:41:10.976 UTC] [svservice:P1124:T1208] CleanUpSystemDrive: deleted "C:\SnapVolumesTemp"

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] Processing of Scheduled Tasks is disabled

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] Using 8 worker threads to communicate with driver

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] InitializeWmi: called

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] UpdateInteractiveSessionCount: SessionId 0 Name(Services) State(4)

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] UpdateInteractiveSessionCount: SessionId 1 Name(Console) State(2)

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] UpdateInteractiveSessionCount: Found 0 active / 2 total user session(s)

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] Setting the following data in Run key for svservice : "C:\Program Files\CloudVolumes\Agent\svservice.exe"fromrunkey

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] HttpComputerStartup: called 0 logged in (computer startup)

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] svdriver is running

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1208] Becoming trusted installer

[2019-06-03 07:41:10.992 UTC] [svservice:P1124:T1272] HandleNGVC: NGVC not present, error 2

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] Enter : BuildSecurityDescriptorForIPC

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] Exit : BuildSecurityDescriptorForIPC

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] IPC server initialize success!

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] ServiceInit completed successfully

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] ServiceMain now running

[2019-06-03 07:41:11.039 UTC] [svservice:P1124:T1208] Setting status to SERVICE_RUNNING

[2019-06-03 07:41:11.101 UTC] [svservice:P1124:T1196] OnCreateSession called (Session ID 1, Handle 001511E0, Params 015FF5EC, Context 00000000)

[2019-06-03 07:43:13.300 UTC] [svservice:P1124:T1272] GetComputerUuid: unable to locate UUID

[2019-06-03 07:43:13.300 UTC] [svservice:P1124:T1272] HttpComputerStartupThread: failed (computer startup)

[2019-06-03 07:44:22.573 UTC] [svservice:P1124:T1128] Received SERVICE_CONTROL_INTERROGATE

[2019-06-03 07:44:22.573 UTC] [svservice:P1124:T1128] Current status being sent to SCM is 4

[2019-06-03 07:48:00.362 UTC] [svservice:P1124:T4616] OnLogon called (Session ID 1, Handle 001511E0, Params 0157F2D4, Context 00000000)

[2019-06-03 07:48:00.362 UTC] [svservice:P1124:T4616] OnLogon: DOMAIN\USER (NameSamCompatible)

[2019-06-03 07:48:00.393 UTC] [svservice:P1124:T4616] OnLogon: CN=USER'S NAME,OU=Users,OU=DEPARTMENT,OU=Departments,DC=DOMAIN,DC=DOMAIN,DC=local (NameFullyQualifiedDN)

[2019-06-03 07:48:00.393 UTC] [svservice:P1124:T4616] OnLogon: USER@EXTDOMAIN (NameUserPrincipal)

[2019-06-03 07:48:00.393 UTC] [svservice:P1124:T4616] NotifyLoginStarted failed: error 0x80070002

[2019-06-03 07:48:00.393 UTC] [svservice:P1124:T4616] IsDomainJoinedComputer: NetGetJoinInformation() success, domain name DOMAIN and type is 3

[2019-06-03 07:48:00.393 UTC] [svservice:P1124:T4616] GetUserComputerInfo: user:"USER" computer:"windows7-099" userdomain:"DOMAIN" computerdomain: "DOMAIN"

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] GetUserProfileDirectoryW failed: error code 2

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] Logged in user is USER

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] OnLogon: skipping scripts because filtering is inactive

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] GetViewClientIdValue: Unable to open key Volatile Environment\1: error 2

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] GetViewClientIdValue: Pool ID value in key Software\VMware, Inc.\VMware VDM\SessionData\1 is Windows7

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] HttpUserLogin: called 0 logged in (user login)

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] svdriver is running

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] HttpUserLogin: skipping notifying manager of user login (computer-startup failed)

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] OnLogon : succeeded

[2019-06-03 07:48:06.848 UTC] [svservice:P1124:T1128] Received SERVICE_CONTROL_INTERROGATE

[2019-06-03 07:48:06.848 UTC] [svservice:P1124:T1128] Current status being sent to SCM is 4

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] OnStartShell called (Session ID 1, Handle 001511E0, Params 02B5F688, Context 00000000)

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] OnStartShell: DOMAIN\USER (NameSamCompatible)

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] NotifyLoginCompleted failed: error 0x80070002

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] HttpFileShareRequest WinHttp over SSL is disabled. Log collection to file share not supported.

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] handleFileShareStr: File share info received from manager is empty.

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T6016] OnStartShell: Error Failed to Start DCT Logger

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T2920] Waiting 0 second(s) for a new volume

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T2920] Activate filtering (called by DelayActivateWorker)

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T1256] MeasureTime::RecordCenter: Start recording GUID:{58fffd46-2b8f-11e9-af91-806e6f6e6963} Type:0

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T1256] Preload volume event (startup): "\Device\HarddiskVolume2" GUID {58fffd46-2b8f-11e9-af91-806e6f6e6963} Hive (1 logged in, SystemVolume 1, VolumeType 0)

[2019-06-03 07:49:14.360 UTC] [svservice:P1124:T1256] Sending reply to SVCMD_ID_NEW_VOLUME_PRE (Message 13, Size 0)

[2019-06-03 07:49:23.157 UTC] [svservice:P5988:T4296] *** Started

[2019-06-03 07:49:23.157 UTC] [svservice:P5988:T4296] Entered fromrunkey case

[2019-06-03 07:49:23.157 UTC] [svservice:P5988:T4296] Successfully opened runkey event.

[2019-06-03 07:51:16.428 UTC] [svservice:P1124:T1128] Received SERVICE_CONTROL_INTERROGATE

[2019-06-03 07:51:16.428 UTC] [svservice:P1124:T1128] Current status being sent to SCM is 4

[2019-06-03 08:19:27.858 UTC] [svservice:P1124:T6016] OnLock called (Session ID 1, Handle 001511E0, Params 02B5F688, Context 00000000)

[2019-06-03 08:49:27.910 UTC] [svservice:P1124:T6016] OnUnlock called (Session ID 1, Handle 001511E0, Params 02B5F688, Context 00000000)

[2019-06-03 10:14:39.333 UTC] [svservice:P1124:T6016] OnLock called (Session ID 1, Handle 001511E0, Params 02B5F688, Context 00000000)

[2019-06-03 10:17:40.131 UTC] [svservice:P1124:T6468] OnUnlock called (Session ID 1, Handle 001511E0, Params 015FF008, Context 00000000)

[2019-06-03 11:24:42.440 UTC] [svservice:P1124:T6468] OnLock called (Session ID 1, Handle 001511E0, Params 015FF008, Context 00000000)

[2019-06-03 11:44:14.937 UTC] [svservice:P1124:T6468] OnUnlock called (Session ID 1, Handle 001511E0, Params 015FF008, Context 00000000)

Strange issue with AppStacks failing to attach

DanVM99 — Tue, 18 Jun 2019 09:50:56 GMT

For a few weeks now (and prior to our recent upgrade to 2.16) our users have been experiencing random issues with missing AppStacks when they login to their Horizon 7.8 non persistent clone machines. We currently have around 120 users of the system and we tend to see around 1-3 people each day experiencing this issue.

There doesn't appear to be any pattern to this behavior and it is affecting different users with varying AppStack assignments and seemingly no commonality. The manager side log doesn't appear to reveal any connection issues but the client side svservice.log file does indicate the below issue at a fairly early stage during the user logon process.

[2019-06-03 07:48:00.409 UTC] [svservice:P1124:T4616] HttpUserLogin: skipping notifying manager of user login (computer-startup failed)

The non persistent VM seems perfectly healthy.

The user who's log this belongs to didn't receive any of their three assigned AppStacks. Advising the user to logoff (which refreshes the VM) and log back on to a new VM resolved the issue and their AppStacks were then attached. We're seeing this behaviour with multiple users but asking them to log off and back on to resolve it is not a feasible long term solution.

Logged this with VMware Support a few weeks ago and I'm still yet to hear anything back from them after supplying multiple log file examples etc.

Does anyone have any ideas? Ray?? Are you out there!?

Re: Very Slow Start Menu and Search Box Initial Opening in Windows 10 VMs

DanVM99 — Tue, 15 Jan 2019 11:23:56 GMT

Did you ever come to a conclusion with your findings on this? We're having the same issue and I'm reticent to revert to a pre optimization snapshot as we've done lots of other work to our Gold Image since then. I was hoping someone might have determined the necessary registry keys that needed to be restored to go back to pre optimization tool start menu performance...

Thanks

Re: App Volumes 2.13.1 - The connection to the remote computer has ended

DanVM99 — Thu, 30 Nov 2017 09:46:12 GMT

The AppVols Agent 2.13.1 turned out to be a red herring. We managed to resolve this issue by decreasing the screen resolution of our Gold Image to 800 x 600 and recomposing the pool.

App Volumes 2.13.1 - The connection to the remote computer has ended

DanVM99 — Wed, 22 Nov 2017 11:18:41 GMT

Since updating our App Volumes Manager and Agent from v2.12.1 to v2.13.1 we are seeing around 1 in 3 logons to our non persistent linked clone pools fail with the error The connection to the remote computer has ended. We seem to see this error quite quickly, only a few seconds after clicking on the pool in the Client. Removing the v2.13.1 agent and going back to using v2.12.1 immediately resolves the issue.

I've read the article here https://kb.vmware.com/s/article/2151948 that seems to suggest this error can occur in large scale deployments of AppVols but our current use is very small (10 users or so). This article also says the symptoms occur after being logged into a VM for a few minutes then being kicked off which doesn't match our scenario either. They also suggest using a writable volume script as a fix but we don't use writable volumes..

I've trawled the Clients logs for further clues but there's very little to indicate the root cause. Everything seems to be going well in the logs until it displays the error message with no underlying reason given.

Has anyone else had any experience of connection errors since upgrading their AppVols?

Re: App Volumes - App Stacks appearing after logon and connection errors when SSL Certificate validation is enabled

DanVM99 — Mon, 02 Oct 2017 12:51:50 GMT

Hi Ray,

Thanks for your insight into the attachment of the stacks.

We did some additional testing on Friday but didn't have anything concrete to post. Some additional testing this morning appears to have shown some positive results in relation to the issue contacting the App Volumes manager.

With certificate validation enabled, we have not yet run into any connection errors by having a script that is initiated by the Horizon Quickprep process. On the gold image we have created a folder that contains our root certificate, and a batch file that uses the certutil program to install it. We've entered the location of the batch file into the QuickPrep post synchronisation script location (during pool creation in Horizon View) and the seems to have cured that problem, admittedly with only a small number of logons attempted.

If anyone else is having this issue, the batch file is only one line as follows

certutil -addstore -f -enterprise -user root <path to root certificate>\<certificate file name>

e.g. certutil -addstore -f -enterprise -user root C:\resources\root.cer

However we are still having the issue with being logged on prior to all application being available and have opened a support request with VMWare about this. If we get a reliable fix, I'll post it here.

Re: App Volumes - App Stacks appearing after logon and connection errors when SSL Certificate validation is enabled

DanVM99 — Fri, 29 Sep 2017 15:35:03 GMT

Hi Ray, thanks for your quick response

Your description of the issue regarding the 7 second pause seems reasonable. Just wanted to check, when you say that there is a message sent to the vCenter to recompose, do you mean a reconfigure of the virtual machine to attach the App Stacks the user has assigned to them? If this is the case, as we have 10 App Stacks in our test it will take a while to attach them all. We will try different amounts of App Stacks and see if it changes accordingly.

In regards to the certificate validation, we did a very rudimentary test of a theory we've had for a little while in that the Quickprep process is somehow interfering with our Trusted Root Certificate. Our root certificate is present in our gold image but occasionally we notice that some machines will behave as if no root certificate is installed. This usually is shown by programs asking for credentials when they normally wouldn't. It may also explain why we are having issues connecting to the App Volumes manager when certificate validation is enabled. To test this we tried giving a certificate a friendly name in the gold image and then creating a pool from a snapshot that contained the friendly name. When the pool had been composed, the friendly name had been erased. Like I said it is a rudimentary test but shows that "something" is happening to the root certificate store during the creation of the pool.

Finally the issue with the all the apps not attaching prior to login seems to ignore the default timeout of VolWaitTimeOut as if the registry key is not present, it doesn't appear to wait the 3 minutes it should before logging a user in if not all app stacks are "ready". By this I mean it will log in the user well before the 3 minutes is up and then the apps will appear around 3 minutes after logon. I'm not sure what VMWare's criteria is in determining at what point everything is done and that the logon process should complete and the user should be presented with a desktop. I'm guessing there are a variety of ways it could meet the necessary criteria but these details seem to not be included in the logs (unless we are reading the wrong ones), so it makes it difficult for us to troubleshoot. We would prefer the user not be presented with a desktop prior to all the apps being present but have so far struggled to achieve this with any level of reliability.

It is also worth mentioning that we are not using writable volumes as the intention is currently go with UEM or Persona Management for user profiles. We do use disposable disks though.

App Volumes - App Stacks appearing after logon and connection errors when SSL Certificate validation is enabled

DanVM99 — Fri, 29 Sep 2017 11:37:39 GMT

We are using Horizon View 7.2 and are currently testing with pools of linked clones. We are using App Volumes 2.12.1 (though the majority of stacks are based on the 2.12.0 template) to deploy our applications.

Initial testing of App Volumes (with SSL certificate checking enabled) produced a connection error each time we logged on 'Cannot contact App Volumes Manager - Virtualization is disabled'. We did find however that restarting the svservice and logging back on to that particular VM would allow Apps to attach... albeit with the behaviour described below.

When logging into our Win7 32bit pool with 10 App Stacks assigned we only see around 7 or 8 apps successfully attached upon initial logon. The remaining apps appear around 8 seconds later. We are eventually going to introduce UEM into the environment and the concern here is whether settings for the missing Apps would be applied or not. In an effort to try and resolve this issue we created the VolWaitTime regkey with a values of 5 and 10 seconds in successive tests. The result of which was only around half of the 10 apps were attached at logon and we had to wait a further 3-4 minutes before the missing stacks would successfully attach.

So, first question. Disabling SSL certificate validation prevents us from getting connection errors, but given we have successfully replaced the certificate on the App Vols Manager with an internal CA assigned cert that is trusted by our pool of desktops that have the Trusted CA cert in the Gold Image, why are we seeing connection errors with cert validation enabled? And why does restarting the svservice after the pool has finished composing get rid of these errors? Is the svservice starting prematurely for some reason?

Second question. Why are we only getting half our apps attached before the point of logon and subsequently seeing the remainder of the Apps burst in at a later point (either 8 seconds or 3 minutes with VolWaitTime key in place)?

Regularly trawling through both Manager and Agent logs doesn't reveal much as to why any of this is happening. We did however notice a 7 second pause after attempting to contact the AppVolumes Manager during the certificate validation phase regardless of whether validation is enabled or not.

Any insight into these issues would be greatly appreciated as we're really struggling to make a case for a successful implementation of AppVolumes for our VDI project.

Re: Printing nightmare in Horizon View 7

DanVM99 — Thu, 26 Jan 2017 10:04:39 GMT

Thanks Henderson,

That's given me a good insight into the ThinPrint option. Using the older version of that DLL to sustain UNC ptah printers is definitely going to form the basis of my 'Plan B' for printing should UEM fail to come up with the goods.

Lastly, can you tell me which is the latest version of the TPVMGPoACmap.dll file that still appears to work with UNC path printing? We're using View 7. Do I need to grab the DLL from View 6 or perhaps even older?

Thanks

Re: Printing nightmare in Horizon View 7

DanVM99 — Thu, 26 Jan 2017 09:41:22 GMT

Thanks jmacdaddy.

After playing about with UEM I think we're going to see if there's any mileage in it's printer deployment by AD Group condition feature as despite having the correct underlying drivers in our template we can't seem to get any printers appearting in VMs.

Good idea re adding each printer then deleting it though - I'll remember that one.

Printing nightmare in Horizon View 7

DanVM99 — Tue, 24 Jan 2017 16:26:08 GMT

Can anyone shed any light onto our current printing position?

We're building up our HV7 Test environment with Win7 32bit Gold Image in the hope of going live later this year in Production.

When looking at our printing options we can't seem to find a suitable solution.

Our existing printing infrastructure consists of a single Windows print server that has 100 or so printers shared out via UNC path. We currently use Group Policy to install printers targetting users by the appropriate OU and security groups they're in. For some reason this process does not work within our VMs. I have tested placing the machines in the same OU as our physical machines and run a GPResult which shows the printer policies are supposedly being applied successfully - but no group policy printers to be found anywhere inside our virtual desktops and no trace of any GP issues in Event Viewer.

We're hoping to go live with some kind of a thin/zero client device that will NOT be running Windows IOT/embedded though this is currently dependent on Microsoft's upcoming development of a suitable Skype for Business plugin to offload VOIP audio to a non Windows based client. Therefore VMware's client printer redirection is not an option for us as this depends upon a Windows based client device.

The next option is to use Location Based Printing with the ThinPrint feature of Horizon. From my reading of the implementation guidance though it apears that VMware do not support UNC Path printers. All our printers are currently installed and shared out by UNC from our print server. We don't want to use direct printing to IP as we'd lose valuable central management of print drivers such as changing duplex settings and installed options etc centrally.

The next option we considered was manually installing printers into the virtual desktop for each user as we on board them into VDI. Our initial testing seemed to show that Persona Management was retaining connections to these manually added printers across our non persistent linked clones but we later found that this proved unreliable and some printers would persist and other didn't on a seemingly random basis.

We have UEM but haven't started to use it as yet. Does this give us any additonal options in terms of printer deployment? Are there any other ways of skinning this cat that we haven't considered?

Many many thanks in advance for anyone who's managed to make it this far! Apologies for the lengthy post.