Windows 10 and roaming user profiles don’t harmonize well. In this post, you will learn about the various traps you might fall into if you’re working with roaming profiles in Windows 10 in your network.

Microsoft touts Windows 10 as the mobile and cloud platform of the future. However, it is interesting to see how the operating system performs in traditional environments – that is, environments that you choose to deploy and manage using time-honored technologies most of us have been relying on for years.

Roaming profiles are a case in point. Microsoft was the first entrant into the market that grew up around user mobility, allowing network-based profiles to persist across multiple desktop sessions. It rapidly became a crowded space, with other vendors – such as RES, AppSense, Liquidware Labs, Scense and many others – extending, augmenting, or even outright replacing the traditional roaming profile functionality.

A roaming profile basically allows you to copy the user-based filesystem and HKEY_CURRENT_USER Registry hive to a defined network location at logoff (usually a user’s home drive area or a dedicated profiles share). This data is then copied back to the user’s %USERPROFILE% area at logon to ensure a consistent user experience across sessions and devices. To avoid problems with large files or large numbers of files, the roaming profile is often combined with Folder Redirection, allowing certain pertinent folders within the profile (usually My Documents, Pictures, and Videos) to be “redirected” permanently onto the network, avoiding the need for copying these particular folders at logon and logoff.

Setting roaming profile path in Active Directory Users and Computers

Setting roaming profile path in Active Directory Users and Computers


Traditional roaming profile traps ^

Traditional roaming profiles have occasionally suffered from issues regarding profile failures and have always been susceptible to “last writer wins” issues when multiple sessions are in use. When Windows writes a locally cached profile back to the file server during logoff, it compares each file pair’s timestamps and overwrites only older files.

This approach works well in the file system, but it fails miserably with the registry, because the registry is a file system within a single file. A user’s hive (mounted to HKEY_CURRENT_USER during a session) is stored in the file NTUSER.DAT in the profile. Since the registry is modified in every session, NTUSER.DAT is always written back and will be written back when any “odd man out” session is closed; the “last writer wins” (hence the name of the issue), potentially overwriting registry-based settings changes made in other sessions.

Roaming profiles have also always been restricted to particular versions for particular OS combinations, although some later operating systems have been slightly backward compatible with “v2” profiles. Mainly, it is recommended that a roaming profile be restricted to the combinations of operating systems that match the defined versions:

  • Server 2003/Windows XP – v1
  • Server 2008/Server 2008 R2/Windows Vista/Windows 7 – v2
  • Server 2012/Windows 8 – v3
  • Server 2012 R2/Windows 8.1 – v4
  • Server 2016/Windows 10 – v5

Windows 10 roaming profile traps ^

When defining a roaming profile for Windows 10, everything seems to behave normally. You create a “username.v5” profile in the nominated user share and it is populated accordingly. However, you will notice a number of issues as soon as your roaming user logs in to a different machine.

Profile unload fails

It is common in roaming profile environments to remove cached client-side copies of the roaming profiles to avoid filling up local hard drives with multiple user profiles copies – especially in environments where open-access machines are in use. Typically this is done by defining the “Delete cached copies of roaming profiles” GPO and setting it to Enabled. In Windows 10, though, a hook from a process (called the State Repository Service) will more often than not prevent the profile from being unloaded.

Start Tiles fail to persist

One of the most visually obvious aspects of the Windows 10 experience is the new Start Menu and the attached Start Tiles. At first logon, most users customize this to their own preferences. However, the data for these Tiles is stored in the %LOCALAPPDATA% folder, meaning that it simply does not exist within a roaming profile. Only %APPDATA%\Roaming is copied to the roaming profile store – and you can only specify exclusions, not inclusions, to this data.

Modern Apps fail to persist

Microsoft’s new apps also do not persist in any settings within the roaming profile store. Again, these are written to %LOCALAPPDATA%\Packages, which is beyond the scope of a roaming profile’s mandate. For certain modern apps – particularly Microsoft Edge (popular among Windows 10 users) – this adds to a frustrating experience when roaming settings are expected and it simply does not happen.

Corruption of the profile is common

When a Windows 10 user logs in, a database is created that deals with the Start Tiles, modern apps, and various visual aspects of the Start Menu (there’s also a separate database created for the Notification Center). When using a roaming profile, this database can become corrupted, resulting in problems, such as Cortana crashing, icons disappearing from the Start Tiles, or, in the worst-case scenario, the left-click Start Menu simply does not function at all.

Example of Cortana load failure whilst using a roaming profile

Example of Cortana load failure whilst using a roaming profile

Conclusion ^

With all of this in mind, it seems that there are serious bugs in the Windows 10 implementation of roaming profiles that need to be addressed before the product is enterprise-ready. Optimistically speaking, it would appear that Microsoft is probably going to address these issues in the June 2016 Redstone update – when, with Windows Server 2016 Remote Desktop Session Host (RDSH) being available, roaming would be a much more relevant subject.

However, with a more cynical train of thought, it could be said that it is in Microsoft’s interests to intentionally hobble the roaming capabilities of Windows 10. Making it so much more difficult for those using traditional methods or those using third-party vendor tools to successfully roam the user state would mean that Microsoft has an opportunity to fill this gap with a tool of its own creation and fuel its larger goal of widespread cloud adoption. In fact, there is a tool already in beta, called Enterprise Settings Sync, which appears to do precisely that, saving the user state into an Azure Active Directory (AD). Is this the wider play and the reason that Windows 10 appears to be incompatible with traditional forms of roaming?

Subscribe to 4sysops newsletter!

Whichever it is, Microsoft must tread carefully. Already enterprises are holding back in some areas because of concerns about how their traditional management and deployment methods will function on Windows 10 and how much adaptation is required. Windows 10 has immense promise – but it would not take an awful lot to end up with customers hanging onto Windows 7 in the same way they did with Windows XP.

36 Comments
  1. TheSearch 3 years ago

    We are struggling with Windows 10 and folder redirection. Is anyone aware if this functionality will work at all with windows 10? we didn't manage to get it to work yet, and spent already some weeks in trying. many thanks

  2. Jim 2 years ago

    Nake sure Fast Boot is disabled in "Settings -> Power and Sleep -> Additional Power Settings -> What do the buttons do".   This can happen because the folder redirection tries to process before the Group Policy Manager has completed it's processing.

  3. Emily 2 years ago

    When I created the Windows 10 Home User Accounts on my desktop I did not realize that assigning a User account linked to a Microsoft Account was a bad idea. SO... I attempted to delete the User Accounts and re-add them as standard accounts, then I created a "local account" with Administrator privilege's (which I only use to approve changes, remove programs etc.). The issue is that I dug around, lacking knowledge of what I was digging in and now.... it seems as if all files on both standard accounts are only links to desktops.... What is going on? What have I done? How can I fix this?

    Thanks,
    Emily

  4. Bishop 11 months ago

    > Microsoft was the first entrant into the market that grew up around user mobility, allowing network-based profiles to persist across multiple desktop sessions.

    You're gonna flip when you hear what Solaris has been doing for exported homes since the 90s .. and how it was derived from an earlier Unix before that.

Leave a reply to Emily Click here to cancel the reply

Please enclose code in pre tags

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

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account