I am having some difficulties getting UEM to personalize Windows 1803 start menu. I have a custom layout. First time login, the layout is set properly for all users. Any subsequent logins the start menu layout is missing apps. It is the same exact apps. Removing UEM and the layout works fine. It is the organization custom layout; therefore, I must deploy it. Anyone had any luck with 1803 and higher.
Did you try below config? This works at my customer for Win10 v1809 LTSC. This is a combined config for taskbar and start menu.
<AppData>\Microsoft\Internet Explorer\Quick Launch
Some thing may be very specific for our situation. You may have to delete some items if they are not applicable for your situation.
Hmm, strange. I tested it in my lab just now and it works for me. Did you check if you indeed have a zip for the user that contains the configured settings?
Maybe other conflicting or overruling settings, GPO's, or....?
Btw, I am doing nothing special at logoff. Also, I am not stopping/starting any services.
I use a local profile in non-persistent (stateless) VDI environment.
I decided to move away from customizing the start menu and it has been the best decision ever. I set a custom Layout through GPO without any pinned apps. Users can choose to pin an app but it doesn't always come back. Installed apps work fine but not UWP. It's not that the persistence does not work. I noticed sometimes the user gets to their desktop prior to the app being available hence causing the start menu pinned item to be missing. Nevertheless, because the layout has the classic look, users do not seem to be interested in pinning anything on it. Illusion works.
Oh by the way the xml for the layout in 1803 doesn't seem to work on 1809. I am deploying both version simultaneous on two different environments.
Try this special registry key SpecialRoamingOverrideAllowed
To get around some limitations of migrating start layouts from LTSB 1607 to SAC 1809, we used a logoff script that exported the start layout as xml and then a special intermediary migration pool that enforced a start layout based on that xml (this has the desired effect of creating a new read only start menu based on the .xml). This pool is also where we are migrating from UEM (used the uem gpo to set all configs as non direct flex) to FSLogix. On the next production pool, where the start menu is no longer mandatory\gpo, the start layout becomes editable.
Between pools, which are based on different parent images, the bitness and hence path of the .exe's moves from "program files (x86)" to "program files". This change invalidates the path stored in the start layout .xml and those pinned items disappear.
That's interesting. I know of that key but since I stopped using mandatory profile I removed the GPO. I came across a new problem now with the start menu. I moved forward with my 1803 deployment. Login time is under 15 seconds with 3vCPU and 6GB of RAM. Fully deployed in production now. Will soon be running on 20,000 VDIs. I started working on my second environment which supposed to go on 1809. Different environment, different pool, different parent image, different apps. But the same UEM. Now my start menu is broken when I use it with both 1803 and 1809.I wished it was only missing the tiles. It is missing program folders, Windows Accessories, etc...Missing everything :smileyconfused:
Hi cbaptiste. I have been experiencing the same problem and came up with a fix for our environment. This may work for you it may not.
So the first thing that I did was go into the registry on our golden image and change the following service keys' "Start" DWORD value data to 4:
These services seemed to be causing the system to hang on to the cloudstore.dat, cloudstore.dat.log1, and cloudstore.dat.log2 during logout and if those files don't get pulled over by UEM on logoff, then a user will not have anything on their start menu when they log back in. While I was able to start persisting the start menu including programs, accessories, and user pinned start menu tiles, after a certain amount of logoffs i would start losing my start menu every other login. So what I found were a couple of things.
If you are using the following VMware provided templates: Start Menu, Taskbar, and Windows Explorer, there is one duplicated registry tree and one duplicated registry value that are being pulled for multiple config file. So that you can see the values that are a part of the VMware provided template, you must highlight the Template, click on Manage, and then click on expand. You will get the pop up box letting you know that the template's built in definitions and this is okay. The items that I adjusted are as follows:
This is located in both the VMware provided Taskbar and Windows Explorer Config templates. I commented them out in one of the locations. It doesn't matter which one.
This is located in both the VMware provided Taskbar and Start Menu Config templates. I commented them out in one of the locations. It doesn't matter which one.
If you are using the Windows Explorer template config provided by VMware, try adding the following to exclude the key that tends to cause the Start Menu to fail to show anything every other time.
Now my start menu will load every single time. Please let me know if you have any questions or have any ideas to add to what I already put down. I battled this for a couple of weeks so I understand your frustrations. Thanks!
PS - I created my image by following the guide from VMware on creating an optimized Windows Image with a few minor adjustments specific to our environment. I also used mandatory profiles.