Для чего нужен сервер печати

[]

PrintFn » Справочная информация: » Справочное бюро » Принтеры » Принт-сервер

Зачем нужен принт-сервер?

В организациях с локальной сетью малого и среднего масштаба распространенным вариантом совместной сетевой печати является использование персонального принтера, подключенного к одному из ПК. Главное достоинство такого метода — его экономичность. Но в токам варианте при печати задействуются дополнительные ресурсы этого ПК. При этом производительность такого компьютера значительно снижается. Выделение одного ПК лишь для сетевой печати накладно финансово, особенно если объемы печати не превышают возможностей используемого печатающего устройства. В решении этой проблемы и призваны помочь так называемые принт-серверы.

Что такое принт-сервер?

Сервер печати представляет собой небольшое сетевое устройство стоимостью от $40, к которому может подключаться один или несколько (в зависимости от типа устройства) принтеров. Принт-серверы бывают двух типов: внешние и внутренние. Первые могут работать с любыми принтерами, вне зависимости от производителя. Внутренние — только с принтерами разработчика сервера печати. В любом случае устройство является "прозрачным" для ОС и требует лишь корректной настройки его параметров для используемых в сети транспортных протоколов.

Различные модели серверов печати отличаются в основном количеством и типом портов для подключения к ним принтеров, скоростью работы в сети (10 или 100 Mbps), размерами, а также спектром поддерживаемых сетевых протоколов и, как следствие, способностью работать в "многооперационных" сетях (т. е. локальных сетях, в которых используются ПК под управлением ОС различных типов).

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

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

Здравствуйте.
Так сложилось что организация может себе позволить не использовать централизованный сервер печати.

Есть некий интегратор готовый предоставить услугу по аудиту печати. В процессе переговоров было предложено подключить все принтеры (4 филиала по десятку принтеров, в основном сетевых, но есть по 3-4 штуки usb) к одному серверу печати и с него снимать метрики.

В качестве плюса использования сервера печати было приведено легкое администрирование парка принтеров.

Под администрированием подразумевается установка, удаление принтеров на конечных компьютерах.

На наш взгляд использование сервера печати это добровольная организация единой точки отказа, с соответствующими затратами на её эксплуатацию.

Затем непонятен смысл и алгоритм использования подключенных локально (по USB) принтеров к компьютеру через сервер печати.

И если я правильно понимаю, то объем сетевого трафика точно увеличится (точной цифрой не обладаю, но по ощущениям достаточно сильно, т.к. были жалобы на замедление печати на терминальных серверах при использовании технологии Easyprint которая использует XPS).

Так вот собственно вопрос: какие еще преимущества дает сервер печати кроме приведенного выше.

Возможно, количество устройств нам пока не позволяет проникнуться удобством единого сервера, тогда хочется попросить примеры реализаций подсистемы печати.

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

Читайте также:  База данных маркетинговых исследований

Если ответ будет: учи матчасть, прошу не кидаться тухлыми помидорами, а кинуть ссылкой на документацию.

Немного теории

Кто не любит теорию и хочет быстрее поклацать мышью и клавиатурой, может сразу перейти к следующей части.
Как было сказано выше, официальная рекомендация на сегодняшний день — это решение с использованием кластеризации и виртуализации Hyper-V. Также ничто не мешает обеспечить отказоустойчивость сервиса печати на уровне системы виртуализации, причем не обязательно Hyper-V, но такие решения стоят денег.
Мне очень хотелось что-нибудь похожее на DHCP Failover, но для роли принт-сервера.
В интернете в целом и на хабре в частности ничего подходящего не нашлось — и пришлось изобретать самому.

Суть идеи в одном абзаце
Описанное ниже решение основано на использовании утилиты BrintBrm, входящей в стандартную поставку Windows и пришедшую на замену printmig.
Резервный сервер работает в standby-режиме и с заданной периодичностью синхронизирует настройки с основным сервером с помощью этой утилиты. Для клиентских машин в DNS создан CNAME с малым TTL, ссылающийся на основной сервер. В случае аварии основного сервера админ правит CNAME, переключая клиентов на резервный сервер. Вот, собственно, и всё.
Если тема интересна и хочется познакомиться с уже набитыми мной шишками и путями обхода граблей, прошу следовать дальше.

Before you begin, или что нужно знать о PrintBrm

Итак, какова она, эта утилита PrintBrm, главное назначение которой — прислуживать серверу печати?

  • Ухожена. Имеет GUI-воплощение, которое именуется Перенос принтеров (Print Migration) и может быть запущено из оснастки Управление печатью. GUI-вариант менее функционален и имеет проблемы с переносом портов.
  • Внимательна. По умолчанию обрабатывает ACL принтеров принт-сервера. Другими словами, если вы разрешили печатать на принтере \printserverprinter1 только сотрудникам, входящим в AD-группу Бухгалтерия, то это ограничение будет учтено импорте/экспорте. Или не будет, если поставить ключ -NOACL. При этом ACL самого сервера печати не обрабатывается независимо от ключа.
  • Капризна. На момент импорта параметров из файла на целевом сервере должен быть хотя бы один расшаренный принтер, иначе получите ошибку.
  • Нежна. Теряется, видя пробелы в пути файла. При виде кавычек, обрамляющих такой путь, огорчается и выдает ошибку 0x8007007b.
  • Скромна. Если при попытке экспорта настроек указанный файл уже существует, перезаписать его не может, спросить стесняется и также завершается с ошибкой.
  • Таинственна. Всегда возвращает exit-код, равный 0. Получается, идеальная программа.
  • Склонна к раздумьям. Может подзависнуть на стадии 100% минут на 5, а иногда и больше. Но потом одумывается и завершает работу (если, конечно, у вас хватит терпения не нажать Ctrl+C).
  • Внезапна и противоречива. Может устраивать вот такие сюрпризы.
  • Умна. Может переназначать исходные драйверы на другие. Например, с помощью XML-файла можно указать, что все драйверы HP Universal Printing PCL 5 в сохраненном файле на целевом сервере надо переназначить на HP Universal Printing PCL 6. На практике не использовал, но для кого-то может пригодиться.
  • Своенравна. Использовать ее для переноса настроек между доменами без доверия у меня не получилось, даже с ключом -NOACL. Либо не умеет в принципе, либо моя магия недостаточно сильна.
  • Познакомиться поближе можно тут и здесь, а для тех отважных, кто не стесняется спросить напрямую, есть ключ /?

Допускаю, что какие-то черты я незаслуженно обошел вниманием. Возможно, в Windows 10/2016 она стала вести себя иначе. Если есть информация, прошу поделиться.

Подготовка среды

Предполагается, что у вас уже развернута Active Directory и вы знаете как минимум 3 способа вывести ее из строя и хотя бы 2 из них были опробованы на практике.

Будем исходить из того, что все принтеры сетевые и доступны для печати с основного и резервного принт-серверов. Пусть эти серверы называются prn-srv01 и prn-srv02 соответственно.
В качестве принт-серверов подойдут доменные машины на Windows Server не ниже 2008. В принципе подойдут и клиентские ОС, начиная с Vista, если уж очень хочется сэкономить. В примере используется Windows 2012 R2. Крайне желательно перед настройкой установить все необходимые обновления операционной системы как на серверы, так и на клиентские машины.

Вы и сами, конечно, понимаете, но кэп всё же требует обратить внимание: если принт-серверы будут виртуальными, то они обязательно должны быть разнесены по разным физическим серверам, иначе наш failover превратится просто в fail.

Читайте также:  Игра герои 7 вылетает

На prn-srv01 и prn-srv02 должна быть добавлена роль сервера печати. Мне удобнее для этого использовать командлет PowerShell:
Install-WindowsFeature Print-Services

Также на принт-серверах должен быть применен твик реестра, который исправляет ошибку 0×00000709 при обращении клиентских машин к принт-серверу по CNAME. Можно сделать это командой из статьи по ссылке выше:
reg add HKLMSYSTEMCurrentControlSetControlPrint /v DnsOnWire /t REG_DWORD /d 1
После применения команды нужно перезапустить службу Диспетчер печати.
Рекомендую выделить для принт-серверов отдельный OU и раздавать эту настройку с помощью GPP.

Запускаем оснастку DNS на контроллере домена и включаем расширенное отображение:

Это имя должны использовать клиентские машины для подключения к принт-серверу. Т.е. клиент будет подключаться к адресам \printprinter01, \printprinter02 и т.д.
Чем меньше значение TTL, тем чаще клиенты будут обновлять запись и быстрее “поймут”, что надо переключиться на другой сервер печати. Мне достаточно 5 минут.
Задав слишком малое значение, вы плодите DNS-трафик в своей сети, а указав час или два, вы подчеркнете свою стрессоустойчивость и крепкие нервы.
Альтернативный вариант добавления CNAME-записи с помощью PowerShell:
Import-Module DnsServer
Add-DnsServerResourceRecordCName -Name "print" -HostNameAlias "prn-srv01.lab.net" -ZoneName "lab.net" -TimeToLive 00:05:00

(Разумеется, lab.net меняем на ваш contoso.local или как там его)

Надо учесть, что если у вас несколько сайтов AD, то обновление DNS-записи во всех локациях займет больше времени за счет межсайтовой репликации. Форсировать процесс можно командой repadmin /syncall.

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

Создаем служебную учетную запись в AD (я назвал ее svc-printsync) с неограниченным сроком действия пароля:

Согласно требованиям PrintBrm, эта учетная запись должна обладать полными правами на принт-сервере, поэтому добавляем ее в домен-админы, чтобы наверняка всё работало и прописываем пароль в поле описания, чтобы не забыть локальную группу Администраторы на prn-srv01 и prn-srv02 (например, с помощью оснастки Управление компьютером).

Настраиваем первый сервер

Если все нужные принтеры на основном принтере уже добавлены, то можно сразу перейти к разделу о настройке второго сервера.

С помощью оснастки Управление печатью добавляем на сервер драйверы нужных принтеров:

Некоторые комплекты драйверов содержат общий inf-файл и для x86, и для x64-систем, в других же присутствует разделение.

Когда все необходимые драйверы добавлены, займемся портами и принтерами. Можно их добавить вручную из той же оснастки, но я рекомендую создать CSV-файл в Excel и скормить его PowerShell-скрипту. Разумеется, ничто не мешает вместо Excel использовать любой другой табличный редактор или вообще блокнот. Главное — чтобы разделитель и кодировка, указанные в скрипте, соответствовали разделителю и кодировке в CSV-файле.
Также обратите внимание, что имя драйвера в CSV-файле должно быть точно таким же, каким оно указано в оснастке Управление печатью.

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

Сохраним эту таблицу в CSV-формате:

Если в качестве разделителя в вашем CSV используется знак табуляции, то в скрипте надо выставить -Delimiter "`t"

Учтите, что если во время работы скрипта какой-нибудь принтер будет недоступен с сервера, то его добавление на принт-сервер займет больше времени (2-3 минуты вместо нескольких секунд)

Результат работы скрипта:

Чтобы убедиться, что на этом этапе всё работает, добавляем на любую из клиентских машин общий принтер с основного принт-сервера, используя ранее созданный CNAME (например, \printprinter01), и пробуем распечатать на нем что-нибудь. Для этой цели лучше всего подойдет фраза “Превед, я бумажко”, набранная жирным шрифтом Arial с 200-м кеглем.

Настраиваем второй сервер

Un artista copia, un gran artista roba (Пабло Пикассо)

Наш prn-srv02 пока еще не дорос до уровня gran artista, поэтому ограничимся копированием. Хотя… можно легким движением руки.

Создаем и расшариваем хотя бы один принтер, иначе PrintBrm выдаст ошибку. Можно сделать фейковый, но при этом важно не выбрать неподходящий драйвер или порт. Например, принтер с драйвером Microsoft XPS Document Writer или портом FILE: расшарить не получится.

Читайте также:  Внутренняя ошибка подсистемы контроля несогласованных изменений

Создаём незатейливый скрипт синхронизации. Я предпочитаю PowerShell, но никто не запрещает сделать теплый ламповый батник.

Кладем скрипт в укромное место (в примере это C:Scripts) и создаем задачу в Планировщике.
Запускать будем из-под ранее созданной учетной записи svc-printsync с наивысшими правами:

Остальные параметры задачи на вкладках Условия и Параметры оставляем по умолчанию.
При сохранении задачи будет запрошен пароль для учетной записи svc-printsync. Вы ведь его не забыли? Если уже забыли (статья-то длинная), то всё было сделано зря и жизнь не удалась сбросьте его с помощью оснастки ADUC или другим удобным способом и укажите его уже в поле описания, чтоб было спокойнее.

В первый раз запускаем задание вручную и дожидаемся его завершения.
Для моего зоопарка, где около 50-ти принтеров разных видов, как вымирающих, так и недавно выведенных, процедура синхронизации занимает примерно 10 минут. Файл при этом весит почти 1ГБ.
Для ускорения процесса импорта/экспорта можно использовать ключ -NOBIN, который отвечает за копирование драйверов. Имеет смысл, когда парк принтеров состоит из одинаковых моделей и необходимые драйверы установлены на всех серверах.

После завершения запускаем оснастку Просмотр событий, переходим в раздел Журналы приложений и служб, открываем журнал MicrosoftMicrosoftPrintBRMАдминистратор и анализируем его на предмет ошибок и предупреждений. И если их слишком много, то скорее чистим журнал, чтоб глаза не мозолили.

Мне попадались с кодами 20, 22, 80 и 81. Например,

Как ясно из текста, возникла проблема при переносе определенного драйвера. Просматривая журнал, составляем список проблемных драйверов и ставим их руками на резервный сервер, либо заменяем другими, которые не прочь попутешествовать. У меня были проблемы лишь с HP, Kyocera и Konica Minolta, для драйверов других производителей ошибок не выявилось (может потому, что они лучше, а может потому, что у нас их просто нет).
В итоге нужно добиться одинакового списка принтеров на основном и резервном серверах и отсутствия ошибок и предупреждений в логах.

Переключаемся на резерв

Через некоторое время (что вы там ставили в TTL?) угрожающие вопли стихнут, клиентские машины переключатся на prn-srv02 и дверь с телефоном можно будет разблокировать.

Возвращаемся обратно

Если за время восстановления основного сервера на резервном были изменения конфигурации, которые необходимо сохранить, запускаем синхронизацию в другую сторону. Для этого в указанном выше скрипте PrintSync.ps1 меняем местами значения переменных $SourceServer и $DestServer. После переноса изменений не забудьте вернуть эти значения обратно, иначе все изменения в конфигурации принтеров на prn-srv01 будут нещадно отметаться каждую ночь злой волей судьбы.
В оснастке DNS устанавливаем для CNAME-записи print значением конечного узла prn-srv01 — и всё возвращается на круги своя.

Что в итоге?

Бурные овации руководства, подкидывание админа на руках, повышение зарплаты (автору статьи — честные 10% от прибавки)…
Ну и несколько мыслей в сторону наведения дальнейшей красоты.

Чудес, к сожалению, на всех не хватает, и данное решение — не полноценный Failover. Если в момент крушения основного принт-сервера на нем будут непустые очереди печати, то их содержимое скорее всего канет в лету и кому-то придется повторять отправку на печать.

Зато очень удобно будет прозрачно для пользователей выполнять регламентное обслуживание серверов печати.

Фанаты автоматизации могут пойти дальше и создать скрипт, который на входе получает имена серверов с интервалом синхронизации и остальные настройки делает сам: создает сервисную учетную запись при необходимости, задание в планировщике и т.д.

Гуру мониторинга добавят наблюдение за выполнением задачи синхронизации и ошибками в логах.

Любители копать глубже могут продумать двухстороннюю синхронизацию в духе репликации AD с отслеживанием времени изменений по каждому принтеру. PrintBrm тут уже не поможет, но никто не отменял PowerShell!

Вишенкой на торте будет автоматическая установка принтеров на клиентских машинах с помощью GPP с нацеливанием на группу AD. Добавляем пользователя в группу — и ему прилетает нужный принтер. Правда, это уже другая история, выходящая за рамки статьи.

Надеюсь, для кого-то моя публикация окажется полезной. Желаю всем поменьше сбоев и жду вопросов и предложений в комментариях.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Оцените статью
Adblock
detector