Вася Пупкин

Сам не настраивал, но погуглите "kyocera private printing". Похоже на то что вам нужно.

confbridge.conf

[admin_menu]
...
*#=dialplan_exec(conf-invite,s,1)

extensions.conf

[conf-invite]
exten => s,1,Answer
same => n,Read(NUMBER,vm-enter-num-to-call)
same => n,Originate(SIP/${NUMBER},exten,conf-invite,conference,1)

exten => conference,1,Answer
same => n,ConfBridge(conference,bridge,simple-user,user_menu)

Действительно, кажется нет штатной возможности пригласить человека в конференцию. Самым простым способом все же будет попросить его самостоятельно подключиться.
Есть решение - выполнить Originate с приглашённым пользователем и номером конференции. Для вдохновения можно использовать такой пример https://community.asterisk.org/t/how-to-invite-som...

тут два варианта: маршрутизатор или файрвол
дальше вам решать что вам больше подходит под ваши задачи
1. минимальный рухтер, который протащит 100 метров - ISR4331/K9
правда надо понимать что цискина производительность считается как сумма входящего трафика по всем интерфейсам. т.е. если вам надо загрузить 100 метров в обе стороны то по цискиной математике это уже 200 метров
тут либо брать модель 4351 либо докупать к 4331 perfomance license на 300М (оно right to use так что если совесть позволит можно сэкономить)
кроме IPSec получите стандартные фишки маршрутизации: динамику, PBR, VRF, QoS, итп
плюс к этому вся ISR серия умеет в телефонию

2. файрвола хватит самого простого FPR1010-NGFW-K9
он протащит теже 300 метров как 4331 с лицензией
при этом дополнительно получите стейтфул файрвол, IPS и прочие секурити фишки если они нужны (большинство по подписке)

з.ы. маршрутизатор работает под IOS-XE и та же OS используется на всех коммутаторах каталист (это к вопросу о в будущем все на циско)
а вот в файрволах все не так
там ASA или FXOS

Вводить в домен их не нужно - стройте workgroup cluster
https://techcommunity.microsoft.com/t5/failover-cl...

Нет ли варианта какого-то по типу wild-card?

Нет.

По трем причинам.

1. Сертификат для домена может оказаться без нужного EKU (Extended Key Usage). Для удостоверения сервера обычно используется EKU TLS Web Server Authentication, а для подписи/шифрования почты нужен EKU E-Mail Protection - а вовсе не факт, что CA его пропишет в сертификате, скорее всего нифига.
2. Клиент электронной почты не сможет использовать сертификат, в котором emailAddress в поле Subject не совпадает с тем мылом, на которое пытаетесь настроить - он его тупо не будет признавать (Outlook не будет находить, будет делать ерунду, TB будет игнорировать)
3. Коммерческие CA тоже прекрксно знают о том, что для защиты почты нужен каждому персональный сертификат и именно поэтому продают их поштучно :) Хотя у GlobalSign например есть услуга корпоративного PKI - тебе дают типо промежуточного CA, корневой у которого - GlobalSign и в пределах некоторой емкости ты выпускаешь сертификаты. За деньги, ессно.

0 - имхо - значимость вопроса несколько преувеличена, но ход рассуждений скорее в целом верный
1 - при наличии ресурсов? я бы однозначно таки бы и сделал
2 - да, по крайней мере для начала. у вас же вагон инструментов для оценки нагрузки! теже метрики через диспетчер серверов. мало того - улаленно вэлкам. даже с десятки
https://www.microsoft.com/ru-RU/download/details.a...
3 - .. вот тут конфуз, не помню, и не помню на столько, что успел ли вообще узнать, когда рулил подобным колхозом )).. но! у нас есть гугл! возможно подтянутся коллеги и еще че накидают. если вдруг нет - см п2 в части про метрики, мониторьте все что возможно*! будете властелином ситуации всегда )))

ps * - не забываем, что и сам мониторинг, может стать потребителем ресурсов. по этому тут все равно частенько надо включать голову )))

pps чуть не забыл, еще одна классная штука, собенно для безголовых серверов
https://docs.microsoft.com/ru-ru/windows-server/ma...
она не заменяет диспетчеср серверов, но частенько закрывает 99,99% потребностей удаленного администрирования, даже без участия диспетчера серверов

Вы не совсем разобрались с DFS-R/N. DFS сам по себе, не существует (начиная с сервака 2008, до этого это была одна роль, возможно старые статьи вас немного запутали). Есть 2 раздельные роли DFS-R (replication) и DFS-N (namespaces). Обе они представлены уже в вашей сети, чуть только вы подняли контроллер домена, и синкают и предоставляют доступ к папкам SYSVOL и NETLOGON.
Вам нужно решить, куда и какие роли хотите вынести - под неймспейсами (DFS-N) понимают роли, которые настраивают доступ к шарам, т.е. юзерские линки настраиваются. В вашем описании - это "ретрансляторы", клиент идет к ним за ссылкой, а они перенаправляют уже на конкретную шару, которая хостится где угодно в сети (не обязательно на реплике - реплика нужна для отказоустойчивости, не более). А реплики (DFS-R) - это, соответсвенно, серваки, которые синкают настроенные на это дело шары с другими репликами, включенными в одну группу репликации для нужного фолдера.
Эти роли можно совмещать, или разносить по разным сервакам как вам удобно. Неймспейсами можно сделать и сами же контроллеры домена, а под реплики уже выделять файлопомойки. Если у вас не тысячи юзеров постоянно работающих с шаренными доками и шастающих по шарам, то нагрузки от неймспейсов особо не будет, и я бы не отдавал под это дело отдельный сервак - дорага.) Можно и на сами реплики отдать неймспейсы, они там так же не сильно помешают, просто будете терять сразу по 2 роли в случае чего.

Изучите поиск, можно по сайту для начала.
Ну или зайдите на hh.ru и смотрите в вакансиях требования к системным администраторам Linux.

Подозреваю, что в настройках роутера есть пункт что-то вроде "показывать web ui на WAN интерфейсе". Так вот его надо отключить. Это и для безопасности полезно и порт освободит.

Графана красиво визуализирует данные, красивее заббикса. Выносить смысла нет, графана грузит клиент (браузер), а не сервер.