MVV

Про 9e895472-e19f-4eb8-a124-c0a83ae40777._msdcs.kubstu.edu. Репликация использует псевдонимы КД в DNS, завязанные на GUID их копии AD. Что это за КД - сморите в DNS, в зоне _msdcs.kubstu.edu на какое имя указывает этот псевдоним.

Для понимания, работает ли репликация реально, выполните на каждом КД из командной строки в режиме администратора команду repadmin /showrepl.

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

Пробовал менять реестр , ставил обновы и ничего

Так как непонятно, что вы там делали, для начала попробуйте вот решение из вот этого ответа
https://www.linuxshop.ru/forum/f5/t41632--resheno-...

Нет, нельзя.
В hosts можно прописать только записи типа A, а обнаружение домена работает через записи типа SRV.

PS А с чем связано такое странное желание? Если с тем, что вам нужно разрешать ещё и имена в интернете, то можно настроить на сервере DNS на контроллере домена пересылку на тот сервер, который разрешает имена в интернете. Либо - позволить контроллеру домена свободно рассылать запросы DNS по всему интернету - тогда он сам обратится к нужным серверам-владельцам зон, начиная с корневых (их список у него есть).

IP, как известно, скрываются в зоне DNS (запись типа A). Впрочем, Windows ищет КД по другим записям (SRV). Для начала: этот ваш КД указан на второй машине, как сервер DNS, причем - единственный? Если нет - укажите.
Если уже указан - проверяйте работспособность поднятого КД - объявляет ли он себя контроллером? dcdiag (в командной строке в режиме администратора) - вам в помощь.

PS Ещё IP может временно храниться в кэше DNS на клиенте, но если вы уже перезагружали клиент, то там его быть не может.

PPS

уже все перерыл

Вы уверены, что перерыли действительно всё? В файл hosts на клиенте заглянули, например?

По вопросу имею сказать
1. Домен почти наверняка чинится. Как чинить - зависит от того, как переносили контроллер, и как выглядит сейчас сломавшийся. Если будет информация (здесь в Вопроснице, лучше - другим вопросом) готов посодействовать.
Самое простое - если переносили миграцией виртуалки и старая виртуалка на ESXI жива: запустить ее и перенсти по уму: поднять второй КД на новом месте (железо или другая виртуалка), убедиться что среплицировались и AD, и SYSVOL (готов подсказать в деталях, как именно) и штатно понизить исходный КД. Потом по желанию - переименовать новый в старый (некоторым это зачем-то надо).
2. Если все совсем плохо то можно создать нужных локальных пользователей (и локальные группы) на файл-сервере, и позаменять старые SID в списках разрешений на SID этих пользователей (и групп) утилитой subinacl,exe. Примерная форма команды -

subinacl /subdirectories "Z:\*.*" /replace=S-1-5-1-2-3-4-5=SERVER\user

. Когда-то, когда ADMT ещё не было, это было практически штатным способом мигрировать файл-сервер в другой домен, была даже статья с описанием процедуры в MS Knowledge Base (к сожалению, не пережила инноваций). Однако в интернетах ещё можно нарыть кое-каких примеров
Но вот соответствие пользователей и SID без живого КД посмотреть, увы, негде, придется применить творческий подход.
Как-то так.

PS Советы в каментах - жуть! Ну, кроме тех, которые от Роман Безруков, те - норм.
PPS И ещё раз напоминаю - делайте бэкапы.

Скорее всего, потому что они входят или когда-то входили в привилегированную группу:
https://learn.microsoft.com/en-us/windows-server/i... (русский перевод там тоже есть, но он - с ошибками).
Если учетная запись теперь ни в одну из привилегированных групп больше не входит - установите в 0 (через ADSIEdit.msc, например)значение ее атрибута AdminCount и включите наследование.

Похоже, тут требуются разъяснение:
пользователь (системная сущность, которая имеет логин с паролем, членство в группах и привилегии в системе) и профиль пользователя (набор связанных - с пользователем папок и файлов, включая дополнительные файлы реестра) - это разные вещи. А локальный пользователь и пользователь из домена - это разные пользователи.
От того, что вы назначили с помощью User Profile Wizard доменному пользователю тот же профиль (т.е. набор файлов), что и локальному, локальный пользователь, со всеми своими правами, никуда не делся. Если он вам больше не нужен - просто отключите его (в консоли Управление компьютером). А чтобы доменный пользователь мог войти на компьютер локально при отсутсвии связи с контроллерами домена (если это требуется) - не запрещайте (по умолчанию оно разрешено) кэширование учетных данных в групповой политике домена, действующей на этот компьютер и зайдите хотя бы раз под этим пользователем на этот компьютер.

Сервер DHCP может быть где угодно. Но он обычно раздает адреса серверов DNS для клинтов. И для работы AD это критично. Общее правило: на клиентах в списке серверов DNS не должно быть серверов, которые не знают про домен AD. В списке серверов DNS должны быть только контроллеры домена (КД) или серверы/прокси DNS, которые переадресуют запросы к именам из этого домена на КД.
Простейший вариант этого правила, для начинающих: в списке серверов DNS на членах домена должны быть только КД.

Через групповую политику: Конфигурация компьютера/Административные шаблоны/Система/Дисковые квоты

Нехватка IP адресов исключается, их хватает

"Верить в наше время нельзя никому, порой - даже себе."((с) Папаша Мюллер). Поэтому для начала проверьте, получает ли компьютер адрес IP (командой ipconfig, к примеру) .
И только потом уже проверяйте обнаружение контроллера домена:
целиком - командой nltest /dsgetdc:имя.домена
через DNS (если первое не прошло) nltest /dnsgetdc:имя.домена

Ну, и если ничего не получается, надо посмотреть ошибки в журнале событий Система (System) от источника Сетевой вход в систему(Netlogon) - там может быть написано, почему.

В настройках dhcp распространяю выдачу ip адресов, указываю dns домен-контроллера (*.10.1) и основной шлюз (*.10.2)

Так делать нельзя: клиенты по Windows в каждый момент работают с одним сервером DNS (по крайней мере - при елинственном подключении сети), на другой они переключаются при недоступности первого.
Настраивайте в качестве сервера DNS для клиентов только КД (точнее, сервера DNS на нем), а для самого КД обеспечьте возможность разрешения имен в общемировом DNS. Если не хотите разрещать ему доступ к любым серверам DNS в интернете (кстати, почему?), используйте DNS-сервер или DNS-прокси на шлюзе: настройте его как сервер пересылки в консоли сервера DNS в Windows.
Для п.3 вам требуется прокси-сервер. Какой - не посоветую: что там сейчас на какой платформе модно (и вообще поддерживается) - я не в курсе.

я поднял 1й КД (dc1), установил ему адрес 192.168.88.2, и в dns добавил 1 запись, самого себя.

Когда КД в сети больше одного, то так делать не надо. Добавляйте на него второй DNS на DC2. Иначе есть возможность, что содержимое зон DNS на обоих КД будет рассогласовано (впрочем, для вас, судя по в вашему описанию, эта возможность - теоретическая, но все равно стоит делать хорошо сразу).

решил глянуть статус репликации, а там ошибка
ошибка репликации

Прямо сейчас там ошибок нет: все разделы каталога среплицировались. Но проверьте обратную репликацию на DC1 - она совершенно отдельная, мало ли что там.
Те сообщения, которые вы видите - это пока не забытые прошлые ошибки (например, при старте AD). Или такое бывает, если команда была запущена не в режиме администратора.

PS А вообще состояние КД лучше проверять командой dcdiag (из командной строки в режиме администратора). Если не хотите читать лишние буквы - используйте dcdiag /q, тогда будут выведены только тесты с ошибками.

Смотрите подробный отчет, который можно получить ключом /H
gpresult /h file.htm

Судя по симптомам, наиболее вероятная проблема - изначальная неисправность репликации SYSVOL, препятствующая этому КД объявить себя таковым. Перезапустите на каждом КД службу репликации DFS (она же DFSR) и смотрите наличие в его журнале событий ошибок или предупреждений в течение 15 минут после перезапуска. Дальнейшие действия зависят от того, что там зафиксировано.

PS Официальные рекомендации от MS по аналогичным проблемам: https://learn.microsoft.com/en-us/troubleshoot/win...

Отключить регистрацию записи A для имени домена на всех КД и добавить вручную запись, указывающую на ве-сайт. Для этого В политике, применяемой к контроллерам домена (Default Domain Controller Policy) в разделе Administrative Templates/Netlogon/DC Locator DNS Records включите политику "Specify DC Locator DNS records not registered by ... и добавьте в нее мнемонику LdapIpAddress.

Есть альтернатива: установить на всех КД обратный прокси для имени домена, проксирующий запросы на веб-сайт: например IIS+ARR (Application Request Routing).

Переименовывать домен AD, как тут советуют вsыше, из-за такой мелочи не стоит IMHO

Проверьте (например, командой ping) на сервере AD разрешение имен DNS для сайтов, которые находятся в интернете. Если оно не работает - настройте так, чтобы оно работало. Как именно настроить - завист от причины. Например, если запросы DNS наружу от сервера AD режутся у вас на маршрутизаторе - разрешите их: сервер DNS на сервере AD по умолчанию уже настроен на поиск в DNS, начиная с корневых серверов, и дальше в соответствиеи с делегированием, а чтобы этот поиск работал, нужно чтобы запросы проходили.
Если запросы DNS к посторонним серверам (кроме своего) режет провайдер - настройти на сервере DNS для AD в его свойствах безусловную пересылку на сервер DNS провайдера.