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.

The Windows 7 Start Menu

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.

The abomination of Windows 8

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.

16 comments

  1. I always used ABE for windows XP and higher machines to build up a startmenu on plain terminal servers (2003/2008) (no citrix on top) or on windows XP/Win 7 machines.

    1. Yep, that’s the method I used to use and I found it great. However the ACLs have gotten a lot more tricky to configure in later versions.

  2. Thanks for this.
    I’m currently building a new environment as part of upgrading our Office version in Citrix, so starting to use and test WEM and FSLogix. We are still on Server 2012 R2 though but it looks like we can still use this method as we also use Classic Start Menu so we don’t have to use the horrible Start Screen.

    Any reason why Public Desktop is kept clear. We have some app icons on the Desktop for all users too so surely we can use the same method on this location as the start menu?

    With regards to the dead icons in the taskbar… as we have situation where users could move between ThinClients that are either licensed or not licensed for Office, there can be situations where their Office taskbar icons end up as dead icons. Now you can’t use a hide rule on those pinned taskbar lnk files because of the info in the registry and still ending up with a dead icon, but you can use a redirect rule instead. So basically I would have a redirect rule like this: –
    Source:
    C:\Users\*\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Word 2016.lnk
    Destination:
    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories\Wordpad.lnk

    So when a user is on a licensed machine, they get Word 2016, but on an unlicensed machine it launches Wordpad instead.
    You could obviously redirect to anything, so it could be to a lnk file that just launches a message box informing the user that the machine they are on is not licensed for Office for example.

    1. That’s an interesting method for the dead icons, I like it….although it feels like it could get a bit busy if you have machines/images with multiple application sets.

      I keep the Public desktop clear just because it’s somewhere else to manage. You can achieve much the same thing with GPP and make it more flexible for the users. YMMV

  3. James,
    How do I remove Win10 apps like Calculator, Alarm, Camera, etc.? I don’t see them in FSLogix Apps RuleEditor as an installed program. For example, with Calculator, when I choose “Enter Program Files Path” option, I cannot see the Calc.exe file.

    Thanks.

    1. UWP apps are installed per-user rather than on a machine basis, so they’re a bit tricky to do with FSLogix. With UWP apps, I generally remove the ones I don’t want users to have from the image by using Remove-AppXProvisionedPackage. If I wanted to do calculator for certain users I’d be tempted to install OldCalc and remove the UWP version, so it could be done in the “traditional” way. If you *really* wanted to do it via FSLogix you’d need to look under %LOCALAPPDATA%\Packages or c:\windows\systemapps, but be prepared for some fun with permissions. See this article for more details https://james-rankin.com/articles/how-to-remove-uwp-apps-on-windows-10-v1803/

  4. Great article, thanks again.

    I did have the white/orphaned icon problem under pinned icons even using WEM latest versions and don’t like it. Still some ground to cover there unfortunately.

  5. Hi

    On Windows Server 2019 I notice that some application and folders are still generated. I see that they have the location c:\users\%username\appdata\Roaming\Microsoft\Windows\Start Menu\Programs.
    Folder: Accessoiries – Startup – Windows Administrative Tools
    Files (links): Microsoft Edge, Microsoft Teams

    For the moment I have no idea where they come from.
    I followed your article and cleared the default location.

    So if you have any tips, it could be helpful.
    Thanks.

    I cleared the start menu in de default profile.

    1. There are Registry entries for the likes of Edge and Teams that generate shortcuts when they are set.

  6. Good article, slowly working my way through them.
    How do you handle Shortcuts for the different Web applications, for instance use Chrome to launch. we have a few of these and like to hide them if the user doesn’t need them

    We have Ivanti as well as FS Logix so not sure best way as we use FSLogix to hide Apps installed on the base image,

    1. If you’re just talking about hiding the shortcuts deployed to the users, you can use the same method – hide the shortcuts with FSLogix rules. However, if the user types the address into the browser or saves a Favourite/Bookmark, then that’s a bit trickier. The bookmarks you could maybe do but address entry is difficult to block without perimeter rules.

    1. Not that I’ve noticed. There may be slight impact to the “TTOE” – the time it takes to have everything “ready” for the user – but only if you have a large amount of items to be processed.

  7. Hey James,

    Great article! I am dealing with preparing a RDS 2016 server farm for rolling out applications for my users. Currently have FSLogix Profile Containers and working well so far. Now trying to deal with cleaning up the Menu system (Start, Tiles, WinX) to make it more appropriate for our users as well as administratively as easy and elegant as possible!

    Just a quick question regarding a statement in your post:

    “…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.”

    Do you mean to use the redirections.xml to exclude the above folder structure? I was a bit confused by your use of *discard*.

    Thanks, and thanks for such great articles!

    – Joe

Leave a Reply to Roland van der Kruk Cancel reply

Your email address will not be published. Required fields are marked *