Dynamic Start Menu on Server 2016/2019 and Windows 10

Let’s sort the Start Menu out…and find a nice, secure, simple way of managing it.

The Start Menu in Windows used to be a user-customizable area of the filesystem, but ever since Windows 8, new functionality has been added here that has made it much more tricky to manage. How can we manage it so that it updates dynamically based on user entitlements so that we have security and flexibility, but also is easy to manage and doesn’t require a lot of updating?

History

The Start Menu has always been a combination of filesystem shortcuts that were applied to the user (from %APPDATA%\Microsoft\Windows\Start Menu) and the device (common start menu items were stored in an area that now maps to %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu). However, as operating systems moved on this became less a pure filesystem and was supported more by other items in the interface. Up to Windows 7/2008 R2, these additional features were quite simple and could be manipulated by Group Policies, Registry items and special folders – but with Windows 8 and upwards, we were introduced to wonderful things like the Start Tiles, Start Screen, UWP apps, WinX menus and many others that have made our management of this area of the UI much harder.

Before we start and dive in, let’s be clear what we are talking about here – we’re not referring to the Start Tiles (which are shown below)

but the actual Start Menu (shown here)

I’ve always been a fan of building a dynamic Start Menu when the user logs in based around their entitlements. Many have traditionally used the Citrix Receiver/Workspace app to do this, but a) you may not be in a Citrix environment, or b) using the Workspace App in this way often feels clunky, drawn-out and messy – you’ve got to wait for the app to launch and kick in, at which point it then injects its own shortcuts into a pre-existing Start Menu. I prefer, where possible, to get the user’s entire Start Menu built during the logon process, so it’s ready to go as soon as the logon completes.

Under Windows 7/2008 R2 I used to do this by redirecting the Start Menu to a local folder that was mirrored from a network share, and contained NTFS-restricted shortcuts that the user could only access based on their AD security groups. The theory was, they would have their entire Start Menu redirected to this folder and the NTFS ACLs would allow it to only contain application shortcuts their group membership entitled them to. This worked pretty well, but on the latest versions of Windows it doesn’t behave well, mainly due to new ACLs and the way the Start Menu is generated (see below). It can also be pretty intensive to maintain this. Ideally, as already stated earlier, we want something that’s pretty simple and straightforward to create, manage and maintain.

Windows 8 and 8.1 introduced the “Start Screen” that I spent a long time trying to figure out the intricacies of (with some interesting results – here are some examples of it) – but seeing as though Microsoft dialed that paradigm back, let’s just leave it where it was.

Windows 10/2016/2019 Start Menus

The later versions of the Start Menu introduce some oddities:-

They are created from the same two areas, %APPDATA\Microsoft\Windows\Start Menu and %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu and aggregated together. UWP apps are added from the provisioned user profile areas as well.

However, folders under \Programs are never aggregated more than one level deep, unlike earlier versions where you could nest very long folder structures and which were replicated exactly in the Start Menu. Shortcuts in these folders, though, will be aggregated and presented on the Start Menu – under certain conditions.

Only shortcuts in the root or in the first subfolder will appear on the Start Menu. Anything in second or subsequent subfolders will appear in the first subfolder instead. Also, duplicate shortcut targets (so, for instance a shortcut called “ASSCLOWN” which pointed to notepad.exe) will not appear on the Start Menu, because there is already a shortcut that points to notepad.exe in there.

Some examples:-

• If you had a folder under either Start Menu path called \Programs\Test\Test1\Test2 and placed a shortcut there, it would appear under \Programs\Test on the Start Menu – as long as it was a unique shortcut target.
• If you placed a shortcut pointing to Notepad.exe anywhere on the Start Menu (even with a different name), it would not appear, because there is (normally) already a shortcut to Notepad.exe in \Programs\Windows Accessories.
• Empty folders are generally ignored
• Folders and shortcuts from the root of the \Start Menu folder OR the Start Menu\Programs folder will be aggregated into the root of the Start Menu. So a folder called \Start Menu\Programs\Test will appear on the Start Menu in the same way as if there was a folder called \Start Menu\Test

UWP apps are not enumerated from these areas – they appear based on what has been provisioned into the user’s profile at first logon.

Shortcuts are usually added on-the-fly to the user’s Start Menu (so if you create a new folder with shortcuts in while the user is logged in, they will appear), whereas removing is sometimes a bit more hit-and-miss – sometimes they will disappear on the fly, other times they may appear as blank or inaccessible icons until the user logs out and back in.

Fellow CTP James Kindon has done some good posts on the Start Menu behaviour too – see here and here for some of them.

All of this comes together to make the Windows 10/Server 2016 Start Menu a little more tricky to manage!

Management

In the past, we’ve done some very clever work in creating dynamic Start Menus. However, I feel that in this day and age, simplicity is key. What we want is a way to create a Start Menu for the user when they log in based around their group memberships – so that they only see what they are allowed to see.

As I’ve said before I think using the Citrix Workspace App to populate the Start Menu, whilst popular, has too much of an overhead in terms of delay and reliability. I’ve seen Citrix environments where the user logs in and then has to wait as the Workspace App populates the Start Menu – often as the user is trying to use it! This feels haphazard and clunky. If you were using a published desktop and then offering Citrix-based shortcuts on other remote servers, then this would be a good way to do those particular shortcuts, but as most published desktops I see often have all of the required applications already installed, then it’s not something I’m keen to embrace except for niche requirements. Of course, there’s always the possibility that you’re not using Citrix at all so this wouldn’t be an option anyway.

My currently preferred method is to use FSLogix App Masking to handle this. App Masking behaves in a similar way to the old “NTFS-tiedown” method we used back on Windows 7 and 2008 R2, but it is a much more straightforward method to maintain.

What I do is try to restrict the “feeder” areas of the Start Menu (and Desktop, for that matter) to one location. Ideally, all the shortcuts that are enumerated should be from one area only – and the easiest one to use is %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu. Within this area, App Masking controls access to the shortcuts and/or shortcut folders by Active Directory group.

So there are a number of things I make sure to configure to allow this:-

• The default profile contains *no* shortcuts under c:\users\Default\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
• The c:\users\Public\Desktop folder is cleared of all shortcuts and kept clear (usually by a GPP or script that runs at boot)
• Ensure that when applications are installed, deployed or packaged, the only place that a shortcut is dropped is into %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu
• App Masking rules are configured to allow each folder or shortcut within the %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu folder to be accessed by specific AD security groups (this also includes restricting the filesystem and Registry entries for each application if you want to be fully secure)
• If you’re restricting App-V applications using FSLogix App Masking, you also need to allow the Windows process c:\windows\system32\appvclient.exe to the Rule Assignments
• Any profile management tool in use (FSLogix Profile Containers, Citrix UPM, Ivanti UWM, etc.) needs to be configured to *discard* the %APPDATA%\Microsoft\Windows\Start Menu folder. If you’re not using a profile management tool and the profile is being persisted, then you can configure a logoff action to clear this folder which will have much the same effect

The idea is, when a user logs in, their AD group memberships are read and the only shortcuts they can see are ones they are allowed access to. The Start Menu is built from these “allowed” shortcuts. When the user logs out again, the user-specific Start Menu items are discarded and therefore they cannot be persisted into another session. If the user’s group memberships change, then the next time they log in the Start Menu is created based around their new entitlements, and either adds (or removes) shortcuts that they now have access to (or don’t have access to).

It’s much easier for me to demonstrate this via a video than by step-by-step instructions, so here is precisely that 🙂

The video does mention one flaw in this, which is that if a user pins an application to the Start Tiles or Taskbar, and then has their entitlement to that application removed, they will then have a blank icon showing. I thought of many (very complex) ways of mitigating this, but then I simply thought – how much of an issue is this, really? It’s not likely to be a particularly common occurrence, and even if it does happen, all the user has to do is right-click the “dead” icon and choose Remove. If you really wanted to avoid this, you could use a locked Start Tiles layout and prevent users pinning to the Taskbar, but I don’t see that it’s really that burning an issue that you’d need to restrict the users’ ability to customize their own environment.

Summary

So, in my humble opinion, the current best way to deliver a dynamic Start Menu to your users is by using FSLogix App Masking. Essentially, we are masking the entire application and not just the Start Menu entry points, but the net effect is the same. Each time a user logs in, the Start Menu is composed not from multiple areas, but the single %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu area, and the shortcuts presented are precisely what they are entitled to because of the FSLogix controls. There is a slight overhead as you need to create rules for each application that is provisioned, but this is something that could very easily be added to a process or even automated.

I like to combine the FSLogix method with the awesome App-V Scheduler to give myself a really agile, scalable, simple deployment platform, but we will have more on that in another post. For now, if you want to manage your users’ Start Menus in the easiest possible way and maintain security controls, this is the best way to do it.

Probably worth a final mention about PolicyPak which has a feature called Start Screen Manager which gives you similar capabilities with a lot more granularity – https://www.policypak.com/products/start-screen-taskbar-manager.html – and allows you to target it more effectively and take into account UWP apps and the like. So if you want extra functionality (obviously for a price), this would be a good option to consider.