none
2008 R2 - Добавление КД в существующий домен RRS feed

  • Вопрос

  • Доброго времени суток.
    Режим работы леса и домена 2008. 1 КД -2008, 2й КД -2008R2, соответственно подготовка леса и домена уже делались, оба КД являются DNS-серверами. Пытаюсь добавить еще 1 КД 2008R2, при работе с dcpromo довольно долго проходила проверка конфигурации DNS (минут 5), но прошла успешно, однако после этого запрашиваются логин/пароль, при вводе логина/пароля для добавления КД выдается ошибка: 
    Сетевые учетные данные.
    Операция не выполнена по следующей причине: не удалось связаться с контроллером для домена domain.local, содержащим учетную запись для данного компьютера. Сделайте компьютер членом группы, присоединитесь к домену до повторения попытки повышения роли. "Отказано в доступе".
    Использованная учетная запись пользователя имеет права администратора домена, предприятия и схемы. Сама машина находится в домене, в котором пытаюсь добавить контроллер. В качестве первичного и альтернативного DNS сервера на этой машине заданы соответственно 1й и 2й КД, nslookup резолвит и короткие имена контроллеров, и fqdn. Подскажете в чем может быть проблема?

    update: \\domain.local\sysvol доступен, \\domain.local\NETLOGON - нет. net share говорит что папки NETLOGON нет ни на одном из 2х текущих КД. 

    В событиях от источника NETLOGON есть такое:
    Служба Netlogon не может создать общий ресурс сервера C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS. Ошибка: 
    Не удается найти указанный файл. В C:\Windows\SYSVOL\sysvol\domain.local\ есть 2 каталога Policies и StarterGPOs, о каком файле идет речь?

    Машину пробовал вывести и ввести в домен с удалением учетной записи компьютера и записи DNS.

    Пробовал перезапустить оба КД, в событиях указано что служба NETLOGON перезапущена успешно. 

    dcdiag: http://pastebin.com/buunjP8w

    Очень странно что pdc якобы отключен, ведь держатель pdc - sd.domain.local и netdom query fsmo это подтверждает.

    в дебаге dcpromo: http://pastebin.com/hfLb6H3x





    30 сентября 2014 г. 3:24

Ответы

  • Во-первых, репликация SYSVOL у вас идет, скорее всего, с помощью DFSR, а не FRS (функциональный уровень домена - Win2008). Так что смотрите именно этот журнал.

    Но если есть сомнение, то проверьте состояние миграции FRS-DFSR командами

    dfsrmig /GetGlobalState

    dfsrmig /GetMigrationState

    (мигарция запросто могла быть не доведена до конца при повышении функционального уровня домена, если таковое имело место).

    Если состояние миграции - eliminated(3), то используется DFSR, Start(0) - FRS, а все остальные варианты надо лечить.


    Слава России!

    30 сентября 2014 г. 9:24
  • Почему-то у вас не ищется контроллер домена.

    Проверка имени домена с помощью nslookup неэффективна - в реальности КД ищется через совсем другие записи DNS (записи SRV). Проверить можно с помощью команды nltest

    nltest /dnsgetdc:domain.local

    Полностью поиск КД проверяется командой

    nltest /dsgetdc:domain.local /force

    В политиках проверьте, дано ли право подключения к компьютеру по сети к КД всем прошедшим проверку, если нет - дайте.

    PS IPv6 часто настраивается сам.

    PPS Найденая вами статья Knowledge base- для Win2K и Win2K3, для Win2K8 и выше она не совсем применима.


    Слава России!

    1 октября 2014 г. 8:33
  • Ну, контроллер домена, вроде как, находится в сети без проблем.

    PS Записи для AS можно просто вычистить вручную - см. SRV-записи в поддоменах _tcp и _udp и в зоне поддомена _msdcs (этот поддомен для корневого домена леса начиная с Win2K3 обычно делается отдельной зоной, но если её нет - смотрите поддомена в зоне домена AD). Смотрите, есть ли право на подключение к нему по сети (и нет ли явного запрета на это для, например, локальных администраторов). Для проверки можете просто попытаться подключиться к любой общей папке на нем с учетными данными администратора.


    Слава России!

    1 октября 2014 г. 13:08
  • Теперь - про инструкцию.

    Проводник (Explorer) для работ с SYSVOL лучше не использовать, т.к. он вместо ссылок создаст дополнительные папки (так уж он устроен), предупреждение было об этом.

    Вообще-то вам файлы копировать сейчас не потребуется, но если будете - используйте команды copy или xcopy. Папку C:\WINDOWS\SYSVOL\staging\domain надо создать, если её нет на каждом КД. После этого ссылка в папке "staging areas" должна заработать.  Папки ниже C:\WINDOWS\SYSVOL\DOMAIN - Policies и Scripts - на других КД можно не создавать - их создаст репликация.

    По детальной инструкции

    3. Команду

    ntfrsutl ds |findstr /i "root stage"

    нужно запускать в командной строке в режиме администратора. Ко всем остальным командам это тоже относится.

    4,5. Без команды linkd из Resourse Kit Tools для Win2K3 вполне можно обойтись

    Посмотреть ссылки (они же - точки повторного разбора (reparse points)) в Win2K8 можно обычной командой dir - она в выводе укажет для них тип (в нашем случае - <JUNCTION>) и путь, на который указывает ссылка (в квадратных скобках).

    Создать точку повторного разбора можно командой mklink :

    mklink /j имя_ссылки имя_папки_на_котрую_указывает_ссылка

    6. Это размер области временного хранения файлов для репликации, настраивается через указанный ключ реестра. Свободное место на C: соответсвующего размера должно быть - иначе будут проблемы с репликацией.

    7. Все манипуляции с удалением и последующим копированием файлов в SYSVOL\domain можете не производить - они для случая, когда содержимое SYSVOL повреждено и восстановлено из другого источника. У вас содержимое уже есть и лежит в нужном месте.

    "Контроллеры не участвующие в DFS-репликации" у вас все: рекомендация в статье дана на всякий случай, когда в домене используются оба механизма. Такое возможно в процессе миграции, но это - не ваш случай.

    Последний вопрос по поводу процедуры -в инструкции есть некоторые неточности: в п.1 сказано остановить на всех КД Службу репликации файлов (NtFRS) и изменить её тип запуска на "Отключено", чтобы она не запустилась случайно в процессе всех манипуляций. Все указанные в инструкции манипуляции (кроме вызова команды ntfrsutl - там в статье неточность) должны производиться при остановленной службе NtFRS. Но команду

    ntfrsutl ds |findstr /i "root stage"

    надо будет запустить до остановки службы.

    По минимуму (если опустить все проверки и восстановления папок и других параметров) в вашем случае нужно:

    а) остановить NtFRS на всех КД;

    б) изменить значение BurFlags в реестре на d4 на референсном КД и d2 - на остальных;

    в) Запустить NtFRS на всех КД.


    Слава России!

    3 октября 2014 г. 11:52
  • Значения D2/D4 в Burflags после запуска службы NtFRS этой самой службой сбрасываются, т.к. они лишь однократно указывают режим инициализации этой службы (или набора репликации, если установлены для какого-то конкретного набора).

    Слава России!

    8 октября 2014 г. 8:48

Все ответы

  • update: \\domain.local\sysvol доступен, \\domain.local\NETLOGON - нет. net share говорит что папки NETLOGON нет ни на одном из 2х текущих КД.  В событиях от источника NETLOGON есть такое:
    Служба Netlogon не может создать общий ресурс сервера C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS. Ошибка: 
    Не удается найти указанный файл. В C:\Windows\SYSVOL\sysvol\domain.local\ есть 2 каталога Policies и StarterGPOs, о каком файле идет речь?


    Речь идёт именно о той самой папки SCRIPTS в папке domain.local, которая указана в сообщении. Именно она делается общей под именем NETLOGON. Просто создайте эту папку на одном из КД, дождитесь ее репликации на другой и перезапустите на обоих службу Netlogon.

    Возможно именно отсутствие этой общей папки и препятствует успешному выполнению dcpromo (а проверить это, при желании, можно, просмотрев файл %SystemRoot%\Debug\dcpromo.log ).


    Слава России!

    30 сентября 2014 г. 8:55
  • Спасибо за ваш ответ, я тут сделал глупость, нашел вот такое решение:

    "в реестре в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters создал строковый параметр Scripts и указал путь на папку Policies например C:\WINNT\SYSVOL\sysvol\имя_домена\Policies "

    перезапустил службу, шара NETLOGON создалась, но появилось событие: 

    Произошла следующая ошибка при чтении параметра 'Scripts' в разделе Параметры реестра  Netlogon:
    Синтаксическая ошибка в имени файла, имени папки или метке тома.

    Имеет смысл удалить шару NETLOGON, создать папку scipts в C:\Windows\SYSVOL\sysvol\domain.local\ и перезапустить службу? Шара NETLOGON должна создаться корректно?

    30 сентября 2014 г. 9:01
  • Имеет смысл удалить созданный в реестре параметр Scripts  и создать папку.

    Слава России!

    30 сентября 2014 г. 9:05
  • Спасибо за ваш ответ.

    Так и сделал, шара создалась заново, ошибок от NETLOGON в событиях нет.

    Но встретилась другая проблема: если на 1м КД не было шары NETLOGON, то на 2м КД нет ни sysvol, ни NETLOGON. В журнале репликации DFS ошибок нет, но в журнале службы репликации файлов есть событие 13568. Вроде нашел как полечить: http://sysadmin-blog.blogspot.ru/2012/09/event-id-13568-source-ntfrs.html. НО на этом КД в в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\ нет каталога Parameters, его тоже стоит создать вручную?

    P.S. этот кд вообще странный, когда он мне достался, я обратил внимание что он какой-то "обрезанный", у многих сервисов в реестре не хватает кучи веток, параметров и т.д. (например w32time и другие). избавлюсь от него после введения нового КД.

    30 сентября 2014 г. 9:15
  • Во-первых, репликация SYSVOL у вас идет, скорее всего, с помощью DFSR, а не FRS (функциональный уровень домена - Win2008). Так что смотрите именно этот журнал.

    Но если есть сомнение, то проверьте состояние миграции FRS-DFSR командами

    dfsrmig /GetGlobalState

    dfsrmig /GetMigrationState

    (мигарция запросто могла быть не доведена до конца при повышении функционального уровня домена, если таковое имело место).

    Если состояние миграции - eliminated(3), то используется DFSR, Start(0) - FRS, а все остальные варианты надо лечить.


    Слава России!

    30 сентября 2014 г. 9:24
  • Ну начнем с того что репликация SYSVOL у меня вообще не идет :D

    C:\Windows\system32>dfsrmig /GetGlobalState

    Миграция DFSR еще не инициализирована. Чтобы начать миграцию,
    установите глобальное состояние в нужное значение.
    C:\Windows\system32>dfsrmig /GetMigrationState

    Миграция DFSR еще не инициализирована. Чтобы начать миграцию,
    установите глобальное состояние в нужное значение.
    C:\Windows\system32>

    Я никогда не поднимал уровень леса и домена, начал работать с 2008R2. Этот домен как мне сказали повышали с 2003 и похоже действительно миграция не доведена до конца. Сейчас буду изучать как провести миграцию с FRS на DFS.

    30 сентября 2014 г. 9:38
  • Да репликация SYSVOL у вас должна идти с помощью FRS. И, прежде чем проводить миграцию, её надо починить.

    А судя по дополнительным сведениям, чинить стоит путем понижения "странного" КД и дальнейшим разбирательством с ним (возможно, там проще переставить систему).

    А сейчас просто попробуйте добавить тот КД, который вы хотели добавить вначале, при выключенном "странном" КД. Если всё (кроме репликации со "странным" КД) будет нормально (проверяется это командой dcdiag примерно через час после загрузки КД), то можно будет спокойно, имея уже 2 работоспособных контроллера, заняться этим "странным" КД.


    Слава России!

    30 сентября 2014 г. 10:11
  • Спасибо за ответ.

    Попробовал добавить КД еще раз - та же проблема, но это при включенном "странном" КД, он держатель ролей хозяина именования домена и схемы, может стоит сначала мигрировать роли на 1й КД, потом потушить странный и попробовать еще раз добавить КД?

    30 сентября 2014 г. 10:27
  • Schema и Domain Naming master при добавлении КД в домен не задействуются, но вот при выключенном КД - держателе роли RID Master (а это тоже небось "странный" КД) второй контроллер домена вы нормально не добавите - он не сможет получить пул номеров RID.

    Так что попробуйте перенести роли. Только роли именно переносите, а не захватывайте (seize) с помощью ntdsutil.

    А вот если не получится, то надо выбирать, что делать: либо пытаться вылечить проблему, либо понизить "странный" КД принудительно и теперь уже захватить роли.


    Слава России!

    30 сентября 2014 г. 10:42
  • Нет, странный держатель только тех ролей, который я упомянул. Сейчас потушу и попробую еще раз.
    30 сентября 2014 г. 10:44
  • Беда, даже с выключенным странным КД та же ошибка при попытке добавить КД. Даже не знаю куда еще посмотреть.
    30 сентября 2014 г. 11:03
  • Для начала - в файл dcpromo.log (полный путь см. выше).


    Слава России!

    30 сентября 2014 г. 11:30
  • Доброго дня.

    В dcpromo.log такая же проблема, которую я выкладывал в стартовом посте:

    09/30/2014 18:02:18 [INFO] Promotion request for replica domain controller
    09/30/2014 18:02:18 [INFO] DnsDomainName  guei.alt
    09/30/2014 18:02:18 [INFO] 	ReplicaPartner  SD.guei.alt
    09/30/2014 18:02:18 [INFO] 	SiteName  Default-First-Site-Name
    09/30/2014 18:02:18 [INFO] 	DsDatabasePath  C:\Windows\NTDS, DsLogPath  C:\Windows\NTDS
    09/30/2014 18:02:18 [INFO] 	SystemVolumeRootPath  C:\Windows\SYSVOL
    09/30/2014 18:02:18 [INFO] 	Account (NULL)
    09/30/2014 18:02:18 [INFO] 	Options  1179840
    09/30/2014 18:02:18 [INFO] Validate supplied paths
    09/30/2014 18:02:18 [INFO] Validating path C:\Windows\NTDS.
    09/30/2014 18:02:18 [INFO] 	Path is a directory
    09/30/2014 18:02:18 [INFO] 	Path is on a fixed disk drive.
    09/30/2014 18:02:18 [INFO] Validating path C:\Windows\NTDS.
    09/30/2014 18:02:18 [INFO] 	Path is a directory
    09/30/2014 18:02:18 [INFO] 	Path is on a fixed disk drive.
    09/30/2014 18:02:18 [INFO] Validating path C:\Windows\SYSVOL.
    09/30/2014 18:02:18 [INFO] 	Path is on a fixed disk drive.
    09/30/2014 18:02:18 [INFO] 	Path is on an NTFS volume
    09/30/2014 18:02:18 [INFO] Start the worker task
    09/30/2014 18:02:18 [INFO] Request for promotion returning 0
    09/30/2014 18:02:18 [INFO] Forcing time sync
    09/30/2014 18:02:18 [INFO] Принудительная синхронизация времени с SD.guei.alt
    09/30/2014 18:02:19 [INFO] Поиск контроллера для домена guei.alt, который содержит учетную запись DC$
    09/30/2014 18:02:19 [ERROR] Failed to find a DC for domain guei.alt: 5
    09/30/2014 18:02:19 [ERROR] Failed to get domain controller for account DC$ (5)
    09/30/2014 18:02:19 [INFO] Error - Не удалось связаться с контроллером для домена guei.alt, содержащим учетную запись для данного компьютера. Сделайте компьютер членом группы, присоединитесь к домену до повторения попытки повышения роли.
     (5)
    09/30/2014 18:02:19 [INFO] Предпринятая контроллером домена операция завершена
    09/30/2014 18:02:19 [INFO] DsRolepSetOperationDone returned 0

    Машину я уже пробовал вывести из домена и ввести (с удалением учетной записи компьютера и записей DNS). В dcdiag теперь проверка NETLOGON проходит успешно:

    Запуск проверки: NetLogons
    
             ......................... SD - пройдена проверка NetLogons

    Также в dcdiag больше не пишет что держатель pdc отключен.

    Из ошибок только проблема с билетом керберос для одной машины, на которой вероятнее всего просто время рассинхронизировалось более чем на 5 минут, и эта машина сейчас меня не интересует. И уже известные ошибки репликации Sysvol:

    Запуск проверки: FrsEvent
    
             За последние 24 часа после предоставления SYSVOL в общий доступ
    
             зафиксированы предупреждения или сообщения  об ошибках.  Сбои при
    
             репликации SYSVOL могут стать причиной проблем групповой политики. 
             ......................... SD - не пройдена проверка FrsEvent
    
          Запуск проверки: DFSREvent
    
             За последние 24 часа после предоставления SYSVOL в общий доступ
    
             зафиксированы предупреждения или сообщения  об ошибках.  Сбои при
    
             репликации SYSVOL могут стать причиной проблем групповой политики. 
             ......................... SD - пройдена проверка DFSREvent
    DFS пройдена - но миграция на нее еще не производилась, хотя подготовку я делал. FRS - не пройдена, это уже известно. Но в чем же причина того, что я не могу добавить еще 1 КД, с NETLOGON проблем нет и шара доступна по сети. Подскажите пожалуйста куда еще можно посмотреть.

    1 октября 2014 г. 2:30
  • Провел такой тест: вывел этот компьютер из домена еще раз, удалил учетную запись, записи DNS удалились. Потушил "странный" КД, пытаюсь добавить КД еще раз, но в этот раз машина не в домене (уже так делал - работает нормально), но выдалась та же ошибка, те же строки в логе И после завершения мастера появилось сообщение о том, что изменилось членство в домене этой машины и ее нужно перезагрузить (она была в WORKGROUP), НО после перезагрузки она не встала в домен domain.local, а встала в воркгруппу "DOMAIN". Вот такая странность.

    При этом руками я машину в домен вводил нормально (ну по крайней мере в DSA учетка была без "стрелки вниз" и в свойствах системы было указано что она в домене).


    1 октября 2014 г. 2:53
  • Нашел вот такую статью: https://support2.microsoft.com/kb/2002413?wa=wsignin1.0 где говорится что такое возможно если в дфеолтной политике контроллеров домена отсутствует "Разрешение доверия к учетным записям компьютеров и пользователей при делегировании". Посмотрел дефолтную политику для КД, сравнил с дефолтной политикой КД на другом домене - различия колоссальные (но проблемный домен повышался с 2000 если мне дали верную информацию, а сравнивал я с тем, который изначально был 2008R2). Добавил разрешение, указанное в статье, сделал gpupdate, в rsop изменения отобразились, но это не помогло. Не знаю правил ли эту политику кто-то до меня.

    P.S. если я не уверен менял ли кто-то политику контроллеров (хотя она не выглядит как по умолчанию), то дефолтную доменную политику меняли точно и много. Что мне стоит в ней искать, из-за чего может возникать такая ошибка при попытке добавления КД. Стоит ли восстановить политику контроллеров с помощью dcgpofix?

    P.S.2: на КД не выключен ipv6, и есть адрес (непонятно откуда взялся, dhcp нет), может ли быть такая проблема из-за этого? Оба КД являются DNS серверами, вот например что пишет nslookup:

    C:\Users\nokogerra>nslookup domain.local
    ╤хЁтхЁ:  sd.domain.local
    Address:  194.135.107.1

    ╚ь :     domain.local
    Addresses:  2002:c287:6b01::c287:6b01
              2002:c287:6b04::c287:6b04
              194.135.107.1
              194.135.107.4

    1 октября 2014 г. 4:03
  • Нашел http://support.microsoft.com/kb/308311/ru где указано что такая ошибка может быть из-за нехватки прав на папку %windir%\NTDS и файл %windir%\system32\ntds.dit, в безопасности папки у DOMAIN\Администраторы полный доступ, на с файлом проблемы - доступ у DOMAIN\Администраторы только на чтение и выполнение, изменить это нельзя, владельцем числится TrustedInstaller а не система. Думаю владельца можно сменить, но не скажется ли это негативно. К тому же в статье указано что в логах dcpromo должно быть упоминание ntds.dit, но этого нет.

    update: на машине, которую пытаюсь сделать КД не применяется групповая политика компьютера, пишет вот что:

    C:\Users\xxxx>gpupdate /target:computer /force
    Обновление политики...

    Не удалось успешно обновить политику компьютера. Обнаружены следующие ошибки:

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

    Чтобы диагностировать сбой, просмотрите журнал событий или запустите GPRESULT /H
     GPReport.html из командной строки для просмотра сведений о результатах группово
    й политики.

    Возможно ли это из-за того, что у КД есть ipv6 адрес? Хотя опять же не пойму откуда он вообще мог взяться.

    1 октября 2014 г. 6:21
  • Почему-то у вас не ищется контроллер домена.

    Проверка имени домена с помощью nslookup неэффективна - в реальности КД ищется через совсем другие записи DNS (записи SRV). Проверить можно с помощью команды nltest

    nltest /dnsgetdc:domain.local

    Полностью поиск КД проверяется командой

    nltest /dsgetdc:domain.local /force

    В политиках проверьте, дано ли право подключения к компьютеру по сети к КД всем прошедшим проверку, если нет - дайте.

    PS IPv6 часто настраивается сам.

    PPS Найденая вами статья Knowledge base- для Win2K и Win2K3, для Win2K8 и выше она не совсем применима.


    Слава России!

    1 октября 2014 г. 8:33
  • Спасибо за ваш ответ!

    Я все таки выключил ipv6, но это мало что изменило: КД долго пытался применить политики, в rsop ошибки, опять нет сети. Сделал привязку сети к сайту - gpupdate на КД прошел успешно, но на клиентах (из этой же сети) - нет.

    C:\Windows\system32>nltest /dnsgetdc:domain.local
    Список контроллеров домена в псевдослучайном порядке с учетом приоритетов и весо
    в SRV:
    Не специфический для сайта:
       second.domain.local  194.135.107.4
       sd.domain.local  194.135.107.1
       as.domain.local  194.135.107.17
    ПРЕДУПРЕЖДЕНИЕ. Нет доступных записей заданного типа
    Команда выполнена успешно.

    Очень странно - ведь AS уже давно не контроллер домена, он сейчас используется как DNS, но от него планирую избавиться, в dsa как домен контроллер он не указан. Убрать упоминание о нем как о КД можно с помощью ntdsutil?

    Предупреждение смущает, что это может значить? Кстати в зонах прямого просмотра domain.local в _msdcs\dc\_sites\Default_first_dite\_tcp есть _kerberos и _ldap записи для 4х машин, кроме SD и SECOND (которые являются КД) упомянут как раз этот AS и GW, которого даже как машины уже давно нет. Стоит их удалить, я полагаю?

    C:\Windows\system32>nltest /dsgetdc:domain.local /force
               Контроллер домена: \\SD.domain.local
          Адрес: \\194.135.107.1
         GUID DOM: d629e432-1427-4916-b609-e588c91b77c5
         Имя DOM: domain.local
      Имя леса: domain.local
     Имя сайта контроллера домена: Default-First-Site-Name
    Имя нашего сайта: Default-First-Site-Name
            Флаги: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN
    DNS_FOREST CLOSE_SITE FULL_SECRET
    Команда выполнена успешно.

    Вот здесь вроде верно - SD сейчас единственный включенный контроллер домена.




    1 октября 2014 г. 8:47
  • Ну, контроллер домена, вроде как, находится в сети без проблем.

    PS Записи для AS можно просто вычистить вручную - см. SRV-записи в поддоменах _tcp и _udp и в зоне поддомена _msdcs (этот поддомен для корневого домена леса начиная с Win2K3 обычно делается отдельной зоной, но если её нет - смотрите поддомена в зоне домена AD). Смотрите, есть ли право на подключение к нему по сети (и нет ли явного запрета на это для, например, локальных администраторов). Для проверки можете просто попытаться подключиться к любой общей папке на нем с учетными данными администратора.


    Слава России!

    1 октября 2014 г. 13:08
  • Спасибо что продолжаете помогать с моей проблемой, больше нигде так активно не отозвались.

    Удалил все записи _ldap, _kerberos, _kpasswd, _gc отовсюду. Единственно, здесь тестировали SCCM и в зоне domain.local\DomainDnsZones\_tcp есть запись _ldap для SCCM, похоже создалась автоматически. Сейчас nltest /dnsgetdc:domain.local выдает: 

    Список контроллеров домена в псевдослучайном порядке с учетом приоритетов и весо
    в SRV:
    Не специфический для сайта:
       sd.domain.local  194.135.107.1
       second.domain.local  194.135.107.4
    Команда выполнена успешно.

    Т.е. те 2 машины, которые действительно являются контроллерами домена (но second все еще выключен). Правда если выполнить ту же команду на pdc (SD), то строка такая:

    sd.domain.local  194.135.107.1  ::1, видимо из-за отключения ipv6?

    Не совсем понял где в политиках настраивается подключение к КД для всех прошедших проверку?

    Я создал простую шару на КД, на чтение для всех, зашел на другую машину домена под администратором домена и подключился к этой шаре нормально, этого достаточно для проверки? Или стоит проверить в политике, только я не уверен где искать это право подключения?

    update: похоже нашел в политике контроллеров в локальные политики\предоставление прав пользователям:

    Доступ к компьютеру из сети BUILTIN\Администраторы, DOMAIN\Пользователи домена, DOMAIN\Контроллеры домена,  DOMAIN\Администраторы домена, DOMAIN\administrator

    p.s. пока ввести КД все еще не могу.


    2 октября 2014 г. 2:36
  • Спасибо огромное!

    И так: добавил в политику контроллеров домена:

    Все

    NT AUTHORITY\КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПИРЯТИЯ

    NT AUTHORITY\Прошедшие проверку

    добавил их исходя из сравнения с политикой КД на другом домене. КД добавился, но проблемы с репликацией SYSVOL также присутствуют - в папке SYSVOL пусто. Сейчас необходимо решить проблемы с FRS и лишь потом произвести миграцию на DFS, верно? Можем продолжить обсуждение здесь, если вы не против и у вас не пропало желание помогать мне, или мне стоит завести новую тему?

    2 октября 2014 г. 3:20
  • Сейчас имею 3 контроллера домена:

    1. SD 2008 (pdc, rid, хозяин инфраструктуры, глобальный каталог)

    2. Second 2008R2 (хозяин схемы, именования домена, глобальный каталог)

    3. DC 2008R2 (глобальный каталог)

    Sysvol на Second и DC не реплицируется.

    В журнале DFS на SD событие 1202:

    Службе репликации DFS не удалось связаться с контроллером домена , чтобы получить сведения о конфигурации. Репликация остановлена. Служба вновь попытается это сделать во время следующего цикла опроса, который произойдет через 60 мин. Это событие может быть вызвано проблемами с подключением TCP/IP, брандмауэром, доменными службами Active Directory или DNS. 
     
    Дополнительные сведения:  
    Ошибка: 160 (Неверны один или несколько аргументов.)

    Хотя дальше идут события 1206:

    Служба репликации DFS успешно связалась с контроллером домена SD.domain.local для получения сведений о конфигурации.

    и 2010:

    Служба репликации DFS обнаружила, что все реплицированные папки на томе  C: были отключены или удалены. 
     
    Дополнительные сведения: 
    Том: 5B07FE53-20F6-11E3-9B7F-806E6F6E6963

    На Second последняя ошибка в журнале DFS (тоже событие 1202) была 3 дня назад.

    На DC также есть событие 1202 и 1302:

    Служба репликации DFS обнаружила ошибку во время записи в файл журнала отладки. Сбой записи в журнал отладки может произойти из-за переполнения диска, сбоя в работе диска или достижения папкой, содержащей журналы, предела квоты. Ведение журнала будет отключено до тех пор, пока эта ошибка не будет исправлена. 
     
    Дополнительные сведения: 
    Ошибка: 1307 (Этот идентификатор безопасности не может быть назначен владельцем этого объекта.) 
    Путь к файлу журнала отладки: C:\Windows\Debug\ 
    Наибольшее количество файлов журнала отладки: 999 
    Серьезность сведений в журнале отладки: 4 
    Наибольшее количество сообщений журнала отладки: 10000

    Хотя миграцию на DFS я не проводил, и лишь сделал подготовку:

    dfsrmig /setGlobalState 1

    Сейчас на SD и Second:

    C:\Users\nokogerra>dfsrmig /getglobalstate
    
    Не удалось создать файл журнала миграции DFSR. Ошибка 5
    Текущее глобальное состояние DFSR: "Пуск"
    Успешно.
    
    C:\Users\nokogerra>dfsrmig /getmigrationstate
    
    Не удалось создать файл журнала миграции DFSR. Ошибка 5
    Все контроллеры домена успешно мигрировали в глобальное состояние ("Пуск").
    Состояние миграции согласовано на всех контроллерах домена.
    Успешно.

    На DC то же самое, но по поводу файла журнала миграции ошибка 1307.

    в журналах frs (служба репликации файлов) на SD и Second ошибка 13568 и рекомендация задать значение 1 параметру "Enable Journal Wrap Automatic Restore" в "System\CurrentControlSet\Services\NtFrs\Parameters", но на Second вообще нет каталога Parameters в ntfrs, следует создать его вручную?

    На DC такой ошибки frs нет, но есть предупреждения что есть проблемы репликации с Second.

    задать значение 1 следует только на Second и DC, или на всех контроллерах?

    В общем я слегка потерялся в каком порядке мне действовать и не понятно что повлечет за собой изменение параметр Enable Journal Wrap Automatic Restore, написано что автоматическое восстановление может привести к недоступности данных и нужно установить значение в 0, но на каком этапе тоже не ясно.

    Извиняюсь за стену текста.


    2 октября 2014 г. 4:42
  • Результат nslookup /dnsdisg с SD меня настораживает - похоже, он не способен найти другие контроллеры доменов. Связано это, скорее всего, с настройкой серверов DNS на подключении (смотреть командой ipconfig /all): каждый КД в простейшем варианте настройки должен иметь там адреса свой и любого другого КД (и не иметь адресов, не являющихся адресами КД).

    Если перенастройка DNS потребуется, то через некоторое вермя (часа достаточно) проверьте репликацию AD с помощью repadmin /showrepl на каждом из КД.

    Политику вы изменили правильно.

    Миграцию репликации вы начали зря: необходимым условием для нее служит исправность репликации SYSVOL через FRS. А с учётом того, что второй КД у вас находится в нестабильном состоянии, я бы рекомендовал вообще не выполнять миграцию до его понижения. Сейчас я рекомендую пока откатить миграцию в состояние 0 и вылечить FRS.

    Проблема с репликации SYSVOL с помощью FRS у вас прежде всего на SD. А т.к. другой актуальной копии SYSVOL у вас в домене нет, то я не рекомендую использовать Journal Wrap Automatic Restore, надежнее было бы восстановить SYSVOL вручную, согласно рекомендациям статьи 315457 MS KB, при этом шаги с 3 по 7.e (восстановление структуры и содержимого SYSVOL на референсном КД) раздела Detailed Steps  в вашем случае можно пропустить, т.к. у вас уже есть полноценное содержимое  SYSVOL на КД SD, который в вашем случае можно считать рефересным. Но, на всякий случай, проверьте, что все упомянуте там папки и ссылки на папки у вас есть.

    Понизить SECOND можно, в принципе, до исправления FRS - главное, чтобы репликация AD работала (если не работает - придётся понижать принудительно и удалять следы его из AD).


    Слава России!

    2 октября 2014 г. 17:36
  • Доброго времени суток и спасибо за ответ.

    1. Не совсем понял что такое nslookup /dnsdisg, не нашел такого в справке по nslookup. Если речь о nltest, то да, странноватые результаты. На SD (pdc, rid infrastucture, GC) и DC (GC) вывод такой:

    Не специфический для сайта:
       sd.domain.local  194.135.107.1  ::1
       dc.domain.local  194.135.107.9
       second.domain.local  194.135.107.4
    Команда выполнена успешно.

    Хотя до того, как DC был введен в домен, на нем в результате nltest /dnsgetdc SD отображался без ::1.

    На Second вот такой вывод: 

    Не специфический для сайта:
       dc.guei.alt  194.135.107.9
       sd.guei.alt  194.135.107.1
       second.guei.alt  2002:c287:6b04::c287:6b04  194.135.107.4
    Команда выполнена успешно.

    Сейчас это единственный КД с не выключенным ipv6, на DC я выключил ipv6 до ввода в домен, на SD (который является КД уже давно) - буквально сутки назад.

    На рядовом клиенте (например, моя машина):

    Не специфический для сайта:
       sd.guei.alt  194.135.107.1
       dc.guei.alt  194.135.107.9
       second.guei.alt  194.135.107.4
    Команда выполнена успешно.
    Т.е. без всяких единиц.

    В качестве DNS серверов на интерфейсах всех КД указаны только они сами и другие КД. По этому поводу меня просветили недавно. В общем на контроллерах домена похоже нормально отображаются машины, для которых есть SRV-записи _ldap, _kerberos, меня смущает только ::1. Что это и стоит ли из-за этого беспокоиться?

    2. По поводу политики контроллеров домена - там до сих пор много отличий (сравнивал с девственной политикой КД на домене 2008R2), стоит ли попробовать восстановить политику с помощью dcgpofix и стоит ли игнорировать схему?

    3. По поводу отката миграции - я уже делал dfsrmig /setglobalstate 0, на всех КД вывод dfsrmig /getmigrationstate такой:

    Не удалось создать файл журнала миграции DFSR. Ошибка 5
    Все контроллеры домена успешно мигрировали в глобальное состояние ("Пуск").
    Состояние миграции согласовано на всех контроллерах домена.
    Успешно.
    Единственное, что на DC ошибка журнала миграции DFSR не 5, а 1307. Но есть сомнение: значение параметра SysvolReady в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameter на SD равно 1, на остальных КД равно 0. Означает ли это что миграция откачена и можно приступить к ручному восстановлению репликации, или нужно изменить значение этого параметра вручную?

    P.S. никогда не встречал понятия "референсный КД", перевод вроде "дающий рекомендации" не внес ясности, что же все таки означает это понятие?
    3 октября 2014 г. 3:14
  • Изучил инструкцию по восстановлению репликации, но много неясностей возникло. Если накидать кратко:

    1. На всех КД остановить службу FRS и отключить ее. - понятно.

    2. Выбрать "референсный КД", Sysvol которго будет авторитетной. Для этого задать параметру BurFlags в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID значение D4. - понятно.

    3. Удостовериться что на всех КД есть соответствующие папки и ссылки в SYSVOL. Также сказано создать недостающие папки вручную. НЕ использовать Windows эксплорер для копирования или перемещения контента Sysvol или reparse точки могут быть повреждены (Do not use Windows Explorer to move or copy contents of the SYSVOL tree, or the reparse points may be damaged.). - последнее предложение не совсем понятно.

    \SYSVOL\staging\domain нет ни на 1м КД - просто создать вручную?

    \SYSVOL\domain\Policies нет на DC и Second (т.к. репликация похоже никогда не работала) - создать вручную?

    \SYSVOL\domain\scripts – нет на DC и Second, на SD тоже не было, из-за этого не создавалась шара NETLOGON$, поэтому эту папку я создал вручную. Создать на DC и Second тоже?

    Удостоверьтесь что существуют следующие “reparse” точки:

    \SYSVOL\staging areas\DNSDomainName Есть везде, но к ней нет доступа (это нормально?), она указывает на \SYSVOL\staging\domain.

    Далее идет инструкция из 10 пунктов:

    1. Запустите cmd и т.д. - понятно.

    2. На каждом КД выполните net start FRS (она была отключена, т.е. видимо подразумевается ее предварительное включение). - понятно?

    3. Получить расположение корневой директории набора реплики SYSVOL: ntfrsutl ds |findstr /i "root stage". Команда должна вернуть

    Root: C:\WINNT\SYSVOL\domain
    Stage: C:\WINNT\SYSVOL\staging\domain, но возвращает:

    C:\>Ntfrsutl ds |findstr /i "root stage"
    FINDSTR: Не удается открыть stage
    C:\>Ntfrsutl ds |findstr /i "root"
    C:\>

    не работает

    4. Linkd %systemroot%\SYSVOL\SYSVOL\ DNSDomainname, должно быть возвращено:Source DNS DomainName is linked to %systemroot%\SYSVOL\domain. Но команды linkd нет, нашел ее в Windows 2003 Resource Kit Tools, но такого набора для 2008 или 2008R2 не обнаружил.

    5. linkd "%systemroot%\SYSVOL\staging areas\", должно быть возвращеноSource DNS Domain Name is linked to %systemroot%\SYSVOL\Staging\domain. 

    Если возвращены не верные значения, то нужно пересоздать ссылки с помощью linkd - но команды опять же нет.

    6. Удостоверьтесь что на всех контроллерах домена достаточно “staging space”.
    Нужно узнать размер %SysteomRoot%\SYSVOL\domain, чтобы настроить размер папки “staging” нужно задать значение Staging Space Limit in KB в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters.
    Какой размер, при чем тут размер папки  %SysteomRoot%\SYSVOL\domain – не понятно при чем тут размер \SYSVOL\domain. Вообще не ясен этот пункт.

    7. На референсном КД создайте "хороший" набор политик и скриптов и поместите их во временную папку за пределами SYSVOL. Сравнил GPO в dsa.msc и Sysvol\domain\policies - полное совпадение. Далее сказано очистить содержимое папок Sysvol\domain\ и Sysvol\staging\domain. После этого сказано перенести содержимое временной папки в Sysvol\domain - вопрос зачем вообще было оттуда что-то удалять? Похоже на перемещение из пустого в порожнее.

    Далее на всех КД кроме референсного задать значение BurFlags в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID равным D2.

    Для контроллеров, не участвующих в DFS-репликации установить D2 в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\ProcessatStartup\BurFlags - это что вообще значит, они по идее все не участвуют в DFS-репликации, ведь речь идет о восстановлении FRS-репликации?

    Используйте Replica Set Parent в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\SYSVOL Seeding\DOMAIN SYSTEM VOLUME (SYSVOL SHARE)  чтобы указать КД-источник репликации - уже указан SD.domain.local.

    8. Для всех контроллеров кроме референсного очистите содержимое папок \Sysvol\domain и \Sysvol\staging\domain - не проблема, в них и так пусто. - понятно.

    9. Для всех контроллеров кроме референсного перезапустите FRS и удостоверьтесь что шары NETLOGON$ и SYSVOL$ присутствуют. Установить тип запуска FRS - Автоматически.

    И вопрос по поводу самой процедуры - не понятен порядок, после установки D4 на SD на нем нужно перезапустить службу FRS, потом перезапустить ее на остальных КД?

    Опять стена текста получилась.



    3 октября 2014 г. 7:16
  • Ответы на предпоследний пост.

    1. Конечно же, не nslookup /dnsdisg, а nltest /dnsgetdc. Результаты теста у вас сейчас допустимые.

    2. С политиками решайте сами, потом - пока это не критично. Прежде всего надо восстановить форму - работоспособность контроллеров домена в полном объеме и согласованность репликации, а потом уже можно заняться и содержанием.

    3. Миграция откачена успешно.

    "Референсный КД" - это калька с reference DC из английского текста статьи. В варианте машинного перевода я эту статью не смотрел, кажется там это сочетание перевели, как у вас написано - смотрите сами по смыслу: это должен быть КД, который послужит источником правильного содержимого SYSVOL.

    PS За "стены текста" не переживайте - пусть лучше текст стеной стоит, чем телепаты требуются.


    Слава России!

    3 октября 2014 г. 10:04
  • Теперь - про инструкцию.

    Проводник (Explorer) для работ с SYSVOL лучше не использовать, т.к. он вместо ссылок создаст дополнительные папки (так уж он устроен), предупреждение было об этом.

    Вообще-то вам файлы копировать сейчас не потребуется, но если будете - используйте команды copy или xcopy. Папку C:\WINDOWS\SYSVOL\staging\domain надо создать, если её нет на каждом КД. После этого ссылка в папке "staging areas" должна заработать.  Папки ниже C:\WINDOWS\SYSVOL\DOMAIN - Policies и Scripts - на других КД можно не создавать - их создаст репликация.

    По детальной инструкции

    3. Команду

    ntfrsutl ds |findstr /i "root stage"

    нужно запускать в командной строке в режиме администратора. Ко всем остальным командам это тоже относится.

    4,5. Без команды linkd из Resourse Kit Tools для Win2K3 вполне можно обойтись

    Посмотреть ссылки (они же - точки повторного разбора (reparse points)) в Win2K8 можно обычной командой dir - она в выводе укажет для них тип (в нашем случае - <JUNCTION>) и путь, на который указывает ссылка (в квадратных скобках).

    Создать точку повторного разбора можно командой mklink :

    mklink /j имя_ссылки имя_папки_на_котрую_указывает_ссылка

    6. Это размер области временного хранения файлов для репликации, настраивается через указанный ключ реестра. Свободное место на C: соответсвующего размера должно быть - иначе будут проблемы с репликацией.

    7. Все манипуляции с удалением и последующим копированием файлов в SYSVOL\domain можете не производить - они для случая, когда содержимое SYSVOL повреждено и восстановлено из другого источника. У вас содержимое уже есть и лежит в нужном месте.

    "Контроллеры не участвующие в DFS-репликации" у вас все: рекомендация в статье дана на всякий случай, когда в домене используются оба механизма. Такое возможно в процессе миграции, но это - не ваш случай.

    Последний вопрос по поводу процедуры -в инструкции есть некоторые неточности: в п.1 сказано остановить на всех КД Службу репликации файлов (NtFRS) и изменить её тип запуска на "Отключено", чтобы она не запустилась случайно в процессе всех манипуляций. Все указанные в инструкции манипуляции (кроме вызова команды ntfrsutl - там в статье неточность) должны производиться при остановленной службе NtFRS. Но команду

    ntfrsutl ds |findstr /i "root stage"

    надо будет запустить до остановки службы.

    По минимуму (если опустить все проверки и восстановления папок и других параметров) в вашем случае нужно:

    а) остановить NtFRS на всех КД;

    б) изменить значение BurFlags в реестре на d4 на референсном КД и d2 - на остальных;

    в) Запустить NtFRS на всех КД.


    Слава России!

    3 октября 2014 г. 11:52
  • Спасибо огромное за Ваши ответы!

    По поводу папки  C:\WINDOWS\SYSVOL\staging\domain - внезапно оказалось что она существует, но скрытая (на всех КД), после включения опции "показывать скрытые файлы и папки" она отобразилась, при первой попытке перехода в нее выдало "У вас недостаточно прав... , Продолжить?". "Продолжил" и перешел нормально, после этого ссылка в staging areas заработала нормально. Обратил внимание на SACL C:\WINDOWS\SYSVOL\staging\domain - там права оказались только у того пользователя, который включил "показывать скрытые папки и файлы" (т.е. у меня), думаю стоит добавить "прошедшим проверку" на чтение и выполнение, "администраторам" и "системе" полный доступ.

    ntfrsutl ds |findstr /i "root stage" действительно отработала после запуска в cmd от имени администратора, вернула:

     Root      : c:\windows\sysvol\domain
     Stage     : c:\windows\sysvol\staging\domain

    dir показала что ссылки domain.local в  c:\Windows\SYSVOL\sysvol и c:\Windows\SYSVOL\staging areas указывают на [C:\Windows\SYSVOL\domain] и [C:\Windows\SYSVOL\staging\domain] соответственно, и тип их JUNCTION.

    На контроллерах домена свободно по 30-40 Гб, так что с этим тоже проблем не будет.

    Сегодня после окончания рабочего дня проведу процедуру.

    Спасибо.

    6 октября 2014 г. 2:53
  • Доброго времени суток.
    Провел процедуру восстановления репликации FRS.
    На SD (референсный с флагом D4) в ходе проведения процедуры было событие (предупреждение) 13566: 

    Служба репликации файлов просматривает данные на системном томе. Компьютер SD не сможет стать контроллером домена, пока этот процесс не завершится. Затем системный том станет общим ресурсом с именем SYSVOL. 
    ..........
    

    А на остальных КД 13565 с содержанием:

    Служба репликации файлов инициализирует системный том с помощью данных с другого контроллера домена. Компьютер DC не может принять роль контроллера домена, пока этот процесс не будет завершен. Этот системный том станет общим ресурсом под именем SYSVOL. 
    ......................................

    Далее на всех трех КД появились события 13553, 13554 и 13516, где говорится соответственно:

    Служба репликации файлов успешно добавила этот компьютер к следующему набору репликации: 
        "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 
    ......................
    И описание SYSVOL соответствующего КД
    Служба репликации файлов успешно добавила перечисленные ниже подключения к набору репликации: 
        "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 
     ...............
    с описанием соседей (на каждом КД указаны оба соседа с "входит" и "исходит")

    и

    Служба репликации файлов больше не препятствует компьютеру XXX стать контроллером домена. 
    ..........................

    После этого уже в течение 16 часов никаких сообщений.

    net share на всех КД показала что шары NETLOGON$ и SYSVOL$ существуют и доступны. Содержимое SYSVOL успешно реплицировалось на все КД, попробовал создавать/удалять папки в SYSVOL на разных кд в рандомном порядке - все реплицируется практически моментально. Судя по всему восстановление репликации прошло успешно. Спасибо большое за помощь.

    Осталось лишь несколько вопросов прежде чем я буду переходить к миграции на DFS:

    1. Флаги D4 и D2 нужно оставить на контроллерах или снова задать параметрам значение 0?

    2. В случае если я захочу ликвидировать референсный КД, нужно ли поставить флаг D4 кому-то другому? (этот вопрос на случай, если флаги D2 и D4 нужно оставить).


    8 октября 2014 г. 6:09
  • Значения D2/D4 в Burflags после запуска службы NtFRS этой самой службой сбрасываются, т.к. они лишь однократно указывают режим инициализации этой службы (или набора репликации, если установлены для какого-то конкретного набора).

    Слава России!

    8 октября 2014 г. 8:48
  • Извиняюсь, я на это внимания не обратил. Спасибо вам огромное за терпение и помощь, ваш опыт оказался для меня бесценным! Тему можно считать закрытой, буду готовиться к миграции на DFS.
    8 октября 2014 г. 9:04