Managing Edge with Group Policy and Roaming Profiles

• Author
• Recent Posts

James Rankin

James is a consultant from the UK, specializing mainly in end-user computing, Active Directory and client-side monitoring. When not consulting for james-rankin.com, he can often be found blogging, writing technical articles and speaking at conferences and user groups.

Latest posts by James Rankin (see all)

• Can’t uninstall app: Delete or change Windows apps that have been flagged as non-removable - Thu, Mar 16 2023
• FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
• Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022

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:

ProtectedSearchScopes Group Policy

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.

Default search provider setting 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.

Conclusion

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.

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.