Hi all,
I think it is time for me to rant a little about how Microsoft is dealing with the Start Menu management currently. Keep in mind that I work with their products every day and I still love a lot of what they did with Windows 10 from a design standpoint. Microsoft is providing tons and tons of documentation about Start Menu and some about Taskbar customization – and its really good. I got a working XML file in less than 2 hours. I remember the first time I tried it took me a little while to understand that I if I want to change the Taskbar as well I need to modify the XML myself. (Really now Microsoft? That should just be an additional trigger with the Export-Startlayout cmdlet…).
That unfortunately doesn’t change the fact, that from an administrative perspective managing the Start Menu is a nightmare. Please read the sites provided above before continuing here. In this blog I will not reiterate what Microsoft already provided in regards to creating the files needed to manage the Start Menu or Taskbar. This is more of a deep dive into what is actually happening behind the scenes. Some of the issues described below also apply to roaming profiles and therefore cover some Citrix scenarios as well. (Spoiler: Roaming Profiles don’t work with Start Menu customization [yet])
What’s the goal for most customers?
- Customers don’t want to lock in the Start Menu completely, except for certain machine types like kiosks. We can easily use a GPO for that.
- Customers want to provide a good OOBE, where the user is able to refine the Start Menu later on to their own taste.
- Even a partially locked down menu isn’t enough for most, but it’s a start
- Customers want to be able to change the menu later down the line if new tools get added or removed
Especially the last point is crucial. Let me explain what I usually do and why that’s a problem:
- Customize a customers machine to my needs (Start Menu and Taskbar)
- Use the cmdlet Export-Startlayout to get my XML File. Add the Taskbar modifications manually (*sigh*)
- Use Import-Startlayout during OSD. Apply the same via a management solution (SCCM, Matrix42 […])
Lets start digging
Seems simple right? Of course there’s a catch. Lets look at what Import-Startlayout does. I fire up Procmon apply some filters and run the command.
Ok, we now have a LayoutModification.xml in the default user, buuuuuutt… uhhh… that means this file only gets copied while a user profile is created for the first time. Lets verify that. By the way, its neat to see that the date on the file is the same as the date on the XML File you exported.
Ok, so the file does get copied over the the local storage of the user. If I now import another XML…
Sooo what if I reboot the machine now and login again?
So there’s our first issue with this method.
We cannot modify the LayoutModifications.xml if we use Import-Startlayout after the user profile has been created.
“So what? Just copy the LayoutModification.xml from the default user to the current user and be done with it” I hear you say. Nay I say – let me show you why.
So how does Windows exactly save the changes done by the user? It isn’t the LayoutModification.xml for sure, since that was what the default user provided and is holy to the profile. Lets start Procmon once more and change the menu around a bit.
Ouch. So you’re telling me everything the user does is saved into two different Databases which we cannot edit? Sweet. Dead. End. The edb.log in Cortana seems to save the structure of the menu while the TileDataLayer\Database\EDB.log saves the tiles the user changed. The information is then most likely merged with the DefaultLayouts.xml and LayoutModification.xml to create the menu – every time the menu is opened mind you. These Databases are merged in last. So we arrive at our second issue:
User changes are saved in two different EDB.log, which are unmodifiable Databases.
I tried copying the LayoutModification.xml – it will still use what is in those databases. The XML Files aren’t touched after profile creation is finished. As soon as I delete the profile and login in again the menu resembles the new layout. Which means:
We cannot modify the Start Menu or Taskbar if we use the Import-Startlayout method after the user profile has been created.
This description might also explain why roaming profiles are not currently supported. All of the files we talked about here are stored in AppData\Local which explicitly does not fall into the “Roaming Profile” (that would be AppData\ROAMING *duh*). Of course Citrix can’t support it if even Microsoft doesn’t offer a solution for this.
“So what about a GPO with a partially locked Start Menu and Taskbar” – glad you asked. If you apply the policy (which is a user setting btw. [WHY Microsoft…]) in “User Configuration\Administrative Templates\Start Menu and Taskbar\Start Layout” it looks like this
The “Bug Recorder” was pinned by me while the little lock should give away the settings that come down from the policy. I cannot change these at all. Fun fact: If you uninstall Office the Start Menu layout follows by removing those tiles (*phew*). It works the other way around as well. If I were to install the Adobe Reader the missing tile would be filled. So what about our XML Files? They play no part in this. They’re not even touched while applying the policy (no, not even with /force). User changes are again done in the edb.log below AppData\Local. If I change the target XML in the policy, apply it and logout and login again the new menu gets applied. User settings will only be overwritten if we change from a partial lock down to a full lock down. So we get this:
If a partial lockdown is enough use a policy! This way you can change the Start Menu and Taskbar easily even after the user profile has been created!
I tried finding what exactly is changed while applying the policy but I couldn’t find anything exciting except this:
Well, that doesn’t help a lot. There are some changes below HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\ but I can’t reproduce what it is doing. Plus I don’t like fiddling with the registry unless I really REALLY have to.
Conclusion:
While I’m OK with the fact that there’s no way to modify the Start Menu easily [looking at you here Microsoft] at least provide the administrators decent tools to modify what is needed. If you use Import-StartLayout during OSD everything is fine. But managing the Layout after the user profile has been created becomes impossible. I can’t even use the policy to apply a new menu once (as in “apply once and do not reapply”), since the changes will revert to the local files if the policy is not applied anymore. There’s no way to really give the user AND the administrator more control here. Why not just add an option into the computer policy like “Apply Start Layout to all users”? Or “Use this Start Layout as a template”? Or “Merge this Start Layout with local settings” together with “Merge this Start Layout with user settings”? Every bit of data is saved in a way that those settings would be possible.
That’s it for today. You’re welcome to send me a mail for further investigations and additional info on this topic.