MVV

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).

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

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

Например, поставить трансформатор ;-)
Если считаете, что вам такой ответ не подходит - уточняйте условия задачи.

Добавьте в начало файла строку using System.Linq;
чтобы указать компилятору искать методы расшерения в этом пространстве имен.
ToList() - это метод расширения для интерфейса IEnumerable<Matches>, который реализуется объектом, который возвращает метод Regex.Matches. Этот метод определен (как обобщеный, для IEnumerable<T>) в классе Enumerable из пространства имен System.Linq.
PS Подозреваю, что у автора примера ссылка на это пространство имен живет в Global Usings, а потому у него все работает, а у вас - нет.

Вот руководство от MS по одновременной настройке ARR+WNLB
https://learn.microsoft.com/en-us/iis/extensions/c...
Оба сервера ARR будут иметь одинаковый внешний IP, который надо прописать в DNS (или на шлюзе, если серверы стоят за ним). Браузер будет ходить по этому IP и попадать на ARR - на один из двух, если доступны оба, либо на работоспособный если другой откажет.