Differentiation between per user and system wide modifications

[rnc]

Hi,

Is there any way of knowing which tweaks (even comment markers in the code would be a good enough first step) apply on a per user basis rather than a per system basis? I guess this is related to #243.

Background: As I'm shortly going to be setting up a home machine, I've been experimenting with configuring Windows in a VM, initially controlled by a set of Ansible scripts. While I can create additional users via that, I suspect I'd need to do an initial login to get the 'first setup' of that user complete before running any 'per user' scripts.

Also, if other additional users are non-administrator child accounts would any of the tweaks apply/not apply to them ?

[Disassembler0]

Apart from #243 it's related also to #5 and #29.

Is there any way of knowing which tweaks apply on a per user basis rather than a per system basis?

Rule of thumb is that tweaks that modify HKLM are per-system, tweaks that modify HKCU are per-user (although some may require admin privileges as they touch protected GPO keys). Installation/uninstallation of AppX is per-user, Installation/uninstallation of everything else is per-system.

I suspect I'd need to do an initial login to get the 'first setup' of that user complete before running any 'per user' scripts.

Currently, yes. There's some discussion about modifying the default registry hive in one of the linked tickets, but I don't intend to add such functionality anytime soon, as this is something what should rather be done via installation media customization (sysprep). Windows do a lot of stuff during the first setup, so some tweaks would be even completely ignored in this scenario.

if other additional users are non-administrator child accounts would any of the tweaks apply/not apply to them ?

That's a trick question. Virtually all tweaks would apply to them, but you're probably asking which tweaks can be applied by them. In that case only the tweaks which don't require admin privileges can be applied to/by such users. If you try to use RequireAdmin, the elevation mechanism will cause the tweaks to be applied to the impersonated (admin) account instead of the non-admin user. But then again, most of the tweaks which require admin privileges are per-system and would affect also the non-admin users.

[rnc]

Apart from #243 it's related also to #5 and #29.

Is there any way of knowing which tweaks apply on a per user basis rather than a per system basis?

Rule of thumb is that tweaks that modify HKLM are per-system, tweaks that modify HKCU are per-user (although some may require admin privileges as they touch protected GPO keys). Installation/uninstallation of AppX is per-user, Installation/uninstallation of everything else is per-system.

Great thanks. I'll take a look at the code to see which does which. It might be useful to provide grouping?

I suspect I'd need to do an initial login to get the 'first setup' of that user complete before running any 'per user' scripts.

Currently, yes. There's some discussion about modifying the default registry hive in one of the linked tickets, but I don't intend to add such functionality anytime soon, as this is something what should rather be done via installation media customization (sysprep). Windows do a lot of stuff during the first setup, so some tweaks would be even completely ignored in this scenario.

Thats fine. Even if I run the ansible scripts, perform a login manually then rerun on the other user then its still better than doing everything manually! :-D

if other additional users are non-administrator child accounts would any of the tweaks apply/not apply to them ?

That's a trick question. Virtually all tweaks would apply to them, but you're probably asking which tweaks can be applied by them. In that case only the tweaks which don't require admin privileges can be applied to/by such users. If you try to use RequireAdmin, the elevation mechanism will cause the tweaks to be applied to the impersonated (admin) account instead of the non-admin user. But then again, most of the tweaks which require admin privileges are per-system and would affect also the non-admin users.

Actually no, apologies for not making it clear enough. I'm still reading up on it, but while the admin level accounts I think I can create them as local accounts, I suspect creating the child accounts as full microsoft accounts would be preferable to get the benefit of cross-device monitoring/protection. I wouldn't want them to run the scripts, but simply be able to set up their UI to make it simpler - and hence wondering whether there are any implications if the accounts are not 'local' as such?

[Disassembler0]

It might be useful to provide grouping?

The tweaks are already grouped thematically, so adding another dimension would just make things more confusing. But one day in the distant future, there will be a wiki #225, which will contain this info. And in even farther future possibly also a version of the script which will handle also all accounts and the default user registry hive.

...microsoft accounts...

You can still choose if the account will have the admin privileges (will be a member of local admin group) on the device or not. Although I personally haven't tested it, there seems to be a decent amount of users of this script and I have yet to hear about any substantial problems related to Microsoft accounts. I don't know exactly which parts are subject of roaming, so I'm unable to answer if the setting will be carried over between the devices, but other than that there aren't any special implications to Microsoft accounts. The only thing which comes to mind is that there are some tweaks impacting synchronization and sharing (DisableSharedExperiences, DisableActivityHistory) so you may want to not apply those.

[rnc]

It might be useful to provide grouping?

The tweaks are already grouped thematically, so adding another dimension would just make things more confusing. But one day in the distant future, there will be a wiki #225, which will contain this info. And in even farther future possibly also a version of the script which will handle also all accounts and the default user registry hive.

Yes I see in Default.preset

...microsoft accounts...

You can still choose if the account will have the admin privileges (will be a member of local admin group) on the device or not. Although I personally haven't tested it, there seems to be a decent amount of users of this script and I have yet to hear about any substantial problems related to Microsoft accounts. I don't know exactly which parts are subject of roaming, so I'm unable to answer if the setting will be carried over between the devices, but other than that there aren't any special implications to Microsoft accounts. The only thing which comes to mind is that there are some tweaks impacting synchronization and sharing (DisableSharedExperiences, DisableActivityHistory) so you may want to not apply those.

Yes, the plan is to have both adults with admin level permissions. And the child accounts are a work-in-progress ... its a 'learning experience' :-D

Thanks very much for your answers... the ansible script is starting to work (for a VM at least) - https://github.com/rnc/nicks-shell/tree/master/ansible-windows

One final question for this - while I can see from Default.preset that some settings are enabled by default, am I correct in thinking that Windows defaults is for everything enabled/installed? - i.e. what are the original values versus Default.preset?

[Disassembler0]

while I can see from Default.preset that some settings are enabled by default, am I correct in thinking that Windows defaults is for everything enabled/installed?

Windows defaults are the ones in the second column of Default.preset. The functions in the first column apply the modifications deviating from the default, the functions in the second column restore the same settings to the default values. Some tweaks have also third column for cases where there are more options than just do / undo.

Some of the tweaks are commented in the file because they're not suitable for everyone. The tweaks which are enabled by default are curated by years of experience and user requirements, but those are my years or experience and my users, so your mileage may vary. You're definitely encouraged to read through FAQ and the script itself and create a preset suiting your needs. You may even supply your own tweaks, if needed.

[rnc]

Perfect, thanks!