Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup

imageПри настройке сервера служб Remote Desktop Services (RDS) на Windows Server 2008 R2 c включённым UAC, столкнулся с интересной ситуацией. Стояла такая задача, чтобы при входе в систему для каждого пользователя отрабатывал *.cmd файл, в котором исполнялись бы все необходимые директивы дополнительной настройки пользовательского окружения.

По старой памяти, запустив редактор реестра от имени Администратора, я открыл ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon и с удивлением обнаружил отсутствие строкового параметра AppSetup (параметр служит для запуска скриптов обеспечения совместимости приложений в многопользовательской среде). Без задней мысли я создал этот параметр, вписал в него имя моего командного файла (USRLOGON_2.CMD), расположенного в папке C:\Windows\System32 и перезагрузил систему. Но к моему удивлению после перезагрузки, при входе пользователей в систему, файл не отрабатывал.

Пришлось вооружиться Sysinternals Process Monitor (Procmon) и проследить за происходящими процессами с реестром и файловой системой в процессе входа пользователя. Оказалось, что мой файл даже и не пытался быть прочитанным пользовательскими процессами. В ходе экспериментов, я удалил созданный мной ключ реестра AppSetup…и к своему удивлению через Procmon увидел что значение этого ключа продолжает успешно читаться в процессе логона…Стало понятно, что regedit запущенный от имени Администратора мне что-то «недоговаривает». Вот как выглядел вышеописанный куст реестра в таком случае (после удаления ранее созданного ключа AppSetup):

image

С помощью утилиты PsExec.exe из состава Sysinternals PsTools я запустил редактор реестра от имени системы (SYSTEM) командой

PsExec.exe /i /s regedit

… и перед моими глазами открылась расчудесная картина Улыбка

image

После этого стало понятно «откуда ноги растут». После того как значение ключа реестра было изменено в режиме пользователя SYSTEM — всё заработало как надо.

image

И ещё одну интересную вещь заметил – если копировать в системную папку C:\Windows\System32 разного рода файлы (в моём случае это были файлы *.cmd *.reg *.vbs) через файловые менеджеры – система не даёт их обнаруживать пользователям, хотя разрешения на уровне NTFS судя по вкладке Безопасность в свойствах файлов вполне адекватные, то есть наследуются с папки верхнего уровня и все пользователи имею право на чтение и выполнение таких файлов… А вот если скопировать эти же самые файлы в системную папку через проводник Windows – файлы пользователям доступны на чтение и выполнение в полноценном смысле этого слова… Даже не знаю как это трактовать… Возможно это особенности механизма работы UAC… Будет интересно услышать любые комменты от «просвещённых» по этому поводу.

Всего комментариев: 4 Комментировать

  1. Алексей /

    «А вот если скопировать эти же самые файлы в системную папку через проводник Windows – файлы пользователям доступны на чтение и выполнение в полноценном смысле этого слова…»
    Файловый менеджер x64 или x32? Если x32, то он при попытке доступа к папке c:windowssystem32 перенаправляется в папку c:windowssyswow64. Я как-то очень долго не мог понять, почему не вижу нужных файлов через TotalCommander )

  2. Алексей Максимов /

    Я сразу отмёл вариант перенаправления, так как поведение системы было одинаковым при попытке копирования файлов описанным способом и в тот и в другой каталог

  3. Станислав /

    кстати, на эту тему (UAC) есть отличная статья

    http://technet.microsoft.com/ru-ru/magazine/2007.06.uac.aspx

    все подробно описано про реестр в том числе

  4. Обратная ссылка: Загадочное поведение окна запуска баз 1С 7.7 настроенного через GPP Registry Wizard | Блог IT-KB /

Добавить комментарий