VMware Horizon Community

Windows 10's start menu and applications don't work properly when using writable volumes

Hi everyone.

I'm currently trying to set up a Horizon 7 environment with instant clones using App Volumes and its Writable Volumes features to store user installed applications and profiles.

When I'm using the "uia_plus_profile" template, the start menu and some of Windows' application stops behaving correctly. Most notably starting the control panel from the start menu does not work, neither does any of the pinned applications on the start menu.

Furthermore, when you start control panel (by rightclicking on the desktop choosing "Display Settings" and then "Home"), the title is not shown properly (see attachment).

I have looked around both this and other communities, but have no success in finding anyone else with a similar issue.

My current App Volumes version is, and my VMs are running Windows 10 Professional version 1703 build 15063.483.

When disabling writable volumes Windows behaves as it should, and when using the "uia_only" template Windows starts acting better but still has some problems (i.e. not willing to launch calc.exe).

If more information is needed to help me out, just let me know.

4 Replies

Try going to powershell and running the command  Start ms-settings:

That will register the immersive control panel appx package. See if that fixes your issue. I had an issue with settings not opening and using that command fixed my issue. I added a different command in the shellstart.bat file to register the appx at login.

0 Kudos

I spent some time trying to get this working and I believe I have found the answer. I am using the UIA only writable template.

The problem as far as I can tell is due to the way the appx applications work.

I added the following to the sanpvol.cfg on my writable volume.







Now all of the Appx apps that I need get installed on login like they should (Edge, Calc, Photos) and the Start Menu works properly.


We recently stood up a new VDI environment and found that Writable Volumes created several inconsistencies.

Ignoring application-specific problems for now - since this thread is primarily about the Start Menu - I can confirm that when Writable Volumes are in play, the Start Menu on Windows 10 (v1607) doesn't consistently build.  For example:

  1. Problem 1: Missing Tiles
    1. Login to VDI A: Missing Alarms & Clock, Calculator, Weather, 3 custom tiles; 1 custom tile is present (functional) but has no icon
    2. Login to VDI B: Same
    3. Login to VDI C: Missing Alarms & Clock, Calculator, Weather, 2 custom tiles
    4. Login to VDI 😧 Perfect Start Menu
    5. Login to VDI E: Missing Alarms & Clock, 1 custom tile; 1 custom tile is present but has no icon
    6. Login to VDI A: Same
    7. Login to VDI F: Perfect Start Menu
    8. Login to VDI B: All Office tiles are present (and functional) but missing icons
    9. And so on - roulette
  2. Problem 2: Built-in tiles are not named correctly: Basically various built-in tiles will be named something like "{@Micros....".  Sometimes
  3. Problem 3: Missing Icons: On several occasions, many tiles were present but missing icons.  This frequently happened to the Office tiles as well as some custom ones

Because my team (me plus 2 others) performed fairly extensive testing in the environment as a whole, we thought it might be possible that we were bringing something over from a past bad configuration, so to be sure, we recomposed the pool and deleted our Writable Volumes so new ones would get created.   Again, the experience wasn't consistent:

  • One of us might have a perfect start menu
  • The other two would have missing icons and the icons that were missing weren't necessarily the same (e.g.: I have weather, the other doesn't; I don't have Calculator, the other does etc.)
  • After logging on/off multiple times hitting various machines in the pool, the menu would change

We recomposed & deleted Writable Volumes multiple times but the problems persisted for each of us across each machine in the pool.

To help narrow he scope of issue, we removed Writable Volumes altogether, refreshed the pool, we when we re-tested, we each had a 100% success rate across each machine in the pool.  Heck, even the application-specific problems went away lending credence to the idea that the problem is Writable Volumes.

We're still diving into the snapvol.cfg file but we don't have the following line in there:

So we may try that tomorrow and report back our findings.

0 Kudos

I can vouch for WTopping​ 's post. I've added those extra lines to the snapvol.cfg of my 2.12 template and the start menu worked again. Just a quick test this was so haven;t doen any extensive testing yet.

We are on 1703 though.

0 Kudos