MVV

А настроили ли вы на стороне ADFS передачу утверждения (claim) о членстве в группе , по которой вы фильтруете пользователей?
Пример настройки утверждения членства в группе есть в документации AD FS.

PS Имя группы на скриншоте ищите сами: я его вижу, но мне его руками набивать лень, а скопировать-вставить со скриншота нельзя. Надеюсь это вас убедит в следующий раз вставлять информацию по вопросу текстом.

cmd /k powershell ...

Программный доступ к календарю (и другому содержимому п/я) возможен через Excange Web Services (EWS). В частности - из PowerShell можно туда добраться через EWS Managed API - он, вообще=то предназначен для работы из C# и прочих языков для .NET, но в PowerShell, посколько он тоже на базе .NET, тоже можно его использовать. Я не подскажу, можно ли там поменять свойство автора встречи, или оно только для чтения, но, в любом случае, можно создать встречи с новым автором и скопировать в них информацию из существующих встреч уволившегося сотрудника.
Но все это требует самого натурального программирования, т.е. это непросто, и, возможно, встречи будет проще создать заново.

Требуется дополнительная информация. Знать, что и куда подключено по кабелю - этого недостаточно. Требуется понимние на "уровне IP" (он же - "3-й уровень модели OSI") : нужно знать таблицы машрутизации на обоих маршрутизаторах и на типичных компьютерах в каждой из (под)сетей и, главное, включен ли на промежуточном маршрутизаторе (Redmi) NAT между интерфейсами в сети 192.168.1.0/24 и 192.168.2.0/24.
Текущая картина похожа на то, что NAT включен. Если так, то вы из сети 192.168.1.0/24 к серверу в 192.168.2.0/24 не подключитесь - разве что, сервер у вас один, и вы прокинете на него 445 порт с Redmi, и работать это может только, если на Redmi нет Samba или другого сервера SMB, слушающего на этом порту.
Чтобы после отключения NAT в сети 192.168.2.0/24 интернет не пропал, надо на Keenetic прописать маршрут к этой сети через интерфейс Redmi в сети 192.168.1.0/24. В принципе, этого должно хватить и для подключения к серверу по IP. Если не хватает - прверьте брандмауэр Windows на сервере, и разрешите подключение по SMB из сети 192.168.1.0/24 (по умолчанию ЕМНИП там разрешено подключение только из непосредственно подсоединенной (под)сети).
Для подключения по имени сервера нужно настроить разрешение имен между этими сетями: по умолчанию все простейшие протоколы разрешения имен - NetBIOS и пр. - работают только в пределах одной (под)сети. Как это сделать с вашим оборудованием - это я так сразу не подскажу: информации недостаточно.

1. Назначить для User1 стандартное разрешение "Список содержимого папки"
2. Убедиться, что нет менее ограничивающих разрешений для каждой из групп (и псевдо-групп, типа "Прошедшие проверку"), куда входит User1.

PS По жизни разрешения лучше назначать не отдельным пользователям, а группам. Т.е., в данном случае - создать группу, куда входит только User1 и дать разрешения этой группе. Так будет проще что-нибудь поменять, когда потребуется: заменить User1 на другого пользователя и т.п. А по жизни поменять что-нибудь потребуется обязательно.

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

Соображение второе, практическое. Раз, как вы пишете "Domain содержит только сущности, Enum'ы", то выбросьте из головы слово Domain, оно вас только запутывает. Потому что намекает на DDD, а то, что у вас есть, в DDD обзывают "анемичной моделью", и сильно не любят. Т.е. сейчас, с нынешней структурой приложения, DDD - оно не про вас.

Так что, по факту, у вас есть два слоя абстракций, описывающих функции классов и методов: UI и Application. И я подозреваю, что логика приложения - классы и методы, отнесенные к Application - использует в качестве средства доступа к БД EF напрямую. То есть - что там прямо в коде используются сущности под названием DbContext и DbSet.

А это означает, если по жизни, что от EF вы в таком раскладе никуда впоследствии не денетесь. Хорошо это или плохо - решать вам. Однако о намерении прибить гвоздями свое приложение к EF вы не упоминали и, предполагаю, не думали. Если это так, то задумайтесь именно об этом. Не о замене БД - EF может работать поверх разных БД, так что к MS SQL вы, по факту, с EF привязаны не будете (ну, разве что, сами того очень захотите).

А задуматься надо: EF - штука неоднозначная. Она, подобно любому средству ORM, полна абстракций, которые, так скажем, не совсем хорошо ложатся на логическую структуру реляционных БД, а потому в них есть заметные дыры, через которые эта структура будет проглядывать. В частности, это нередко касается вопросов производительности.

Но если вы выберети жизнь EF и ни с чем другим, то о Repository и UoW можете больше не думать: EF будет для вас и тем, и другим.

Кароче, выбирайте.

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

А в чем сложность? В командной строке, в той папке где эта пака archive находится, выполните команду:ren archive Archive - и папка будет переименована.

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

Хосты источником информации о маршрутах IPv4 (и, в частности, об адресах, доступных через интерфейсы маршрутизатора) не являются в принципе. Вся информация о подключенных к маршрутизатору адесах и их диапазонах (подсетях) создается исключительно на маршрутизаторах и распространяется между ними по протоколам маршрутизации.
Спуфинг IP отправителя возможен, но только в одну сторону, в исходящих пакетах - и то, если не настроена фильтрация на интерфейсе маршрутизатора,к которому подключен хост или нижестоящий маршрутизатор. Ответные пакеты, однако, такому отправителю не дойдут (по крайней мере, из-за пределов локальнного сегмента).

Делайте связи в обратную сторону - добавьте в таблицы user, и game внешние ключи на promo. EntityId в таком случае просто не нужен (ну, или его можно сделать первичным ключом в promo).

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