Мы немного про разные вещи говорим. Я про склады, где есть рабочие места с термопринтерами и А4, где сотрудник работает на одном месте и должен получать результаты печати чуть ли не мгновенно, от этого зависит скорость обработки. Эта скорость достигается принтером на каждом рабочем месте, а то и не одним. Как вы понимаете - follow printing это не вариант))
Другой сценарий - сотни филиалов по 2-3 сотрудника на каждом. Сотрудники в терминалках, хотя тут не сильно важно. Обслуживание также максимально ускорено и ожидание печати с одного принтера недопустимо.
Выливаются данные сценарии в тысячи принтеров, которые надо раздавать, что и решают подобные скрипты
А зачем применять CoW для файла лога? Не проще его копировать обычным методом и сделать отдельным для каждой БД, тем более, что за счет отсутствия там CoW и производительность должна чуть вырасти, если мы говорим про запись?
Прочитал, что в домене вы не можете делать новые группы, но по-хорошему, это подразумевается. Даже в случае недоступности изменений в домене, можно обойтись фильтрацией LDAP в разделе authc для указания групп и не указывать точечно пользователей.
даже на 30 сек таймаута фейлится, на особо больших папках получение размера беклога занимает до минуты иногда.
Используется командлет Get-DfsrBacklog с -Verbose
Самое главное с чем столкнулись в своей реализации — таймауты от агентов при мониторинге беклога больших папок.
На больших папках — они неизбежны, поскольку беклог в 1000+, а то и в 10000+ это норма у нас при больших изменениях.
Выкручивались шедулером, который собирает инфу в текстовые файлы, заббикс уже работает с ними (дискавери и опрос).
Если этот порт смотрит в мир без ограничений — да.
Если вы единственный пользователь, то еще полбеды.
Если это терминальный сервер с N юзеров, политикой смены паролей и блокировки учеток — то это совсем беда. Будете ловить и блокировки учеток из-за попыток подбора и пароли в стиле «Qwe123!», который прекрасно подходят под политику сложности, но неустойчивы к брутфорсу.
К сожалению — выставить 3389 в мир, а потом героически сражаться с последствиями — излюбленная игра многих. Идеальное решение — VPN. Если невозможно, то хотя-бы нестандартный порт.
Рекомендации проброса 3389 на роутере — вообще за гранью.
Это один из излюбленных сервисов для атаки брутфорсом, не пробрасывайте стандартный порт никогда.
Пробовали встроенные в винду v4 драйвера? У нас была проблема с HP UPD всех версий.
Когда число принтеров достигло 200 — с ними работать стало невозможно, свойства принтера открывались минут по 5.
Переход на Class Driver проблему решил полностью.
На Kyocera вижу тоже есть встроенные драйвера, в том числе и универсальные Monochrome\Color.
Что-то у вас нездоровое со спулером, ну или дрова кривые на принтера. Зависшие в очереди задания это конечно проблема, но решается она гораздо проще: Get-Printer | get-printjob | where{$_.SubmittedTime -lt ((Get-Date).adddays(-1))} | Remove-PrintJob
Запуск каждый час — вычищать все, что поставлено в очередь больше суток назад. Врядли кому-то нужны уже эти документы.
Ну и даже при 700+ суммарно в очередях — проблем со 100% потреблением ЦПУ не наблюдали.
Maintenance позволяет оставить триггеры и сбор данных, но убрать ненужные оповещения в действиях. У нас например в период обновлений вин серверов триггеры работают только в Jabber. SMS и Телеграм отключаются установкой галки «Приостановить операции в режиме обслуживания»
Самым веселым в переезде на VCSA было то, что переезд с Vcenter на винде версии 6.5 на VCSA версии 6.5 — не поддерживается. Если вы уже обновились на 6.5 виндовый — никаких вариантов, только ручной перенос конфигурации.
У нас благо не такая большая инсталляция, перенесли руками.
VCSA HA — понравился, отработали различные сценарии падения — все четко отрабатывает как и должно.
Если на ферме одна коллекция рабочих столов, то даже без loadbalanceinfo вас бросит на наименее нагруженный (по сеансам) RDSH.
Случаи с несколькими коллекциями не тестил, возможно там и работает так, как вы описали.
Вы немного передергиваете. Удалить выключенный сервер из фермы можно, само удаление проходит с предупреждениями, но доходит до конца.
В статье говорится про ситуацию, когда в ферме есть выключенный сервер и его учетка удалена в AD. Вы часто такое делаете?
Мы немного про разные вещи говорим. Я про склады, где есть рабочие места с термопринтерами и А4, где сотрудник работает на одном месте и должен получать результаты печати чуть ли не мгновенно, от этого зависит скорость обработки. Эта скорость достигается принтером на каждом рабочем месте, а то и не одним. Как вы понимаете - follow printing это не вариант))
Другой сценарий - сотни филиалов по 2-3 сотрудника на каждом. Сотрудники в терминалках, хотя тут не сильно важно. Обслуживание также максимально ускорено и ожидание печати с одного принтера недопустимо.
Выливаются данные сценарии в тысячи принтеров, которые надо раздавать, что и решают подобные скрипты
Очень узкое решение, рассчитано на офис, где стоит большое МФУ, к которому все ходят
Нереализуемо для организации печати на складах и россыпи филиалов, думаю, что вы понимаете почему
Проще ровно до того момента, пока не начнете ловить приколы с расшаренными принтерами. А они проявляются довольно быстро. Навскидку:
Забивание реестра расшаренными принтерами.
Забивание механизма CSR удаленными\старыми\ненужными принтерами.
Исчезновение всех принтеров у пользователя до перелогина. Иногда до удаления профиля.
Это основные проблемы, которые заставили сделать свое решение, примерно такое же как в статье. Отличия:
В качестве хранилища используется MSSQL, поскольку уже развернут в компании.
Импорты разделены на фулл\дифф, поскольку сравнение занимает много времени. Дифф вычисляется при экспорте сравнением на стороне SQL.
Инициатор установки не принт-сервер, а каждый RDSH, из-за их количества.
Данный механизм позволил полностью решить все проблемы с принтерами, работает успешно уже более 5 лет. Принтеров около 2000+, 100+ серверов.
А есть какая-то зависимость от версии ОС под SQL сервером? Win2016/2019?
А зачем применять CoW для файла лога? Не проще его копировать обычным методом и сделать отдельным для каждой БД, тем более, что за счет отсутствия там CoW и производительность должна чуть вырасти, если мы говорим про запись?
Прочитал, что в домене вы не можете делать новые группы, но по-хорошему, это подразумевается. Даже в случае недоступности изменений в домене, можно обойтись фильтрацией LDAP в разделе authc для указания групп и не указывать точечно пользователей.
Пример из живой системы:
Соответственно, для вашего случая, можно указать 3 memberOf параметра через OR и просто наполнять группы, не трогая конфиг Opensearch.
В идеале, конечно, сделать одну группу и включать в нее нужные.
Используется командлет Get-DfsrBacklog с -Verbose
На больших папках — они неизбежны, поскольку беклог в 1000+, а то и в 10000+ это норма у нас при больших изменениях.
Выкручивались шедулером, который собирает инфу в текстовые файлы, заббикс уже работает с ними (дискавери и опрос).
Как у вас это обходится?
Если вы единственный пользователь, то еще полбеды.
Если это терминальный сервер с N юзеров, политикой смены паролей и блокировки учеток — то это совсем беда. Будете ловить и блокировки учеток из-за попыток подбора и пароли в стиле «Qwe123!», который прекрасно подходят под политику сложности, но неустойчивы к брутфорсу.
К сожалению — выставить 3389 в мир, а потом героически сражаться с последствиями — излюбленная игра многих. Идеальное решение — VPN. Если невозможно, то хотя-бы нестандартный порт.
Это один из излюбленных сервисов для атаки брутфорсом, не пробрасывайте стандартный порт никогда.
Когда число принтеров достигло 200 — с ними работать стало невозможно, свойства принтера открывались минут по 5.
Переход на Class Driver проблему решил полностью.
На Kyocera вижу тоже есть встроенные драйвера, в том числе и универсальные Monochrome\Color.
Get-Printer | get-printjob | where{$_.SubmittedTime -lt ((Get-Date).adddays(-1))} | Remove-PrintJobЗапуск каждый час — вычищать все, что поставлено в очередь больше суток назад. Врядли кому-то нужны уже эти документы.
Ну и даже при 700+ суммарно в очередях — проблем со 100% потреблением ЦПУ не наблюдали.
Как раз ищем приемлимый способ синхронизировать джобы на alwayson кластере, пока находил только плагин под студию для ручной синхронизации.
У нас благо не такая большая инсталляция, перенесли руками.
VCSA HA — понравился, отработали различные сценарии падения — все четко отрабатывает как и должно.
Случаи с несколькими коллекциями не тестил, возможно там и работает так, как вы описали.
В статье говорится про ситуацию, когда в ферме есть выключенный сервер и его учетка удалена в AD. Вы часто такое делаете?