MVV

Похоже, тут требуются разъяснение:
пользователь (системная сущность, которая имеет логин с паролем, членство в группах и привилегии в системе) и профиль пользователя (набор связанных - с пользователем папок и файлов, включая дополнительные файлы реестра) - это разные вещи. А локальный пользователь и пользователь из домена - это разные пользователи.
От того, что вы назначили с помощью User Profile Wizard доменному пользователю тот же профиль (т.е. набор файлов), что и локальному, локальный пользователь, со всеми своими правами, никуда не делся. Если он вам больше не нужен - просто отключите его (в консоли Управление компьютером). А чтобы доменный пользователь мог войти на компьютер локально при отсутсвии связи с контроллерами домена (если это требуется) - не запрещайте (по умолчанию оно разрешено) кэширование учетных данных в групповой политике домена, действующей на этот компьютер и зайдите хотя бы раз под этим пользователем на этот компьютер.

Что нужно сделать, чтобы объявить эту связку авторитативным DNS-сервером?

Как минимум, заменить stub-зону полноценной вторичной зоной, содержащей все записи зоны. Возможно этого будет даже достаточно.

Заглянул через OWA - все сообщения на месте.

Outlook подключен в режиме кэширования (сейчас это - по умолчанию)? Тогда, значит, кэш с п/я у вас не синхронизовались.

Одно из сображений, касающееся производительности. Контролллер - это класс, который создается каждый раз для обработки запроса.
Поэтому имеет смысл смотреть на сервисы-зависимости в его конструкторе (параметры конструктора, которые извлекаются из контейнера сервисов): если действия этого контроллера используют разные зависимости, особенно - с временем жизни Scoped (DatabaseContext, к примеру) или Transient, то эти действия - хорошие кандидаты на перенос в отдельный(е) контроллер(ы).

Task (задача) - это не Thread. Это спрецифичный для исполняющей системы (CLR) .NET объект, который позволяет отследить завершение выполнения операции, выполняющейся независимо от вашего основного потока управления и получить результат выполнения, если он есть (в вышем случае результата нет). Для запуска задачи, которую возвращает асинхронный метод (в отличие от вновь созданного объекта задачи - new Task(...)) ничего делать не нужно - она уже запущена исполняющей системой. Поток (Thread) для ее выполнения, если он нужен (а нужен он не всегда, иногда задача завершается внутри асинхронного метода синхронно) обычно берется из пула потоков (но могут быть нюансы, если они вам интересны - читайте про SynchronizationContext).
Если вам нужно дождаться выполнения задачи в синхроннном коде (у вас сейчас такой), то следует использовать метод задачи Wait(), но он заблокирует основной поток. Альтернатива для современного .NET (7.3 для этого достаточно современный) - использовать асинхронный метод Main: просто указать static async Task Main() вместо static void Main. Тогда можно дожидаться выполнения Install асинхронно, с помощью операции await: await update.Install(); При этом основной поток блокироваться не будет, но если ему все равно делать нечего (это зависит от типа приложения), то выигрыша от этого не будет (в консольном приложении, например).
PS Зачем вы применили атрибут [STAThread] к метод Install? Ведь, согласно документации

Примените этот атрибут к методу точки входа (Main()метод в C# и Visual Basic). Это не влияет на другие методы

То есть, он тут бессмысленнен. И вообще, это - тяжкое наследие технологии OLE2/COM.

Типо ето же окружность...

Нет, сечение вашей фигуры плоскостью z=const - это сегмент круга, ограниченный полуокружностью x^2+y^2=9 (y>=0) и хордой y=z. Его площадь от z зависит. Подставляйте формулу для площади этого сегмента (это и будет S(z)) и интегрируйте ее по z от 0 до 3.

Простой рецепт для простых случаев (никакой репликации).
Сделать 2 раза с небольшим промежутком следующее:
- выполнить резервное копирование журнала;
- обрезать журнал с хвоста (truncate).
Если предполагается использовать журнал для восстановления (к текущему состоянию или к точке во времени) о сделанные резервные копии журнала надо сохранить.

Сервер DHCP может быть где угодно. Но он обычно раздает адреса серверов DNS для клинтов. И для работы AD это критично. Общее правило: на клиентах в списке серверов DNS не должно быть серверов, которые не знают про домен AD. В списке серверов DNS должны быть только контроллеры домена (КД) или серверы/прокси DNS, которые переадресуют запросы к именам из этого домена на КД.
Простейший вариант этого правила, для начинающих: в списке серверов DNS на членах домена должны быть только КД.

Видел у себя такое недавно, ЕМНИП - в субботу. Ну, я к интернетам и авариям в них привычный, так что перетерпел немного - дальше все заработало.
И, думаю, что про это писать надо не сюда, а в техподдержку Хабра.

Патамушта матан. Остальная часть ряда (если ряд сходится, конечно) при t->0 имеет порядок величины o(t) и при достаточно малых t ей можно пренебречь.
PS Про то, что ряд сходится, в решении не написано (патамушта это физика, а не матан), но он таки сходится: он - знакопеременный.

По умолчанию пользователи из гурппы Администраторы работают в режиме с пониженными привилегиями, где членство в этой группе используется только для проверки запрета. Проводник тоже имеет эти пониженные привилегии. Называется этот механизм UAC (User Account Control). В принципе, программы могут запрашивать повышенные привилегии через этот самый UAC (при запуске, к примеру), но у Проводника с этим плохо.
Если UAC вам мешает, его можно отключить, разными способами - через Панель управления, групповую политику, через реестр. В разных версиях Windows это делается немного по-разному, поэтому лучше поищите рецепт для вашей версии по ключевым словам "отключить UAC".
PS На сервере управление общими папками и разрешением на них обычно делается специальной программой, она уже заранее работает в режиме с поышенными привилегиями.

Ошибка - не в протоколе доступа (SMB), а в аутентификации/авторизаци.
Для поиска включите (если не включен) на сервере аудит удачных и неудачных попыток входа в систему, и смотрите, под каким пользователем идут попытки подключения.
Если под анонимным - проблема в аутентификации. Т.к. при подключении по IP используется только NTLM, то смотрите, чтобы на клиенте и на сервере использование NTLM не было ограничено политиками и на ошибки от Сетевого входа в систему (NetLogon) в журнале Система на сервере.
Если под конкретным пользователем, то для начала смотрите, под ожидаемым ли пользователем происходит вход. Если нет - разбирайтесь на клиенте, нет ли там сохраненных учетных данных для взода на сервер. Если да -смотрите в политиках, на наличие у него прав на вход в систему по сети: входит ли он в группу тех, кому доступ разрешен, и не запрещен ли доступ персонально ему (это две независимые настройки).

Через групповую политику: Конфигурация компьютера/Административные шаблоны/Система/Дисковые квоты