Проблема после удаления контроллера домена из сети
 

В сети работало 2 контролера домена, 1 самый первый контролер (хозяин операций и тд) перевезли в другое место, теперь клиентские машины и второй контроллера не видят домен как такой, не могут в нем залогинится и тд. При попытке провести реплику через интернет с 1-м контроллером не видит его, хотя в днс прописан его адрес. Подскажите что можно сделать

Просмотр и передача ролей FSMO в Windows Server 2003
Если у Вас остался один домен, проверяйте настройку маршрутизации и физической доступности сегментов сети.

Домен остался один, единственное что разные сайты, посколько репликация между контроллерами через интренет. ПРоблема в том что контроллеры отказываются видеть друг друга, хотя оба пингуются

и еще проблема в том, что хотя на втором контроллере установлен глобальный каталог, домен не доступен. Как это исправить?

Надо разобраться с сайтами.
ДВа сайта = два сегмента сети = разная область IP адресов
Проверьте настройки ДНС, настройки Active Directory Sites and Services.
Включите на 2-ом КД "Кеширование универсальных групп"

И еще, для начала разберитесь с коммуникацией. ПОтому как команда Ping - это еще не признак 100% работы. Тем более через Интернет. Есть ли у Вас брандмауеры (прог., аппар.)?!
Самый простой способ проверить хотя бы RPC, подключится через любую оснастку mmc к удаленному серверу

Брандмауэры на обоих сторонах стоят Isa. Порты открывал полностью все на вход, но реплика так не проходила. НА втором КД в журнале ошибка LSA что не найдет первый контролер домена. Насколько я понимаю все проблемы из-за этого. Кто сталкивался с такими проблемами помогите плиз....

P.S. Днс проверял, все работает в норме

Галку "Глобальный каталог" поставьте на обоих DC. На ISA - monitoring смотрите.

Стоит эта галка, при попытке реплики по RPC иса блокирует 135 порт политикой по умолчанию на уровне энтрепрайс

Хотя я обе исы уже полностью открыл

Пинги по внутреним ДНС именам идут в обе стороны.

НА втором КД в поле хозяин операций стоит ERROR.

Подскажи как это сделать? Не могу вспомнить где это, уже всю Ад изрыл...

Кеширование работает только в смешанном режиме при W2k/W2k3 и на уровне Windows 2003. Включается галкой в свойствах NTDS сервера в оснастке Active Directory Sites and Services

По поводу ISA. Пинг - это не 135, 53 и не другие порты. Если, все-таки, в исах проблемы нет, то если выключить второй КД и прописать в настройках TCP/IP ДНС первого КД, клиенты ДОЛЖНЫ войти в домен с задержкой (из-за передачи запроса на главный КД)

Если такого не произошло, и выдало ошибку, то вариантов море: от dcdiag до isa sp2 (для 2004)

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

С регистрацией клиентов в домене разобрался -проблема была в днс, после очистки кеша все стало норм.
Теперь осталась только одна проблема - не идет репликация по RPC между КД. На обоих исах RPC открыт как: RPC server (all interfeces) from: External to: internal.
На выход из локалки в инет открыты все порты. Реплика не идет. Смотрю логинг исы - при попытке подключения одного КД к другому выдается: port 135 denided conection (default enterprise rule). В чем может быть проблема???

Такс, давай притормозим. Между офисами VPN или вообще ничего???

Строчка default enterprise rule (или просто default rule) обозначает, что данный траффик не удовлетворил требованиям НИ ОДНОГО из правил и был послан далеко.

И еще: НИКОГДА не стоит открывать доступ из External в Internal !!!

Нету между офисами VPN, просто открыты порты на исе. Исы раздают инет на офисы, как только я настраиваю на них VPN инет перестает в офисах работать (я с исой работаю недавно, может не так что сделал)...

про дефаул руле я вкурсе....вот мне и интересно почему иса не пропускает трафик на явно открытый порт

Скриншот правил в студию

Сорь что так долго не отвечал.

Вот принтскрин:
http://www.rapidshare.ru/328645

В исе более жесткие правила надо ставить сверху.
Правила публикации сервера (а в данном случае ты опубликовал сервер на входящий 135 порт) ВСЕГДА должны быть сверху.
Не удивлюсь, если вход по терминалу тоже не работает.

И вообще, как же КД вообще у тебя знают друг о друге?

все остальные правила работают норм, проблема только с RPC.
КД узнают друг о друге через ДНС. В ДНС вторым адресом КД прописан внешний IP исы второго офиса, RPC не случайно опубликован ведь. т.е. при запросе на внешний ip исы на порт 135 иса должна переадресовывать запрос напрямую опубликованому КД. Или я чего-то не так понимаю?

Попробуй для начала поместить правило публикации на самый верх... а лучше ->

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

Выделенные IP у тебя уже есть. Далее создаешь в исе VPN подключение, прописываешь новые сети. ПРописывать надо как внутренний диапазон локальной сети, например, 192.168.0.0/24, так и адрес выделенный, например 212.212.212.212.
Затем делаешь правило Route от удаленной VPN сети до внутренней (направление не имеет значения, роут работает в обе стороны). Ставишь его выше правила NAT, иначе работать не будет. Далее создаешь правила в фаерволе, указывая нужные протоколы, пути, порты и т.д. и т.п.

я так и делал, но возникала проблема в том, что у юзверей после настройки VPN либо вообще пропадал инет, либо работал кое-как... есть инфа по настройке такого подключения?

Вчера все таки настроил VPN как ты говорил и понял одну вещ - когда настраиваешь ису, то обязательными атрибутами сего действия является шаманский бубен и ящик пива! Когда только настроил все работало!!! Пингипошли доступ был, отошел на 10 мин от компа, вернулся - нече не работает ))))) только исы по внутреним интерфейсам видят друг друга и все

Спасибо за помощ Dimas_83, проблема решена, теперь VPN форевер! :)