none
Сервер удаленных рабочих столов и службы AD DS в одной системе RRS feed

  • Вопрос

  • Всем привет!

    Так сложились звезды, что на одной и той же машине вынужден был установить сначала службы удаленных рабочих столов, а потом к ним добавились службы AD DS и машина стала не просто сервером терминалов, но еще и резервным DC в домене.

    При этом, всем пользователям данного сервера терминалов стало запрещено запускать regedit.exe (возможно только через UAC) и запрещено печатать на перенаправляемых принтерах. Принтеры перенаправляются (через Easy Print), но не печатают.

    Поискал на форуме временное и не очень грамотное, но работающее решение проблемы — добавить группу "Прошедшие проверку" с правами на "Изменение" к папке %systemroot%\system32\spool\printers

    До этого советовали в оснастке "Управления печатью" установить режим изоляции драйвера Easy Print на "Общий доступ", но это не помогает.

    Как правильно решить указанную проблему с печатью?

    Также подскажите, как разрешить пользователям запускать regedit.exe без UAC?

    Желательно, не выключая UAC, т.к. до того, как добавилась роль AD DS всё работало: и принтеры печатали, и regedit запускался (для внесения изменений в ветку current_user).

    • Изменено Eurisco 28 июня 2012 г. 6:31
    27 июня 2012 г. 7:42

Ответы

  • Правильно - убрать роль контроллера с сервера терминалов. Эта роль автоматически предполагает более жесткий уровень безопасности. Чтобы работало в текущей ситуации:

    1) Настроить запуск сценария в планировщике задач от имени Local System - тогда он сможет внести изменения в реестр. И пользователям никаких прав не потребуется.

    2) Касательно печати - вы нашли единственое верное решение. Разве что можно было ограничиться группой Domain Users


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    • Помечено в качестве ответа Eurisco 5 июля 2012 г. 16:45
    5 июля 2012 г. 11:42
  • Правильно - убрать роль контроллера с сервера терминалов. Эта роль автоматически предполагает более жесткий уровень безопасности. Чтобы работало в текущей ситуации:

    1) Настроить запуск сценария в планировщике задач от имени Local System - тогда он сможет внести изменения в реестр. И пользователям никаких прав не потребуется.

    2) Касательно печати - вы нашли единственое верное решение. Разве что можно было ограничиться группой Domain Users


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    В части печати с сервера терминалов, пожалуй, Вы правы. Это единственный верный вариант решения проблемы в данной ситуации.

    Но с планировщиком заданий и редактором реестра не согласен: конечная цель — внести изменения в ветку CURRENT_USER терминального пользователя, поэтому здесь единственный возможный вариант — использовать утилиту reg в сценарии. И как я сразу-то не догадался!

    • Помечено в качестве ответа Eurisco 5 июля 2012 г. 16:45
    5 июля 2012 г. 16:45

Все ответы

  • ставить rds и adds на один сервер это очень плохая идея, независимо от взаимного расположения звезд, если уж так приперло то можно было воспользоваться виртуалками.

    а зачем это простым пользователям запускать regedit?

    27 июня 2012 г. 8:11
    Модератор
  • Вообще-то это и есть виртуалка!

    Так задумано: на случай очередного переезда офиса в новое здание съедет одна эта ВМ (с настроенными ролями AD DS, DNS, DHCP, DFS и RDS), обеспечив авторизацию всем переехавшим пользователям, а также предоставив бухгалтерии возможность работать с 1С в терминале. Если бухгалтерия в первых рядах не поедет, то она будет работать на другом сервере терминалов, который останется в офисе.

    Вообще ВМ всего 4 (по лицензии Enterprise), и на эти 4 ВМ приходится по две роли каждой из перечисленных далее служб (для отказоустойчивости): AD DS, DNS, DHCP, DFS и RDS, потом планируется еще и AD RMS.

    Есть и другие роли (в одном экземпляре, но также необходимые для обслуживания сетевой инфраструктуры): AD CS, LS, PS, WSUS, IIS и NPS.

    Кто-то скажет, что можно просто перевезти компы и настроить для каждого VPN в офис, но в этом случае всё равно придется сливать доки, базы + что делать на случай проблем с Интернетом? В общем, это не обсуждается: вышеприведенная высокотехнологичная схема перезда офиса идеально подходит при обслуживании одним человеком парка из 50 ПК, который вдобавок вскоре переезжает в полном составе.

    По поводу regedit - у меня сценарий прописывает базы 1С 7.7 всем, кто с ней работает, автоматически при входе в систему. Естесственно, 1С 7.7 хранит свои базы в реестре, в своем подразделе ветки CURRENT_USER.


    • Изменено Eurisco 28 июня 2012 г. 6:33
    27 июня 2012 г. 9:35
  • А что такого очень-очень плохого в том, чтобы разрешить пользователям работать в терминале, который установлен на secondary DC? У них нет прав, чтобы негативно повлиять на работу контроллера, вдобавок, этот контроллер не единственный, поэтому его замедление работы вследствие нагрузки, а то и вовсе перезагрузка (для установки программ) никак не повлияют на работу отстальной сети, т.к. есть primary DC (который как и рекомендовано, кроме ролей AD DS, DNS, DHCP и еще AD CS ничего более не имеет).
    • Изменено Eurisco 28 июня 2012 г. 6:32
    27 июня 2012 г. 9:43
  • Как правильно решить указанную проблему с печатью?

    Как разрешить пользователям запускать regedit?

    28 июня 2012 г. 6:34
  • Правильно - убрать роль контроллера с сервера терминалов. Эта роль автоматически предполагает более жесткий уровень безопасности. Чтобы работало в текущей ситуации:

    1) Настроить запуск сценария в планировщике задач от имени Local System - тогда он сможет внести изменения в реестр. И пользователям никаких прав не потребуется.

    2) Касательно печати - вы нашли единственое верное решение. Разве что можно было ограничиться группой Domain Users


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    • Помечено в качестве ответа Eurisco 5 июля 2012 г. 16:45
    5 июля 2012 г. 11:42
  • Правильно - убрать роль контроллера с сервера терминалов. Эта роль автоматически предполагает более жесткий уровень безопасности. Чтобы работало в текущей ситуации:

    1) Настроить запуск сценария в планировщике задач от имени Local System - тогда он сможет внести изменения в реестр. И пользователям никаких прав не потребуется.

    2) Касательно печати - вы нашли единственое верное решение. Разве что можно было ограничиться группой Domain Users


    Мнения, высказанные здесь, являются отражением моих личных взглядов, а не позиции корпорации Microsoft. Вся информация предоставляется "как есть" без каких-либо гарантий
    Follow us on TwitterFollow MSTechnetForum on Twitter

    Посетите Блог Инженеров
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html

    В части печати с сервера терминалов, пожалуй, Вы правы. Это единственный верный вариант решения проблемы в данной ситуации.

    Но с планировщиком заданий и редактором реестра не согласен: конечная цель — внести изменения в ветку CURRENT_USER терминального пользователя, поэтому здесь единственный возможный вариант — использовать утилиту reg в сценарии. И как я сразу-то не догадался!

    • Помечено в качестве ответа Eurisco 5 июля 2012 г. 16:45
    5 июля 2012 г. 16:45