MVV

1. Чтобы Exchange Server принимал почту для другого домена, этот домен в нем должен быть прописан в Обслуживаемых доменах с типом "Внутренняя ретрансляция". А для фактической отправки почты на другой домен нужно создать соединитель отправки для этого домена с назначением (smarthost) на сервер, фактически обслуживающий этот домен. Сервер на том конце может быть совершенно любым сервером SMTP.
2. Адреса для п/я в Exchange настраиваются политиками адресов: в политике должен быть прописан первичный домен для адреса SMTP (используется и для отправки и для приема) и может быть несколько вторичных доменов. На той стороне, где нужно поменять адреса, просто добавьте в политику нужный домен с нужным типом. Кстати, если политика поменяет первичнй адрес п/я, то его бывший первичный адрес останется в качестве вторичного, так что, если новым пользователям не нужно добавлять адреса из старого домена, то в политике можно просто заменить первичный домен на новый, не оставляя старый вторичным.
3. Чтобы письма с Exchange с адресом его обслуживаемого домена могли отправляться на другой сервер SMTP (в том числе - в Exchange в другом лесу), нужно сменить тип этого домена с полномочного на внутреннюю ретрансляциию и создать соединитель отправки аналогично п.1
4. Вам наверняка потребуется синхронизировать адресные книги обоих Exchange. Раньше для этого можно было использовать бесплатный упрощенный вариант Microsoft Identity Integration Server (названия у него были разные, но суть одна: синхронизация AD между разными лесами, так чтобы пользователи с п/я из одного леса отображались как контакты в другом). Остался ли он сейчас - не интересовался. Но, в принципе, это может делаться и скриптом.
5. Вариантов совместного использования Exchange много разных (например, можно сделать общие календари). Но тут я их рассматривать не буду - вы все равно, скорее всего, захотите все это поскорее мигрировать в один лес. Но если интересно - ищите книги/документацию по Exchange 2007: эта функция (называется "федерация") в современном виде появилась там, и лучшие описания относятся именно к этой версии. С тех пор мало что поменялось, потому что MS пошла в облака.
6. При миграции есть возможность заводить п/я в одном лесу для пользователей из другого, доверенного леса (называется это Linked Mailbox, как по-русски - точно не помню). Для этого, кстати,в Exchange есть скрипт (его использовали для подготовки миграции с ADMT или ему подобными).

Get-WinEvent -LogName Application -MaxEvents 10 | Format-List Machinename, TimeCreated, Message

Ответ на вопрос "как хранить" зависит от того, какие данные вы будете запрашивать. То есть - от представлений данных, с которыми работает ваша программа (программы). Именно на основе этих представлений синтезируется полная модель даннных, хранящаяся в БД.
В свое время, лет 25 назад, был (может, и сейчас есть) стандартизированный подход, называвшийся IDEF1 (это имя из стандарта) или Entity-RelationShip (это название процедуры), позволявший формальным образом синтезировать из этих, частных, представлений полную модель данных. И были программы, которые позволяли это делать. Я одной такой пользовался, ERwin называлась (AFAIK она жива и сейчас), но, в принципе, нужные процедуры можно выполнять и вручную. Описание процедуры на русском есть, как минимум одно, которое я знаю - в старой книге "Мартин Дж. Организация баз данных в вычислительных..."
Короче, синтез модели ваших данных - это ваша задача, связанная со специфическими вашими задачами.
Судя по информации из вашего вопроса, я могу только сказать, что:
1. этот вариант вам явно не походит: данные из представления "Товары в корзине" включают товары из всех категорий, так что отделные таблицы для каждой категории - это костыль: ходить можно, а бежать - уже нет.
2. В ItemOptions можно хранить данные для всех категорий - достаточно указать в каждой записи дополнительно к идентификатору товара идентификатор категории и идентификатор свойства. Потребуются ещё таблица категорий (идентификатор категории как первичный ключ плюс дополнительная информаци) и таблица свойств для каждой из категорий (идентифкатор свойства как первичный ключ, идентификатор категории - внешний, плюс дополнительная информация). Схема получается не очень уклюжая, но для работы в рамках реляционной модели более-менее годная (я когда-то такую и делал и с ней работал, но это было жутко давно). Насколько для вас такая схема пригодна - зависит от ваших моделей предствалений: например, будете ли вы в Корзине указывать дополнительную информацию из ItemOptions.
3. NoSQL - это название больше коммерческое, а не техничекое: оно включает много разных технологий хранения в БД, единственным общим признаком которых является, что они - не реляционные. Под эту задачу мне видится годным вариант навигационной БД (это где каждая запись содержит физические ссылки на связанные с ней записи): сетевая, например. В настоящее время такие БД иногда ещё проходят под псевдонимом "графовая". Но, опять же, смотрите на нужные вам представления, в данном случае - обращайте внимание на пути доступа к данным (эти самые ссылки): навигационные БД в этом плане не так гибки, как реляционные, и отсутствие нужных ссылок может заставить ходить по кривым путям и убить тем самым производительность.
Но это все теория, а что там сейчас на практике творится - я с уверенностью сказать не могу. Насколько я понимаю, там надо смотреь возможности конкретной СУБД - тем более, что производители часто называют их словом "гибридная", и надо понимать, что в этот гибрид попадает.

В журнал событий DFSR на DC08 загляните: там должно быть событие с ошибкой или предупреждением.
Например - если перезагружали другой КД. Вот и смотрите, насколько там что-то серьезное сообщается.
И да, эта проверка "вылечится" сама через, максимум, сутки - даже если репликация SYSVOL в реальности не работает ;-) .

Есть: применить к каждому возвращенному имени папки функцию (статический метод) Path.GetRelativePath и записать результаты в новый массив. Короче всего это записать через LINQ, примерно так:

String[] rel_folder_names = Directory.GetDirectories(RootFolder).Select(s=>Path.GetRelativePath(RootFolder,s)).ToArray();

Но если пока не умеете или боитесь использовать LINQ, то можно это сделать в обычном цикле

String[] full_folder_names=Directory.GetDirectories(RootFolder);
String[] rel_folder_names = new String[](full_folder_names.Length);
for(int i=0;i<full_folder_names.Length;i++) {
     rel_folder_names[i]=Path.GetRelativePath(RootFolder,full_folder_names[i]);
}

Как-то так.

PS Весь код написан "из головы", так что ошибки могут быть.

'MultipleActiveResults=True'

Уберите эти одинарные кавычки.

Я бы в такой задаче попробовал сделать архитектуру, основываясь на виртуальных базовых классах - т.е. множественном наследовании, при котором многократно наследуемый класс везде, где он возникает, определяется как виртуальный базовый. Как известно, если класс (напрямую или через своих предков) многкратно наследует некий класс как виртуальный, то при содании экземпляра такого класса создается только один экземплярэтого базового класса.
В частности, с помощью виртуального абстрактного базового класса, содержащего только чистые виртуальные методы, вполне можно сделать аналог интерфейсов, существующих в других языках: Java, C# и пр. - и пользоваться в C++ архитектурными наработками, сделанными с использованием интерфейсов.

Если вы умеете отправлять и получать запрос с фронта в формате JSON на голом JS через XMLHttpRequest или fetch (либо у вас есть фронтовой фреймворк для этого), то вам повезло: сама Microsoft о вас позаботилась. Как раз в ASP.NET 6 появился Minimal API. Суть его в том, что если раньше базовые делегаты-обработчики конечных точек маршрутизации (подключаемые через Map/MapGet/MapPost etc) должны были иметь тип RequestDelegate (HttpContext context на входе, Task на выходе, а в context.Response изволь писать сам), то теперь делегаты-обработчики могут иметь произвольный тип (ну, почти): принимать произвольное количество произвольных параметров - ASP.NET привяжет их к путям/параметрам в URL и содержимому тела запроса как надо - и возвращать произвольный объект в качестве результата - он будет правильно записан в context.Response: например, если это обычный объект, то он будет послан как JSON. То есть, Minimal API - это новый способ написания контроллеров API, безо всякого MVC.
Что касается вашего вопроса: если вы передадите с фронта через XHR/fetch объект в JSON с полями и значениями в них, то ASP.NET привяжет параметры метода-обработчика к одноименным полям объекта, а объект, возвернутый из метода-обработчика, закодирует в JSON. И никакого дополнительного фреймворка не надо.
Подключаются эти обработчики все теми же методами Map/MapGet/MapPost etc: просто в качестве делегата передаете не RequestDelegate а нужный метод-обработчик.
Но есть нюанс: в документации по ASP.NET 6 все это великолепие еще толком не описано - читайте документацию по ASP.NET 7: она в целом подходит, только не испольуйте группы маршрутизации и фильтры - их в ASP.NET 6 ещё не было.
PS Кому интересно: как это работает под капотом(конкретно для ASP.NET 7), описано в серии статей Эндрю Лока (знаете такого автора книжек по ASP.NET?).