none
Умер родительский домен, но внезапно для дочки появился новый родитель. RRS feed

  • Вопрос

  • Есть в организации головной офис, есть дочерний. Решили как то сделать общую доменную структуру. Завязали серваки VPN-ом, подняли в головном офисе контроллер домен(pdc.domain.local), в дочернем соответственно дочерний контроллер домена(dc-srv.super.domain.local). Все было прекрасно и все работало. В один прекрасный момент связь между серваками нарушилась. Пока связи не было, контроллер домена в головном офисе перенесли на новую машину(dc.super.domain.local) и в новую подсеть. Старому контроллеру (pdc.domain.local) понизили роль и убили его совсем. После этого связь восстановилась и дочерний контроллер начал искать своего любимого родителя (pdc.domain.local). А того уже давно заколотили в гробик и закопали. Что делать? Как дочернему контроллеру сказать, что родитель у него внезапно поменялся? 
    Оба контроллера (pdc.domain.local и dc-srv.super.domain.local) являлись глобальными каталогами. В настоящее время доверие между родительским доменом и дочерним работает. Но реплицироваться они совсем не хотят.
    26 октября 2009 г. 14:42

Ответы

  • Переподключать так и так придется - нельзя съесть колбасу, не съев колбасу)) Поднимаем новую дочку, берем ADMT 3.0, руководство к нему, несколько часов времени, пиво и сигареты по вкусу)) И переезжаем со старой дочки на новую. После чего никогда не меняем настройки критических узлов системы, если у них нет связи с остальной структурой ;)
    Все вышесказанное является моим личным мнением, не имеющим отношения к корпорации Майкрософт.
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    • Помечено в качестве ответа Kostiki Dmitriev 21 ноября 2009 г. 17:32
    29 октября 2009 г. 9:04
    Модератор

Все ответы

  • Что у Вас за пространства имен? Не понятно, что за иерархия: где и какой домен, где/чьи контроллеры...

    26 октября 2009 г. 15:54
    Отвечающий
  • domain.local - условное название родительского домена. super.domain.local - соответственно название дочернего домена.
    pdc.domain.local - старый контроллер родительского домена, dc.domain.local - новый контроллер родительского домена.
    dc-srv.super.domain.local - контроллер дочернего домена.
    В двух словах: без ведома дочернего контроллера, подняли добавочный контроллер в домене domain.local, понизили роль старого контроллера этого домена и убили его.\
    В итоге имеет новый контроллер домена dc.domain.local, и контроллер дочернего домена dc-srv.super.domain.local. Причем контроллер дочернего домена ничего не знает, что у родительского домена domain.local теперь новый контроллер.

    26 октября 2009 г. 18:43
  • А дочерний контроллер может получать SRV-записи с зоны корневой?..
    Объекты соединений пробовали пересоздавать, а "repadmin /sync"?

    В общем, рекомендую на дочернем контроллере в оснастке "Active Directory Sites and Services" добавить новый головной контроллер, пересоздать объекты соединений (автоматически - "Check Replication Topology") и провести репликацию. Разумеется, это все выполнимо лишь при условии корректно функционирующего разрешения имен.
    26 октября 2009 г. 19:13
    Отвечающий
  • Спешу радостно сообщить, что репликация DNS-зоны, интегрированной в АД, тоже не происходит :) Завтра вечером попробую перенастроить DNS-сервер и последовать Вашим рекомендациям.

    26 октября 2009 г. 19:46
  • Можно с нового DC взять файл netlogon.dns (c:\WINDOWS\system32\config) и импортировать его содержимое в DNS дочернего DC.


    Сазонов Илья http://www.itcommunity.ru/blogs/sie-wl/
    27 октября 2009 г. 5:23
    Модератор
  • Дочерний контроллер не получает srv-записи с корневой зоны:
    C:\Program Files\Support Tools>nslookup -q=srv dc
    Server:  dc-srv.super.domain.local
    Address:  192.168.0.2

    domain.local
            primary name server = dc-srv.super.domain.local
            responsible mail addr = hostmaster
            serial  = 683
            refresh = 900 (15 mins)
            retry   = 600 (10 mins)
            expire  = 86400 (1 day)
            default TTL = 3600 (1 hour)
    Как его заставить возвращать srv-записи с корневого домена по человечески? Честно признаюсь, что все SRV-записи в ДНС которые указывали на старый контроллер руками переделал на новый.

    repadmin /syncall радостно сообщает:
            CALLBACK MESSAGE: Error issuing replication: 1396 (0x574):
                Вход в систему не произведен: конечная учетная запись указана неверно.
    Как добавить  в оснастке "Active Directory Sites and Services" новый головной контроллер? можно только создать сервер, а что за сервер нигде сказать нельзя :(  С кем он должен реплицироваться соответственно тоже

    27 октября 2009 г. 17:42
  • Как импортировать содержимое файла? В оснастке ДНС нигде не нашел кнепочки импорт. ручками в блокноте произвести импорт?
    27 октября 2009 г. 17:43
  • Например с помощью утилиты dnscmd c ключом zoneadd
    http://technet.microsoft.com/en-us/library/cc756116(WS.10).aspx#BKMK_22
    27 октября 2009 г. 18:09
    Модератор
  • Есть небольшая проблема. зона domain.local уже существует на дочернем контроллере домена. Убить ее я думаю не стоит, последствияя могут будут очень плохими.
    27 октября 2009 г. 18:26
  • Да что Вы мучаетесь? Просто назначьте в IP-конфигурацию дочернего КД сервером DNS IP-адрес нового корневого контроллера!

    27 октября 2009 г. 18:39
    Отвечающий
  • ВПН счас сделан следующим образом: в головном офисе поднят сервер впн на РРАСе, а дочерний подключается к нему. соответственно в подключении в качестве сервера днс указан ДНС-сервер головного контроллера.
    На дочернем контроллере:
    C:\Program Files\Support Tools>nslookup dc
    Server:  dc-srv.super.domain.local
    Address:  192.168.0.2

    Name:    dc.domain.local
    Address:  10.7.20.10

    27 октября 2009 г. 18:49
  • Прошу прощения. nslookup dc - разрешил дочерний ДНС, так как у него есть запись типа А на контроллер головного домена в зоне domain.local. Остальные сервера в головном офисе он не разрешает. Однако пинг по имени на все сервера головного офиса одет прекрасно, что говорит о нормальном разрешении имен.

    еще одно: repadmin /syncall говорит:
            CALLBACK MESSAGE: Error issuing replication: 1396 (0x574):
                Вход в систему не произведен: конечная учетная запись указана неверно.
    Я так понимаю потому что он щимится на несуществующий контроллер. repadmin /sync, направленный на новый контроллер говорит:
            DsReplicaSync() failed with status 8452 (0x2104):
                   Контекст именования находится в процессе удаления или не был реплицирован с указанного сервера.
    27 октября 2009 г. 19:14
  • А Вы сервер добавили в "Sites and Services" на дочернем контроллере, объекты соединений пересоздали?..

    см. мое первое сообщение в этой теме
    27 октября 2009 г. 20:05
    Отвечающий
  • Я не понял как создать сервер в этой оснастке :(
    Говорю создать сервер. говорю его имя. ОН появляется. Но в своойствах нем ни имени домена, ни имени компьютера. Соответственно NTDS Settings тоже нет. как в этой ситуации пересоздавать соеднения? Или я что то неправильно делаю?

    Попробовал счас сделать следующее:
    Добавил пользователя - админа родительского домена в группу Administrators дочернего домена. Поднял на еще одном сервере дополнительный контроллер для дочернего домена от имени этого пользователя родительского домена. Он поднялся, однако в оснастке Sites and Services на дочернем домене не появился новый родительский контроллер, и соответственно в оснастке Sites and Services на родительском контроллере не появился новый дочерний контроллер. Чего в принципе следовало ожидать, но все равно обидно :(
    27 октября 2009 г. 20:21
  • Товарищи Эксперты. Неужели нет нормального способа пофиксить эту ненормальную ситуацию? Переустанавливать дочерний домен и заново подключать всех пользователей ну очень не хочется

    28 октября 2009 г. 17:01
  • Так Вы пробовали удалять соединения, после чего выполнить "check topology"?..

    28 октября 2009 г. 18:01
    Отвечающий
  • Пробовал. Толку от этого. Дочка то все равно не знает, откуда загружать схему.

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

    Удаление соединений на дочки и проверка репликации ничего не дает. Создание нового сервера и соединений на дочке не сделана по незнанию или невозможности такого. В свойствах подключения на дочке прописан ДНС родителя, пинг соответственно с дочернего контроллера на компы родительского домена идет нормально. repadmin /syncall - говорит "Вход в систему не произведен: конечная учетная запись указана неверно.", repadmin /sync с указанием нового головного контроллера говорит "Контекст именования находится в процессе удаления или не был реплицирован с указанного сервера". Создание еще одного дочернего контроллера тоже ничего не дало. Есть мысль руками в оснастке ADSIEdit переправить все GUIDы со старого контроллера на новый, но есть крайне большая вероятность что не поможет.

    Итого тупик. Интересно, неужели никто не сталкивался с подобной ситуацией? 

    Проанализировав все можно прийти к выводу, что единственный выход, заново создавать дочку, поэтому хотелось бы перевести данную тему плавно в другую. Как сделать новую дочку, но при этом не пришлось переподключать всех пользователей к новой дочке?
    29 октября 2009 г. 6:35
  • Переподключать так и так придется - нельзя съесть колбасу, не съев колбасу)) Поднимаем новую дочку, берем ADMT 3.0, руководство к нему, несколько часов времени, пиво и сигареты по вкусу)) И переезжаем со старой дочки на новую. После чего никогда не меняем настройки критических узлов системы, если у них нет связи с остальной структурой ;)
    Все вышесказанное является моим личным мнением, не имеющим отношения к корпорации Майкрософт.
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    • Помечено в качестве ответа Kostiki Dmitriev 21 ноября 2009 г. 17:32
    29 октября 2009 г. 9:04
    Модератор
  • Итак, наконец-то собрался с духом, взял в зубы сигарету, налил кружку пива и запустил ADMT v3. (Предварительно соответственно было поднята исчо одна дочка)
    попытка репликации тестового пользователя привела к следующему:
    [Settings Section] 
    Task: User Migration (5) 
    ADMT Console
    User: domain\admin
    Computer: dc-dc.new_doch.domain.local (DC-dc)
    Domain: new_doch.domain.local (new_doch)
    OS: Microsoft Windows Server 2003 R2 5.2 (3790) Service Pack 2
    Source Domain
    Name: super.domain.local (super)
    DC: dc-srv.super.domain.local (dc-srv)
    OS: Windows Server 2003 5.2 (3790) Service Pack 2
    OU:
    Target Domain
    Name: new_doch.domain.local (new_doch)
    DC: dc-dc.new_doch.domain.local (dc-dc)
    OS: Windows Server 2003 5.2 (3790) Service Pack 2
    OU: LDAP://new_doch.domain.local/CN=Users,DC=new_doch,DC=domain,DC=local 
    Intra-Forest: Yes 
    Update Rights: No 
    Translate Roaming Profiles: No 
    Fix group membership: Yes 
    Conflict Option: Ignore 
    Source Disable Option: Leave source account 
    Source Expiration: Do not expire source account 
    Target Disable Option: Set target same as source 
    Migrate groups: No 
    Migrate service accounts: Yes  

    [Object Migration Section] 
    2009-11-11 18:42:14 Starting Account Replicator. 
    2009-11-11 18:42:15 Removing CN=test (LDAP://dc-srv.super.domain.local/CN=test,OU=users,DC=super,DC=domain,DC=local) from the global groups it is a member of : 
    2009-11-11 18:42:15 LDAP://dc-srv.super.domain.local/CN=test,OU=Users,DC=super,DC=domain,DC=local is a member of LDAP://dc-srv.super.domain.local/CN=Test,CN=Builtin,DC=super,DC=domain,DC=local. 
    2009-11-11 18:42:15 ERR2:7422 Failed to move source object 'CN=test'. hr=0x800720e2 Произошла ошибка операции репликации из-за несоответствия схемы задействованных серверов. 
    2009-11-11 18:42:16 Operation completed.

    Я так понимаю. что это связано во первых с тем, что в домене существует "мертвая" дочка. с которой новая дочка ессно не реплицировалась. ну и к тому же перенос должен идти с этой самой "Мертвой" дочки.
    admt запустил соответвенно на target от имени админа предприятия. доверительные отношения настроены тоже. 
    Чиго делать? попробовать ldifde.exe? выгрузить там и загрузить сюда. Или ADmt всетаки можно заставить заработать?

    11 ноября 2009 г. 18:11
  • Вот касательно такой мертвой репликации существует следующая статья: http://support.microsoft.com/kb/887430. Написана для 2000 Server, но должна подойти и для 2003


    Все вышесказанное является моим личным мнением, не имеющим отношения к корпорации Майкрософт.
    Доклады на Techdays: http://www.techdays.ru/speaker/Vinokurov_YUrij.html
    16 ноября 2009 г. 8:13
    Модератор
  • С новой дочкой так и не разобрался. больше потому что влом было. Поднял новый домен в новом лесу. все туда перенес, снес старую дочку. вычистил отовсюду инфу о ней. поднял снова дочку и перенес в нее все обратно. ADMT отличная весчь. Правда со своими глюками. 
    Возникшие проблемы:
    1. не для всех папок ADMT переделала права пользователей.
    2. Часть компов при ребуте во время миграции радостно заклинило. помогало тока шевеление мышью :) Тогда ребут и все нормуль
    3. Очень странно стала выглядеть вкладка безопасность для некоторых папок. Присутствует два-три раза имя одного итого же пользователя. ручками такого не сделаешь :)
    4. Очень обидно, что у группы админов криво перенесся SID. Придется в радмине везде переделывать права на подключение :)
    5. Ну и совсем самое обидное, все компы с профилями пользователей мигрировались нормально, а мой профиль не мигрировался :)
    21 ноября 2009 г. 17:39