none
Не выполняются netlogon скрипты пользоватлей дочернего домена при входе в терминал корневого домена. RRS feed

  • Вопрос

  • Есть 2 домена. Корневой (kanzburo.local) и дочерний (ekat.kanzburo.local) Пользователи дочернего домена при входе на терминальный сервер должны выполнять скрипты, которые подключают сетевые диски своего домена и ресурсы корневого.

    Пользователи корневого домена, при входе на этот терминальный сервер (TS) отлично выполняют свои скрипты. У каждого пользователя в User Profile остнастки Active Directory стоит запись (kb.cmd).

    Пользователи дочернего домена (ekat.kanzburo.local) не выполняют скриптов корневого домена при входе в TS. Если зайти и выполнить скрипты вручную, то все отрабатывает и подключается. Это исключает неправильное выполнение скриптов. Вот что я попробовал:

    1. Прописал в User Profile AD дочернего домена выполнение скрипта \\kanzburo.local\netlogon\kb.cmd (не помогает, не выполняется)

    2.Прописал в User Profile AD дочернего домена выполнение скрипта \\ekat.kanzburo.local\netlogon\kb.cmd (не помогает, не выполняется). Скопировал его туда

    3.Прописал в User Profile AD дочернего домена выполнение скрипта kb.cmd (не помогает, не выполняется)

    Далее я полез в групповые политики контроллера дочернего домена. Он у меня GC.

    1. Пытался применить выполнение logon script'a через Конфигурация пользователя -> Конфигурация Windows -> Сценарии (Вход/Выход из системы). Прописал там пути выполнения этих скриптов 3-мя выше перечисленными способами. Обновил политику через gpupdate /force (Не помогло)

    2. Включал обработку политики перекрестного леса (не помогает)

    3. Включал обработку политики при медленном соединении (не помогает)

    Пробовал делать все действия описанные в

    http://social.technet.microsoft.com/Forums/ru/windowsserverru/thread/6ba4e766-a0a2-47f9-b455-06153a4587ef

    Не знаю что можно еще сделать. Подскажите, может быть у кого-нибудь есть мысли?

    23 марта 2012 г. 4:57

Ответы

  • Огромное спасибо за помощь, все заработало, нашел причину. Она была в том, что на сетевом накопителе не было прав пользователя, и он не мог подключить  сетевой диск. Эта строка стояла выше всех, и пыталась выполнится. Т.к. в групповой политике не стояло отображение выполнения logon-скрипта, то я просто не видел что он висел в фоновом режиме и остальные ресурсы просто не подключались.
    23 марта 2012 г. 12:51

Все ответы

  • Проблема может быть связана с разрешением NetBIOS-имени одного домена из другого, вряд ли вы настраивали WINS вообще, либо для разрешения имен одного домена из другого. Имена в UNC-путях должны быть короткими, а не FQDN. Для справки посмотрите статью

    http://support.microsoft.com/kb/918495/en-us

    однако в ней нет информации, что предлагаемое исправление доступно для Windows Server 2003, кроме того даже после установки функциональность обновления выключена.

    Предлагаю настроить Logon-скрипты через групповые политики или посмотрите предлагаемые в статье workaround'ы.




    23 марта 2012 г. 6:53
    Модератор
  • Добавил DNS суффикс на клиентском компьютере дочернего домена. суффикс kanzburo.local. Также в GP OU, в котором находятся и компьютер и пользователь, разрешил выполнение скриптов при отключенном net-bios. Не помогло(
    23 марта 2012 г. 7:26
  • А UNC-пути переделали на короткие имена? Вручную скрипт по UNC-пути с коротким именем запускается?

    И все же, почему не устраивают logon-скрипты, запускаемые через групповые политики?

    23 марта 2012 г. 7:31
    Модератор
  • Переделал на \\kanzburo\netlogon\test.cmd

    Пробовал test.cmd

    Вручную запускается, без проблем

    В групповой политике стоит запись выполнения этого скрипта там написано \\kanzburo\netlogon\test.cmd

    Возможно нужно выполнять скрипт, который лежит именно контроллере домена? Я имея пользователя из дочернего домена (ekat.kanzburo.local) пытаюсь выполнить скрипт из kanzburo.local\netlogon\

    23 марта 2012 г. 7:38
  • Нет, если настраиваете logon-скрипт через групповые политики, то располагайте сценарий в самом объекте групповой политики (там можно нажать кнопку Show Files, и откроется нужная папка). Тогда достаточно добавить только имя файла сценария, без путей.

    Пользовательские сценарии, которые вы настраиваете, должны располагаться в папке netlogon на своем контроллере домена, они тоже указываются по имени, без пути. Не берусь сказать, насколько работоспособно ваше решение.


    23 марта 2012 г. 7:48
    Модератор
  • сделал как Вы посоветовали.

    Расположил фаил со скриптом через групповую политику в папку, через "Show Files". При этом в списке выше ничего не было.

    В user Profile в поле script тоже оставил пусто.

    На клиентской машине сделал gpupdate /force чтобы обновить политику.

    Зашел на терминальный сервер корневого домена, скрипт не отработался

    23 марта 2012 г. 8:01
  • Вы настроили logon-скрипт групповой политики в дочернем домене? Когда регистрируетесь на рабочей станции в дочернем домене, скрипт отрабатывается?
    23 марта 2012 г. 8:09
    Модератор
  • В OU. Когда регистрируюсь на рабочей станции в дочернем домене скрипт не отрабатывается
    23 марта 2012 г. 8:11
  • В OU.

    OU находится в корневом домене или в дочернем домене?
    23 марта 2012 г. 8:14
    Модератор
  • Сейчас речь идет о дочернем домене. Самое интересное, что взял другую машину, выполнил вход и скрипт отработал. Только, когда я захожу на терминальный сервер корневого домена, этот же скрипт не отрабатывается.
    23 марта 2012 г. 8:27
  • В корневом домене для OU, в котором расположен терминальный сервер, настроена политика замыкания (loopback processing policy)? Если да, то в каком режиме (merge, replace)?
    23 марта 2012 г. 8:32
    Модератор
  • Нет не была настроена. Настроил. Стоит в режиме слияния(merge). Создал *.cmd фаил, сунул его в сценарии политики OU. Почему-то не отработался.
    23 марта 2012 г. 8:47
  • Нет не была настроена.

    Ее обычно настраивают для терминальных серверов, но это вовсе не обязательное требование. Насколько я понимаю из общего описания, политика пользователя должна применяться, так что сейчас следует выяснять, почему этого не происходит на трминальном сервере.

    Вот примерный план troubleshooting'а:

    1. Посмотрите Application Log в Event Log на терминальном сервере на предмет ошибок применения групповых политик.

    2. Проверьте настройки DNS на терминальном сервере и убедитесь, что в настройках прописаны IP-адреса домен-контроллеров корневого домена (или один IP-адрес, если такой домен-контроллер - один).

    3. Зайдите под пользователем из дочернего домена в терминальную сессию (пользователю должен быть доступен Рабочий стол) и запустите утилиту gpresult. Внимательно посмотрите, какие объекты групповых политик применяются к пользователю, а если не применяются, то по какой причине.

    4. Настройте в том же GPO, где расположен logon-скрипт, еще какое-нибудь правило групповой политики, действующее на пользователей и которое вы сможете легко заметить. Проверьте, что правило применяется на терминальном сервере.

    23 марта 2012 г. 10:05
    Модератор
  • Настроил, но политики выполняются как непонятно. То выполняются, то нет. Меняю *cmd, не выполняется. Перед исправлением одни раз выполнилось на локальной машине и в терминальном сервере, а после вообще ни в какую. делал gpupdate на локальной тачке, на контроллере дочернего домена. logout делал, reboot делал, не отрабаывается. Не понимаю, что сделал не так
    23 марта 2012 г. 11:38
  • При внесении изменений в политики требуется некоторое время на репликацию, если у вас не один домен-контроллер,  и также сами политики применяются не сразу. Выполняйте на терминальном сервере gpupdate /force, чтобы обновить политики на клиенте.

    Между доменами канал случайно не медленный? ping не заблокирован, потерь пакетов нет?

    23 марта 2012 г. 12:03
    Модератор
  • Огромное спасибо за помощь, все заработало, нашел причину. Она была в том, что на сетевом накопителе не было прав пользователя, и он не мог подключить  сетевой диск. Эта строка стояла выше всех, и пыталась выполнится. Т.к. в групповой политике не стояло отображение выполнения logon-скрипта, то я просто не видел что он висел в фоновом режиме и остальные ресурсы просто не подключались.
    23 марта 2012 г. 12:51