Публикация принтеров в AD

Механизм объявлений упрощает поиск принтеров

Когда системным администраторам приходится иметь дело с нарушениями в работе принтеров, у большинства из них возникает желание удалиться в серверную комнату и спокойно наблюдать за миганием маленьких цветных лампочек. Принтеры — скучный предмет. Тем не менее возможность отыскать доступные принтеры в Active Directory (AD) — одно из самых очевидных преимуществ, получаемых пользователями при переходе от Windows NT к Windows 2000. Такой поиск становится эффективным благодаря механизму публикации принтеров в AD.

Публикация принтеров

По умолчанию Windows 2000 Server и более поздние версии автоматически публикуют информацию о принтерах в AD. Чтобы проверить, были ли данные о принтерах опубликованы в AD, нужно открыть диалоговое окно Properties принтера, перейти к вкладке Sharing и установить или сбросить флажок List in the Directory (экран 1).

Экран 1. Окно свойств принтера с выбранным флажком List in the Directory

Следует помнить, что информация о принтерах, опубликованная в AD, — это простое описание принтера. В процессе публикации в AD создается объект класса printQueue. Очередь печати является потомком объекта computer, который предоставляет службу принт-сервера. Для просмотра атрибутов объекта print queue (очередь печати) в AD можно использовать такие инструменты, как ADSI Edit или ldp.exe. В табл. 1 приведен пример атрибутов, установленных для принтера Epson DFX-8500. Данная информация полезна, если требуется убедиться, что сведения о принтере опубликованы в AD.

На рабочих станциях Windows XP или Windows 2000 Professional информацию о принтерах можно публиковать в AD с помощью флажка List in the Directory, но эта процедура не автоматизирована. Для большинства организаций возможность публикации принтеров рабочих станций в AD менее полезна, чем публикация принтеров, связанных с принт-серверами, так как принтеры рабочих станций выделяются для конкретных пользователей. Кроме того, рабочие станции часто бывают отключены или по другим причинам недоступны в течение длительного времени.

В AD можно опубликовать и принтеры, связанные с компьютерами NT 4.0 и Windows 9x, но это более трудоемкий процесс. В настройках таких систем отсутствует флажок List in the Directory, поэтому администратор должен сформировать объект print queue вручную (с помощью оснастки Active Directory Users and Computers консоли управления MMC) или используя сценарий pubprn.vbs в папке system32. Более подробно о применении сценария pubprn.vbs рассказано в статье Microsoft «Publishing a Printer in Windows Active Directory» (http://support.microsoft.com/?kbid=234619).

Поиск принтеров

Для пользователя главным преимуществом публикации информации о принтерах в AD будет расширение возможностей поиска. Пользователи могут не только отыскивать принтеры в лесу, но и вести детальный поиск по отдельным функциям и характеристикам принтеров. Например, можно будет искать принтеры по имени, местонахождению, модели (если эта информация имеется в AD) и функциональным возможностям устройства (например, цветная или двусторонняя печать). Обращаясь к вкладке Advanced из окна поиска, пользователи могут искать принтеры почти по любым атрибутам объекта print queue, хранящимся в AD.

Для доступа к функции поиска на рабочих станциях XP и Windows 2000 Pro следует выбрать пункты меню Start, Search и Find Printers. В предыдущих версиях Windows таких возможностей не было, но пользователи могут искать принтеры в AD, если на компьютеры установлен Directory Services Client.

Чтобы облегчить задачу пользователей, следует заполнить поле Location для каждого принтера, публикуемого в AD. Проектируя AD, необходимо составить удобное, масштабируемое соглашение об обозначении местоположения устройств. Синтаксис поля Location следующий:

name/name/name/name/...

от наиболее общих к наиболее точным указателям места. Например,

Switzerland/Basel/Building8/Level1/Room18

обозначает конкретную комнату в швейцарском офисе.

Экран 2. Использование поля Location для поиска принтеров в AD

При использовании поля Location возможны два варианта. Первый из них — просто заполнить поле Location на странице General properties каждого принтера, определенного на принт-сервере. Данный подход позволяет выполнять поиск во всей названной области или ее части (с применением универсального символа — *). При использовании второго, гораздо более эффективного способа также следует заполнить поле Location всех определенных в AD подсетей и активизировать параметр групповой политики Pre-populate printer search location text. При таком подходе пользователи увидят в поле местоположения окна Find Printer готовые данные о своей рабочей станции (экран 2). Рабочая станция получает сведения о местонахождении, сравнивая IP-адрес с подсетями, определенными в AD. Обнаружив совпадение, рабочая станция копирует сведения из поля Location подсети в строку местонахождения окна Find Printer. Более подробная информация об автоматическом заполнении поля Location приведена в материале Microsoft «Best Practices for Deploying Printer Location with Active Directory» (http://www.microsoft.com/windows2000/ technologies/fileandprint/print/addeploy.asp).

Обнаружить принтеры можно и с помощью оснастки Active Directory Users and Computers. Щелкнув правой кнопкой мыши на левой панели, следует выбрать пункт Find, затем Printers из раскрывающегося списка и ввести критерий поиска. Чтобы просмотреть в оснастке объекты print queue под соответствующими родительскими объектами print-server (экран 3), необходимо сначала выбрать пункт Users, Groups and Computers as Containers из меню View.

Поиск неисправностей в Printer Publishing

В Windows 2000 Server и более новых принт-серверах используется протокол LDAP для автоматической публикации в AD информации о принтерах. Как показано на экране 4, SRV-записи DNS объявляют LDAP-службы, работающие на контроллерах домена (DC). Для публикации информации о принтерах принт-сервер ведет поиск ближайшего DC с помощью SRV-записей DNS. С целью повышения производительности принт-сервер пытается опубликовать информацию на ближайшем DC. В распределенной инфраструктуре AD, сайты которой соединены каналами связи с малой пропускной способностью, принт-серверу следует публиковать данные на локальном, а не на удаленном DC. В результате при возникновении неполадок с DNS или если настройки DNS на принт-сервере неверны, на предприятии могут возникнуть проблемы с публикацией принтеров в AD.

Если принтер успешно опубликован в AD, то принт-сервер, выполнивший операцию, записывает в журнал System событие с ID 36, аналогичное показанному на экране 5. С помощью ADSI Edit или ldp.exe можно убедиться, что объект print queue был успешно опубликован в AD и атрибутам присвоены корректные значения (примеры приведены в табл. 1).

Экран 5. Событие ID 36 журнала событий System

Любой компьютер или пользователь, записывающий информацию в AD, должен иметь для этого определенные разрешения. Чтобы успешно создать объекты print queue в AD, родительский объект (то есть принт-сервер) должен иметь разрешения для создания дочерних объектов. Такое разрешение (создавать/удалять дочерние объекты) устанавливается по умолчанию, но если администратор внес какие-либо изменения в стандартные параметры, возможно, придется специально активизировать разрешение для публикации принтеров в AD.

Если принт-сервер не опубликует принтеры после установки флажка List in the Directory, как описано выше, то он продолжит свои попытки. Однако при этом принт-сервер выведет на экран сообщение The Directory operation is still in progress (идет выполнение операции в службе каталога). Это же сообщение может появиться при неполадках, после того как администратор сбросил флажок, чтобы удалить информацию о принтерах из AD. Процесс публикации или удаления принтера занимает всего несколько секунд. Поэтому, если принт-сервер не выполнил эту операцию за несколько минут, значит, возникли неполадки. Следует проверить правильность параметров DNS на клиенте и доступность SRV-записей DNS на контроллере домена. Если причина сбоя все еще не установлена, нужно убедиться, что родительский объект computer имеет разрешения для создания дочерних объектов.

Удаление принтеров

AD автоматически удаляет информацию о принтерах, если очередь печати удалена из принт-сервера. Но что происходит, если принт-сервер неожиданно и безвозвратно удаляется из сети? В этом случае AD не удаляет информацию о принтерах автоматически, так как удаление этих данных — задача принт-сервера. В результате устаревшие объекты print queue могут неопределенно долгое время оставаться в AD. Для решения этой проблемы специалисты Microsoft разработали службу удаления принтеров (printer pruner — она же directory pruning в групповых политиках). В действительности служба удаления принтеров — не отдельная служба Windows, но она работает как поток в процессе спулинга на контроллерах домена.

В определенных условиях результаты работы службы удаления могут быть непредсказуемыми. Иногда в дискуссионных форумах приходится встречать сообщения о том, что некоторые или даже все принтеры исчезли из AD. Как это произошло? Чтобы понять причину проблемы, нужно рассмотреть, как работает служба удаления.

Она работает на всех контроллерах домена AD. Периодически служба связывается с очередью печати сервера, дабы убедиться, что принтеры, опубликованные в AD, все еще присутствуют в сети. Затем служба несколько раз обращается к очереди печати в течение определенного периода времени. Стандартный режим проверок — три обращения с восьмичасовыми интервалами в сутки (интервал можно изменить в разделе Computer Configuration, Administrative Templates, Printers оснастки MMC Group Policy). Если служба удаления не может установить связь с очередью печати в течение заданного периода, то она удаляет объект print queue из AD. Таким образом, используя периодические проверки, служба удаляет принтер из AD в течение 24 часов.

Сначала каждая служба удаления принтеров DC составляет список всех принтеров, опубликованных в AD. Затем с помощью DNS отыскиваются принт-серверы, расположенные в ее собственном сайте AD. После этого служба пытается установить связь с каждой очередью печати на принт-серверах в этом сайте, удаляя объекты print queue из AD.

Проблемы возникают, когда служба не может найти информацию о принт-сервере в DNS и, следовательно, не в состоянии определить, находится ли принт-сервер в том же сайте AD, что и DC. В этом случае служба удаления просто полагает, что принтер находится в том же сайте AD, что и DC, на котором работает служба удаления. Это предположение может вызвать проблемы в том случае, если DC и принт-сервер находятся в разных местах, соединенных медленными сетевыми каналами, или если одно из устройств расположено за брандмауэром. Если DC не может установить связь с очередью печати в течение заданного периода, то служба удаления просто изымает информацию об очереди печати из AD. DC, на котором выполняется удаление, использует стандартную процедуру репликации каталогов для пересылки изменений на все другие DC домена.

Другая проблема связана с клиентской службой DHCP. Как известно, служба DHCP client необходима для динамической регистрации в DNS (DDNS — dynamic DNS). Поэтому, если служба DHCP client на принт-сервере остановлена, сервер не может динамически перерегистрировать хост-адрес (A) и указатель (PTR) ресурсов. По истечении определенного периода времени запись DNS принт-сервера может быть удалена из DNS в процессе уборки «мусора» и устаревших данных. Если запись принт-сервера удалена, то каждая служба удаления принтеров предполагает, что DC, на котором она работает, находится в том же сайте AD, что и принт-сервер. И опять же, если ни один из этих DC не имеет сетевого соединения с принт-сервером, то служба удаления «уберет» принтеры из AD. Важно, чтобы служба DHCP client функционировала на всех принт-серверах в AD, которые работают с DDNS; этой цели можно добиться с помощью групповой политики. Аналогично, если отключить DC от сети на период времени, превышающий заданный период опроса, но при этом DC продолжает работать, то служба удаления принтеров на этом DC удалит все опубликованные принтеры из-за отсутствия связи с ними. Если связь DC с сетью восстанавливается, то удаленная информация будет реплицирована с других DC.

Некоторые записи журнала событий могут быть полезными при диагностике проблем с принтерами, в частности событие с ID 47 в журнале событий System контроллера домена. Это событие, как правило, происходит, когда служба удаления совершает неудачную попытку связаться с очередью печати на принт-сервере. Если вслед за событием с ID 47 в журнале System регистрируется событие с ID 50, значит, предпринято максимальное число попыток и AD удалила объект print queue.

Каким образом эти события помогут обнаруживать неполадки в службе удаления принтеров, можно пояснить на следующем примере. Предположим, администратор замечает, что из AD внезапно исчезли некоторые или все опубликованные принтеры. Если есть основания подозревать наличие неполадок в DNS, то необходимо выяснить, служба удаления какого DC ответственна за удаление принтеров. Вместо того чтобы открывать Event Viewer для каждого DC по очереди, можно воспользоваться утилитой EventCombMT из комплекта ресурсов Microsoft Windows Server 2003 Resource Kit для поиска на контроллерах домена событий с ID 47 и 50. Из графического интерфейса EventCombMT можно отыскать конкретные события в журналах событий заданного круга машин. Утилита записывает итоговую выходную информацию в удобный для просмотра текстовый файл. Отыскав DC, на котором произошла ошибка, можно определить причину неисправности.

При определенных обстоятельствах возникает противоположная проблема: служба удаления не изымает принтеры из AD. Чтобы избежать подобной ситуации, не следует удалять разрешения Print, по умолчанию назначаемые группе Everyone в списке параметров безопасности принтеров на принт-сервере. Если возникает насущная необходимость ограничить доступ к принтеру, то можно удалить разрешения, назначенные группе Everyone, и назначить разрешения Print только группе Domain Controllers. Следует помнить, что службе удаления принтеров, работающей на DC, требуется доступ к очередям печати на принт-серверах. Без минимальных полномочий Print служба удаления не может выполнить своей задачи.

Как правило, принт-сервер повторно публикует информацию о принтерах только в том случае, если на принт-сервере перезапускается служба спулинга. Таким образом, удаленные принтеры не удастся вернуть в AD без вмешательства в какой-либо иной форме. Если принтер удален из списка опубликованных принтеров, то можно очистить этот список, а затем установить флажок List in the Directory на вкладке Sharing в диалоговом окне Properties принтера. Альтернативный подход — изменить параметр Group Policy, чтобы заставить принт-серверы регулярно повторять публикацию информации об очередях печати.

Управление публикацией и удалением принтеров с помощью Group Policy

Политики, связанные с публикацией и удалением принтеров, хорошо документированы в других источниках. В частности, полезные сведения можно найти в материале Microsoft «Integration of Windows 2000 Printing with Active Directory» (http://www.microsoft.com/windows2000/ docs/printad.doc) и в статье «Using Group Policies to Control Printers in Active Directory» (http://support.microsoft.com/?kbid=234270).

Стандартные параметры Group Policy вполне приемлемы для большинства сред AD, но если предприятие постоянно сталкивается с проблемами при публикации и удалении принтеров, иногда полезно изменить несколько конкретных политик. Параметры, связанные с печатью и удалением, приведены в разделе Computer Configuration, Administrative Templates, Printers консоли Group Policy (экран 6). При частом неоправданном удалении принтеров (например, из-за сетевых неполадок) я рекомендую сначала попытаться увеличить значение Directory pruning interval. Если это ничего не дает, следует увеличить число попыток Directory pruning retry. Можно также активизировать режим Check published state и установить подходящее значение — 12 часов должно быть достаточно. Последний параметр особенно полезен, так как он заставляет принт-серверы повторно публиковать удаленные принтеры без перезапуска спулера на принт-сервере. Это значение не должно быть слишком малым — частые перезапуски снижают производительность сервера.

Я не рекомендую отключать службу удаления принтеров полностью, так как со временем информация о принтерах в AD может стать неактуальной. Но если это сделать необходимо, следует изменить параметр Allow pruning of published printers, присвоив ему значение Disabled.

Непросто бывает принять решение относительно параметров Group Policy для удаления принтеров, опубликованных вручную. Если разрешить удаление этих принтеров, то время от времени их придется повторно публиковать вручную. Однако если отключить режим удаления этих принтеров, то в конечном итоге в AD почти наверняка появятся «осиротевшие» устройства. Кроме того, исключается возможность использования параметра Check published state, так как данная политика применима только к принт-серверам, способным автоматически публиковать принтеры. Компромиссным решением будет размещение опубликованных вручную принтеров в отдельной, специализированной организационной единице (OU), связанной с политикой, имеющей повышенные относительно типовых значения параметров Directory pruning interval и Directory pruning retry. Кроме того, полезно присвоить параметру политики Allow printers to be published значение No для организационных единиц, содержащих рабочие станции. В результате такой меры флажок List in the Directory становится недоступным.