Windows Server 2008

Pliki pulpitu Udostępnij na: Facebook

Uruchamianie sieciowe Windows

Autor: Wes Miller

Opublikowano: 9 stycznia 2009

Zawartość strony
 Jak działa PXE   Jak działa PXE
 Zagłębiamy się w RIS   Zagłębiamy się w RIS
 WDS – początki   WDS – początki
 Inni gracze   Inni gracze
 Predefiniowani klienci   Predefiniowani klienci
 Więcej o technologiach zawiązanych z PXE   Więcej o technologiach zawiązanych z PXE
 Podsumowanie   Podsumowanie

Przez kilka następnych miesięcy planuję zajmować się usługą Windows Deployment Services (WDS), która jest dostępna dla Windows Server 2003 i jest wbudowana w Windows Server 2008. WDS może być bardzo ważnym komponentem w strukturze naszego wdrożenia, więc trzeba się upewnić, że mamy dobre podstawy do dyskusji. Ten pierwszy artykuł wprowadzi nas w architekturę Pre-boot eXecution Environment (PXE), historię Remote Installation Services (RIS), a także inne, związane z PXE technologie stosowane przez Microsoft.

Kiedy w 2001 r. przeszedłem do głównej grupy systemów operacyjnych, RIS był jedną z technologii, którą oddziedziczyłem (byłem trochę przerażony tym posiadaniem, z powodu jej złożoności i zależności od implementacji BIOS-u i sprzętu). Była to jednak, obok Windows® PE, jedna z technologii, które najbardziej lubiłem w mojej roli menedżera programu.

Pamiętam jak po raz pierwszy instalowałem Windows 3.0 – korzystając z 3,5-calowych dyskietek. Przez lata instalacja stała się łatwiejsza dzięki rozruchowym płytom CD (dostępnym wraz z niektórymi wersjami Windows 98). Rzecz w tym, że instalacja zawsze wymagała jakiegoś typu lokalnego nośnika, a także lokalnego dysku twardego.

Przez lata możliwość instalacji sieciowej Windows – czyli całkowitego uruchomienia systemu za pośrednictwem sieci, bez konieczności posiadania twardego dysku – była częstym życzeniem klientów. Chociaż niektóre wcześniejsze wersje Windows miały tę możliwość, Windows NT nigdy jej nie miał. A chociaż aktualne wersje Windows Server 2003 i Windows Server 2008 mogą być uruchamiane za pośrednictwem inicjatora iSCSI, ten proces jest całkiem inny pod tym względem, że nie jest tak naprawdę lokalny – pociąga za sobą ciągłe zależności na zdalnym dysku jako dysku rozruchowym.

Począwszy od Windows 2000, Microsoft zaczął rozwijać technologię, która ostatecznie została nazwana RIS i która umożliwia instalację sieciową. Cel RIS był stosunkowo prosty – za pomocą PXE umieścić obraz systemu na dysku lokalnym docelowego komputera.

Jak działa PXE

N rysunku 1 pokazana jest sekwencja uruchamiania PXE. PXE jest stosunkowo prostym protokołem, który został opracowany przez firmę Intel i innych producentów, jako część inicjatywy Wired for Management. PXE wywodzi się z DHCP (Dynamic Host Configuration Protocol), pochodzącego z BootP, i jest zwykle implementowany w karcie sieciowej NIC (Network Interface Card). Przedstawiając to w prosty sposób, oto co się dzieje:

Rysunek : 1 Sekwencja rozruchowa PXE.

  1. Klient PXE rozgłasza DHCPDISCOVER do portu 67 UDP.
  2. DHCP lub Proxy DHCP wysyła DCHPOFFER z adresem IP do klienta 68.
  3. Klient wysyła DCHPREQUEST do serwera DHCP dla nazwy pliku rozruchowego.
  4. Serwer rozruchowy wysyła z powrotem DHCPACK, który zawiera nazwę pliku programu sieciowego ładowania początkowego (Network Bootstrap Program, NBP).
  5. Klient żąda NBP z serwera rozruchowego.
  6. NBP jest ładowane z usługi TFTP, a następnie wykonywane na kliencie.

PXE Client – Klient PXE

PSX Boot Server – Serwer rozruchowy PXE

Krok 1 System BIOS uruchamia się i określa kolejność ładowania.

Krok 2 Jeśli kolejność ładowania ustawia PXE przed dyskami twardymi lub dyskami typu flash albo płytami CD-ROM, lub jeśli nie ma żadnego z tych urządzeń, UNDI (Universal Network Driver Interface) jest ładowany z karty NIC. NIC jest wyposażona w niezwykle mały sterownik dysku napędu sieciowego oraz implementację protokołu TFTP (Trivial File Transfer Protocol). (Niektóre implementacje BIOS-u wymagają, aby użytkownicy naciskali klawisz F12 w celu uruchomienia PXE. Nie jest to standard i doceniam możliwość wyłączenia tego.)

Krok 3 System zaczyna wykonywać proste rozgłaszanie UDP (User Datagram Protocol), szukając serwera DHCP. Jest to faktycznie pierwszy krok sekwencji uruchamiania PXE i jest nazywany Wykryciem (Discover). Zwróćmy uwagę, że protokołem jest UDP – co oznacza, że jeśli jeszcze tego nie zrobiliśmy, będziemy musieli poświęcić sporo czasu routerom i przełącznikom, aby cała komunikacja PXE mogła przez nie przejść.

Krok 4 Jeśli serwer DHCP odbiera transmisję, odpowiada odpowiednio adresem IP. Ten krok nosi nazwę Oferty (Offer). Ważna rzeczą jest tutaj pamiętanie, że PXE jest bezstanowy i ilość unikatowej dla systemu informacji o stanie, jaką ma do zaoferowania klient, jest w tym momencie jest dość ograniczona (adres MAC i – jeśli jest dostępny – System Management BIOS GUID, znany także jako SMBIOS GUID).

Krok 5 Po otrzymaniu pakietu z adresem IP klient stwierdza, że w rzeczywistości potrzebuje dalszych informacji – mianowicie adresu serwera PXE. Następuje kolejna transmisja, która zawiera informację z serwera DHCP, który wcześniej odpowiedział. Tutaj klient mówi serwerowi DHCP, “Potrzebuję więcej informacji – w szczególności potrzebuję lokalizacji NBP (Network Boot Program)." Ten krok nosi nazwę Żądania (Request).

Krok 6 Serwer PXE odpowiada adresem serwera PXE i lokalizacją NBP, niezwykle małym plikiem wykonywalnym do ładowania, który ma być mniejszy niż 32 KB. Ten krok nazywamy Potwiedzeniem (Acknowledge). Tę sekwencję kroków można zapamiętać poprzez akronim DORA (Discover, Offer, Request, Acknowledge).

Zwróćmy uwagę, że jeśli zainstalowaliśmy Microsoft DHCP i WDS (lub stosujemy jakieś technologie innych producentów), etap żądania się nie pojawi, a początkowy pakiet Oferta z serwera DHCP, zawiera już lokalizację serwera PXE i program NBP (z ten sposób eliminujemy dwa kroki i oszczędzamy trochę czasu).

Krok 7 Klient, który ma, wspomniany wcześniej, mały stos protokołów TFTP, pobiera NBP z lokalizacji sieciowej określonej przez serwer PXE. TFTP jest przestarzałym, nadzwyczaj małym, protokołem bezstanowym. Nie został wybrany ze względu na bezpieczeństwo lub wydajność – i w rezultacie wielu administratorów routerów domyślnie go wyłącza. Musi być włączony, aby PXE mógł działać.
Wiele implementacji PXE (łącznie z RIS) zawiera możliwość poproszenia użytkownika, aby w tym miejscu w celu kontynuacji nacisnął klawisz F12, ale zwykle funkcja ta może być wyłączona przez administratora serwera PXE. W następnym miesiącu, gdy dalej będę analizował WDS, popatrzę na niektóre z ulepszeń umieszczone przez Microsoft w TFTPD (TFTP Daemon) w WDS, aby poprawić wydajność Windows Server 2008.

Krok 8 NBP został zainicjowany. W przypadku RIS, uruchamia to program rozruchowy Windows, który rozpoczyna proces wdrażania. PXE (przynajmniej w obecnej wersji protokołu poziomu rozruchowego) nie jest już składnikiem tego procesu.
Trzeba pamiętać, że PXE (w RIS, WDS lub dowolnej innej architekturze) nie pracuje dobrze na powolnych łączach (może przesyłać znaczną ilość danych) lub łączach o dużych opóźnieniu, takich jak satelitarne (komunikacja po prostu nie działa dobrze i może nawet się nie utrzymać).
Można zauważyć, że w procesie uruchamiania PXE, w którym klient wysyła żądanie, nie ma nic, co wyraźnie pyta, "Czy jesteś moją mamą?" Po prostu nie ma dość informacji o stanie serwera PXE , aby dowiedzieć się tego w taki, czy inny sposób. Zwykle mają miejsce warunki wyścigu – gdzie wygrywa pierwszy serwer, który odpowie na żądanie klienta. Kilka rzeczy może pomóc w zmniejszeniu tego problemu:

  • Dostosowanie szybkości odpowiedzi lub drugiego serwera PXE. Opóźnienia sieciowe i moc serwera będą miały wpływ na szybkość odpowiedzi serwera. W rzeczywistości, w firmie Microsoft przywykłem do tego, że serwery stosowane przez Microsoft IT były tak dobre, że nawet gdy serwer PXE był w biurze, serwery korporacyjne czasami wygrywały wyścig. W tym przypadku tak ustawiamy swój lokalny serwer PXE Server, aby nie miał w ogóle limitu czasu – dla naszych predefiniowanych klientów.
  • Predefiniowanie klientów. Jest to bardzo ważne, jeśli tak operujemy naszym serwerem PXE, aby odpowiadał przed innymi serwerami IT korporacji. Predefiniując naszych klientów, pozwalamy, aby Active Directory powiedział WDS lub RIS, że tak, rzeczywiście, "Jestem twoją mamą". Zwróćmy uwagę, że użycie SMBIOS GUID jest dużo bardziej preferowane jako unikatowy identyfikator dla naszych systemów w Active Directory – lecz jeśli SMBIOS GUID nie jest implementowany w systemach (bardziej prawdopodobne w starszym sprzęcie), można (i trzeba będzie) użyć GUID opartego na adresach MAC. Więcej informacji można znaleźć w ramce "Predefiniowani klienci".

Niezezwalanie na przejście komunikacji PXE przez przełączniki lub routery; trzeba umieścić serwer PXE po każdej stronie. Ma to taką wadę, że jest zarówno drogie w implementacji, jak i w utrzymaniu (każdy serwer musi mieć utrzymywany swój własny obraz).

Serwery RIS (a teraz WDS), tak jak serwery Microsoft DHCP, muszą być uwierzytelniane w stosunku do implementacji Active Directory, z którą są związane. Celem jest zmniejszenie problemów, które mogą spowodować oszukańcze serwery PXE (takie jak burze transmisyjne PXE), przez poinformowanie Active Directory o takich serwerach.

Zauważmy, że to chroni tylko przez serwerami, o których wie Active Directory. Jeśli zainstalujemy swoją własną domenę lub serwer PXE inny niż Microsoft PXE, to nie będzie działać.

Nadgorliwy pracownik firmy Microsoft skonfigurował kiedyś "bezobsługowe" wdrożenie serwera PXE, innego niż RIS. Ta implementacja działała poprzez całkowite czyszczenie dysku twardego i umieszczanie na nim nowego obrazu. Byłoby świetnie, gdyby takie wdrożenie zdarzyło się w izolowanym laboratorium (poza siecią), lecz niestety się nie zdarzyło – i wyczyściło dysk dyrektora firmy Microsoft, który miał PXE w swojej kolejności uruchamiania przed dyskiem twardym.

Nie byłoby problemu, ponieważ Microsoft IT zawsze wymagał naciśnięcia F12 do rozruchu PXE, lecz ten serwer PXE nie miał opóźnienia, prośby o naciśnięcie F12, ani żadnego innego powiadomienia. To oznacza, że dyrektor skutecznie utracił swój komputer i wszelkie dane niechronione przez Mobilny profil użytkownika (Roaming User Profile).

Niech ta historia posłuży do zwrócenia uwagi na konieczność izolowania swoich serwerów PXE, jeśli planujemy działanie "bezobsługowe", a przynajmniej wymagajmy naciśnięcia F12.

 Do początku strony Do początku strony

Zagłębiamy się w RIS

Odziedziczyłem RIS po dostarczeniu Windows 2000. Czasy nie były dobre dla Windows 2000, jeżeli chodzi o RIS – testowanie, wydajność i inne ograniczenia prowadziły to tego, że RIS dla Windows Server 2000 był stosowany tylko do wdrożenia Windows 2000 Professional. Niestety produkty serwera nie mogły być wdrażane za pośrednictwem RIS. Windows 2000 był dostępny tylko dla maszyn x86, więc sprawdził sie jako doby system doświadczalny dla RIS, ponieważ zawierał jeden produkt w jednej architekturze. RIS obejmował (i wymagał) całkowitej integracji z Active Directory, dobrze się integrował z serwerem Microsoft DHCP oraz zawierał swój własny TFTPD.

RIS używał NBP do dalszego pobierania TFTP – na tyle dezaktywując jądro Windows, aby rozpocząć proces instalacji. (W pewnym momencie, gdy Windows przełączył się z TFTPD na połączenie z serwerem oparte na SMB (Server Message Block), dosłowny kod ścieżki jest faktycznie identyczny z tradycyjną, inicjowaną z dyskietki, instalacją Windows 2000 lub Windows XP.) Po zainicjowaniu Windows we wbudowanym trybie, instalacja Windows uruchamia kreator RIS OS Chooser (OSC).

Ekrany OSC są częściowo konfigurowalnymi stronami w stylu HTML 2.0. Są poważnie ograniczone i nie mogą zawierać obrazów ani podobnych elementów, a faktycznie nie mogą zawierać znaków innych niż ANSI (co komplikuje wdrażanie niektórych lokalnych wersji Windows).

Produkt końcowy RIS jest plikiem txtsetup.sif, umieszczonym na serwerze RIS. Po zakończeniu działania kreatora OSChooser Wizard, klient ma „miękki rozruch”, lecz lokalizacja serwera RIS oraz plik txtset¬up.sif są zachowane i ponownie ładowane po miękkim rozruchu. Ten plik txtsetup.sif jest w gruncie rzeczy taki jak plik unattend.txt, z kilkoma dodatkowymi polami włączonymi, aby pomóc RIS w wykonaniu procesu instalacji.

RIS może także wykonywać instalację, która wygląda bardziej na tradycyjną, nienadzorowaną instalację (RISetup) oraz ma infrastrukturę opartą na klonowaniu, podobną do Sysprep (RIPrep), i z którą ma faktycznie wspólny kod. RIPrep może także przekazywać swój własny obraz do serwera RIS.

RIS ma kilka podstawowych ograniczeń, które stały się jednak widoczne. Pierwszy to brak obsługi wdrażania serwera. Pewne exploity, takie jak Code Red oraz Sasser, w połączeniu ze złożonością IT, której doświadczyło kilku kluczowych klientów przy przywracaniu systemów bezpośrednio po tragedii 11 września 2001 r., spowodowało przyspieszenie prac przy rozwiązaniu dla istniejących serwerów RIS Windows 2000, umożliwiającego wdrożenie Windows Server. To było coś, nad czym pracowaliśmy dla Windows Server 2003, lecz nie było formalnie wypuszczone na rynek.

Po drugie, RIS nie miał możliwości pełnej automatyzacji kreatora OSChooser Wizard, co zostało później udostępnione za pomocą elementu w Windows Server 2003. I wreszcie, OSChooser nie mógł prawidłowo działać ze znakami innymi niż ANSI – najważniejsza wada, wskazywana przez wielu klientów poza Stanami Zjednoczonymi.

W rezultacie nie można było na przykład wykonać instalacji RIS, na przykład korzystając z francuskiej klawiatury. Spowodowanie, aby znaki inne niż ANSI działały bezpiecznie na poziomie BIOS w komputerach na całym świecie było niezwykle skomplikowane i nie było łatwo to osiągnąć.

Wraz z wydaniem Windows Server 2003, oficjalnie dodaliśmy obsługę architektury Intel Itanium i wszystkich wariantów serwerów Windows 2000 oaz Windows Server 2003. W Windows Server 2003 został zrobiony jeden krok do przodu z obsługą architektury x64.

RIS miał znacznie zmieniony TFTPD w celu zwiększenia wydajności. Windows Server 2003 obsługiwał jednoczesne uruchamianie do 75 klientów; pamiętajmy, że górna granica zostaje tu osiągnięta, gdy potok SMB wypełnia się ruchem sieciowym do klientów.

 Do początku strony Do początku strony

WDS – początki

Kiedy zaczęliśmy pracę nad RIS dla system "Longhorn" (robocza nazwa systemu Windows Server 2008), stało się jasne, że musimy zrobić krok do tyłu. Wspomniałem wcześniej w swoim artykule, że już dużo zaryzykowaliśmy przy opartej na obrazie (WIM) instalacji z Windows PE. W rezultacie kluczową zasadą, leżącą u podstaw WDS było oparte na obrazie wdrożenie z egzemplarza Windows PE, uruchamianego z PXE.

Wiedzieliśmy także, że Windows Server 2003 będzie popularną platformą wdrażania Windows Vista i będzie wymagał rozwiązania "pozapasmowego" na niskim poziomie WDS. W rezultacie WDS mógł działać pod Windows Server 2003 SP1 i był wbudowany w Windows Server 2003 SP2.

Ponieważ mógł funkcjonować jako serwer RIS (tryb Legacy), serwer hybrydowy (tryb Mixed) lub jako serwer tylko WDS (tryb Native), WDS pozwala nam przejść do formalnych wdrożeń w stylu WDS. Klienci pytali, czy jest jakaś metoda instalowania RIS w systemie Windows Server 2003 SP2. Tak, jest – instalujemy WDS i uruchamiamy tryb Legacy. Na rysunku 2 pokazano obsługiwane systemy operacyjne

Rysunek 2. Platformy obsługiwane do wdrożenia

System operacyjny RIS (Windows 2000) RIS (Windows Server 2003)** WDS (Windows Server 2003)**** WDS (Windows Server 2008)
Windows 2000 Pro X X X X
Windows 2000 Server * X X X
Windows XP Pro   X (x86 i IA64)*** X X
Windows Server 2003   X (x86 i IA64)*** X X
Windows Vista     X X
Windows Server 2008     X X

* support.microsoft.com/kb/308508 oraz support.microsoft.com/kb/313069 dodały obsługę dla Windows 2000 Server poprzez RIS.
** Tryby WDS Legacy i Mixed obsługują taką samą macierz dla starszych instalacji.
*** W Windows Server 2003 SP1 dodano obsługę dla systemów 64-bitowych. Systemy IA64 są obsługiwane tylko przez instalację opartą na RISetup.
**** Obsługa trybu Native.

WDS w Windows Server 2003 SP1 oraz SP2 rozpoczynał proces migracji do WDS. Jak wcześniej wspomniałem, kluczowymi funkcjami WDS, dodanymi w Windows Server 2008 były poprawiony TFTPD, obsługa rozruchu EFI (Extensible Firmware Interface) oraz oczywiście wdrożenie oparte na transmisji grupowej.

 Do początku strony Do początku strony

Inni gracze

Usługi ADS (Automated Deployment Services) zostały utworzone prze inny zespół w firmie Microsoft, mając przede wszystkim na celu szybkie dostarczenie serwera. ADS jest wyposażony w formalne obrazowanie oparte na sektorach, własnego agenta rozruchu (mniejszego niż Windows PE, lecz z mniejszą liczbą funkcji), swój własny TFTPD i bardzo zaawansowaną transmisję grupową. Funkcjonalność wbudowana w ADS stała się dostępna to pewnego stopnia w SCCM (Center Configuration Manager), chociaż nie jest w 100 procentach taka sama.

Windows XP Embedded zapewnia pełny rozruch PXE w RAMDisk za pośrednictwem swojego własnego TFTPD, lecz nie można w ten sposób dokonywać zdalnego wdrożenia. Ta technologia została zaprojektowana do obsługi jednoczesnego uruchamiania wielu systemów z tego samego obrazu dysku za pośrednictwem PXE.

 Do początku strony Do początku strony

Predefiniowani klienci

 Do początku strony Do początku strony

Więcej o technologiach zawiązanych z PXE

 Do początku strony Do początku strony

Podsumowanie

Taka w skrócie jest historia. Aby dowiedzieć się więcej, można przeczytać ramkę „Więcej o technologiach związanych z PXE”. W następnym miesiącu zabiorę się za podstawy WDS, aby kontynuować artykuł na temat zaawansowanych funkcji WDS (multicast i inne) oraz, w końcu, za stosowanie WDS bez WDS, czyli wyjście poza obecne doświadczenia z WDS/instalacją, aby rozwinąć swoje własne techniki wdrażania.

 Do początku strony Do początku strony

Windows Server 2008