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

Механізм оголошень спрощує пошук принтерів
публікація принтерів
Пошук принтерів
Пошук несправностей в Printer Publishing
видалення принтерів
Управління публікацією і видаленням принтерів за допомогою Group Policy
Рекомендації по роботі з механізмом Публікації принтерів

Механізм оголошень спрощує пошук принтерів

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

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

За замовчуванням Windows 2000 Server і більш пізні версії автоматично публікують інформацію про принтерах в AD. Щоб перевірити, чи були дані про принтерах опубліковані в AD, потрібно відкрити діалогове вікно Properties принтера, перейти до вкладки Sharing і встановити або скинути прапорець List in the Directory (екран 1).

Слід пам'ятати, що інформація про принтерах, опублікована в 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» ( com/?kbid=234619> 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

позначає конкретну кімнату в швейцарському офісі.

При використанні поля 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).

Будь-який комп'ютер або користувач, який записує інформацію в 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» ( com/?kbid=234270> 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 стає недоступним.