Tajniki usługi WDS (ang. Windows Deployment Services), cz. II

Uaktualnienie usługi RIS

Autor: Jacek Światowiak

Opublikowano: 17 lipca 2007

Zawartość strony

	Wstęp
	Windows PE
	Zestawienie wersji WINDOWS PE
	Tworzenie obrazu Systemu WINDOWS PE
	Tworzenie obrazu CD
	Proces startu Windows PE
	Jak dodać przygotowany tak obraz systemu Windows PE, aby był dostępny via serwer usługi RIS/WDS
	Komponenty usługi WDS
	Komponent BINL
	Wykorzystanie przez komponent BINL kontrolerów domeny i serwerów wykazu globalnego (ang. global katalog)
	Obszar BCD Generation
	Magazyn obrazów
	Komponenty serwera TFTP
	Komponent SIS i usługa Groveler
	Foldery/udziały zdalne
	Podsumowanie
	Przeczytaj pozostałe części tego artykułu

Wstęp

Usługa Windows Deployment Services posługuje się nowym formatem obrazów z rozszerzeniem .wim. Obrazy te bazują m.in. na zmodyfikowanym środowisku Windows PE 2.0 (Preinstallation Environment). Czym jest dokładnie Windows PE? Jakie są dostępne wersje w/w środowiska? Zagadnienia te oraz inne omówimy poniżej. Środowisko Windows PE jest dostępne w postaci obrazów płyt CD/DVD uruchamianych z napędów optycznych. Dodatkowo, może być uruchamiane z pamięci zewnętrznych typu flash oraz z usługi RIS i WDS. Występuje kilka wersji środowiska Windows PE bazujących na różnych wersjach dostępnych systemów operacyjnych Windows (XP, 2k3, Vista, Longhorn/2008).

Do początku strony

Windows PE

Microsoft Windows PE jest w pełni 32-bitowym środowiskiem pracy pracującym w trybie chronionym procesora z minimalną liczbą niezbędnych usług systemowych, bazujących na jądrze Windows XP Professional, Windows Server 2003 lub Windows Vista. Środowisko to wykorzystywane jest w procesie instalacji systemów operacyjnych, w szczególności w trybie nienadzorowanym lub do przeprowadzania czynności serwisowych, gdy domyślny system operacyjny serwera lub stacji roboczej uległ jakiemuś uszkodzeniu. Ze względu na fakt wykorzystania jądra systemów Windows, nie istnieje już konieczność korzystania ze specjalnie przygotowanych sterowników do sprzętu pracujących w trybie 16-bitowym - wykorzystuje się tu domyślne sterowniki systemu Windows.

Dostępne są wersje dla platformy x86, x64 oraz Itanium. W niniejszym artykule skupię się wyłącznie na wersji 32-bitowej.

Właściwości:

• sprzętowo niezależne (ang. hal independent) środowisko 32- lub 64-bitowe,
• zawierające podzbiór najważniejszych aplikacji API, w tym linię poleceń: (cmd.exe), wsparcie dla skryptów hosta systemu Windows (Windows Script Host), aplikacji HTML, obiektów ActiveX, oraz innych aplikacji i narzędzi firm trzecich,
• wsparcie dla protokołu TCP/IP oraz wielu usług sieciowych, w tym możliwość dodawania dodatkowych sterowników kart sieciowych, protokołów i klientów,
• wsparcie dla sterowników pamięci masowych, kontrolerów RAID i HBA, w tym i OEM,
• natywne wsparcie dla systemu plików FAT/FAT32/NTFS, możliwość tworzenia, usuwania i zarządzania partycjami,
• wsparcie dla protokołu PXE, umożliwiające uruchamianie systemu Windows PE z wykorzystaniem usługi RIS lub WDS,
• wsparcie dla urządzeń Plug and Play,
• wsparcie dla Windows Management Instrumentation (WMI),
• obsługę Firewall’a systemu Windows,

Do początku strony

Zestawienie wersji WINDOWS PE

Wersja Windows PE	Windows XP	Windows XP SP1	Windows XP SP2	Windows 2003:	Windows 2003 SP1	Windows Vista	Windows Server 2008
1.0	•
1.1	•	•
1.2	•	•		•
2004			•
2005			•		•
2.0						•	•

 

Windows PE dostępne jest również wraz z Windows OPE (ang. Oem Preinstallation KIT) dla dostawców sprzętu typu OEM. Windows PE 2004 i 2005 dostępne są dla przedsiębiorstw posiadających podpisane umowy klasy SELECT lub ENTERPRISE wraz z opcją SA. Windows PE 2.0 dostępne jest wraz z produktem Windows Automated Installation Kit (Windows AIK) for Windows Vista i Windows Server 2008.

W niniejszej części artykułu będę się posługiwał wersją Windows PE 2005 (dla Windows XP Prof.). Następne części oparte będą o Windows PE 2.0 (dla Windows Vista).

Do początku strony

Tworzenie obrazu Systemu WINDOWS PE

Dla wersji Windows PE 2005 (dla wersji Windows PE 2.0 – Vista – omówione zostanie w kolejnych rozdziałach) tworzymy folder na dysku twardym, zawierający narzędzia Windows PE.

md c:\build_x86

Przegrywamy zawartość płyty CD lub folderu zawierającego narzędzia Windows PE wraz z podfolderami do utworzonego wcześniej folderu na dysku twardym.

xcopy e:\winpe c:\build_x86 /s

Umieszczamy w napędzie optycznym nośnik zawierający właściwą wersję systemu, dla której chcemy utworzyć obraz Windows PE 2005 (czyli Windows 2k3 SP1 lub Windows XP SP2). Przechodzimy do naszego folderu:

cd c:\build_x86

I uruchamiamy polecenie MKIMG.CMD wraz z dwoma argumentami:

mkimg.cmd  folder_źródłowy    folder_zawierający_obraz _docelowy_Windows PE, np.

mkimg.cmd e:\ c:\winpe

Z tak przygotowanego folderu możemy utworzyć obraz płyty CD/DVD lub obraz uruchamiany z serwera usługi RIS/WDS.

Do początku strony

Tworzenie obrazu CD

Utworzony w poprzednim punkcie obraz można sobie dostosować do własnych potrzeb czy wymagań. Tu pokażemy, jak się przygotowuje obraz płyty CD w formacie .iso. Należy skorzystać z narzędzia oscimg z odpowiednimi parametrami:

oscdimg –blokalizacja_pliku_zawierającego_boot_sector  -nfolder_glowny zawierający_obraz_Windows_PE  

nazwa_obrazu.iso

Przykładowo:

oscdimg –bc:\build_x86\etfsboot.com -nc:\winpe c:\winpex86.iso

Tak przygotowany obraz można wypalić na CD.

Uwaga:

Pomiędzy parametrem -b a ścieżką do pliku zawierającego rekord startowy nie może być żadnej spacji.Identyczna uwaga dotyczy również drugiego parametru, czyli –n!

 

W powyższym przykładzie wykorzystujemy boot sector w formacie El Torino ze wsparciem długich nazw plików. Aby przygotowany obraz nie wyświetlał w czasie startu informacji „Press any key to boot from CD-ROM", należy przed przygotowaniem obrazu narzędziem oscimg usunąć plik Bootfix.bin z obrazu platformy, dla której obraz przygotowujemy, czyli: i386, amd64 lub ia64.

Aby dobrze wykorzystywać platformę WINDOWS PE, należy zrozumieć jej budowę oraz proces startu systemu Windows PE. Będzie to bardzo przydatne podczas dostosowywania platformy Windows PE dla naszych potrzeb.

Poniższy rysunek opisuje cały proces startu systemu Windows PE, wraz z plikami konfiguracyjnymi wykorzystywanymi w poszczególnych fazach startu Windows PE.

Rys. 1. Proces instalacji systemu z wykorzystaniem Windows PE.

Do początku strony

Proces startu Windows PE

Ładowany jest boot sector z danego typu medium. Sterowanie przekazywane jest do pliku setupldr.

Setupldr uruchamia Ntdetect.com, który to odkrywa podstawowe parametry sprzętowe wraz z ich konfiguracją i umieszcza je w rejestrze w gałęzi HKLM\HARDWARE\DESCRIPTION.

Setupldr ładuje odpowiedni sterownik warstwy abstrakcyjnej sprzętu HAL, ładuje część rejestru odpowiadającą za konfigurację systemu - System registry hive, a następnie ładuje wymagane sterowniki sprzętowe wyszczególnione na ścieżce w pliku Winpeoem.sif. Po załadowaniu, środowisko jest przygotowane do załadowania jadra, pliku Ntoskrnl.exe.

Zawartość domyślnego pliku Winpeoem.sif

this section to replace the inbox driver

; list with your own files

;

;[massstoragedrivers.replace]

;mydriver = mydriver.sys

;

; Use this section to append non-pnp drivers to

; the list of the drivers already present

; in the inbox

;[massstoragedrivers.append]

;mydriver = mydriver.sys

;

; Use this section to load pnp/non-pnp oem drivers

; in addition to the inbox driver list

;

; OemDriverRoot : Indicates the path relative to

;                 the system directory of WinPE. If 

;                 none, then specify ""

;

; OemDriverDirs : Specifies series of directories separated

;                 by comma. Each specified directory has the

;                 txtsetup.oem which has the information on

;                 what driver to load.

;

; e.g. OemDriverRoot = "" and OemDriverDirs = drv1, drv2

; indicates to the WinPE that under WinPE's system32 directory 

; there are two directories named drv1 and drv2. Each of these 

; directories contain txtsetup.oem file which lists which

; driver to load

;

;[OemDriverParams]

;OemDriverRoot=""

;OemDriverDirs=

Jeżeli Windows PE zostanie uruchomione z medium pracującym w trybie do odczytu, jak CD, DVD Windows PE umieści poszczególne gałęzie rejestru (hives) w pamięci tak, aby aplikacje, mogły dokonywać tam zmian. Zmiany wprowadzane w tak przygotowanym rejestrze nie są widoczne pomiędzy poszczególnymi sesjami Windows PE.

Ntoskrnl.exe jest wykonywany i kończy się proces konfigurowania środowiska. Sterowanie przekazywane jest do menadżera sesji - Session Manager (SMSS). SMSS ładuje resztę rejestru, konfigurując w ten sposób podsystem Win32 (Win32k.sys) i jego procesy potomne. SMSS ładuje proces Winlogon, który to tworzy sesje użytkowników, startuje usługi oraz resztę dodatkowych sterowników i podsystem bezpieczeństwa (LSASS).

Windows PE uruchamia aplikację Winpeshl.exe, która to uruchamia proces (Cmd.exe) - linię poleceń, a w jej kontekście plik startowy Startnet.cmd.

Kiedy zakończy się działanie poleceń zawartych w pliku Startnet.cmd, wyświetlane jest zgłoszenie systemu. W tym miejscu start systemu Windows PE można uznać za zakończony. Aby wyjść można wpisać exit.

Opcje pliku konfiguracyjnego startnet.cmd. Poniżej zawartość domyślnego pliku startnet.cmd.

factory -winpe

@echo off

echo.

echo.

echo.

echo. 

echo IMPORTANT-READ CAREFULLY: The Microsoft Windows Pre-Installation Environment

echo (the "Software") is protected by copyright laws and international copyright 

echo treaties, as well as other intellectual property laws and treaties.  The 

echo Software is licensed, not sold.  In order to install and use the Software, you

echo must have executed with Microsoft an appropriate license agreement ("License 

echo Agreement") for the Software.  IF YOU HAVE NOT SIGNED A LICENSE AGREEMENT, YOU

echo ARE NOT LICENSED TO INSTALL AND USE THE SOFTWARE. YOU MUST NOT INSTALL, COPY, 

echo OR USE THE SOFTWARE UNTIL A LICENSE AGREEMENT IS EXECUTED.

echo.

echo.

echo You are permitted to remove this paragraph from the startnet.cmd, provided that

echo you acknowledge and agree to the foregoing statements.  

echo.

echo.

echo.

echo.

Plik Startnet.cmd uruchamia polecenie factory z opcją -winpe. Można dodać również inne opcje w celu dostosowania startu systemu Windows PE. Polecenie Factory.exe przetwarza zawartość pliku Winbom.ini, w zależności od parametru WinbomType w sekcji [Factory] Winbom.ini file.

Jeżeli WinbomType zawiera wartość WinPE, przetwarzane są tylko te sekcje pliku Winbom.ini, które są wykorzystywane przez Windows PE, podczas uruchomienia polecenia Factory -winpe.

Jeżeli WinbomType zawiera wartość Factory, przetwarzane są tylko te sekcje pliku Winbom.ini, które są wykorzystywane przez Windows PE do kontroli polecenia sysprep , polecenie Sysprep – Factory.

Jeżeli WinbomType zawiera wartość OOBE, przetwarzane są tylko te sekcje pliku Winbom.ini, które są wykorzystywane przez Windows PE podczas konfiguracji Windows XP w czasie wyświetlania okna powitalnego Windows (Windows Welcome). Po uruchomieniu polecenia Sysprep -reseal okno powitalne Windows (Windows Welcome) ukaże się po kolejnym restarcie Windows.

Podczas startu komputera z wykorzystaniem środowiska Windows PE, uruchamiane jest polecenie factory –winpe, które przetwarza sekcje z pliku Winbom.ini. Poniżej zawartość domyślnego pliku Winbom.ini.

[Factory]

WinBOMType=WinPE

Reseal=No

[WinPE]

Restart=No

[PnPDriverUpdate]

[PnPDrivers]

[NetCards]

[UpdateInis]

[FactoryRunOnce]

[Branding]

[AppPreInstall]

W przypadku uruchomienia komputera przy użyciu środowiska Windows PE wykonywane jest polecenie factory -winpe, które przetwarza następujące sekcje pliku Winnbom.ini w następującej kolejności:

[WinPE.Net] 

[DiskConfig] 

[OEMRunOnce] 

[OEMRun] 

[WinPE], z wyjątkiem wpisu Restart 

[UpdateSystem]

Wpis Restart w sekcji [WinPE]

Często zachodzi konieczność dodania do systemu dodatkowych sterowników pamięci masowych.

W tym celu należy zmodyfikować zawartość pliku Winpeoem.sif. Wstępnie jednak należy skopiować zawartość sterowników do folderu wewnątrz obrazu Windows PE winpe_image\System32, przykładowo: c:\Winpe\System32\Driver1

Modyfikujemy zawartość pliku winpe_image\System32\Winpeoem.sif usuwając średnik z linii [OemDriverParams] i dodając nazwę folderu zawierającego sterowniki w linii OemDriverDirs, przykładowo:

[OemDriverParams]

OemDriverRoot = ""

OemDriverDirs = Driver1

Jeżeli sterownik zawiera dodatkowe pliki .dll należy je również skopiować do wymienionego wyżej folderu. Informacje, które dokładnie pliki należy skopiować, można uzyskać przeglądając zawartość pliku Txtsetup.oem, który dostarcza wraz ze sterownikami producent danego sprzętu.

Z tak dokonanymi zmianami Windows PE wystartuje i doda do systemu sterowniki pamięci masowych wymienione w sekcji [Defaults] pliku Txtsetup.oem, który umieścimy wewnątrz naszego przygotowanego wcześniej folderu (w naszym przykładzie poniżej zaznaczyłem interesujący fragment na czerwono); tu \Driver1. Sterownik ten będzie ładowany jako pierwszy przed wszystkimi innymi sterownikami. Czasami trzeba manualnie dokonać modyfikacji pliku Txtsetup.oem, w szczególności gdy jest on uniwersalny i zawiera listę sterowników dla wielu produktów. Jako przykład podam, jak dodać sterowniki dla kontrolera RAID Promise model SuperTrak EX12350 (Pci Express).

Po rozpakowaniu sterownika z pliku .zip, otrzymujemy następującą strukturę folderów.

Rys. 2. Zawartość sterownika SuperTrak EX12350.

Oraz zawartość najważniejszego folderu (dla platformy i386)

Rys. 3. Folder dla platformy i386.

A oto zawartość pliku Txtsetup.oem

[Disks] 

disk0 = "Promise SuperTrak EX Series Controller Driver Diskette", \stex, \

disk1 = "Promise SuperTrak EX Series Controller Driver Diskette", \stex, \i386

disk2 = "Promise SuperTrak EX Series Controller Driver Diskette", \stex, \amd64



[Defaults] 

SCSI = st8350_i386



[SCSI] 

st8350_i386  = "Promise SuperTrak EX83x0/163x0 Controller-Intel x86 platform", stex

st4350_i386  = "Promise SuperTrak EX43x0 Controller-Intel x86 platform", stex 

st12350_i386 = "Promise SuperTrak EX123x0 Controller-Intel x86 platform", stex

stex_amd64   = "Promise SuperTrak EX Family Controller-x64 platform", stex



[Files.SCSI.st8350_i386] 

inf = disk1, stex.inf

driver  = disk1, stex.sys, stex

catalog = disk1, stex.cat



[Files.SCSI.st4350_i386] 

inf = disk1, stex.inf

driver  = disk1, stex.sys, stex

catalog = disk1, stex.cat



[Files.SCSI.st12350_i386] 

inf = disk1, stex.inf

driver  = disk1, stex.sys, stex

catalog = disk1, stex.cat



[Files.SCSI.stex_amd64] 

inf = disk2, stex.inf

driver  = disk2, stex.sys, stex

catalog = disk2, stex.cat



[HardwareIds.SCSI.st8350_i386] 

id = "PCI\VEN_105A&DEV_8350", "stex"

[HardwareIds.SCSI.st4350_i386] 

id = "PCI\VEN_105A&DEV_4302", "stex" 



[HardwareIds.SCSI.st12350_i386] 

id = "PCI\VEN_105A&DEV_C350", "stex" 



[HardwareIds.SCSI.stex_amd64] 

id = "PCI\VEN_105A&DEV_8350", "stex" 

id = "PCI\VEN_105A&DEV_4302", "stex" 

id = "PCI\VEN_105A&DEV_C350", "stex" 



[Config.stex]

value = "", Tag, REG_DWORD, 1

Uwaga:

Sekcja [Defaults] z pliku Txtsetup.oem zezwala na dwa typy wpisów SCSI i HAL. Jednakże Windows PE rozpoznaje jedynie SCSI. W przypadku konieczności dodania więcej niż jednego sterownika, dopuszcza się dodanie dodatkowych folderów sterowników. Muszą być one umieszczone w linii OemDriverDir rozdzielone znakiem przecinka.Przykład poniżej. OemDriverDirs = Driver1, Driver2, Driver3

 

Do początku strony

Jak dodać przygotowany tak obraz systemu Windows PE, aby był dostępny via serwer usługi RIS/WDS

Na serwerze usługi RIS/WDS uruchamiamy kreatora dodawania nowego obrazu, np. z linii poleceń RISSetup.exe –add.

Tworzymy klasyczny obraz typu CD-based.

Otwieramy folder i386 (dla platformy 32-bitowej) wewnątrz tak utworzonego obrazu.

Przechodzimy do lokalizacji zawierającej pliki środowiska Windows PE i otwieramy tam folder i386. Po czym kopiujemy jego zawartość do folderu i386 obrazu typu CD-BASED – zastępując pliki.

Otwieramy folder Templates w folderze i386, do którego zostało skopiowane środowisko Windows PE i modyfikujemy zawartość pliku RIStndrd.sif; wiersz zaczynający się od OSLoadOptions dodając przełącznik /minint.

Tak przygotowany obraz Windows PE próbujemy uruchomić via WDS.

Niestety otrzymujemy błąd. Ekran o podobnym jak niżej wyglądzie. Gdzie leży problem? Podobny ekran pojawi się również dla obrazów istniejących typu CD-BASED czy RIPREP.

Rys. 4. Ekran startowy boot’owania via WDS.

Proszę zajrzeć do właściwości usługi WDS. Zakładka - Boot.

Rys. 5. Właściwości serwera usługi WDS – zakładka Boot.

Jaki jest ustawiony domyślny program boot’ujący dla platformy x86? PXEBoot.com. Ale wewnątrz folderu, w którym mają być zlokalizowane pliki startowe, takiego pliku nie ma!!! Są dwa inne. abortpxe.com i wdsnbp.com. Niestety żaden z nich nie jest w tym przypadku plikiem prawidłowym.

Wybranie abortpxe.com powoduje wyjście z trybu PXE i wybór innego medium startowego. wdsnbp.com – wykorzystywany jest dla obrazów typu .wim w procesie auto-odkrywania trybu platformy sprzętowej. Bardziej dokładny opis samego procesu startu via PXE/RIS/WDS zostanie umieszczony w kolejnych częściach artykułu.

 

Rys. 6. Ekran wyboru plików obrazów startowych.

Uwaga:

Dopóki nie będziemy mieli obrazów startowych – Boot Images – które są tworzone z wykorzystaniem produktów Windows VISTA OEM Preinstallation Kit lub Windows VISTA Automated Installation Kit należy sobie poradzić w sposób opisany poniżej!

 

Trzeba podstawić inny program boot’ujący, ten oryginalny wykorzystywany przez usługę RIS, czyli …OSChooser\i386\startrom.com.

Rys. 7. Podstawienie oryginalnego pliku obrazu startowego dla architektury x86.

Po zrestartowaniu usługi WDS, pojawia się znane z RIS menu startowe. Wybieramy obraz z systemem Windows PE.

Rys. 8. Dostępna przykładowa lista obrazów po poprawce pliku obrazu startowego.

System się bootuje…

Rys. 9. Start systemu Windows PE 2005.

I po chwili ukazuje się następujący ekran

Rys. 10. Uruchomione Windows PE 2005.

Wybieramy Quit. I mamy dostęp do linii poleceń. Aby opuścić system Windows PE należy wpisać EXIT i ENTER.

Rys. 11. Przykładowe uruchomienie narzędzia tekstowego.

Powyżej pokazałem dostęp do narzędzi z linii poleceń, np. ipconfig. Możliwe jest uruchamianie zarówno narzędzi tekstowych jak i graficznych, ale muszą one zostać dodane do przygotowywanego obrazu systemu Windows PE 2004 czy 2005. Dodawanie komponentów dodatkowych do Windows PE 2004/2005 zostawię na inną okazję. Pokazałem tutaj, iż istnieje możliwość boot’owania z RIS/WDS nie tylko systemów typu CD-BASED, RIPREP ale np. DOS’a, Windows ME oraz Windows PE. Jak wspomniałem wcześniej, do Windows PE 2.0 wrócimy w części kolejnej artykułu.

Do początku strony

Komponenty usługi WDS

Komponenty serwera usługi RIS (czyli BINL, DHCP, SIS, TFTP) były ze sobą dość luźno związane. W przypadku usługi WDS, jest zupełnie odwrotnie. Narzędzie zarządcy usług (SVCHOST.exe) ładuje bibliotekę dll WDSsrv.dll, która to pośredniczy w wymianie komunikatów UDP/RPC do pozostałych elementów składowych usługi WDS.

Za obsługę serwera PXE odpowiada WDSpxe.dll – komunikujący się z wykorzystaniem interfejsu API z dostawcami rozwiązań komunikacyjnych dla interfejsów sieciowych (PXE providers) – w naszym przypadku z domyślnym BINLsvc.dll. Bibliotek BINLsvc.dll odpowiada również za komunikację (z wykorzystaniem protokołu RPC) z narzędziami administracyjnymi. Ostatni komponent WDSmgsrv.dll odpowiada za dostarczanie obrazów do klientów.

Rys. 12. Struktura i wzajemne powiązania komponentów składowych usługi WDS.

Usługa WDS może być wyposażona w więcej niż jeden komponent typu (PXE Custom Providers). Takiego przypadku nie będziemy tutaj omawiać, gdyż niepotrzebnie wydłużyłoby to materiał a dodatkowo na dzisiejszy dzień dostępny jest tylko komponent standardowy Microsoft PXE Providers.

Nie będę tu omawiał również konfiguracji niestandardowych, tzn. serwerów typu multihomed (wyposażonych w więcej niż jeden interfejs sieciowy klasy Ethernet, czy środowisk korzystających z serwerowych produktów firm trzecich, np. zewnętrznego serwera DHCP).

Spróbujmy teraz podzielić komponenty usługi, WDS w zależności od przeznaczenia:

1. Usługa WDS

   • komponenty rdzenia usługi WDS,
   • komponenty serwera PXE,
   • - BINL PXE Provider (dostawca usługi PXE),
   • magazyn obrazów.

2. Komponenty serwera TFTP

   • Single Instance Storage i usługa Groveler,

3. Foldery/udziały zdalne

Do początku strony

Komponent BINL

Moduł BINL PXE Providers – zawiera w sobie zintegrowaną logikę do komunikacji z rdzeniem usługi WDS. Do przechowywania informacji wykorzystuje usługę katalogową Active Directory, łącząc fizyczny komputer z obiektem w Active Directory, jakim jest konto komputera wraz z przypisanym mu identyfikatorem GUID. Dla zapewnienia kompatybilności z usługą RIS zawiera komponenty emulujące RIS na WDS. Ze względu na przeznaczenie można go podzielić na trzy obszary pracy:

• Active Directory Intergration
• Boot Configuration Data (Generation) - BCD
• Legacy RIS emulation – zapewnienie pełnej kompatybilności wstecznej z usługą RIS

Z punktu widzenia funkcjonalności usługi WDS nie ma znaczenia czy domena /las pracuje w trybie native 2000/2003 czy mixed. W przypadku środowiska wielodomenowego należy zapewnić tylko odpowiednie relacje zaufania pomiędzy domenami. W przypadku środowiska składającego się z wielu lasów Active Directory, występuje pewne ograniczenie, co do komputerów – dla których tworzymy prekonfigurowane konta komputerów. Funkcjonalność ta będzie działać tylko w tym lesie, w którym zainstalowany jest serwer WDS. Aby WDS funkcjonował dla wszystkich domen i lasów, niestety trzeba włączyć odpowiadanie usługi BINL dla wszystkich komputerów, a nie tylko dla prekonfigurowanych (ang. Prestaged).

Do początku strony

Wykorzystanie przez komponent BINL kontrolerów domeny i serwerów wykazu globalnego (ang. global katalog)

Komponent BINL stara się odkryć najbliższe serwerowi WDS dostępne kontrolery domeny (w tym i te pełniące rolę wykazu globalnego), najlepiej znajdujące się w tej samej lokalizacji, (ang. Site), co serwer usługi WDS – nazwijmy je lokalne). Wykaz globalny jest wykorzystywany w celu odszukania specyficznych atrybutów netbootGUID oraz netbootMachineFilePath. Wykorzystanie global katalogu zdecydowanie zmniejsza liczbę zapytań LDAP’owych.

Dygresja. Klasyczny serwer RIS robi to w inny sposób, ale nie będę tego tu opisywał.

 

Dodatkowo usługa WDS dla określonej domeny (swojej), będzie odpytywać kontroler domeny w poszukiwaniu atrybutów:

netbootAnswerOnlyValidClients,

netbootAnswerRequests,

netbootMaxClients,

netbootSCPBL,

netbootServer.

Upraszczając, BINL potrzebuje do pracy kontrolera domeny i global katalog. W przypadku lokalizacji bez serwera wykazu globalnego można manualnie określić, z którego konkretnie kontrolera domeny ma usługa WDS skorzystać, a nie posiłkować się odległym wykazem globalnym. Za konfigurację odpowiada poniższy klucz w gałęzi rejestru:

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC

O nazwie: ADSearchOrder

Typ: REG_SZ

Wartość:

0 lub nie ustawiona – przeszukaj globalny katalog (choćby odległy), później kontroler domeny.

1 – przeszukaj najbliższy kontroler domeny a później global katalog.

Ogólnie – ustawienie wartości parametru ADSearchOrder na 1 może zmniejszyć skuteczność odszukiwania kont dla komputerów typu „prestaged” w środowisku wielodomenowym.

Istnieje możliwość manualnego wskazania usłudze WDS nazw kontrolerów domen i wykazu globalnego. Odpowiadają za to następujące klucze w gałęzi rejestru:

HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSPXE\Providers\BINLSVC

Nazwa klucza: DefaultServer

Typ: REG_SZ

Wartość : nazwa wybranego kontrolera domeny dla usługi WDS (może być NETBIOS lub FQDN).

Nazwa klucza: DefaultGCServer

Typ: REG_SZ

Wartość : nazwa wybranego kontrolera domeny pełniącego rolę global catalog’u (może być NETBIOS lub FQDN).

Ten sam efekt można również uzyskać b za pomocą poleceń:

WDSUTIL /Set-Server /DomainSearchOrder:DCFirst – kolejność przeszukiwania – najpierw kontroler domeny

WDSUTIL /Set-Server /DomainSearchOrder:GCOnly – przeszukuj wyłącznie w global catalog’u

WDSUTIL /Set-Server /PreferredDC:<name> gdzie nazwa oznacza nazwę zwykłego kontrolera domeny - NetBIOS lub FQDN

WDSUTIL /Set-Server /PreferredGC:<nazwa> gdzie nazwa oznacza nazwę kontrolera domeny pełniącego rolę wykazu globalnego - NetBIOS lub FQDN

Do początku strony

Obszar BCD Generation

W implementacji serwera RIS klienci wykorzystywali dla platformy x86 i x64 ten sam obraz startowy OSChooser.exe (w rzeczywistości jest to zmieniona nazwa NTLDR’a) w przypadku IA-64 (Itanium) był to OSChoice.efi. Dla usługi WDS klient może wybrać wiele obrazów startowych, np. instalacja systemu 32-bitowego (x86) na sprzęcie z procesorem wyposażonym w rozszerzenie 64-bitowe (EM-64T Intela), lub wybór wielu wersji startowych Windows PE. Menu wyboru obrazu startowego pozwala wybrać klientowi, jaki typ obrazu chce zainstalować. W przypadku tylko jednego obrazu menu też będzie wyświetlane, ale ze względu na jeden typ obrazu będzie on automatycznie wybierany. Nowe menu wyboru obrazów o nazwie – Boot Configuration Data (BCD) jest identyczne jak nowy mechanizm w Windows Vista, który zastąpił znany plik boot.ini.

Do początku strony

Magazyn obrazów

Usługa RIS wspierała dwa typy obrazów RISETUP (inaczej zwany CD-BASED) oraz RIPREP. Oba omawiałem we wcześniejszych rozdziałach artykułu. WDS wprowadza nowy typ obrazów – Windows Image .wim. Ten pojedynczy typ obrazu zawiera w sobie nie tylko sam obraz, ale również pewną „logikę” i informacje dodatkowe, które wykorzystuje WDS do dystrybucji obrazu. Magazyn obrazów składa się z następujących komponentów:

• obrazów przechowywanych na fizycznym dysku twardym
• komponentu serwerowego wykorzystywanego do pobierania i instalacji obrazu
• narzędzi zarządzających wykonywaniem operacji związanych z obrazami, jak dodawanie, usuwanie czy zmiana nazwy

Do początku strony

Komponenty serwera TFTP

Na komponentach serwera TFTP skupimy się bardzo krótko. Pełnią one trzy funkcje:

• dla komputera wyposażonego w kartę sieciową zgodną z PXE – transportują do klienta sieciowy program startowy pobierany z serwera RIS,
• dla Windows PE – przesyłają obraz RAMDISKU startowego Windows PE,
• dla serwera RIS zapewniają transport plików niezbędnych do wyświetlenia po stronie klienta menu wyboru obrazów typu RISETUP lub RIPREP.

Do początku strony

Komponent SIS i usługa Groveler

Oba te komponenty są wykorzystywane przy pracy w trybie emulacji RIS’a (legacy) oraz w trybie mieszanym RIS/WDS Mixed. Właściwość Single Instance Storage opisywałem w pierwszych częściach artykułu dotyczących RIS i nie będę jej tu powtarzał. Pewne dodatkowe funkcjonalności wnosi wersja systemu Windows Storage Server 2003 R2, ale nie jest to produkt do kupienia i samodzielnej instalacji – dostarczany jest on wraz ze sprzętem przez określonych dostawców sprzętu jak , np. HP czy Dell. Jakie korzyści daje zastosowanie Windows Storage Server’a 2003 R2:

• konsolidacja na poziomie woluminu dyskowego zduplikowanych plików,
• konsolidacja na poziomie pamięci cache zduplikowanych plików,
• wyposażenie w uaktualnione mechanizmy do archiwizacji i odtwarzania zawartości SIS.

SIS Groveler i SIS Storage Filter pełnią identyczną rolę jak w serwerze usługi RIS dla trybu LEGACY i MIXED.

Dla obrazów typu .wim osługa ich przez SIS Grovelera i SIS Storage Filter nie jest już wymagana. Sam obraz w sobie zapewnia funkcjonalność Single Instance Storage, a dodatkowo, czego nie było wcześniej – kompresję w celu dodatkowej redukcji zajmowanego miejsca na dysku twardym. Dla trybu NATIVE usługa Groveler jest zatrzymywana oraz ma ustawioną właściwość na Disable.

Do początku strony

Foldery/udziały zdalne

W procesie konfiguracji usługi WDS lub/i migracji z RIS tworzone są następujące udziały. Folder lokalny o nazwie RemoteInstall (dla zapewnienia kompatybilności z usługą RIS), oraz folder /udział REMINST.

Rys. 13. Struktura folderów udziału RemoteInstall.

Folder Admin zawiera narzędzia wykorzystywane przez usługę RIS/WDS w trybie LEGACY i MIXED. Sam folder Admin nie zawiera żadnych plików, natomiast zawiera folder/foldery zgodny/e z typem obrazów dla różnych platform sprzętowych. W naszym przypadku platformy i386 (x86). Znajdują się tutaj znane z RIS narzędzia riprep.exe i rbfg.exe, omawiane już we wcześniejszych częściach artykułu.

Rys. 14 Zawartość folderu Admin\i386.

Boot – zawiera pliki obrazów startowych Windows PE i związanych z nimi plików PXE boot. Wykorzystywany w trybie MIXED i NATIVE. Zawartości folderu Boot przyjrzymy się dokładniej w następnych częściach.

Rys. 15. Zawartość folderu Boot.

Zawartość folderu …Boot\x86.

Rys. 16. Zawartość folderu Boot dla platformy x86 (32-bit)

Zawartość folderu …Boot\x64.

Rys. 17. Zawartość folderu Boot dla platformy x64 (64-bit).

Images – zawiera foldery z obrazami w formacie .wim. Wykorzystywany w trybie Mixed i Native.

Rys. 18. Przykładowa zawartość folderu Images – z listą folderów obrazów typu .wim.

• Mgmt – zawiera bazę komputerów oczekujących na zgodę administratora na instalację obrazu. Wykorzystywane w trybie Mixed i Native.
• OSChooser – opisywane w poprzednich częściach artykułu – zawiera menu startowe dla RIS i obrazy startowe dla PXE. Wykorzystywane w trybach Legacy i Mixed.
• Setup – zawiera listę obrazów typu RISETUP i/lub RIPREP, wykorzystywanych w trybach Legacy i Mixed
• Template – zawiera szablon (templates) dla obrazu typu .wim wraz z wyborem sposobu nazewnictwa komputera i podłączeniem do domeny. Wykorzystywany w trybach Mixed i Native.

Rys. 19. Zawartość folderu …\Templates.

Folder Tmp – zawiera pliki tymczasowe oraz plik .sif wykorzystywany przez komputery podczas pobierania obrazów typu RISETUP i RIPREP oraz dane Boot Configuration Data (BCD) wykorzystywane aktualnie przez klientów.

WdsClientUnattend – zawiera plik Unattend.xml wykorzystywany przez klientów usługi Windows Deployment Services.

Do początku strony

Podsumowanie

W następnej części omówimy dokładnie formaty plików obrazów systemów (System Images) oraz plików startowych (Boot Images) wykorzystywanych w trybie MIXED i NATIVE. Omówione zostanie dokładnie środowisko Windows PE 2.0 oraz środowisko Windows Vista Automated Installation Kit (WAIK) oraz Windows OEM Preinstallation KIT (OPK).

Do początku strony

Przeczytaj pozostałe części tego artykułu

• Tajniki usługi WDS, cz. I
• Tajniki usługi WDS, cz. III
• Tajniki usługi WDS, cz. IV
• Tajniki usługi WDS, cz. V

---

Jacek Światowiak (MCT, MCSE, MCSE+M, MCSE+S, MCTS, MCP) Absolwent Wydział Elektroniki, Telekomunikacji i Informatyki Politechniki Gdańskiej. Obecnie zatrudniony w Altkom Akademia S.A. jako Trener Technologii Microsoft. Posiada bogate doświadczenie w zakresie wdrażania różnych technologii informatycznych. Od 2002 roku wykładowca Technologii i Protokołów Sieciowych na Podyplomowym Studium Politechniki Gdańskiej. Jest współautorem skryptu dla studentów informatyki: „Protokoły IPv6 – Opis protokołów. Materiały do laboratorium”. Posiada certyfikaty MCT, MCSE, MCSE+M, MCSE+S, MCTS Microsoft Exchange Server 2007, MCP ID 3621156.

Do początku strony

---