MVV

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

Нужная вам функциональность - переаправление почты для части получателей на другой сервер, даже если он "не той системы", чисто по протоколу SMTP - есть во многих почтовых серверах (малую часть списка см. в моем комментарии к предыдущему ответу). Так что балансировщик, скорее всего, вам не нужен. Но, в крайнем случае, в качестве балансировщика можно поставить такой сервер SMTP, который имеет эту функциональность.
А более конкретные советы можно будет дать, только когда вы озвучите конкретику со своей стороны - хотя бы названия ПО SMTP-серверов вашего старого и предполагаемого нового почтовго сервера.

Имя_файла.cs ищется относительно вашего текущего каталога - того, в котором вы находились, когда ввели команду с csc.exe. Его имя пишется в приглашении командной строки. Вот и посмотрите, из какого каталога вы запускаете команду, и есть ли там нужный файл.

А для чего будет использоваться второй сервер? Если чисто для приема почты с клиентов и отправки ее дальше (например, ради отказоустойчивости), то ему запись MX вообще не нужна. MX - это для других почтовых серверов, чтобы они знали, куда почту для этого домена слать. Главное, чтобы этот второй сервер знал, куда пересылать полученную с клиента почту.
Если второй сервер вдруг будет участвовать в доставке почты в этот ваш локальный домен с другого почтового сервера из другого домена - тогда создавайте запись MX.
Маршрутизация писем между почтовыми серверами для одного домена обычно с MX не связана и делается другими средствами. Например, один сервер можно выбрать в качестве места хранения п/я, а на ддругих - указать, что все письма нада пересылать на него (общепринятое названиие такой настройки - SmartHost)

Здесь временная таблица не нужна: все можно сделать одним запросом:

select distinct c.CrossArticleId from Crosses c inner join Crosses f 
on c.ArticleId=f.CrossArticleId where f.ArticleId=1

А чтобы избежать сканирования всей таблицы, создайте (если их ещё нет)индексы по полям Crosses.ArticleId и Crosses.CrossArticleId - например, как в предыдущем ответе написано. И пусть работает и оптимизирует запрос планировщик: он кремниевый, и у него есть статистика по индексам. Если вдруг сомневаетесь в планировщике - посмотрите план выполнения запроса.
Индексы - это ключевой момент: без них серверу придется сканировать всю таблицу.

Видите этот маршрут в route pring

65.20.87.158  255.255.255.255      192.168.1.1      192.168.1.7     36

- к хосту (маска 255.255.255.255 ) - серверу VPN (65.20.87.158 ) через шлюз локальной сети (192.168.1.1)?
Именно он отвечает за сохранение в Windows пересылки трафика самого VPN на сервер VPN 65.20.87.158 , чтобы после смены маршрута по умолчанию через VPN пакеты на сервер VPN могли идти.
В Windows это делает автоматически системный клиентский компонент службы удаленного доступа (как я понимаю, OpenVPN тоже им пользуется), причем адрес сервера VPN берется из реально установленного соединения с этим сервером.
Такой же маршрут надо прописать и в Linux. Но как получить адрес сервера VPN для него - это я вам не скажу: для этого надо курить manы.

CityzenUNDEAD, сообщение об ошибке означает, что у вас таки действительно кривые данные, а именно - есть минимум одна запись в RiskLevels со значением поля OrganizationControlId = 0, для которой в таблице OrganizationControl нет записи с таким же значением первичного ключа (как я понял - поля Id).
Вывести все такие записи из RiskLevels, которые ссылаются на отутствующие записи в OrganizationControl, можно SQL-запросом

SELECT * FROM RiskLevels WHERE OrganizationControlId!=ALL(SELECT Id FROM OrganizationControl)

И пока такие записи есть, наложить ограничение внешнего ключа не поле RiskLevels.OrganizationControlId у вас не получится. Ищите и разбирайтесь, что с этими записями делать.

PS Entity Framework - он шибко умный, он сам находит связанные друг с другом поля, сам добавляет поля для чего-нибудь типа первичного ключа и т.д. Так что не удивляйтесь, что EF умничает, а если не хотите этого - жестко его контролируйте.

Создавайте п/я с тем же адресом, что был у отключаемого пользователя и настройте на нем автооответ (Set-MailboxAutoReplyConfiguration). Чтобы этот п/я не мешал в адресной книге - скройте его. Переадресацию, если нужно изменение темы, придется делать ЕМНИП транспортным правилом. Поэтому лучше тему не менять - достаточно будет того, что получателем будет отображаться уволенный сотрудник: в таком случае можно просто сделать переадресацию на самом п/я. Но я вообще бы предпочел подключить этот п/я (можно после увольнения: он сразу не удалится, а некоторое время будет обитать в числе отключенных) нужным людям как дополнительный в Outlook (перед этим нужно дать разрешение на него через Add-MailboxPermission ...-AccessRights FullAccess). Скрытый п/я подключается путем указания его legacyExchangeDN в качестве имени.

Как правильно замтили отвечашие ранее, такие вещи надо искать в отладчике, а при чтении кода можно, разве что, заметить подозрительные места. В частности, я вижу подозрительное место в функции buildFanoTable - вот этот оператор:

if (abs(diff1 - diff2) < abs(diff1 - diff2 - frequencies[mid + 1].frequency)) {
        mid++;
        diff += frequencies[mid].frequency;
    }

В предыдущем цикле mid может дойти до end-1, и обращение по индексу mid+1 будет как раз выходом за границу вектора.

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

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

Если вам нужно подключиться самому для администрирования сервера - попробуйте для подключения запустить mstsc /admin: подключитесь в режиме администрирования, без запроса лицензии, но число таких подключений ограничено (ЕМНИП до сих пор 2-мя).

Если у вас установка свежая и ещё не в бою, считаю предпочтительным вариант выше, от Роман Безруков .
Но есть альтернатива, которую можно попробовать: загрузиться в безопасном режиме восстановления службы каталогов (надеюсь пароль для этого режима у вас есть) и переименовать компьютер обратно, как было. После чего - помолиться своему богу или постучать по дереву и попробовать перезагрузиться.
PS

Не то, чтобы ответ, но идея ответа. И если чо непонятно - могу в каментах поуточнять.
Со стороны тыла (на C#) можно ограничить число параллельных запросов в целом к сервису безо всяких там плагинов, а саморучно сделанным велосипедом: семафором (например, SemaphoreSlim, как самым модным в этом сезоне). Либо сделать его статическим, либо (чтобы веру в IoC свято блюсти и модульные тесты делать) - запихнув в Singleton-сервис с теми же свойствами/методами, что и у семафора используются, и получать этот сервис через конструктор (передавать через DI - в бою, напрямую - в тесте).
Для семафора(сервиса) устанавливаете максимальное число параллельно выполняемых запросов в качестве начального значения. При входе в обработчик захватываете семафор (Wait/WaitAsync, таймаут - по вкусу), при выходе (лучше - в блоке finally того try, который начинается после захвата семафора) - освобождаете (Release).
Таймаут выставляете в зависимости от поведения фронта: какие у него у самого таймауты на запрос (в том числе - на повторение) и как он реагирует на задержку ответа и на всякие разные коды статуса HTTP в ответе. В целом, стратегии тут две. Первая - пытаться захватывать семафор с коротким таймаутом и в случае неудачи - возвращать другой код статуса, кроме ОК, чтобы сказать фронту, что он не прав. Вторая - тормозить лишние запросы таймаутами. Кароче, без знания вашего фронтового плагина тут точно не скажешь, а я его знать не знаю и знать не хочу.

Это вам Google Chrome пишет, что этот пароль утек (где-то, когда-то): Google Chrome стал шибко умным и любит теперь поучать пользователей, что они должны делать, а что - не должны. На эту тему нынче даже статья на Хабре есть.
Так что пароль, скорее всего, утек не у вас (ибо много кто из разработчиков пользуется сайтами в домене localhost ;-) ), но я бы, к примеру пароль сейчас поменял, чисто на всякий случай.
Если вам надоела опека Google Chrome, то ее можно(пока?) отключитью Конкретно как включить (а, следовательно отключить) - про это в Интернете ссылок много, например, такая). Только потом, если чо, не жалуйтесь.

PS Использовать самопальную аутентифкацию/авторизацию крайне не рекомендуется (если вы не Брюс Шнайдер, конечно, или кто-нибудь вроде него). Потому что в этом деле тонкостей много и накосячить можно влегкую. Совет тут простой: посмотреть, как в вашем стеке стандартным образом реализуется аутентифкация с авторизацией (про .NET - см. документацию, а ещё, если непонятно, есть куча учебников)и сделать именно так, стандартно. В частности, передавать каждый раз на сервер логин с паролем плохо из соображений даже не безопасности, а производительности: аутентификация (полноценнная) - довольно дорогая операция. Сейчас для этого стали модны token, раньше обходились cookie. Но выбор, как всегда - за вами.