- Consolidating Group Policy, part 3: Loopback policy processing and folder redirection - Wed, Aug 25 2021
- Consolidating Group Policy, part 2: GPOZaurr - Thu, Aug 19 2021
- Consolidating Group Policy, part 1: Get-GpoReport and Advanced Group Policy Management (AGMC) - Wed, Aug 18 2021
Edge, being a browser (and what’s more, a new, standards-compliant, lightweight browser), is of specific interest to users, admins, and developers alike. However, users also have expectations of the behavior of their browsers, and given that we operate in an environment in which users frequently use different machines, the persistence of user settings such as typed URL history is one of these expectations. Modern Apps, by their very nature, struggle slightly to meet this expectation.
Edge and roaming profiles ^
As the settings are stored in %LOCALAPPDATA%\Packages, a roaming profile is of no use. Roaming profiles can have exclusions configured for them but not inclusions. So if a roaming profile is used, Edge data are not maintained.
Microsoft itself recommends using UE-V or the Edge feature “Sync my settings.” However, both of these are specifically limited as to what data they actually retain, and an administrator cannot customize this in any way. Sync my settings also requires a Microsoft account to be used, which may not be acceptable in many domain enterprise environments.
Profile management tools like AppSense, RES, and Citrix UPM, etc. also have problems hooking the settings for Modern Apps because they are not yet capable of natively detecting the Modern Apps processes.
Essentially, to persist the user settings users for Edge usually requires running logon and logoff scripts to copy file and registry settings out to a home drive share and then bringing them back in at the next logon. This can be achieved with Group Policy scripts or a user environment management (UEM) solution such as AppSense or RES. The irony is that “Modern” Apps require a legacy approach like logon/logoff scripts to accommodate functions that the user has come to expect.
Edge and Group Policy ^
It is also incredibly difficult to set policy settings for users within Edge, such as the default search provider. Most people in enterprise are keen to have Google as their default search provider, and Internet Explorer’s coming with a built-in default set of search providers enabled Google to be set as the default with a simple policy to enable specific registry values.
Edge, though, uses OpenSearch (as do Chrome and Firefox), meaning that to set a search provider, the page must first be visited. For Chrome and Firefox, though, their default search provider is already Google, but with Edge, unsurprisingly, the default is set to Bing.
I thought it might be possible to get around this issue by setting the user’s home page to Google via GPO, automatically “visiting” the page at application launch and then capturing and persisting the associated registry values. However, the registry value that Edge sets appears to be created with some device-specific variables, making it impossible to roam. You can see the protected nature of the registry value that controls the search provider by looking at its name:
So if an administrator tries to set the registry value by capturing it with the intention of setting the default search provider to Google for new sessions, the application thinks the provider is “corrupted” and resets it straight back to Bing again after presenting this error message: Microsoft Edge reset your default search provider because the default search provider setting was corrupt.
The upshot of this is that when users move sessions between devices, they will have to reset their search provider manually.
There are GPOs for management of Edge, but some of them are more preferences than policies. For instance, the GPO that deals with setting corporate home pages for Edge has this text in the description of the policy: “Your employees can change this setting.” This essentially makes it not a policy at all.
Furthermore, all of the Edge settings (again, like setting home pages) are defined as computer objects rather than user ones. This is something of an oddity but fits with Microsoft’s current stance—for instance, it has done the same thing (moving the settings to the computer) with user-based settings like file type associations (FTAs).
Microsoft’s response is that this is done for security (so that even administrators get the same homepage delivered initially) and that the user can only define and manage the homepage via the API. This is a strange approach, given that some enterprises like to configure specific intranet home pages for users from different business areas and/or provide a uniform desktop experience in line with corporate policies. But it is consistent in that Microsoft has applied this device-centric attitude to GPOs in several parts of the operating system now.
Modern Apps represent a paradigm change, and enterprises looking at Windows 10/Server 2016 RDSH need to consider this very carefully. Adoption is currently slow, but Microsoft is shifting more applications into this delivery mechanism, with OneNote and Skype being two of the more pertinent.
Project Centennial will be a big indicator of whether Modern Apps will take off. This is the codename for the way in which legacy App-V packaged applications can be converted directly into Modern Apps and published through the Windows Store for Business. For enterprises with large App-V deployments, this could be the perfect way for them to migrate to Windows 10 and may well kick-start further developer interest in Modern Apps.
Subscribe to 4sysops newsletter!
For now, most enterprises simply want to keep the door open to Modern Apps, as they are primarily concerned with delivering the applications from their “legacy” desktop app estates. In the end, any changes will have to be for the better—and make the user experience better too. If they don’t, then Modern Apps may become another part of the “legacy” as well.