With Windows 10 now into its latest edition, the 1607 “Anniversary” update, it now appears, for better or worse, to be here to stay. It has generated a lot of interest; supposedly the “last version of Windows”, many expected it to be akin to Windows 7 – an improvement following a much-maligned previous Windows version. However, the reality has turned out to be somewhat different from what many were expecting.
Microsoft are now “cloud first, mobile first”, and a lot of this new strategy shows through – sometimes somewhat cynically – in Windows 10. For my sins, I’ve been involved in a Windows 10 deployment since August of 2015, so now, just over a year in, it is maybe time to share the things I’ve learned in the hope that it may give some of you a bit of help when it comes to deploying (or not deploying!) this new version of Microsoft’s flagship operating system.
This set of articles is going to expand at the rate of one a day over the next week or so, and cover a wide range of issues for those of you deploying Windows 10 – whether it be fully virtualized via Citrix XenDesktop or the like, or simply a general physical deployment. Hopefully, it will be everything you need to know!
Don’t forget to read the first parts of this series too – EDITIONS, SERVICING BRANCHES, MODERN APPS, TELEMETRY, THE START MENU and ROAMING.
The Start Menu remains an integral part of the Windows user experience, and a real bone of contention for many users and administrators. Despite being nothing much more than anapplication launcher, it debuted with Windows 95 and, despite a brief death at the hands of Windows 8, remains to this day.
Still, many expected that after the Windows 8 debacle, that Microsoft would simply return it to the glory of its Windows 7 days. But no, there was no such backtracking from Microsoft. Instead, we were treated to the bastardized offspring of the Windows 7 Start Menu and the Windows 8.1 Start Screen, a schizophrenic mix of Windows shortcuts and Microsoft’s new baby, Start Tiles.
Windows 95
Windows XP
Windows 7
Windows 10
Now, up to Windows 7, the Start Menu was an application launcher attached to a flat filesystem, comprising entries from both the All Users area and the logged-on user’s profile. Windows 10 changes this paradigm rather heavily, bringing along a database that sits in %LOCALAPPDATA%\TileDataLayer\Database called vedatamodel.edb to control the “live” area of the Start Menu, whilst still leaning on legacy shortcuts that sit in %PROGRAMDATA%.
This database is compiled at first logon using a source XML file that sits in C:\Users\Default\AppData\Local\Microsoft\Windows\Shell called DefaultLayouts.xml. This file can be updated and changed by Microsoft, which accounts for the different application sets seen in a default Start Menu from Windows 10 RTM, compared to Windows 10 1607. Legacy desktop shortcuts are created to complement the database and populate the “All Apps” area of the Start Menu, aggregated from %PROGRAMDATA%\Microsoft\Windows\Start Menu and dropped into %APPDATA%\Microsoft\Windows\Start Menu. The legacy shortcuts behave in the same way as Windows 7, with one strange caveat – folders more than one level deep under Start Menu | Programs won’t be aggregated or displayed.
Roaming of the Start Menu under Windows 10, whether in hot-desking or non-persistent VDI environments, is a real challenge because of these changes. However, this article will merely address the provision of the Start Menu to the user, rather than dealing with the problems of roaming it. Not surprisingly, the roaming aspect will be dealt with in part #6 of this series – ROAMING.
Finally, before we start, it’s important to understand the principle of Start Menu tile Groups. See below for an example of different Groups (highlighted in the image)
Groups of Start Tiles shown, with their respective names
Now, if you simply leave the DefaultLayouts.xml in place in your image, you will get a Start Menu chock full of useless default apps and adverts, with placeholders full of Farmville and World of Tanks (or apps from whichever vendors are paying Microsoft the biggest dollars at the time). If you’ve followed my advice and culled some of the Modern Apps from the image, then leaving the DefaultLayouts.xml in place will simply give you a whole host of blank tiles, leaving things rather messy.
So what options do we have for deploying customized or clean Start Menus to our users?
Well, with my anarchic head on, if you simply delete the DefaultLayouts.xml file from the machine, you get a Start Menu that looks like this
Not the best – but free of all the advertising at least 🙂 Anyway, is there way we can handle this without adopting the anarchic approach? Well, as far as my testing has gone, you need to adopt one of three approaches:-
- 1. Apply a custom Start Menu and allow customization
- 2. Apply a custom Start Menu and don’t allow customization
- 3. Apply a custom Start Menu and allow customization except for a specific group or groups of tiles
Apply custom Start Menu and allow users to customize it themselves
To achieve this, you may be aware that you can use a bit of PowerShell to save a customization file. Log on to a machine, configure the Start Menu the way you want it, and then run the following PowerShell to export the layout to an XML file
Export-StartLayout -Path \\SERVER\SHARE\LayoutModification.xml
Naturally replacing \\SERVER\SHARE with the path to the area you wish to store your XML file in. You can put it locally if you wish.
You can then use Import-StartLayout from PowerShell to import this back into the default user profile, but personally, I find it far easier just to use a Group Policy Preference to do it. Note that when it lands on the client machine, it must be called LayoutModification.xml and exist in the same folder as DefaultLayouts.xml in order to work (that’s the C:\Users\Default\AppData\Local\Microsoft\Windows\Shell folder)
So, if you combine a custom LayoutModification.xml with the standard DefaultLayouts.xml, you end up with a custom Start Menu that the user can modify.
Just as an aside, we also used different LayoutModification.xml files for the 1511 and 1607 versions of Windows 10. We filtered the application of this Group Policy Preference by using the following WMI filters:-
Here’s a screenshot showing the results of this method (with the custom Start Menu, and the option to customize, both highlighted). When a user logs on for the first time, the custom Start Menu is applied. They can then customize it to their heart’s content and the changes will be persisted (assuming you can get the Start Menu to roam – see the next part of this series)
Apply custom Start Menu and lock it so users cannot customize
Ideal for kiosks or other locked-down environments, this method uses an XML file in conjunction with a Group Policy Object. Set up your custom Start Menu, and export it out using the following PowerShell:-
Export-StartLayout -Path \\SERVER\SHARE\StartMenuFile.xml
Note that this time we can call it anything we want – you don’t need a specific name as with the previous method (or a specific location, which is why we won’t use GPP).
Now you can simply reference this file in the GPO User Config | Admin Templates | Start Menu and Taskbar | Start Layout, from a network or local location.
Once you log in, this enforced custom Start Menu should be applied (note the word “Enforced” used in this XML file), and the user should be unable to pin new items or customize it in any way (see image)
Apply custom Start Menu and allow customization apart from a specific group
This next method of Start Menu management involves applying a custom layout, and allowing the users to customize the layout except for a specific group of tiles that must always be applied.
This is almost a combination of the preceding two methods with a little bit of XML editing thrown in for fun. Firstly, you need to log on to a machine and configure the Start Menu with the group or groups you want to be locked. Then, output them using the (now familiar) PowerShell command
Export-StartLayout -Path \\SERVER\SHARE\PartialLayout.xml
Again, this doesn’t have to be a particular name or location.
Now, open up the XML file you have outputted and do the following. You need to replace the first instance of this string
<DefaultLayoutOverride>
with this string
<DefaultLayoutOverride LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”>
In case this isn’t clear, here’s an image of the XML file before editing:-
and here’s one after editing:-
Now, to deploy this, you use exactly the same GPO as from the second method, the one that applies the fully-locked Start Menu, User Config | Admin Templates | Start Menu and Taskbar |Start Layout
However, when you apply the GPO with the modified XML file, you should see a difference in the Start Menu behaviour. The group you have locked will show with a lock icon, and cannot be modified…
…whereas other groups can be customized and have things added to them…
When a partial Start layout is applied for the first time, the new groups are added to the users’ existing Start layouts. If an app tile is in both an existing group and in a new locked group, the duplicate app tile is removed from the existing (unlocked) group.
When a partial Start layout is applied to a device that already has a GPO XML file applied, groups that were added previously are removed and the groups in the new layout are added.
If the partial Start layout is applied by Group Policy, and the policy is removed, the groups remain on the devices but become unlocked.
SUMMARY
So, when it comes to managing and provisioning the Start Menu, these are the three main methods that you should consider using for your environments. They should (hopefully!) cover every use case that you currently have. They can be deployed in many different ways, it’s a case of picking whichever works best for you. Dependent on the method you choose, you can even bake some of this into the base image for speed and ease of deployment.
I’ve come across people who have tried editing the DefaultLayouts.xml file directly, but given Microsoft’s propensity for editing and updating it, I would leave it well alone. The methods described here can be implemented without great overhead (something which we will discuss more in the PROFILES and OPTIMIZATION parts of this series).
With regard to roaming the Start Menu from device to device and maintaining user changes in non-persistent environments, this will be covered in (what will probably be a very long post, hopefully out by the end of the weekend) – part #6 of this series, ROAMING.
Share
