App Volumes Chrome Appstack Plugins

[danielmgrinnell]

I have an app stack with chrome and i am having an issue w/ chrome plugins, when i try to install a chrome plug it complains that it could not install package 'COULD_NOT_GET_TEMP_DIRECTORY". I also have a writable volume running so this doesn't seem to be pulling the package to the Writable. Has anyone experienced this before and know a resolution or do i need to build this into my parent image and not use AppVols for this app.

Thanks

[Ray_handels]

Not entirely off topic.

The reg key needs to be in base image, not creating using UEM or GPO or any other tool!!! So please update the golden image, add this key, seal and upgrade the pool, then it should work.

Regarding the driveletter alsmk2. We have seen the exact same issue. When using 2.12.0.70 with older appstacks if not all appstacks are processed before logon they get assigned a driveletter and for as far as I could see (at least in our enviornment) Appvolumes doesn't detach the driveletter right away. It waits for the restting volume order for 180 seconds, the removes the drives and processes all refreshes all at ones. My startmenu goes a little berserk .

We are also in the process of updating all appstacks and setting the NoDefaultDriveLetter setting using diskpart. Any tips to do this in a faster way than changing them all??

[saieesh]

HI Ray_handels

thank you for the prompt response, i have done what you suggested but still no luck. the golden image is updated with the registry key as you have suggested and we have re-composed the machines but till i can see the drive is not assigned with any letter or user is not able to add extensions to chrome.

[Ray_handels]

What happens if you add the writable to a machine that doesn't have an appvolumes agent installed, start up diskpart and check the attributes of the writable volume.

What's the value of the No Default Drive Letter setting?? For the writable this should be no, otherwise it won't give the writable a drive letter.

Also, have you added a writable to your golden image once and remove the driveletter there? Could be that this information is still in the registry. Setting the DriveLetterSettings DWORD value to 6 does work for us. You did set it in the svdriver\Parameters right? And not in the svservice? The Parameters key doesn't exist for the svdriver, you need to manually create it.

[saieesh]

What happens if you add the writable to a machine that doesn't have an appvolumes agent installed, start up diskpart and check the attributes of the writable volume. - I didn't try this option

Also, have you added a writable to your golden image once and remove the driveletter there?No i haven't added the writable to golden image

Could be that this information is still in the registry. Setting the DriveLetterSettings DWORD value to 6 does work for us. You did set it in the svdriver\Parameters right? And not in the svservice? The Parameters key doesn't exist for the svdriver, you need to manually create it. - Yes i have done the same thing added the registry settings in golden image then re-composed the machines, later i can see the registry settings getting affected in VDI machines. Im attaching the snaps for you reference. even after registry got added to OS, drive letter is not assigned.

By the way we are using Windows 7 as VDI client OS.

[Ray_handels]

Yesy you did do everything right. Sorry, I'm out of ideas. I would suggest creating a ticket with support.

One thing I would like to know though. When you look at the svservice.log file do you happen to see 3 log lines like this??

[2017-03-20 13:35:09.125 UTC] [svservice:P920:T1072] Finished waiting for drive letter D for "\Device\HarddiskVolume4" (called by UpdateMountedVolume)

[2017-03-20 13:35:09.125 UTC] [svservice:P920:T1072] Hiding drive letter D for volume "\Device\HarddiskVolume4" (called by UpdateMountedVolume)

[2017-03-20 13:35:09.125 UTC] [svservice:P920:T1072] Hiding drive letter D in HKLM (called by UpdateMountedVolume)

You can see that it attaches a drive letter here and hides it from the explorer.

[TTC-Seth]

Question to add:

Once the installation is completed, do we remove the the reg settings and reseal/recompose or leave it?

[Ray_handels]

You leave it there. It is a setting that is being loaded every time the machine logs in and starts the Appvolumes service (svservice).

If you remove the DriveLetterSettings setting it won't work anymore. It does nothing more and nothing less that provide it with a driveletter and hide it from base image.

[TTC-Seth]

Ok, has anyone had an issue where the, previously hidden by UEM policy, Disposable disk drive letter is now visible?
I'm wondering if it's a result of this policy change.  I've verified the UEM "Hide drive letter" setting is in place but the Y drive (the letter I have) will not be hidden, now.

Any takers on that one?

[techguy129]

I'm seeing the same issue as saieesh. I'm using 2.12.1 writable volumes. No drive letter is mapped for my writable volume. Have the reg value set to 6

[2017-05-02 16:49:39.782 UTC] [svservice:P1232:T1820] Waiting for "\Device\HarddiskVolume4" to have a drive letter (waited 5 out of 5 seconds)

[2017-05-02 16:49:39.782 UTC] [svservice:P1232:T1820] UpdateMountedVolume "\Device\HarddiskVolume4" SnapvolType 1 Hide 1 Updated 1

[JMHarris]

is there any update on this? I'm having the same problem. I'm seeing the same thing in the logs too.

[techguy129]

Nothing seemed to work for me. VMware support couldn't give me an answer and pretty much gave up on me.

The workaround I am using is to create a new appstack and add the following lines to startup_postsvc.bat. I assign this to any users that use writable volumes. So far its been 100%

powershell.exe -Command "get-volume -DriveLetter E | Get-Partition | foreach{Remove-PartitionAccessPath -DiskNumber $_.DiskNumber -PartitionNumber $_.PartitionNumber -AccessPath "E:"}"

powershell.exe -Command "get-volume -FileSystemLabel "CVWritable" | Get-Partition | Set-Partition -NewDriveLetter E"

[JMHarris]

Worked perfectly!!!! Thank you for this.

Also for anyone else i hid the drive by editing the registry in the base image

HKEY_LOCAL_MACHINE –> Software –> Microsoft –> Windows –> CurrentVersion ->Explorer

Create a DWORD value and name it NoDrives

Choose the drive you want to hide and change the value to that corresponding number. also change the base to Decimal.

If you want to hide more than one drive add the values together

A: 1, B: 2, C: 4, 😧 8, E: 16, F: 32, G: 64, H: 128, I: 256, J: 512, K: 1024, L: 2048, M: 4096, N: 8192, O: 16384, P: 32768, Q: 65536, R: 131072, S: 262144, T: 524288, U: 1048576, V: 2097152, W: 4194304, X: 8388608, Y: 16777216, Z: 33554432, All: 67108863

[Ray_handels]

JMHArris, that might just be your problem then.

We found out that Appvolumes uses tghe exact same registry key to hide the specified drive you are using. It might just be that you used this key to already hide the writable volume drive letter and thus it couldn't attach the drive letter to it.

We don't hide local drives because we let Appvolumes do this for us. And we dont mind if users can actually see the C drive because they have a writable and can create files and folders there.

[jtwwt01]

Thanks for the info techguy129, that appears to solve the issue for us as well.  I just use UEM to then hide the assigned drive letter.  Thanks!

[vitalsign0]

Is this really the only solution to this? As popular as Chrome is we have to go through this to get it to work? The DriveLetterSettings value does not work with our 2.12.1 environment.

[Ray_handels]

I already replied on the other topic as well but here goes .

It has nothing to do with Appvolumes, this is an issue with Google as it will not accept a mount point as a local drive, it sees it as a network drive and thus unsafe, whatever you try to set Windows or google to.

This has been an issue with Chrome as long as I can remember and it has also been filed as a "bug" (depends on how you look at it ).

Google is not willing to change anything about it's behavior so solutions like Appvolumes (and believe me, not only Appvolumes) tries to find a workaround.

The other option is this.

I was able to get this to work with the workaround suggested. Going to http://chrome-extension-downloader.com to download the .crx, unpack the .crx, change Chrome to developer mode, then load unpacked extension and point to the folder where the crx was unpacked.  I now have Hangouts and Motorola Connect working where before I would always get the COULD_NOT_GET_TEMP_DIRECTORY message whenever trying to add extensions.  Thanks for this tip!

[vitalsign0]

Thank you for the reply. I understand Google is at fault, but VMware's recommendation doesn't work. Can't get a drive letter for the mapped drive.

I'll try the Powershell Script and your work around. Thank you.

[Ray_handels]

Strange thins is that I've heard multiple people saying this but haven't been able to reproduce it. From the moment we started using this key it works.

Do keep in mind that if there are other settings within the machine this might cause the D drive (this is what your writable will most likely use) not be to accessible. You could try and look at the svservice.log. normally it should state what driveletter is being assigned to the writable and if it doesn't work.

[Sravan_k]

Hi, if you are using VMware UEM, think about persisting user plug-ins, please let me know if you need any help on it

Regards,

Vkmr.

[Sravan_k]

Hi Techguy129,

have you tried UEM to persist your end-users chrome plug-ins? which is simple and easy if you like it