Using pxe boot technologies to install windows over a network

Я пам'ятаю, як вперше встановлював Windows 3.0 - з набору тридюймових дискет. Згодом установка стала простіше завдяки поширенню завантажувальних компакт-дисків (на яких випускалися деякі версії Windows 98). Але одна річ завжди залишалася незмінною: для установки був потрібний якийсь локальний носій, так само, як і локальний жорсткий диск.

Підготовка клієнтських комп'ютерів

Як працює PXE

На рис. 1 зображена послідовність завантаження за допомогою PXE. PXE - це досить простий протокол, розроблений Intel і іншими постачальниками обладнання як частина ініціативи Wired for Management ( «мережа для управління»). Протокол стався від протоколу DHCP, який в свою чергу був розроблений на основі протоколу BootP і зазвичай реалізується в мережевих платах. Простіше кажучи, відбувається наступне:

Рис 1: Послідовність завантаження за допомогою PXE (клацніть зображення, щоб збільшити його)

Перший етап Завантажується BIOS системи, яка визначає послідовність завантаження.

Другий етап Якщо в послідовності завантаження PXE знаходиться попереду жорстких дисків, флеш-накопичувачів і компакт-дисків або жодне з цих пристроїв не встановлено, то з мережевої плати завантажується універсальний інтерфейс мережевих драйверів (UNDI). У мережеву плату вбудовані дуже маленький драйвер мережевого пристрою і реалізація протоколу TFTP. (В деяких версіях BIOS користувач повинен натиснути клавішу F12, щоб використовувати протокол PXE. Це нестандартну поведінку, і я дуже радий, що його можна вимкнути).

Третій етап Система починає трансляцію по протоколу UDP, намагаючись знайти сервер DHCP. Фактично це і є перший етап послідовності завантаження за допомогою протоколу PXE, який називається «виявлення» (Discover). Зауважте, що використовується протокол UDP - а значить, якщо ви ще цього не зробили, то варто витратити деякий час на настройку маршрутизаторів і комутаторів, щоб дозволити обмін даними по протоколу PXE.

Зверніть увагу, що якщо у вас встановлені сервер DHCP і служба WDS корпорації Microsoft (або схожий набір засобів від іншого постачальника), то етап запиту відсутня, а пакет даних, що відправляється сервером DHCP на етапі пропозиції вже містить відомості про розташування сервера PXE і програми NBP (таким чином, виключаються два етапи і економиться трохи часу).

Сьомий етап Як було зазначено вище, у клієнта є невеликий пакет протоколів TFTP, за допомогою якого і завантажується програма NBP з мережевого ресурсу, зазначеного сервером PXE. TFTP - це застарілий, дуже невеликий протокол без відомостей про стан. Він був обраний не за свою безпеку або продуктивність, і в результаті багато адміністраторів маршрутизаторів забороняють його за замовчуванням. Проте, для роботи PXE він повинен бути включений.

Восьмий етап NBP инициализирован. У разі використання служби RIS ця програма запускає завантажувач Windows, який починає процес розгортання. Протокол PXE (принаймні власне протокол рівня завантаження) в процесі більше не братиме участі.

Важливо пам'ятати, що PXE (в складі служби RIS, WDS або іншої інфраструктури) погано працює на повільних мережевих каналах (він може передавати значні обсяги даних) або на каналах з великими затримками, наприклад супутникових (в таких випадках обмін даними йде дуже погано і може взагалі обірватися).

Ви могли звернути увагу в процесі завантаження PXE на те, що коли клієнт відправляє запит, немає нічого, що могло б запитати: «Ви дійсно моя мама?». Кількість інформації про стан, доступне сервера PXE, слушком мало, щоб так чи інакше про це знати. Зазвичай виникає конфлікт, який виграє сервер, першим відповідає на запит клієнта. Пара прийомів може допомогти зменшити цю проблему.

Правда, цей захист працює тільки проти тих серверів, про які відомо службі Active Directory. Якщо ви встановили свій домен або сервер PXE не від компанії Microsoft, такий захист не працюватиме.

Нехай ця історія допоможе не забувати про необхідність ізоляції серверів PXE, якщо передбачається застосування повністю автоматизованого розгортання, або як мінімум про вимогу натискання клавіші F12.

Служба RIS в подробицях

Екрани майстра вибору ОС - це до певної міри настроюються сторінки, схожі на HTML 2.0. Їх вміст сильно обмежена: на них не може бути зображень і навіть символів не з кодування ANSI (що ускладнює розгортання деяких мовних стандартів Windows).

Кінцевий результат роботи служби RIS - це файл txtsetup.sif, розташований на сервері служби RIS. Коли майстер вибору ОС завершує роботу, відбувається «тепла» перезавантаження клієнта, проте розташування сервера RIS і файлу txtsetup.sif запам'ятовується і відновлюється після перезавантаження. По суті, файл txtsetup.sif такий же, як і unattend.txt, за винятком кількох додаткових полів, які допомагають службі RIS виконати процес установки.

Служба RIS може надати схожу на традиційну автоматичну установку (RISetup), а також містить інфраструктуру клонування, схожу на Sysprep (RIPrep), з якої вона навіть має загальний програмний код. Але і RIPrep може передати свій образ на сервер RIS.

Додаткові відомості про технології, пов'язаних з PXE

В результаті установку за допомогою служби RIS не можна нормально виконати, наприклад, маючи тільки французьку клавіатуру. Надійна робота з символами, що не входять в кодування ANSI, на рівні BIOS на комп'ютерах з різних країн - вкрай складне завдання, яку не так-то просто було вирішити.

Служба розгортання Windows (WDS) - початок

У Windows XP Embedded вбудована повне завантаження по протоколу PXE через свій власний демон TFTPD на диск в ОЗП, проте відсутня можливість віддаленого розгортання таким способом. Ця технологія розроблена для того, щоб підтримувати завантаження великої кількості систем з одного образу диска за допомогою PXE.

Схожі статті