MVV

Для получения ответа на столь обще поставленные вопросы имеет смысл сначала прочесть документацию произовдителя.
В целом, вы понимаете правильно: подавляющая часть конфигурации Exchange хранится в AD, а потому резервное копирование сервера Exchange состоит, в основном, из резервного копирования данных (БД), а восстановление - в установке сервера Exchange в режиме восстановления и восстановлении БД. Но может потребоваться сохранение/восстановление нестандартных настроек служб (если есть), плюс, что-то надо делать с сертификатами: либо тоже сохранять/восстанавливать, либо перевыпускать после восстановления. Подробности см. в документации.
Для резервного копирования БД Exchange вполне достаточно встроенного Windows Server Backup (описано в документации). Сторонние программы предоставляют дополнительные удобные средства для управления резервными копиями, однако стоят денег. Так что, нужны они вам, или нет -разбирайтесь сами по месту.
И напоследок - имейте ввиду, что Exchange сильно зависит от AD, поэтому о сохраненности ее данных надо обязательно позаботиться.

Параметры маршрута привязываются к параметрам метода обработчика страницы по имени, т.е. их имена в директиве @page в шаблоне страницы и в списке параметров метода в коде должны совпадать.
А у вас в @page используется id, а в списке параметров OnGet - pageId. Переименуйте что-нибудь, чтобы имена одинаковые были - и будет вам счастье.

Все эти подробности про кабели, что куда подключено - они ниачом. Правильный вопрос, ответ на который все определяет: какой у принтера IP? Если он из той же подсети, что и компьютера - будет доступен без проблем. Иначе могут быть проблемы с обнаружением принтера по имени и с маршрутизацией между подсетями (но все это решаемо).

PS Чтобы правильно хотя бы задавать такие вопросы, а в идеале - избавиться и от необходимости их задавать, освойте многоуровневую модель сети - TCP/IP (она же - DoD) или OSI. После изучения этой теории вам многое станет понятнее.

Если КД имеет возможность (на шлюзе и провадером не запрещено) посылать запросы DNS в интернет на любой сервер (т.е. открыт исходящий доступ по 53/UDP), то можно не указывать ничего: DNS Server на КД сам может послать все нужные запросы, начиная с корневых серверов. Иначе в пересылке следует указать тот сервер DNS, куда доступ открыт.

Следующие фото -то что сделал я,

Вы неправильно понимаете, что такое "второй вход операционного усилителя": на самом деле, это - вход второго транзистора в дифференциальном каскаде (Q2 на вашей схеме), нога 2 - та, которую вы на землю посадили.

А то, что вы приняли за "второй вход" - это один из входов регулировки нуля для напряжения сдвига. И, кстати, на землю входы для регулировки нуля (1,5) сажать не полагается: их через резисторы подтягивают к "минусу": поищите схему включения, там нарисовано. В качестве которых обычно используют одинн подстроечник, со средним контактом к этому минусу подключенным. Если смотреть по схеме, то резисторы регулировки нуля оказываются подключенными параллельно R1 и R2 соответственно и просто корректируют их сопротивление. Так что если от вашего компаратора особой точности не требуется, ноги 1 и 5 можно их вообще не подключать.

Не легче ли внедрение делать через конструкторы?

А вы не задумывались над тем, кто и как будет разрешать зависимости для конструкторов?
В нынешнем ASP.NET Core этим занимются каркасы приложений ("фрейворки", от английского framework). И делают они это как раз через контейнер сервисов (либо напрямую через GetService, либо через ActvatorUtilities).
Но есть области в ASP.NET Core , которые фремворками не закрываются - наример, в конвейере обработчиков запроса (middleware), там где требуется делегат типа RequestDelegate. И там без прямого обращения к контейнеру сервисов не обойтись.

Есть предположение, что копать надо в сторону DNS - в какие-то моменты она может отдавать для имени сайта не тот адрес, а браузер - запомнить это неправильное соответствие имя-адрес.
Для диагностики в тот момент, когда браузер застревает на таймауте (т.е. ждет перед тем, как выдать эту ошибку) смотрите список соединений TCP: нет ли там попыток подключения на какой-то неправильный IP на порт вашего сайта (80, 443 или какой вы там используете). Смотреть можно командой netstat -n из командной строки, интересующие вас подключения имеют состояние SYN_SENT. Для уверенности можно использовать команду netstat -no, она дополнительно покажет PID процесса, сравните его с PID браузера (его можно увидеть в Диспетчере Задач или в списке задач, который выводит команда tasklist). А потом ищите, какой из серверов DNS отдает этот адрес в ответе для имени сайта (команда nslookup имя_сaйта IP_сервера_DNS).
PS Частая ошибка настройки DNS в сетях с AD - добавление на клиенты в список серверов DNS сторонних серверов DNS: их там быть не должно, там должны быть только контроллеры домена.