Windows 10 roaming settings for remote work scenarios
Published Jul 24 2020 09:29 AM 16K Views

In today's post, I want to discuss how to move away from using legacy user profile technologies and leverage more cloud-friendly, time-tested solutions for Windows 10 roaming settings.

Over the past few months, IT pros around the world have been increasingly tasked with managing devices while end users are working remotely. Early priorities focused on securing corporate devices, securing application access, and ensuring the continuity of ongoing manageability. With these pillars now in place, we have seen many organizations shift greater focus towards user experience and productivity.

In addition, many organizations have realized that ensuring business continuity moving forward will require both user and device flexibility. Some users may continue to work remotely on a mix of portable/mobile devices and remote corporate workstations. Others may return to the office, including those returning on a part-time basis and working in a hybrid scenario where devices may be on-premises at times and remotely connected at others.

Securing access to corporate applications and data is paramount in ensuring that users remain productive throughout this transition. In addition to managing application and data access, ensuring the preservation and roaming of user state data, specifically application preferences and shell settings, is critically important as it is often very personalized and tailored to individual users. In some cases, some of these settings might also be mandated by policy.

Avoid roaming for full user profile data

There has never been a better opportunity to stop traditional Windows user profile management than now. Profile bloat is not something to be desired. IT pros need to avoid profile/settings traffic traveling over any connection, even VPN connections, as much of that data is not pertinent to the majority of the user’s work. Even then, important state data is not needed until an application tied to that data is used. When connectivity is limited and coupled with potential app growth, downloading and uploading full user profile data results in longer logons and logoffs, and the potential for wholesale profile corruption increases, generating more problems that are then further complicated for help desks to remediate without potential state data loss.

Microsoft has two technologies available for offering both more granular user and application state roaming of settings and preferences that can take advantage of the cloud for settings storage and roaming: Enterprise State Roaming and User Experience Virtualization (UE-V.) If you have an Azure AD Premium License or Enterprise Mobility + Security (EMS) license, you can already leverage Enterprise State Roaming. If you have Windows 10 Enterprise or Education, you already have UE-V available to you as well. Both Enterprise State Roaming and UE-V have been around for quite a while and have matured into feature complete solutions. Note that both solutions (designed to roam different types of shell and app settings) can leverage the cloud to roam settings storage.

Modern roaming settings for Windows

Many of our enterprise customers are leveraging Enterprise State Roaming with Azure AD Premium today to roam user state data. In this scenario, settings and data are roamed via your cloud tenant and in a much more granular and streamlined way. Data is processed on demand through specific triggers. You do not have to manage the storage or files as Azure AD and the cloud will take care of that for you. For more information, see Windows 10 roaming settings reference.

To ensure that users can synchronize settings using the cloud across Windows 10 devices in your organization, you will need to:

  1. Sign in to Azure AD admin center.
  2. Select Azure Active Directory > Devices > Enterprise State Roaming.
  3. Select Users may sync settings and app data across devices. For more information, see how to configure device settings.

Enterprise State Roaming settings in Azure ADEnterprise State Roaming settings in Azure AD

For a Windows 10 device to use the Enterprise State Roaming service, the device must authenticate using an Azure AD identity. For devices that are joined to Azure AD, the primary sign-in identity for the user is their Azure AD identity, so no additional configuration is required. For devices that use on-premises Active Directory, you must first Configure hybrid Azure Active Directory joined devices.

Users can also enable synchronization of Windows 10 settings by selecting the Start button, then selecting Settings > Accounts > Sync your settings. When Sync settings is turned on, Windows syncs the settings you choose across all your Windows 10 devices that you have signed in to with your Azure AD account. If you need to enable specific policies for Enterprise State Roaming, you can do so using Group Policy (although you will find it likely that this might not be needed.) You can also control use via security groups and monitor device sync status per user in the portal.

Sync settings options in Windows 10Sync settings options in Windows 10

You do not need to worry about server-side management of storage data, as that all happens automatically. Enterprise State Roaming data is hosted in one or more Azure regions that best align with the country/region value set in the Azure Active Directory instance. Enterprise State Roaming data is partitioned based on three major geographic regions: North America, EMEA (Europe, Middle East, and Africa), and APAC (Asia-Pacific.)

Roaming settings for Modern UWP apps

In addition to key Windows 10 browser and shell components, Enterprise State Roaming can facilitate roaming settings for modern Universal Windows Platform (UWP) applications as well including system, inbox, and Store apps. To view a more comprehensive listing of system and inbox apps, see Understand the different apps included in Windows 10.

Both Universal Windows applications and packaged desktop line-of-business (LoB) applications in MSIX can write settings data to a roaming folder and any data written to this folder will automatically be synced. Your experience may vary, as it is up to the individual developer to design an application to take advantage of this capability. Likewise, for desktop applications repackaged into MSIX packages, this data may not natively write to this folder, and a Package Support Framework (PSF) fixup may be required. For more information about how to develop a Universal Windows app that uses roaming, see the AppData Storage API and the AppData Roaming Developer Guidance.

Roaming settings for classic Win32 applications

Most LOB applications in the enterprise running on Windows are still running predominantly as traditional Win32 applications. Since there may be a lot of variance and non-standard approaches to user preference management, you can still use the UE-V Template Generator to capture those settings and designate for roam in an XML template those file and registry settings that will need to be stored as user state for that application.

UE-V can be enabled via PowerShell (the Enable-UEV cmdlet,) through Group Policy, and through Microsoft Endpoint Configuration Manager. You can also use any of the options to enable the inbox templates, which are, by default, located at C:\ProgramData\Microsoft\UEV\InboxTemplates) and register custom templates either using a custom path or leveraging the default (C:\ProgramData\Microsoft\UEV\Templates.

In order to roam settings for custom applications, you first need to download the Windows 10 ADK and install the UE-V Template Generator. From there, run the template generator to capture the settings and preferences available for each application. For guidance around capturing settings and preferences and generating custom templates for your applications, see Working with custom UE-V templates and the UE-V template generator.

User Experience Virtualization (UE-V) template generatorUser Experience Virtualization (UE-V) template generator

You can then leverage group policy or the register-uevtemplate cmdlet to register the custom template.

UE-V and roaming for additional legacy shell Items

In addition to roaming registered templates that might be customized for your LOB Win32 applications, UE-V can roam other legacy shell items that are still supported in Windows 10. For a list of items UE-V roams by default via its inbox templates, please see User Experience Virtualization (UE-V) for Windows 10 overview.

Note: Some of these items might not be directly applicable in mobile scenarios; however, items such as credential roaming, and legacy explorer preferences may be useful.

Roaming UE-V settings storage in the cloud

Traditionally, many enterprises over the years used UE-V to roam settings using an on-premises file share option. UE-V can also be configured to use an external sync source such as OneDrive. Additional enhancements over the past couple of years to OneDrive, such as Files On-Demand, means you can have your settings available during first-time launch of the application.

UE-V has a few sync methods, but for cloud scenarios, including OneDrive, you will want to select the “External” option. This configuration method specifies that if UE-V settings are written to a local folder on the user computer, then any external sync engine (such as OneDrive for Business, Work Folders, SharePoint, or Dropbox) can be used to apply these settings to the different computers that users access. If you were configuring this via policy, you can assign the %USERNAME% variable when assigning the local folder (i.e. C:\Users\%USERNAME%\OneDrive\Settings.)

Configuring UE-V sync using Group PolicyConfiguring UE-V sync using Group Policy

Putting it all together

Combining Enterprise State Roaming with UE-V gives your organization the capability to provide more user flexibility and portability across multiple devices, and allows those settings to travel with your end users wherever they might be working. We recommend that you take advantage of these two solutions to roam settings if you have Windows 10 Enterprise and have also enabled OneDrive and Azure Active Directory. The chart below is a quick reference to help understand and manage the differences between roaming options.

Item

Solution

Settings Storage

Common Windows 10 Items

Enterprise State Roaming

Automatically roamed via Azure AD

Modern Shell Items

Windows 10 Inbox and UWP Apps

Packaged Apps via MSIX

Legacy Shell items

UE-V

 

Recommendation is to configure an external cloud sync host (OneDrive)

Win32 Apps

 

11 Comments
Iron Contributor

Hi. I read the article and I am having serious doubts about its accuracy, especially because you are using misleading and outdated terminology that Microsoft abandoned in 2012. What you refer to "legacy" or "Win32" apps may in fact be apps compiled against .NET Core 3.1, which is more modern than Universal Windows Platform (UWP). What you refer to "Modern UWP app" is in fact a subset of them, i.e. the sandboxed ones. But most disturbing of all is your reference to the Inbox app! This app has not been part of Windows since Windows 2000. (It predates the word "app"!) Windows 10's email client is called Mail and Calendar.

 

Also "Legacy Shell Items" vs. "Modern Shell Items"? Do we have such things? As far as Group Policy is aware, both the "modern" and "legacy" shell, as well as all other built-in Windows apps, write their settings in the same place.


Thank you very much for your information and insight. If you are speaking specifically in developer nomenclature, I can understand how this may be confusing, but remember this article is intended for an IT Pro audience which usually differentiates application types more broadly. When we speak of apps in the IT Pro context, we avoid the semantic jungle and focus on applications from a management perspective and not a developer one.

Referencing this documentation, we generally classify from an app management perspective the app types on Windows 10: 

 

  • Windows apps - introduced in Windows 8, primarily installed from the Store app.
  • Universal Windows Platform (UWP) apps - designed to work across platforms, can be installed on multiple platforms including Windows client, Windows Phone, and Xbox. All UWP apps are also Windows apps, but not all Windows apps are UWP apps.
  • "Win32" apps - traditional Windows applications.

 

With regards to your confusion re: "inbox apps." I will clarify and use the more appropriate terms "system and provisioned apps." :)

Iron Contributor

With regards to your confusion re: "inbox apps." I will clarify and use the more appropriate terms "system and provisioned apps." :)

In that case, this article has misused "inbox" for "built-in" and have capitalized it for no reason too. Problem is, the above clarification only makes it worse. If I take "Inbox" (capitalized) to mean "system and provisioned apps", then why does the article make a separate category for "Common Windows 10", "Legacy Shell" and "Modern Shell" items, and more importantly, why are they treated differently. Perhaps if the article had examples, it would have been easier to understand. For example, settings created by Settings; are they legacy items, "modern" items, or common Windows 10 items?

If you are speaking specifically in developer nomenclature

Of course I'm not. I asked a practical question: Let's assume we have a LOB written in .NET Core 3.1 and package it via MSIX. Into which of your categories does it fall? Is Microsoft Edge version 82 a legacy app? What about apps packed via Desktop Bridge and sold on Microsoft Store? As I said above, examples help a lot.

Referencing this documentation, we generally classify from an app management perspective the app types on Windows 10

Now that's a good point. It is good to reference your source. The problem is that the source is talking about "different apps included in Windows 10". And sure enough, no .NET Core 3.1 app is included in Windows 10. Also not Qt apps or Electron apps are included with Windows 10 either. But Visual Studio Code, for example, is an Electron app.

Brass Contributor

Are there any future road map available for UE-V ?

Copper Contributor

@The_Smart_One 

if we look at it from a deployment point of view it might be easier. Whatever you install with "legacy" installers such as msiexec, or exe files are "legacy" applications, all the rest are modern :)

Iron Contributor

@AlessandroPerelli 

So, let's say I have a .NET Core 3.1 app that normally gets installed with an MSI file. I download the MSIX Packaging Tool and put that app into an MSIX package. Does that mean I can now roam its settings via Enterprise State Roaming?

 

If only I had access to Enterprise State Roaming and could test things for myself...

Awesome post and very helpful 

Iron Contributor

Guys, you really should invest in making Enterprise State Roaming working w/o connection to Azure, because not everybody can use Azure for their infrastructure.

Some organizations don't want their users to depend on a service which is not under control of the organization, because in that case, for example, they can't set and maintain SLAs - it's a black box.

Iron Contributor

@exchange12rocks 

With respect, your suggestion is not going to happen. Azure is Microsoft's primary source of income. Windows is a dead project. In that light, Microsoft's business model is that the sole purpose of Windows is to bring more customers to Azure.

 

None of this is a secret. Microsoft said as much during the last five years. Only, Microsoft focused a lot on saying why all of this is very amazing, exciting, etc.

Copper Contributor
Copper Contributor

Well the only sad thing is, that Package State Roaming has been deprecated since Windows 1909. It is very sad since I try to sell the benefits of MSIX and UWP and you drop the features.

Version history
Last update:
‎Jul 24 2020 09:30 AM