Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, July 18, 2017 3:00 PM
Given that MS now consider roaming profiles to be unofficially deprecated, we're looking into other methods for synchronising user settings as they move from one device to another. In particular, we're looking for a mechanism that will sync all settings for windows itself and traditional applications (we have no modern apps), without needing to be told how to do this per-application. i.e. UE-V is not a viable solution for our needs.
This looks like it would involve something like exporting the current user registry at logoff and importing it again at logon, and similarly copying off the contents of %userprofile% at logoff and copying it back at logon, with filtering and exclusions as appropriate.
This mostly works, but runs into problems for settings such as the Default Browser. Settings like this are protected by a hash value to indicate that it is a preference that the user set themselves through the UI, and simply copying this setting from one machine to another does not work.
(e.g. HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice)
After a bit of investigation, we've arrived at the following points:
- The hash changes whenever the user goes into settings and changes the default browser, even if they select the existing default browser. This implies that there is some additional information involved in the hash, not purely information based on who the user is plus the setting itself or it would be the same every time for a given user and browser combination. This additional information could be a timestamp or a counter, or simply a random value, but either way this info would need to be preserved as the user moves between devices so that the hash can be validated.
- Only the hash for, say http (and https) changes when making changes via the Settings app. Other hashes remain unchanged and remain valid (i.e. changing the default Email handler does not change the http and https hashes). This implies that the additional info as above, is kept separately for each setting.
- For traditional roaming profile users, the hash remains unchanged after moving between devices, and remains valid. This implies either that there is no machine-specific information (including data in the user's appdata\local) involved in the hash, or that a different hashing algorithm (that avoids machine specific information) is used for users with a traditional roaming profile. For the export/import sync approach, the user profiles are local as far as Windows is concerned.
- When a user logs on for the first time their userchoice settings are populated based on the system default. This seems to happen later than profile creation itself, possibly as part of the shell starting for the first time. (If you have a synchronous logon script, it runs before the shell starts, and the userchoice keys are not yet present while the script is running, but are there by the time you get to a desktop.) If the registry settings are imported (excluding the UserChoice keys) before the shell is started, this does not happen, and the user ends up with no UserChoice keys at all. i.e. the act of importing other settings prevents some first-login things from happening.
- Having no UserChoice keys is the same as having keys with an invalid hash - the user is prompted the first time they launch a URL.
The upshot of all this is that for users using this kind of sync mechanism instead of roaming profiles, their default browser setting works on their first logon only, and never again thereafter. If we copy their userchoice keys, they are ignored because the hash is invalid. If we don't copy them, the machine defaults don't populate the user side. Either way, they are prompted when a URL is launched.
(This is all on 14393 LTSB, and the machines have IE, Firefox and Chrome installed. IE is the system default.)
I understand that MS is somewhat reticent about how the hashing works for the UserChoice keys, as it wants to prevent things from programmatically changing the user's preferences, which is fair enough. However, what we're interested in doing here is ensuring that the user's existing preferences are preserved as they move between devices. We're not looking for a way to calculate the hashes afresh or programmatically set the default browser to a particular value; what we're looking for is what info we need to ensure moves with the user such that the existing hashes remain valid.
Any suggestions? Anyone else tried something along these lines?
If nothing else, confirmation that local and roaming users use different hashing algorithms would be useful. If local users include machine-specific info (e.g. machine name) when calculating the hash, then transporting the hash between machines is never going to work and we need to look at other approaches.
All replies (8)
Wednesday, July 19, 2017 2:33 AM
Hi,
I appreciate your study and discovery, in general, we don’t recommend that copy %userprofile% between different computers to sync user’s setting, this way lack security.
You find out a hash value protect user default settings, it’s valuable, I agree with you. However, tell the truth, I don’t know the specific value we need to move to make migratory user profile keep its inherent browser setting, I even suspect that there is no way to make it by just moving a hash or related information, Windows may have more complex configurations to protect user’s personal settings.
What I can find out is just this registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts
Since Windows 7, Microsoft has added a new registry subkey, named “UserChoice”, to certain file extensions, of course including browser file extension(.htm and .html)
If we import the identical FileExts Value, the default program settings may be changed.
My idea comes from here.
On the other hand, there is an easy way to sync user settings between computers, but we usually ignore it, it is Microsoft account, if it’s convenient to you, try it.
Regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, July 19, 2017 2:40 AM
For your question in the last paragraph, I am sorry for no answer, I don’t know the hashing algorithms on user profile(local or roaming), you may need to open a premier support ticket or expect other forum user’s viewpoints
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, July 20, 2017 10:20 AM
Broadly, what we're looking to do is have our students logging on to our machines, moving from one machine to another, with the settings for their applications moving with them, with as few dependencies (especially external ones) as possible, with logins as fast as possible, and the whole thing as simple and low maintenance as possible.
Ideally we'd depend on nothing but our own AD and storage systems, especially at login and when launching applications - it keeps things simple and minimises the things that can go wrong and the places to investigate to work out why something is slow or not behaving as it should.
Microsoft accounts don't really meet our requirements there at all - that's a whole set of external dependencies and complexity that we'd much rather avoid. In any event, as far as I can tell, one thing that syncing with a Microsoft account doesn't do is sync your choice of default browser.
Up to now, roaming profiles plus folder redirection have largely met our requirements. They're not ideal, but they work well enough. However, MS have made fairly clear that roaming profile support will go in some future version of Windows, so we're looking at how we might address the same needs without them.
The only reason I've bothered asking about this is the fact that the userchoice hash remains valid between machines for a user with a traditional roaming profile. That implies that what we're trying to do can be done in some circumstances - i.e. a hash generated while logged on to one machine can remain valid after moving to another. The question is how roaming profiles are achieving that - they're either doing it by ensuring that whatever information is needed to validate the hash is also moving with the user (in which case maybe we could do that as well), or by ensuring that the hash is generated in the first place without machine-specific details in it (in which case, probably not unless we can also cause that to happen for users with a local profile).
The other stuff about FileExts is interesting, but is about specifying defaults (to be applied either on profile creation or every login), which is a different thing from ensuring that the user's choice of default browser is preserved as they move between machines. However, given that our current experiments for moving away from roaming profiles result in no default browser at all, having a default put back every login may be preferable.
Can you clarify what you mean by "this way lack security"? What we're trying is essentially the same thing that roaming profiles do, just achieved by different means and with a bit more control. If there are security issues with this, then I'd be interested to know what they are and whether roaming profiles generally have the same issues.
Friday, July 21, 2017 8:31 AM
Modifying registry value needs the Admin permission, we can modify registry means we can also do anything on this computer, on your university, it’s not a issue, you are using it for study, but in enterprise environment thing becomes more complex.
Besides, I don’t find Microsoft document claims that roaming profile function or support will go. Since it basically meets with your requirement, you and your students can use it.
Yes, Microsoft is does promoting AAD and Cloud concept, maybe in future, more and more domains join into Azure AD and domain accounts might be replaced by another kind of work accounts, roaming profiles might be replaced by cloud user profiles, but now, roaming profile and domain account are still used widely, we don’t need to worry about it.
For your requirement, I think you have came up with the most proper solution, roaming profile, I don’t have other suggestions for you.
Regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Friday, July 21, 2017 9:18 AM
Modifying registry value needs the Admin permission, we can modify registry means we can also do anything on this computer, on your university, it’s not a issue, you are using it for study, but in enterprise environment thing becomes more complex.
Besides, I don’t find Microsoft document claims that roaming profile function or support will go. Since it basically meets with your requirement, you and your students can use it.
Yes, Microsoft is does promoting AAD and Cloud concept, maybe in future, more and more domains join into Azure AD and domain accounts might be replaced by another kind of work accounts, roaming profiles might be replaced by cloud user profiles, but now, roaming profile and domain account are still used widely, we don’t need to worry about it.
For your requirement, I think you have came up with the most proper solution, roaming profile, I don’t have other suggestions for you.
Modifying the current user registry can be done by the user with no elevation or admin privileges required. It does not mean you "can also do anything on this computer". To be perfectly clear, the mechanisms we're experimenting with run as the user, the user is not an admin, and we are not using any kind of privilege elevation to achieve it. There are a couple of places in HKEY_CURRENT_USER where the user themselves does not have rights (mostly group policy related), but these are easily excluded from the sync process. I don't see any security issue there.
Roaming profiles are indeed still officially supported, but there are many Win10 features that don't work properly with them including basic things like the start menu. Mostly this is because these features expect things in appdata\local to persist, and for a roaming user appdata\local is empty every time they move to a new machine. So, currently this "most proper solution" for us includes using ClassicShell on student PCs such that the user has a start menu that works.
See this thread for the kind of problems the start menu has for roaming users.
As far as unofficial statements about roaming profile support are concerned, see this thread for more info, where a Microsoft employee says "Regarding Roaming User Profiles (RUP) support, RUP is supported on Windows 10 but we’re no longer investing in new features. We do plan to deprecate RUP in the future but the timing has not been determined."
The above, together with the lack of interest MS has shown in fixing features to work properly for roaming users (the start menu hasn't roamed properly in any Win10 release, AFAIK), we think we should probably look at alternatives sooner rather than later.
Tuesday, July 25, 2017 9:20 AM
Your consciousness of advance preparation is reasonable, but now, roaming profile is the most proper method for your scenario, if you don’t want to use it, I don’t have other suggestion.
I am going to share this case to my colleagues to see if they have more ideas or experience.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Monday, November 20, 2017 9:00 PM
i coded a utility that can calculate this hash and therefore set the default browser or a filetype per user
SetDefaultBrowser: http://kolbi.cz/blog/?p=396
SetUserFTA: http://kolbi.cz/blog/?p=346
Enjoy User Experience!
Wednesday, November 28, 2018 5:10 PM
Can you share your code or method of getting the hash value via code? I'd like to pull the hash for any application to be used as a default. My current dilemma is setting Outlook as the default 'mailto' client.