MVV

Обращает на себя внимание тот факт, что скорость копирования совпадает с со скоростью записи с произвольным доступом. То есть, похоже что линейная запись на виртуальный диск оказывается, с точки зрения ваших HDD записью с произвольным доступом.

Смотреть надо там. Но я не знаком детально с ZFS, поэтому не могу подсказать, что и как вам надо посмотреть.

У вас сервер DNS на КД является полномочным для зоны домена example.ru. Поэтому все записи он разрешает чеез свою зону (обычно - интегрированную с AD). Менять такую настройку не надо - иначе замучаетесь с настройко домена AD. Надо решать задачу по-другому, через имеющуюся внутреннюю копию зоны.

Задача, на самом деле распадается на две:
1. Настроить публикацию сайта с именем, совпадающим с именем домена
2. Настроить публикацию других сайтов
Вариантов решения первой задачи два. Как известно, по умолчанию КД по умолчанию регистрируют записи A с именем домена и своим адресом. Поэтому нужно сделать одно из двух:

1. настроить на всех КД обратный прокси для публикации внешнего сайта, совпадающего с именем домена. Для IIS для этого используется модуль ARR (Application Request Routing).
2. Запретить через политику (Default Domain Controller Policy)регистрацию КД записей A с именем домена. Это можно делать практически безопасно - эти записи нужны только для устаревших ещё во времена Windows 2000 клиентов LDAP, которые ищут сервер LDAP домена по записи типа A с его именем. Все хоть сколько-нибудь современные клиенты (включая саму Windows) ищут сервер LDAP для домена по записям SRV. Нужный раздел политики - Конфигурация Компьютера/Административные шаблоны/Система/Сетевой вход в систему/DNS-записи локатора домена/DNS-записи контроллеров домена, не регистрируемые контроллерами домена: добавьте туда слово LdapIPAddress.

А для других сайтов просто добавьте в зону домена их имена с нужными IP.

C AD DS (т.е. , контроллером домена): серверу RADIUS не придется лишний раз лазить в сеть.

Используйте Performance Monitor (монитор производительности). Использовать его можно и с другого компьютера в локальной сети. А можно настроить запись данных в файл. Счетчиков там много разных, выбирайте те, кототорые вам сообщат нужные данные.

Перед переносом нужно настроить загрузку драйвера в процессе начальной загрузки системы. Требуется сделать следующее
1. Установить драйвер для RAID-контроллера
2. Установить для драйвера тип запуска boot, например - командой sc config имя_драйвера start= boot
Имя_драйвера можно найти, посмотрев список драйверов командой sc query type= driver (возможно, чтобы увидеть весь список потребуется увеличить размер буфера параметром bufsize= ).

Просто включите и работайте: все изменения, сделанные на других КД, будут на него перенесены репликацией. AD сконструирована так, что изменения никуда не пропадают в течение срока их хранения. А 5 дней - это значительно меньше срока хранения: для базы данных AD он очень редко в наше время (это когда домен - родом с Win2K) бывает 60 дней, обычно - 180, а для изменений в папке SYSVOL (там лежат политики и скрипты) - 90 дней.
PS Для диагностики отсутствия проблем с КД испольуйте команду dcdiag /q из командной строки в режиме администратора. Если нет ошибок, она не вернет ничего. Правда, в первые сутки после запуска там даже в норме могут быть сообщения об ошибках в журналах событий (во время запуска), в таком случае загляните в эти журналы.

Сначла не дочитал. Увидел ошибку куда серьезнее:

Запуск проверки: Replications
[Проверка репликации,Replications Check] Входящая репликация
отключена.
Для исправления выполните "repadmin /options SERVER2012
-DISABLE_INBOUND_REPL"
[Проверка репликации,SERVER2012] Исходящая репликация отключена.
Для исправления выполните "repadmin /options SERVER2012
-DISABLE_OUTBOUND_REPL"
......................... SERVER2012 - не пройдена проверка

Не вздумайте выполнять эту рекомендацию!
Это может быть признаком USN Rollback (из образа КД не восстанавливали случаем?). Я писал в свое время статью - проверьте остальные признаки по ней.
Если USN Rollback, то AD на SERVER2012 придется сносить, с принудительным понижением, захватом ролей FSMO на существующем КД и чисткой AD от его следов.

Старый ответ.
Ключевая ошибка:

Запуск проверки: FrsEvent
За последние 24 часа после предоставления SYSVOL в общий доступ
зафиксированы предупреждения или сообщения об ошибках. Сбои при
репликации SYSVOL могут стать причиной проблем групповой политики.
......................... SERVER2012 - пройдена проверка FrsEvent

(из комментариев).
SERVER2012 не смог реплицировать себе содержимое SYSVOL, поэтому он не объявляет себя контроллером домена.
Где именно ошибка - смотреть для начала в журнали событий Службы репликации файлов на SERVER2012. По опыту: проблема почти наверняка на старом сервере под Win2K3: пока онбыл один, репликация SYSVOL была никому не нужна, и, скорее всего, она когда-то тихо померла (например, она не переживает внезапное отключение питания). Поэтому, при малейшем подозрении (а можно даже сразу) перезапустите на 2K3 Службу репликации файлов, подождите минут 5-15 и посмотрите в ее журнал событий: скорее всего, там ошибка, может быть даже - с рекомендациями по ее исправлению.
Внимание! Прежде чем пытаться исправлять эту ошибку обязательно сделайте резервную копию содержимого SYSVOL: бывает, что при попытке исправления оно пропадает.
Если затрудняетесь исправить сами - пишите в комментарии, помогу.
PS Снимать галку с Global Catalog(GC) не надо: GC в лесу могут быть хоть все КД (собственно, в наше время нет оснований не делать GC на каждом КД), хотя для леса с одним доменом это, в общем-то, безразлично.

Если вам нужно ПО под 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...