MVV

Если вам нужно ПО под Linux, чтобы оно физически было размещено на сервере под Windows - cоздайте на сервере виртуальную машину в Hyper-V и поставьте Linux на нее. А лучше - посмотрите, нет ли аналогов этого ПО под Windows. Например, сервер DNS уже есть в Windows Server из коробки.

Руководство от MS - здесь там есть ссылки и на руководство по настройке удаленного доступа к WMI, и на руководство по устранению неисправностей.

Пространство может быть занято теневыми копями содержимого диска.
Посмотреть - vssadmin list shadowstorage из командной строки в режиме администратора. Удалить теневые копии можо тем же vssadmin, начинать надо с самой старой.
Но не торопитесь ничего удалять: фактически это место может быть занято старыми версиями резервных копий. Не знаю, как там в DPM (не работал), но вот Windows Server backup совершенно точно использует старые версии файла с бэкапом (у него это - VHD) как способ хранения предыдущих бэкапов.

Я не понял, что именно вы сделали, но по поводу настроек посмотрите эту статью: https://learn.microsoft.com/en-us/previous-version...

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

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

PPS

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

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

Эта ошибка означает, что возникло исключение при обработке некого сообщения. Не исключено (но и не факт), что это произошло из-за вмешательства этой самой DLP системы.
Сообщение вызывающее исключении при обработке, помещается в очередь Poison message queue. Смотрите там - если сообщение есть, конечно: например, ваша DLP могла его удалить внезапно для службы транспорта Exchange, тип исключения вполне такому сценарию соответствует. Если подозреваете DLP - сопоставьте ваш лог Exchange с логом DLP на момент возникновения исключения, чтобы понять, что делала в этот момент DLP.

По вопросу имею сказать
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 И ещё раз напоминаю - делайте бэкапы.

Если делаете ограничение в политике на пользователей, которые ограничени не должны действовать на терминальном сервере, то в политике(ах) компьютера, действующей(их) на терминальный сервер следует включить настройку замыкания групповой политики в режиме замены, а все нужные настройки сделать в политике(ах) пользователей, применяемых к терминальному серверу - в режиме замыкания настройки берутсяя оттуда.
Тогда не потребуется никакой фильтрации.

Но в таком случае ему нужно давать доступ на чтение всего корневого каталога, я верно понимаю?

Неверно. Есть специальное разрешение для таких случаев - "Чтение содержимого папки". Дайте этому сотруднику (или, лучше, группе, в которой он состоит, можно такую сделать специально для него) это разрешение на все папки по пути от той, к которой дан общий доступ, до нужной ему. А если еще для общей папки включено перечисление на основе доступа (оно в Windows есть уже лет пятнадцать), то он ещё и ничего лишнего не должен увидеть.

Вообще говоря, никак: подсистема безопасности не знает ничего о пользователях другого компьютера и как их аутентифицировать.
Со стороны клиента можно попробовать сохранить (в "сохраненных учетных данных) учетные данные (имя и пароль) для пользователя, созданного на сервере, чтобы подключение шло по его имени. Ещё вариант - создать на сервере пользователя с тем же именем и паролем, что и тот, под которым работает программа на клиенте и надеяться, что клиент будет подключаться чисто по имени и паролю. Но это - совершенно без гарантии.

https://learn.microsoft.com/en-us/previous-version...

Есть хорошее под названием WebDAV. Это - протокол доступа к файлам, работающий поверх HTTP (и HTTPS). В WImdows серверная часть реализуется одним из компонентов IIS (обычно его надо устанавливать/активировать отдельно). Ну, а ещё через WebDAV Sharepoint мог работать. Клиент WebDAV встроен в Windows, начиная с XP (надеюсь, его ещё не выпилили) как редиректор (клиентский компонент сети Microsoft) - то есть, папки и файлы по WebDAV доступны как обычные файлы и папки на сетевом диске. Когда-то (не в курсе за сейчас) по WebDAV можно было даже c файлохранилищами типа Яндекс-диска работать.
PS Порты NetBIOS и SMB настолько часто используются всяческими вирусами, что многие провайдеры для клиентов на тарифах для физлиц блокируют их. Вероятно, поэтому вам и не удалось их открыть.

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

Ошибка - не в протоколе доступа (SMB), а в аутентификации/авторизаци.
Для поиска включите (если не включен) на сервере аудит удачных и неудачных попыток входа в систему, и смотрите, под каким пользователем идут попытки подключения.
Если под анонимным - проблема в аутентификации. Т.к. при подключении по IP используется только NTLM, то смотрите, чтобы на клиенте и на сервере использование NTLM не было ограничено политиками и на ошибки от Сетевого входа в систему (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, тогда будут выведены только тесты с ошибками.