App Volumes 2.7 Writable Volumes - Behavior in Windows 8.1

[solgaeDK]

Hello,

I've been evaluating App Volumes 2.7 on a Windows 8.1 VDI environment, seeing that the release notes now indicate that the agent installed in Windows 8.1 is now supported. The AppStack works great with Windows 8.1 desktops, but I'm having issues with Writable Volumes, with or without in conjunction with Appstack(s). I am testing with Horizon View 6.0.1 with floating non-persistent desktop pool that refreshes on logoff.

So far, I tested with profile_only template and uia_plus_profile template, and noted some issues:

profile_only - Worst case scenario. Start screen pinned apps, especially the Modern UI apps, are broken, showing names like App, AppexMaps, AppexNews instead of the real name, and none of the shortcut works. Also, often times, the desktop shortcuts located on C:\Users\Public\Public Desktop that were captured as part of the AppStack doesn't show up at all. When it does show up, however, this is when absolutely nothing works. Shortcuts become broken and double-clicking has no effect. I can't launch anything, even when using Run command to launch explorer.exe and such, and I couldn't even issue a logoff command. Basically, I get a dead desktop.

uia_plus_profile - Better, but still not working correctly. New profile creation process gets triggered every time. This means user will see the "Hi, We're setting things up for you" animation every time (since it is non-persistent), or "Preparing desktop..." message if you disabled the first-time animation via GPO. Also, not all user settings seem to be preserved - Office 2013 thinks it's launching the first time and shows the welcome window when launched, for instance. The start screen problem still exists here as well.

Anyone else having this issue with Writable Volumes under Windows 8.1?

Thanks,

[Ray_handels]

I have not tested with 8.1 yet but the issue you seem to have with the writable volume seem to be that the machine is not being refreshed after it has been used.

Profile only is what it says it is, your user profile only. What happens with the writable volume is that the filter driver records all changes made to the machine and writes it to the writable volume if it isn included in the snapvol.cfg file.

Looking at the profile only it only records changes to the c:\Users\<Username> folder and registry keys related to it.

Regarding the UIA + Profile writable volume. As said. When using this please make sure that your golden image doesn't have a profile folder of a user you log in with that has a writable volume (we use a local configured account to change settings to the golden image and never ever use a domain account) and make sure to refresh the machine after logoff of the user. Otherwise our writable volumes will get filled up with needles crap.

[solgaeDK]

As I stated in the thread, I am using a non-persistent desktop pool that refreshes on logoff. Our gold image is not domain-joined, and the C:\Users folder doesn't have any profiles other than the local admin account, Default, and Public.

I've done some further testing, and observed the following:

1. Any settings that are saved in C:\Users\%username%\AppData folder does gets saved and persist via Writable volumes - it happens on both profile-only and profile+UIA templates. So Applications that save their settings on AppData folder such as Notepad++, Firefox, and Chrome will persist the user settings. However, any applications that save their settings in the user registry hive (HKCU registry tree) will not persist - again, on both profile-only and profile+UIA. So applications like Outlook, PuTTY, and WinSCP, and Windows Explorer/desktop appearance settings will not persist since they store their settings on HKCU registry hive. This also explains why Active Setup doesn't seem to persist as it records the changes on the user registry.

2. Profile-only template seems to be set to virtualize the entire C:\Users folder portion according to the snapvol.cfg within the template itself. Unfortunately, it looks like it also tries to virtualize other user profiles such as Default and Public, which shouldn't be virtualized as they are admin-only profiles. And since writable volumes always have the highest priority over appstacks, it seems to counteract with Appstacks that create shortcuts in C:\Users\Public\Public Desktops, so the shortcuts in the public desktop doesn't show up.

3. Acrobat Reader DC seems to be completely broken when writable volumes are used - when I launch it, it terminates almost immediately with "memory could not be read" error. (exception code 0xc0000005). Acrobat reader is installed on the gold image itself.

4. Chrome is also broken since version 43 when writable volumes are used. Trying to launch it via the shortcut does nothing, and running the executable gives a SidebySide incorrect error. Chrome is installed on the gold image itself, and I'm using the All Users install version (i.e. one that installs on the Program Files folder and not on the User's AppData\Roaming folder)

Seems like the Writable Volumes isn't capturing the registry settings properly. Is it a bug that needs a patch, or something that can be fixed manually by editing the snapvol.cfg?

EDIT: Seems like when I was updating AppStack, Acrobat Reader and Chrome decided to update itself, causing a conflict when I updated the gold image. So I had to re-capture the appstack with background update processes disabled. Both Acrobat and Chrome is now working properly. The issue in #1 and #2 still persist, though.

[solgaeDK]

I just tested it with Windows 7 SP1 64-bit image, and the results are the same. It seems Writable Volumes in 2.7, as it stands, isn't working properly.

[jrp1]

I'm noticing the same issue with 2.7 on a Windows 7 64-bit VM.  Basic customization like pinned icons, themes and desktop wallpaper aren't preserved into the writable volume.  A custom theme I made was preserved but not applied on login to a new desktop.  I haven't used this product for a while (it was CloudVolumes then) and previously it seemed to preserve all user settings.  I'm hoping there's a fix for this too.

[solgaeDK]

Makes sense since pinned icons and theme selection are stored in the user registry hive, while the theme itself is stored as a file in the user profile. While pinned icon's files themselves are stored in the user profile (AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar), there is an accompanying registry entries that must be set (all keys under HKCU\Software\Microsoft\Windows\Current Version\Explorer\Taskband) which stores the location of the pinned icon and such.

Currently, the biggest issue is Writable Volumes in 2.7 fails to capture any user registry hive settings at all when it should be based on the demo I've seen.

Looking at the writable volumes, I'm noticing that NTUSER.DAT file and couple other files like .LOG1 and .LOG2 files are entirely missing on the ones that were created using profile-only template.

For the ones created from profile+UIA template, the aforementioned files are present, but it still fails to save any registry changes.

[solgaeDK]

Update - I've been in contact with VMware support, and they suggested rolling back the app volumes agent component to 2.6. I did that, and writable volumes is now working as expected - the registry settings are now being captured and applied between logins - both profile-only and profile+UIA templates. Nothing else has been altered - manager server and appstack/writable templates are still using 2.7.

Seems like something is broken between Agent 2.6 and 2.7. Not sure if it's a code difference or config difference.

For those who want to try it, just keep in mind that App Volumes Agent 2.6 is not certified with Windows 8.1. So far, though, it seems to work correctly with both AppStacks and Writable Volumes assigned.

[sappomannoz]

Hi solgaeDK,

thanks to you for sharing this. Are you capturing AppStacks with the 2.6 or 2.7 agent? I'm also using 8.1 + AppVolumes, with mixed results. BTW do you have similar issues like in Re: App Volumes 2.7 - Windows 8.1 - Start menu

Regards

Cristiano

[solgaeDK]

I had AppStacks captured while running the Agent 2.7. Appstacks are working without issues in 2.7.

[solgaeDK]

To answer to your start menu question, I do see the start screen -> All Apps menu not updating automatically when the AppStack is attached immediately when the user is already logged in. Restarting the explorer service seems to refresh the start menu, but I always try and put the shortcut to the Public Desktop folder for the Apps that doesn't create one. You can also add a shortcut to the C:\ProgramData\Microsoft\Windows\Start Menu\Programs so it will show up in the Apps section of the start screen -> All Apps menu.

Now if only Microsoft had a way to make the start screen change-able to all users......

[jrp1]

I've done the exact same thing.  The 2.6 agent is working as expected while App Stacks and the Manager remain on 2.7.  I was going to avoid an agent rollback but after I saw your post I went for it and it worked.

[Ray_handels]

Just as a sidenote so everyone knows. It wont work either with the 2.9 Agent.

I've tested with 2.9 manager, 2.9 templates (which are almost exactly the same as the 2.6 ones, so not that many changes there) and the 2.6 agent and that's the only way i get it to work (tested in W7 thought, exactly the same issue)

My guess is they changed the Appvolumes filter driver so it won't pick up those changes anymore. I guess it has to do with the new way they are moving that they don't want to have the profile in the writable volume anymore. So you either are forced to use an old agent (no idea how long they will support this) or be forced to move to other profile management tools like FlexProfiles. This feels like FlexProfiles is being shoved down our throats.

[solgaeDK]

Can confirm the same problem still exists in 2.9.

[Ray_handels]

I did some more testing with multiple agent versions.

When i log in with a 2.6 agent version (all other stuff at 2.9 so manager and template) all changes are recorded. Logged in and out a few times and al settings are still there.

When i then update the golden image with the 2.9 agent and log in, all settings are gone. Files saved in the LOCALAPPDATA folder are there. Writable volume was still the same.

So my guess is that you were spot on solgaeDK with the ntuser.dat. I do believe this file is saved in the writable volume but the filter driver (svdriver.exe) just doesn't process the information. Normally it should merge the snapvol.dat file and the ntuser.dat file of the user logging in into the registry. It seems that they actually removed it (deliberately or not).

I have no idea if they will actually fix this (see other posts regarding change in writable volume) so it seems we are stuck with 2.6 agent for know.

[solgaeDK]

That was one improvement in 2.9 - I looked at the writable volumes created from profile-only template, and did found that ntuser.dat file (along with other essential HKCU registry files) is being captured. Previously in 2.7, the profile-only template won't capture those files.

That said, the agent still fails to apply the HKCU registry changes between logons.

[solgaeDK]

I got the solution from support - adding the REG_DWORD key VolDelayLoadTime with value 0 in HKLM\SYSTEM\CurrentControlSet\services\svservice\parameters will resolve the problem in App Volumes 2.9.

Run the command below in your master image, and then recompose it to have it applied on all the desktops:

reg.exe add HKLM\SYSTEM\CurrentControlSet\services\svservice\parameters /t REG_DWORD /v VolDelayLoadTime /d 0 /f

I confirmed the fix above will work with profile+UIA and profile-only templates. A patch is supposedly coming, but no idea on the timeline.

[Ray_handels]

Thanks solgae for testing. I will try and test it tomorrow also..

But as you said and confirmed, it does do the trick.. Luckily we are able to go to Appvolumes 2.9 agent..

[jrp1]

Thanks for saving me a call.  It does look like writable volumes will be killed off and replaced by FlexProfiles based on the post on the EUC blog.  There are advantages to FlexProfiles but writable volumes are much simpler to roll out.  I'd rather see VMware make the two work together instead of phasing out one, especially since writable volumes are the only solution in a non-persistent environment to capture user installed applications.  I've been working with UEM for the last couple of days and it's much more time consuming to build configuration files for every single application and then test each one.  At least AppStacks are still a thing!

[Ray_handels]

Thanks for saving me a call.  It does look like writable volumes will be killed off and replaced by FlexProfiles based on http://blogs.vmware.com/euc/2015/06/app-volumes-2-9-now-available.htmlthe post on the EUC blog.  There are advantages to FlexProfiles but writable volumes are much simpler to roll out.  I'd rather see VMware make the two work together instead of phasing out one, especially since writable volumes are the only solution in a non-persistent environment to capture user installed applications.  I've been working with UEM for the last couple of days and it's much more time consuming to build configuration files for every single application and then test each one.  At least AppStacks are still a thing!

This, a 1000 times this..

I still hope that they will eventually change their vision about it and let the two work together.

As said in my other post this is a half assed solution with a tool not doing what we want it to do changing a solution that works 100% (or at least near 100%).

I would say please post it as much as possible i really really really (enough really?? ) hope VMWare listens to their customers instead of just going about trying to force us into something we are not waiting for. Mix it all up (writable volume + flexprofiles) and my guess is you have the perfect setup for a multitude of companies wanting best of both worlds.. Even more so now that AppVolumes is supported on physical machines..

But the badest solution made is plain old removing the possibilities of a writable volume with profile.