AntHTML

Не знаю как сейчас, но раньше для решения проблем с пробросом принтеров на терминал, ставили программку screw driver и все норм работало через виртуальные принтеры.

А что за железки под серваками? И как лицензирована 1С?
Я бы все 4 вогнал в hyper-v кластер.
Через L2 свич запустил WAN в VLAN
Виртуалки
1. Керио активный
2. DNS+DHCP+AD+GPO
3. FS
4. 1С
5. DNS+DHCP+AD+GPO
На клиентах по идее ничего настраивать не нужно, т.к. достаточно на DHCP настроить первичный и вторичный DNS, но я DNS люблю настраивать статически на компах.
В кластере виртуалки можно будет мигрировать между железками, а также проще бэкапить и востанавливать целиком

0. А какова конечная цель использования AD? Так-то 25 ПК для домена крайне мало, по мне о домене стоит задумываться когда 75, ну или хотя-бы 50+ ПК, иначе это сильное усложнение инфроструктуры.
1. Сейчас наверное лучше уже на виртуалках, новые винды в них лучше живут, раньше во времена нетребовательных 2003/2008 КД ставили на надежный старый комп, 2019 такой финт не поймет.
2. Очень желательно 2+, но скрипя зубами, на таком парке можно обойтись и одним. Также желательно на КД больше никаких ролей не ставить. (Хотя в сетях 35 ПК встречал серваки "все в одном" AD+SMB+1C+SQL)
3. Лучше перенастроить, это не большая проблема
4. Все зависит от настроек групповых политик, можно разрешить логин без синхронизации с КД, а можно запретить. Но на практике, иногда компы не синхронизируются и пару дней могут входить без обновления билета, но в kerberos шары их тогда не пускает
5. DHCP - где угодно, DNS - желательно на КД, но не обязательно. Главное условие, чтобы DNS знал где находится КД и как можно быстрее эту информацию отдавал. Отсюда очень желательное условие - даже при раздаче IP по DHCP на компах адреса DNS забивать статикой
6. Все зависит от настроек доступа к папкам: можно оставить как есть, можно перевести на авторизацию по домену.

А смысл? Серверная ось - тоже самое ядро, что и в десктопной, только заточенное и протестированное на слегка ином железе. Ну и поверх накаты иные плюшки в виде сервисов.
В про или ультимате винде отличий от серверной, для обычного пользователя, практически нет.

Скриптиком на том же PS пробежаться по дереву и вызвать удаление записей удовлетворяющих условию последнего входа.
Потом закинуть скрипт в регламенты.
У нас к примеру: при последнем логине >60сут - перемещение в OU "неактивные", при >180сут - удаление. Скрипт отрабатывает раз в неделю.

1. CRS326 - свич, с возможностью фильтрации и легкого NATa, от того что Вы написали он загнется.
2. Вполне норм, по практике если в домене <50-70 юзеров, то вреда от домена больше чем пользы, т.к. большинство плюшек домена нормально не развернешь - тупо не хватит юзеров чтоб построить вменяемую иерархию каталогов и написать многолюдные ГПО
3. разбираться что конкретно тормозит, далеко не факт что сеть и маршрутизация
4. WI-FI да, уводить в отдельную сеть

По задачам:
1. AD только если планируете сильно рости
2. ВПН отдельной железкой или виртуалкой

Ну если вы на компе со службой RODC. зайдя под админом DC. добавили пользователя через стандартную оснастку RSAT подключенную к RWDC, то учетка и появится на RWDC.
А вот если бы у Вас небыло доступа/прав на RWDC или оснастка была подключена к RWDC, то, в зависимости от прав, смогли бы только просмотреть или отредактировать выделенную ветку.

1. А что за почтовик и нафига его у себя держать? Гораздо надежнее и экономичнее отдать его в облако. Даже если не подходит готовый сервис то готовый VPS гораздо надежней своей связки сервак + упс + резервные каналы
2. AD+DNS - всегда отдельно - можно виртуалками на обоих хостах (если хосты не вводить в домен)
3. RDS+1C
4. SQL
5. файловый
6. бэкапный - отдельная железка, тот же qnap или что подобное, с доступом только для админов

Первичный контроллер домена ВСЕГДА должен быть только на реальной машине, без сопутствующих задач. Хоть целерон, хоть атом, хоть еще какой баребон или древность
Вторичные могут быть виртуальными.
В случае костыля с виртуальным первичным контроллером - его хост НИКОГДА не должен вводится в его домен. Иначе легко отстрелить себе ноги

А что за токены и умеют ли они пробрасываться через RDP/сеть
Вообще по хорошему в сервак должны вставляться только лицензирующие HASPы
А всякие банковские/налоговые цифровые подписи сейчас законом приравнены к реальной бумажной подписи человека (бухгалтера)
Поэтому раздать болванки юзерам, сделать проброс по RDP, или чему еще. И сказать юзерам чтобы вставляли токен только когда нужно что-то подписать. Иначе их подписью сможет подписать кто-угодно а отвечать в любом случае будут они

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

Зависит от ситуации. Что выгоднее гонять траффик по SQL или по RDP. Иногда при тяжелых базах бывает выгоднее организовать скоростное соединение между ТС и СБД, иногда и ЛВС это нормально вывозит. При до 10-15 юзерах, особенно на 1м свиче смысла нет, а если все на vpn или тп, то можно пропробывать

А обязательно грузить по HTTP? Вообще практически любаф файлопомойка имеет альтернативные варианты доступа для организации автозагрузки. Начиная от клиентских приложений заканчивая стандартными smb, ftp, ssh, api и тд.
Ну или писать свой парсер/кликер под конкретную задачу.

RAID выбырается с определенной целью и вариантов тут вагон и две тележки:
Во первых RAID необходим только на высоконагруженных системах 0, 0Х, Х0 или на системах требующих безостановочной работы 1, 1Х, Х1 и тд. В остальных случаях достаточно бэкапов и синхронизации.
Во вторых смотрится на аппарат/программа: аппаратный не ест ресурсы системы, т.к. все операции выполняются на отдельном контроллере имеющим полную логику, но в случае полета контроллера, нужно иметь в запасе совместимый аналог, без него массив не оживить. Программный обрабатывает все на ресурсах системы, соответственно собрать его можно на любой системе, также как и восстановить.
Так что все зависит от конкретной ситуации. На "старенький сервер" обычно критические сервисы не выводят, так что вполне возможно хватит и регулярного бэкапа +/- простого программного массива (если он там действительно нужен, а не то что "сервер должен быть априоре с raid")

Файловый сервер - Samba
Сервер 1С8 прекрасно живет и на линуксовых терминальниках или вебсервере десктопной винды
Смысла держать под эти задачи WinSrv в 2019 уже нет

Добавить 2 ssd, на один поставить систему второй под базу.
на hdd делать ежесуточные бэкапы
рейд нужен только в случае требований безотказной работы. 4 юзера легко подождут раската вчерашнего бэкапа и за полчаса восстановят все что сделали.
антивирус встроенный, все остальное зарезать на корню

Ну это Вы смотрите, что Вам удобней, лучше, функциональней и преемлемей.
Но я бы виртуализировал, на 10 юзеров 1С такого кол-ва оперативки много, да и по процу не все ядра нужны.
У меня терминалки виртуальные. Причем под разные базы разные виртуалки

1. Анализируйте как часто какие данные и куда бегают (в какие папки и тд) - таким образом получите срез что по загрузке конкретных веток шары и выясните что где важнее IOPSы, скорость, энергосбережение
2. Исходя из вышеописанного прикидываете как вам разнести эту шару по железу
3. Совет. Файловые серваки лучше собирать на хостовой системе, а не на гипервизорах, т.к. в случае чего все данные остаются на винтах чистыми, а не в образах дисков, да и по статистике быстрее работает.
4. Прерационка сервера на отдельном диске. Бекап системы снимать раз в сутки акрониксом раз в сутки и отправлять на сервер бэкапов: если че с системой - просто раскатываем вчерашний бэкап, если с систдиском - меняем и раскатываем вчерашний бэкап
5. По DFSу отправлять на сервак бэкапов. Как минимум в другую комнату, а желательно и здание
6. Раз в неделю критические данные бэкапить акрониксом и в облако или еще куда за пределы территории
В таком случае вам скорее и 10TB сасы не понадобятся, а достаточно будет взять каких 2-4ТБ сас, для остального sata/ssd

Все зависит от специфики работы на месте.
Если это мелкая "Рога и копыта" на 15 компов, то ставится HP Gen10 и заводится все на него, нагрузка по сервисам получается никакая и железо и ось ее незаметно проглатывает, а больше и не надо.
Если это холдиг "Газпрём" с 15 000 конечных юзеров, то там только на одну AD не меньше 20 выделенных серверов будет приходиться.
В общем в первую очередь смотрим по нагрузке и логической организации. Если нужно просто - то одна винда и кучка сервисов, если сложнее и с реальной перспективой роста - то одна платформа с гипервизором, ну а дальше смотрим по нагрузкам - если не справляется - или абгрейдим или дробим и разносим роли - если и дальше не справляется - строим кластеры.