Выбрать "оптимальный контроллер домена"
 

Всем привет. Такая ситуация.
Есть два DC. Один DC1 в "быстрой сетке", другой DC2 удаленно на "медленном канале", репликация настроена ч.з. три часа.
Часто бывают случаи, что ПК в домене сначала цепляются к дальнемe (медленному) DC2. Хотелось бы, чтобы они сначала обязательно
к своему DC1 стучались, а потом (если не нашли), то к дальнем DC2? Сайты и сети вроде все прописаны. Может есть какая-то фишка?

Скрины настроек сайтов в вашей сети покажите.

Разобрался. В Subnets не все сети были прописаны и привязаны к сайтам. В таком случае откуда хочу - оттуда и беру?

Немного не так, если у Вас неправильно были настроены привязки к сетям, то при запросе NS записей DNS сервер будет циклически (round robin) выдавать ip адреса КД доступных в сети. Так первый клиент будет обращаться к первому КД, а второй ко второму, третий к первому и т.д.

Век живи - век учись! Спасибо.

Доброй ночи.
Помогите разобраться с именем контроллера домена.
По совету MS если есть домен mydomen.com то имя DC должно быть например corp.mydomen.com
Но у меня домен 3 уровня mydomen.com.ua, соотвтственно я задал имя DC - corp.mydomen.com.ua
Могут ли от этого в будущем возникнуть проблемы с DC или не имеет значения длина и уровень имени домена?

веб-домены не связаны с windows-доменами. назовите свой windows-домен именем по короче.
а так я не встречал траблов из-за имён.

Согласен, прямой связи нет. Но если я в будущем буду устанавливать внутри домена MS Exchange Server - мне придется ссылаться на мой почтовый домен и связь появится.
Для того чтобы не возникло проблем MS рекомендует выбирать для имени DC реально существующее имя домена (которое вам принадлежит), а для того чтобы DNS правильно отправлял внутренних пользователей домена на сайт mydomen.com MS рекомендует давать имя для DC на один уровень выше (на примере MS это corp.microsoft.com).
В связи с выше изложенным мне нужно дать имя для DC - corp.mydomen.com.ua, а это имя 4 уровня и достаточно длинное.
Если у кого по этому поводу есть еще информация то прошу поделиться...

придётся ссылаться? ну так ссылайтесь. Только почтовый домен не будет связан с windows доменом.
Будет у вас в Exchange по умолчанию домен, например, mydomen.localnet, но никто вам не запрещает создать свой почтовый домен mydomen.com.ua и назначать его пользователям.
у меня домен называется mydomen.local, а почта mydomen1.com, mydomen2.com, mydomen3.net, mydomen4.ru. И почта работает, и входом на сайт проблем нет.
покажите, пожалуйста, мне эту рекомендацию. Так же хочу заметить - это рекомендация, а не требование.
Ещё они рекомендуют не совмещать роли AD, Exchange, SharePoint, SQL и при этом у них есть SBS сервер, где все эти роли и приложения совмещены.

и ещё добавлю - не важно как называется ваш контроллер домена. Важно как называется сам домен.
Т.к. пользователи будут заходить на домен mydomen.com - то реальный и "локальный" будут одним и тем же именем. Но даже в этом случае можно разделить с помощью ДНС.
Как видите - контроллера домена тут нет.

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

Также из этого документа видно, что длина полного имени контроллеров домена ограничена 155 байтами.

с регионами конечно удобнее именовать по рекомендации МС. У меня два региона. Один домен. КД названы по названия городов.
Если в компании активно используются веб-ресурсы (SharePoint, OWA и пр) конечно, лучше называть домен используя имя зарегистрированное для использования в интернете. Если у вас просто домен, веб-ресурсы не главные сервисы в компании и нет удалённых пользователей - всё равно как назовите.
Я никогда не называю домен реальным именем по двум причинам:
1) если есть веб-ресурсы, то ими занимаюсь не я. Я хз что веб-программисты там творят. Пусть сами разбираются с интернет доменным именем. Бывают исключения, когда веб-программисты активно сотрудничают с админами. Но в моей практике такое случалось кране редко.
2) Возможно я буду не прав в своей теории. Логин пользователя состоит из domain\username. Так вот если ваши оба домена, внешний и локальный совпадают - злоумышленнику уже не нужно угадывать имя домена. А по умолчанию, к примеру RDP, подставляется домен - имя локального компьютера пользователя, с которого идёт подключение. Эту теорию можно сравнить со скрыванием SSID в беспроводных сетях: вроде не видно, но найдёт тот, кто умеет искать. Имхо.

Вот нашел полную инфу по теме:
Если имя леса Active Directory совпадает с зарегистрированным внешним именем DNS:
- пользователи осуществляют доступ как ко внешним, так и внутренним ресурсам по одному доменному имени;
- нельзя открывать внутренние ресурсы для внешнего мира; внешний сервер DNS не должен хранить имен, используемых Active Directory;
- для разрешения внешних имен из внутренней сети используйте передачу неразрешенных вызовов на внешний сервер DNS;
- ресурсы, доступные извне, должны храниться в демилитаризованной зоне (DMZ), аутентификация доступа к ним — выполняется через RADIUS-сервер, а не контроллер домена;
- на прокси-сервере надо сконфигурировать список исключений;
- при использовании протокола трансляции сетевых: адресов (NAT)внутренний сервер DNS должен содержать свои записи о ресурсах, доступных как извне, так и изнутри;
- управление этими адресами — забота администратора.
Если имя леса Active Directory является дочерним по отношению к внешнему имени DNS:
- только внутренний сернер DNS содержит информацию об Active Directorу
- на внешнем сервере DNS создается делегирование зоны, соответствующей зоне домена Active Directory;
- пользователи применяют разные имена для доступа к внешним и внутренним ресурсам;
- для обеспечения доступа пользователей ко внешним ресурсам не требуется предпринимать дополнительных усилий;
- полные имена ресурсов длиннее, чем в предыдущем случае.
При различных именах леса Active Directory и внешнего имени DNS:
- управление безопасностью внутренней сети проще за счет полностью различных пространств имен;
- внутренние имена не видны снаружи;
- тиражировать информацию с внешнего сервера DNS на внутренний не обязательно;
- инфраструктура DNS может оставаться без изменений;
- внутреннее имя не обязательно регистрировать в ICAAN.

Теперь еще бы понять это все :)

а что именно не понятно?

В теории вроде все понятно, а при настройке на практике точно где то застряну.

Посоветуйте пожалуйста как правильно построить домен в моей ситуации:

Есть зарегистрированное доменное имя mydomen.com.ua и центральный офис ЦО1 с контроллером домена КД1, а также 2 региональных офиса РО1 и РО2 без возможности установки КД + десяток удаленных работников УР1-УР10 на дому (и им всем нужен доступ к терминальному серверу ТС1 по RDP и файловому серверу ФС1 по VPN, оба сервера находятся в домене КД1).
Как грамотно организовать доступ РО1, РО2 и УР1-УР10 в зону ЦО1 с КД1 (основные задачи: работа в терминале 1С 8.2 на ТС1 и работа с офисными документами на файловом сервере ФС1)?

Больше интересует 2 вариант "Имя леса Active Directory является дочерним по отношению к внешнему имени DNS", на крайний случай 3 вариант "Различные имена леса Active Directory и внешнего имени DNS"

вы всё-таки хотите их связать?

читайте про Direct Access, посмотрите как там всё настраивается, и исходя от этого будите или не будите связывать внешний домен с AD.

но я лично бы назвал домен не используя внешнее имя.