- 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
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.
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.
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.