Windows 7: Различные значения в HKLM ветке

В идеале эта ветка общая для всех пользователей. Даже если к ней у кого-то нет доступа на запись, но на чтение должна быть (к Winlogon). Однако здесь что-то не так.

Установил я Windows Seven x64, настроил и решил скрыть пользователя с админскими правами с «Начального экрана»

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

Ключ DWORD, имя которого совпадает с логином скрываемого пользователя
0 — Скрыть пользователя из списка Welcome Screen
1 — Показывать пользователя в списке Welcome Screen

Создаю ключ «Admin»=dword:00000000
Это мой Администратор.

Вот так РАНЬШЕ все работало, Админ с Экрана приветствия замечательно убирался.

1. Windows Seven x64 SP1 — Открываю реестр под админом (ПКМ, запуск от имени администратора), прописываю все это руками — не работает. Пользователь, которого пытаюсь скрыть, НЕ скрывается.
2. (Причина с этим как-то связана) создаю reg-файл и импортирую его в реестр (успешно), но открываю реестр, там все по старому, как? 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList]
"Admin"=dword:00000000
"Marina"=dword:00000001

Под Админом импортировал созданный кусок реестра, получилось скрыть Admin с Welcome screen, но если под пользователем смотреть реестр, то изменений нет.
Windows 7: Различные значения в HKLM ветке

Покапал инет, ничего не нашел.
Могло быть что-то похожее в HKCU\Software\Classes\VirtualStore\, но у меня там все чисто. Там единственный раздел Software\Wow6432Node.

Вот что про это пишут:

Virtualised registry writes end up getting stored under HKEY_CURRENT_USER\Software\Classes\VirtualStore and it’s possible to check what’s being stored there using regedit if you want.

As to shared information, it depends largely on what it is and who should be able to change it:

1) Configurations that affect all users, but only users with Administrative permissions over the computer should be changing — for example, licensing for an application or opt-in for things like auto-updating. In cases like this, HKLM is the appropriate place and access to areas of the application responsible for configuration of such settings should use elevation (via COM elevated objects or another executable with appropriate manifest like a control panel). When normally reading such settings, be sure to open them with Read-Only access to avoid Windows virtualizing them. Ideally manifest the application itself with a suitable requestedExecutionLevel so that all appcompat shims are disabled.

2) «Shared» settings where ideally an Administrative user would configure for all users, but you want standard users to be able to customise should they so desire. Split the storage into two locations, one under HKLM that is treated as per (1) but have a second set of settings under HKCU that the app will prefer if they are present. When a non-elevated user configures one of the setting, store it in HKCU if the value doesn’t match the HKLM version. Ideally also provide a «reset» that clears all the HKCU settings and thus falls back onto the HKLM configured versions.

3) User data that they might want to share amongst other users of the same PC — for example music or video files. This can go in the appropriate subfolder of the Public directory. Make sure it’s clear in you UI if you’re default to saving anything here as there are potential privacy issues, not to mention inadvertent deletion by another user.

4) «Other» shared data. Be warned, almost every case here is a very bad idea. You’re either exposing users to constant ‘clobbering’ of configuration that they don’t expect, causing unexpected failures in multi-user scenarios such as Fast User Switching and/or risking security or privacy leaks. It is almost always better to keep users entirely isolated from each other, particularly if they are using a non-Administrative account that was presumably created because the intention was they shouldn’t break the experience for other users of the PC.

If you have fully assessed the risks and still want to go ahead, the correct process is to create a folder under the common appdata folder during installation and configure the appropriate minimum level of permissions necessary for your app to run (you don’t want users to actually delete that folder, for example!) You can then store a configuration file in that location, with the caveat that you then need to ensure that multiple user’s access to that file operates correctly without causing each other issues (exclusive file locking, race conditions etc)

DenTNT
DenTNT недавно публиковал (посмотреть все)