Cannot get Chrome Extensions to install or assign a drive letter to Writable Volumes.

[vitalsign0]

We are on version 2.12.1, UIA+Profile template.

Captured Chrome in an appstack, when a user logs in they are getting the error:

I have followed the instructions on updating the registry on the parent image but it isn't working. The settings are present on the desktops' registry, but there is no drive letter. I have tried 2,4, and 6 for DriveLetterSettings. VMware Knowledge Base

Help?

[mhampto]

May be a permissions for C:\Users\USERID\AppData folder. Can you create a test directory to apply the drive assignment settings to and see if they take?

[Ray_handels]

For as far as I know it's got nothing to do with permissions of folders. The problem is that it should be creating the drive letter for the writable, if it doesn't do that Chrome will see the writable asa mountpoint, thus as a network share and marks it as unsafe. That's hen you get that issue.

If you go to Disk management do you see the writable? What happens if you manually give it a drive letter? Normally it should work then.

There seem to be more people that have this issue but I haven't been able to reproduce it. For us it works quite well. It gives the writable a drive letter (in our case D) and hides it from the explorer. I am able to browse to it by simply typing in D in the explorer.

Could it be that you are using a policy to block access to the D drive? What does the svservice.log file say when attaching the writable? Normally there should be a line where it says to attach a drive letter to the writable.

[techguy129]

I called support on this issue. Their solution was to make a change to all the appstacks that are mounted using diskpart. The process is in this link: VMware Knowledge Base

For me, I couldn't get it to work using either method. My ultimate solution was to run two powershell commands to manually map the disk on logon. So far is has been extremely effective.

See this thread

App Volumes Chrome Appstack Plugins

Here is my original post:

-----------

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"

------------