Akina

Если комп с Windows рядом - киньте патч-корд напрямую.
Если не очень далеко - подключитесь по WiFi.

Планировщик заданий - Библиотека планировщика заданий - Microsoft - Windows - UpdateOrchestrator - Reboot - ПКМ - Отключить

Если монитор имеет опцию PiP (картинка в картинке) либо PbP (картинка рядом с картинкой) - то вообще без проблем. Иначе - переключение через меню монитора или, как сказал Stalker_RED, командами DDC.

Ещё вариант - подключить монитор только к одному из компов, и с него же подключиться к удалённому рабочему столу второго компа. Правда, при этом необходимо, чтобы компы были объединены сетью.

1. Каждый DHCP-скоп должен "сидеть" в своём VLAN. Так что VLANID=10 для DHCP-сервера - явно неправильно. Он должен раздавать адреса юзерам и, возможно, принтерам, так что два скопа и три VLANID (ибо он сервер и должен быть в VLAN серверов). Да, серверы с динамическим IP - это более чем странно, даже при статическом резервировании.

2. Клиентских портов - да, не требуется. А вот на транке добавь, хуже не будет.

3. Аналогично - лучше добавь.

4. Можно и так, и эдак. Как по мне - принтсервер таки сервер, вот и пусть его в сегменте серверов. А вообще я б его делал двухинтерфейсным, наверное - один в серверах, второй с принтерами, так ему проще будет отлавливать включение-выключение принтеров.

5. Так принт-сервер и его очереди же публикуются через домен, а доступ к нему маршрутизируется. Зачем тебе прямой доступ клиентов к принтсерверу?

Навскидку:

1. Звезда - плохо. Случись что, и сегмент отвалится. Я бы делал как минимум кольцо, и в него ERPS или RSTP (ещё лучше - кольцо на ERPS, а дальше RSTP). Ещё лучше - два кольца. И из тех же соображений надёжности - минимум два магистральных коммутатора на площадку/здание.
2. Неуправляемые коммутаторы - забудьте как страшный сон. Например, надо перестартовать камеру по питанию - что, бежать к камере? да даже элементарно посмотреть статус коннекта... ставьте PoE L2.
3. Транки я бы делал 10G.
4. Оптический коммутатор в центре достаточно L2 или L2+. У него вообще все порты будут в транке (tagged).
5. По части подсетей - для указанного количества оборудования я бы брал подсети /23 или /22 из 172.16. Избыток адресов ни на что не влияет, а их недостаток - это по определению геморрой. Оно надо?
6. Если подсеть исчерпала адреса - то перестраиваешь DHCP-сервер, раздающий адреса. Либо расширяешь подсеть, либо добавляешь ещё один скоп и организуешь маршрутизацию. Второе правильнее - ибо в любом сегменте найдётся оборудование со статическим назначением адресов (не статическое резервирование!), при изменении маски их придётся перенастраивать.
7. И я как-то не увидел управляющего VLAN, в котором будут только административные адреса коммутаторов.

Вы неправильно понимаете, и от того неправильно мыслите.

Представим, что у нас на коммутаторе сделаны, скажем, 3 VLAN. Ну и подключены какие-то узлы-клиенты. Так вот - чтобы построить то же самое, но без управляемого коммутатора, Вы должны взять три отдельных коммутатора, и в соответствии с VLAN переключить на них всех клиентов.

Иными словами, сети различных VLAN изолированы друг от друга ПОЛНОСТЬЮ. И пусть Вас не обманывает, что все они сходятся в одном коммутаторе - внутри этого коммутатора никакого соединения между VLAN нет. Соответственно чтобы трафик ходил из одного VLAN в другой, нужен маршрутизатор, который одним интерфейсом смотрит в один VLAN, другим - в другой VLAN.

Вы хотите сделать у себя 5 VLAN. Соответственно если они, скажем, должны обращаться к одному и тому же серверу-файлопомойке, или через этот один сервер ходить в Интернет, значит, в этот сервер придётся вставить 5 сетевых карт, и каждую из карт подключить к отдельному порту коммутатора, являющемуся членом одного из имеющихся VLAN. Вот Вы точно этого хотите? А представляете, какой получится монстр, если количество VLAN будет не 5, а 15?

Да, в именно описанном случае можно спасти ситуацию, если использовать серверное оборудование и ПО, которые могут на одном внешнем интерфейсе создать несколько адресов из разных подсетей и статически зафиксировать для каждого из адресов определённый МАС-адрес, а на коммутаторе включить МАС-based VLAN. Но, поверьте, Ваша ситуация ну совершенно не располагает к созданию себе подобного геморроя...

--------------------

Как по мне, Вам вполне достаточно просто сделать несколько подсетей.

Инфраструктура виртуальных рабочих мест TermiDesk
Ну или
Терминальный сервер LTSP

WAN-интерфейс роутера может либо получать настройки по DHCP, либо настройки могут назначаться статически.

Касательно роутера, подключенного к провайдеру, всё очевидно. Провайдер желает DHCP - так и оставь.

Что же до своих роутеров, то лучше соблюдать железное правило - любые узлы, предоставляющие сервис (серверы, маршрутизаторы, включая и роутеры, и пр.), имеют статический адрес. Исходя из этого постулата, следует выделить внутренним роутерам для WAN адреса из LAN-подсети первого роутера, не входящие в его DHCP-скоп (т.е. недоступные для выделения). Кстати, именно с этой целью скоп обычно делают менее широким, нежели подсеть, оставляя и в начале, и в конце несколько свободных от выделения адресов.

Такая настройка позволит не выяснять каждый раз, какой IP присвоен роутеру, если потребуется подключиться к его административному интерфейсу со стороны WAN. Если для доступа к узлам сетей за вторичными роутерами используется port mapping или DMZ - не будет чехарды с адресом, можно будет использовать статические ссылки. Ну и ещё куча ситуаций, когда проблем со статическими адресами меньше, чем с динамическими. Да и правила доступа писать проще - как на основном роутере, так и на клиентских узлах его сети.

Считается, что можно установить на роутер динамический адрес, а в настройках DHCP основного роутера прописать эти назначения как статические. Однако это не убережёт от проблем, когда в сети первого роутера появится криво настроенный клиент с ошибочно включённым DHCP-сервером - сеть просто развалится. К тому же при исчерпании нерезервированных адресов в скопе и выключенном вторичном роутере основной может выдать и зарезервированный адрес - тоже не дождик золотой.

Сначала - инвентаризация. Понять, что есть.
Затем - проект. Понять, что предстоит сделать и что должно получиться в конце.
Далее - бюджет. Убедиться, что бюджет достаточен для реализации проекта, включая непредвиденные расходы, резервирование и прочие форсмажоры.
Если всё соответствует - можно начинать. Иначе даже не надо начинать - когда не получится, виноватого долго искать не придётся.

какой язык более универсальный для системного/сетевого администратора?

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

К примеру написать бота в телеграмм, организовать вывод показателей с серверов на сайт, и запилить минимальное приложение для мониторинга под windows/android, не заморачиваясь над фронт-ендом.

Вообще-то системный (тем более сетевой) администратор такой фигнёй не занимается.

Они идут я так понял для каждого пк со своим кодом (onedrive Standate Task-S-1-5-21-3362628...) и у каждого ПК свой код и они не дублируются.

schtasks /query /fo list | find "OneDrive"
Само собой от имени администратора.
А дальше очевидно - FOR /F и SCHTASKS /Delete.

• 0. Всегда (на все три вопроса). 800 устройств в одном домене коллизий, это [censored] и полный ступор.
  
• 1. Да. Но нет. Все в одной подсети - бред и никакого смысла.
  
• 2. Немаршрутизируемые в Интернет адреса (bogon networks). Я бы делал подсети в 172.16. Но это дело вкуса.
  
• 3. Ни разницы, ни усложнения нет и в помине. Стандартности тут тоже никакой.
  
• 4. Каждую подсеть в свой VLAN. Ибо нефиг.
  
• 5. Серверы в отдельных подсетях. Причём не одной. Что делать серверу видеонаблюдения в подсети бухгалтерии?
  
• 6. Стройте схему на основании потоков трафика, а не по некоему мистическому наитию.
  
• 7. Не у телефонии, а у некоторых коммутаторов есть специальная работа с VoiceVLAN. да, только экономия портов. Если не работал - то и не связывайся. Потом поэкспериментируешь.
  
• 8. По требованиям безопасности сеть видеонаблюдения вообще должна быть по возможности физически отделена от пользовательской. Отдельные коммутаторы и кабельные линии. да и трафика они генерят - могут забивать каналы, оно надо? То же и с линиями охранно-пожарной сигнализации - но тут строго, никаких "по возможности".
  
• 9. Сервер печати. И да - он и принтеры в отдельном VLAN.
  

Ставим L3 коммутатор, который будет рулить потоком, его же добавляем в качестве шлюза.

Ставь сразу нормальный маршрутизатор.
Потому что коммутатор, хоть и L3, тебе ничего не даст во вменяемой форме - ни статистики, ни управления, ни наблюдения.

Найти: +[^ ]+$ (в начале перед плюсом один пробел)
Заменить: (пустая строка)

Режим - регулярные выражения, зацикленный поиск.

Удаляет всё от последнего пробела до конца строки, если строка оканчивается не-пробелом. Удаляет и сам последний пробел (если их несколько - удаляет все). Если последний символ в строке пробел - не удаляет ничего.

Начните с определения группы адресов, подлежащих блокировке. Пропишите туда все подсети из RFC, кроме, возможно, мультикаста.

Затем первым создайте правило, согласно которому входящие пакеты WAN-интерфейса, адреса которых принадлежат этой группе, action=drop.

Нет, это явное нарушение RFC.

Адрес 192.168.40.40 относится к категории немаршрутизируемых в Интернете. Любой узел, если он получил пакет на этот адрес на интерфейсе с маршрутизируемым адресом, либо если он должен согласно своей таблице маршрутизации отправить его через интерфейс с маршрутизируемым адресом, должен отказать в маршрутизации (какое при этом применить правило - deny или drop,- не описано). В трассе имеется адрес 188.***.172, не принадлежащий какой-либо немаршрутизируемой сети - следовательно, в маршрутизации пакета должно было быть отказано.

А что бардак - таки да, это в порядке вещей. Вы поснифьте свой внешний адресок да посмотрите, сколько на него попадает "грязи" - удивитесь.