Как уменьшить время на удаление (30 дней) после перемещения ящика Exchange в другую базу?

Старая версия ящика в БД не отъедает whitespace (котрый есть потеря на фрагментацию), а является хранящимся в БД объектом. Выполните команду Get-MailboxStatistics -Database в EMS - и убедитесь в этом сами. После этого посмотрите GUID удаленного п/я и удалите его окончательно командой Remove-StoreMailbox. Если таких п/я много, можно окончательно удалить их из базы все, в документации на Remove-StoreMailbox есть пример, как это сделать (только он не для помеченных удаленными, а для отсоединеных п/я, но поменять там несложно).

Есть ли такая архитектура?

Ещё раз. UoW - это вообще не слой архитектуры, а прием проектирования (он же "паттерн"), согласно которого работа с данными идет методом Фамусова: "Подписано, так с плеч долой".
EF реализует UoW: вы создаете контекст, вносите изменения в экземпляры сущностей из него, говорите контексту SaveChanges (или SaveChangesAsync) и очищаете его (если он берется как сервис с временем Scoped из контейнера - его контейнер очистит). Раз вас реализация сейчас и навсегда устраивает - не городите ненужные слои.
И вообще, перестаньте молиться на теорию а исходите из своей задачи и своего здравого смысла. Как-то так.

Как автоматизировать создание аккаунтов?

Проще всего это делать не на C#, а наPowershell: связкой Import-Csv и New-Mailbox. Если поискать в интернетах, то там и скрипты найти можно, если не готовые, то годные в качестве основы.

Вам точно обязательно нужен C#?

Как реализовать TcpLister, который будет ожидать запроса?

Nik Faraday, у васт там для ожидания есть await. Какое ещё ожидание вам нужно?

PS А мой ответ, которым вы отвечали предыдущим комментарием, вообще был не вам.

Как реализовать TcpLister, который будет ожидать запроса?

не нравится конкретно while(true) и рекурсивный вызов метода.

Nik Faraday, в упор не вижу тут while(true)- вижу (в первом варианте) while (!stoppingToken.IsCancellationRequested). Я куда-то не туда смотрю?

Если вас устраивает, что задача, выполняющая HandleClientAsync будет брошена на произвол судьбы, можно использовать оба варианта. Если вы хотите узнать, чем она закончилась - надо делать по-друому.

Во втором варианте рекурсия в норме не возникает: вложенный вызов AcceptClientAsync() по факту возвращается сразу после начала await, и рекурсивный вызов породить способен, только если AcceptTcpClientAsync срабатывает синхронно, а такое - редкость (правда если ваш сервер начнут DDoSить...). Иначе вложенный вызов прозойдет уже в, скорее всего, в потоке из пула, и будет использоваться его стек, т.к. в ExecutionContext стек не входит. Но вот выхода из этого, неявного, цикла прослушивания, действительно, нет. Стоит добавить.

В TcpListener.AcceptTcpClientAsync в любом случае стоит передать CancellationToken, используемый для завершения приложения (напримере, IHostApplicationLifetime.Stopping), чтобы он тоже завершился без задержек при завершении приложения.

Как реализовать TcpLister, который будет ожидать запроса?

Сделать фоновый сервер в ASP NET проекте - не очень хорошая идея.

Sergey В., это в ASP.NET Core до 3.0, пока приложение использовало Web Host, могло быть не очень хорошей идеей (и то, справлялись, и у MS даже было документировано, как это сделать). После же перехода на Generic Host в 3.0 фоновые процессы стали штатной частью приложения (собственно, само веб-приложение именно так устроено). И автор вопроса эту, совершенно штатную, возможность как раз использует, с помощью ппредназначенного кдля этого класса BackgroundService.
Про какой веб-сервер вы гоорите - непонятно: по умолчанию приложение ASP.NET Core - сам себе веб-сервер (по умолчанию используется Kestrel). А если кто-то вдруг захочет убить ваш процесс (оркестратор?) - настройте этого "кого-то", чтобы не своевольничал. Кстати, оснований считать такой процесс зависшим нет: на всякие пробы здоровья по HTTP ему отвечать ничто не помешает.

Консоль выдаёт ошибку в коде хотя там её явно не видно, как можно решить?

На стр. 54 внимания не обращайте, это всего лишь часть стека вызовов, который привел к ошибке. Сосредоточьтесь на последнем вызове из вашего кода, приведшем к ошибке - стр.143 и выясняте, почему так получилось.

Проблема с жёстким диском?

из винды нельзя что-то полностью вырезать,

Wispik, не распространяйте невежество, а откройте для себя DISM: современная Windows (начиная ещё с Vista) состоит из пакетов и DISM - менеджер их.

Почему в истории начал появляться коммит слияния?

, ну если удалю update и сделаю новую на основе main.

Dyikot, а изменений в update вам не жалко? Если жалко - просто сделайте git rebase: он вам и update на основе main создаст, и изменения сохранит. Ну, а если не жалко - можно и так сделать.

Почему в истории начал появляться коммит слияния?

"Эту" - это какую? Которая "на всякий случай" - удалить. Эти ваши commit отмены и отмены отмены будут удалены при следуюшей сборке мусора в репозитории. А с update делайте то, что вы обычно делаете, она тут не при делах.

PS А вообще, ветка - это указатель на голову цепочки commit'ов и ничего более.
PPS Если чего-то опасаетесь - сделайте копию папки .git, в случае чего - вернете обратно.

Как настроить web api для передачи куков с React клиента?

Ничего не понял: что за HttpSession и причем оно тут? В C# вы работаете с сессией с интерфейсом ISession - вот и пишите про него.

Ответьте на вопросы, которые я задал раньше. Значение c ключом Id в сессии - оно откуда у вас должно взяться? Вы посмотрели, там, где вы его устанавливаете, что свойство Id интерфейса ISession совпадает там и в вашем фильтре авторизации? Если совпадает, то на куку сессии в браузере вообще можете не смотреть: там все работает.

PS Про вызов метода CommitAsync: можете не заморачиваться. Я посмотрел исходник: обработчик в конвейере middleware, который устанавливает сессию, вызывает его сам.

Как настроить web api для передачи куков с React клиента?

Nik Faraday, прежде всего, посмотрите в новом обработчике тот самый ISession.Id (context.Session.Id) и сравните со значением из старого запроса. Если не совпадают, то у вас что-то с кукой сессии. Жмите F12 в браузере и смотрите - получает ли он куку, отсылает ли.
Во-вторых, где вы в сессию значениt записываете? Если в обработчике предыдущего запроса - то вызвали ли вы там ISession.CommitAsync и выполнился ли он нормально?

Как настроить web api для передачи куков с React клиента?

Nik Faraday, а чо бы вам не разобраться-то?
Сессия - это просто: это - словарь пар "ключ(строка)-значение(массив байтов)", хранящийся в распределеннном кэше. Доступ к сесссии из кода обработчика на сервере - через свойство HttpContext.Session, это работает, как именно - можете даже не заморачиваться.
Значения обычно устанавливаются и излекаются методами расширения для ISession, которые сериализуют/десереализуют значения в соответствии с их типом. Какая именно сессия используется - определяется значением куки с определенным именем (задается в настройках): в этом значении содержится зашифрованный Id сессии. Тут, похоже, я попутал - вы хотите работать не с Id сессии, а со значением под ключом "Id". Так?
Однако, при настройках по умолчанию (и при ваших - тоже) никакой код JS (и React, в частности) к этой куки доступ не имеет: она - HttpOnly. И, в любом случае, к значениям, хранщимся в сессии, код JS доступ иметь не может в принципе: они на клиент не передаются. На клиенте (причем, обычно - в виде, недоступном для JS) есть только идентификатор сессии, чтобы можно было найти ее (и ее данные) в обработчике на сервере. Разве что, вы на клиенте через API (т.е. специальный обработчик) доступ к этим данным сделаете.

PS Дальше обсуждать не хочу, потому что не понимаю, что вообще вы пытаетесь там сделать. Вижу только, что вы хотите странного.

Как настроить web api для передачи куков с React клиента?

Баюшки пора, поэтому подробно посмотрю и наводящие вопросы задам завтра. Мне вот на первый взгляд непонятно, какую куку вы получить хотите - которую механизм сессий устанавливает, или какую-то другую?

А пока что - простой вопрос: а что это вы так сложно, я бы сказал - трансректально (надеюсь, не обидел, если что - извиняйте) извлекаете Id сессии? Ведь в HttpContext есть свойство Session содержащее ссылку на объект сессии. Просто читайте context.HttpContext.Session.Id (вопросительные знаки добавить по вкусу) - и вот он, ISession.Id перед вами.
PS Технически реализация HttpContext извлекает ссылку на ISession из коллекции функций (Features), куда ее помещает соответсвующий обработчик в конвейере (middleware). Так что все эти манипуляции с сервисом - они совершенно не требуются. К сожалению, механизм функций (Features) HttpContext в его общем виде описан в документации плохо (а в учебниках - обычно, никак), а жаль: очень полезная вещь для тех, кто делает компоненты для конвейера.

Настройка 2FA ADFS в NEXTCLOUD?

Outgoing claim type: как нашёл в интернете, установил Authentication method.

Kornev888, у меня есть серьезное подозрение, что нашли вы что-то не то: обычно этот тип утверждений используется по-другому. Но искать самому откровенно лень. Может, вам стоит искать не в интернетах, а в документации NEXTCLOUD, какие именно типы утверждений оно ожидает, а потом настроить нужные правила в ADFS? Тип утверждения - это URI, так что при необходимости типы можно сопоставить точно, а не по сходству названий.

Какая есть метаинформация у доменов?

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

Какими настройками разрешений запретить открытие файла?

sertaliano, так быть не должно. Проверяйте, откуда пользователь получает разрешение. На вкладке Безопасность в свойств в окне, выхываемом по кнопке Дополнительно есть вкладка Действующие разрешения, где это проверить удобно.

Ошибка MSB3021 Не удается скопировать файл, Процесс не может получить доступ к файлу, Как навсегда исправить эту ошибку?

Есть подозрение, что у вас дамп процесса после исключения пишется. Проверьте: поищите файлы дампа.

Как выявить узкое место при запуске приложения?

Process Monitor.
А ещё ядро Windows может писать все происходящие в нем события в лог трассировки ETW, и если вы научитесь с ним работать, то можно использовать его.

Есть ли такая архитектура?

OwDafuq, ну, дык, я рад, что мои предположения не оправдались. Т.е. слой логики приложения у вас не завязан однозначно на EF (ну, разве что, вы свой IUnitOfWork определили так, что иначе, как через EF, его не реализуешь).
Если так, то у вас вообще всё шоколадно и беспокоиться в этом вопросе не о чем: EF сейчас даст вам эти самые Repository и UoW, а если потом от EF придется уйти, то вы их реализуете самостоятельно, не трогая логику приложения.