M
Mike Sandells
Guest
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 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.
More...
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.
More...
