🥇Menu rozruchowe PXE z System Center Configuration Manager

Rozważamy rozszerzenie możliwości System Center Configuration Manager (produkt do zarządzania infrastrukturą IT) podczas uruchamiania komputerów użytkowników przez sieć z wykorzystaniem PXE. Tworzymy menu rozruchowe oparte na PXELinux z funkcjonalnością System Center i dodajemy możliwość skanowania antywirusowego, obrazy diagnostyczne i przywracające. Na końcu artykułu poruszamy kwestie działania System Center 2012 Configuration Manager w połączeniu z Windows Deployment Services (WDS) podczas rozruchu przez PXE.

Wszystkie działania wykonujemy w środowisku testowym, w którym już zainstalowano System Center 2012 Configuration Manager SP1, kontroler domeny oraz kilka maszyn testowych. Zakłada się, że w SCCM już używa się wdrożenia przez sieć z wykorzystaniem PXE.

Wprowadzenie

Środowisko testowe składa się z kilku maszyn wirtualnych. Na wszystkich maszynach zainstalowano system operacyjny Microsoft Windows Server 2008 R2 (x64), adapter sieciowy E1000, kontroler SCSI: LSI Logic SAS.

Nazwa (Role)
Adres IP / Nazwa DNS
Funkcjonalność

SCCM (System Center Configuration Manager)
192.168.57.102
sccm2012.test.local

Zainstalowano System Center Configuration Manager 2012 SP1

DC (AD, DHCP, DNS)
192.168.57.10
dc1.test.local

Rola kontrolera domeny, serwera DHCP i serwera DNS

TEST (Maszyna testowa)
192.168.57.103
test.test.local

Do testowania

GW (Brama)
192.168.57.1
Routowanie między sieciami. Rola bramy

1. Dodajemy PXELinux do SCCM

Działania podejmujemy na maszynie, na której zainstalowano System Center Configuration Manager

Określimy katalog, w którym znajdują się pliki WDS do ładowania, w tym celu w rejestrze sprawdzamy wartość parametru RootFolder w gałęzi HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP
Wartość domyślna C:\RemoteInstall
Pliki do ładowania z punktu wdrożenia SCCM znajdują się w katalogach smsboot\x86 i smsboot\x64 w zależności od architektury.
Najpierw konfigurujemy katalog dla architektury 32-bitowej, domyślnie c:\RemoteInstall\smsboot\x86
Pobieramy archiwum z najnowszym syslinux . Kopiujemy z syslinux-5.01.zip do c:\RemoteInstall\smsboot\x86 następujące pliki:
memdisk, chain.c32, ldlinux.c32, libcom32.c32, libutil.c32, pxechn.c32, vesamenu.c32, pxelinux.0
Dodatkowe pliki są potrzebne, aby nie wystąpił podobny błąd
W c:\RemoteInstall\smsboot\x86 przekreślamy pxelinux.0 do pxelinux.com
W folderze c:\remoteinstall\smsboot\x86 tworzymy kopię abortpxe.com i zmieniamy jej nazwę na abortpxe.0
Jeśli nie zmieni się rozszerzenia na .0, wtedy na przykład instrukcja
```
Kernel abortpxe.com
```
zostanie wykonana z błędem: Booting kernel failed: Bad file number.
Dla PXELINUX rozszerzenie pliku uruchomieniowego należy ustawić zgodnie z tabelą.
```
brak lub inny	obraz jądra Linux
 .0		program rozruchowy PXE (tylko [PXELINUX])
 .bin		"sektor rozruchowy CD" [tylko ISOLINUX]
 .bs		Sektor rozruchowy [tylko SYSLINUX]
 .bss		Sektor rozruchowy, superblok DOS będzie wstawiony [tylko SYSLINUX]
 .c32		Obraz COM32 (32-bitowy COMBOOT)
 .cbt		Obraz COMBOOT (nie można uruchomić z DOS)
 .com		Obraz COMBOOT (można uruchomić z DOS)
 .img		Obraz dysku [tylko ISOLINUX]
```
Źródło: http://www.syslinux.org/wiki/index.php/SYSLINUX#KERNEL_file sekcja „Plik jądra”
Aby nie wciskać kilkukrotnie klawisza F12 podczas uruchamiania SCCM z menu, zmieniamy nazwę pliku pxeboot.com na pxeboot.com.f12, kopiujemy pxeboot.n12 do pxeboot.com
Jeśli tego nie zrobimy, za każdym razem przy wyborze pojawi się to wiadomość

Uwaga: Nie zapomnijmy zmienić nazw tych plików także w folderze dla x64, ponieważ podczas uruchamiania x86wdsnbp.com z folderu x86, program rozruchowy określa architekturę procesora i następny plik ładowany jest już z folderu odpowiadającego architekturze. W ten sposób dla x64 kolejny plik będzie różny x86pxeboot.com, a x64pxeboot.com
Pobieramy/tworzymy background.png, o rozdzielczości 640x480, kopiujemy do tego samego folderu. Tworzymy folder ISO gdzie umieścimy obrazy ISO. Tworzymy folder pxelinux.cfg na pliki konfiguracyjne.

W folderze pxelinux.cfg tworzymy plik default w nie-UTF-8 z treścią
default (Kliknij, aby wyświetlić)

# используем графическое меню
DEFAULT vesamenu.c32
PROMPT 0
timeout 80
TOTALTIMEOUT 9000

MENU TITLE PXE Boot Menu (x86)
MENU INCLUDE pxelinux.cfg/graphics.conf
MENU AUTOBOOT Starting Local System in 8 seconds

# Boot local HDD (default)
LABEL bootlocal
menu label Boot Local
menu default
localboot 0x80
# if it doesn't work 
#kernel chain.c32
#append hd0

# Вход в меню по паролю Qwerty, алгоритм MD5
label av
menu label Antivirus and tools
menu PASSWD $1$15opgKTx$dP/IaLNiCbfECiC2KPkDC0
kernel vesamenu.c32
append pxelinux.cfgav.conf 

label sccm
menu label Start to SCCM
COM32 pxechn.c32
APPEND sccm2012.test.local::smsbootx86wdsnbp.com -W

label pxe64
menu label Start to x64 pxelinux
COM32 pxechn.c32
APPEND sccm2012.test.local::smsbootx64pxelinux.com

LABEL Abort
MENU LABEL Exit
KERNEL abortpxe.0

W folderze pxelinux.cfg tworzymy plik graphics.conf z treścią
graphics.conf (Kliknij, aby wyświetlić)

MENU MARGIN 10
MENU ROWS 16
MENU TABMSGROW 21
MENU TIMEOUTROW 26
MENU COLOR BORDER 30;44 #00000000 #00000000 none
MENU COLOR SCROLLBAR 30;44 #00000000 #00000000 none
MENU COLOR TITLE 0 #ffffffff #00000000 none
MENU COLOR SEL 30;47 #40000000 #20ffffff
MENU BACKGROUND background.png
NOESCAPE 0
ALLOWOPTIONS 0

W folderze pxelinux.cfg tworzymy plik av.conf z treścią
av.conf (Kliknij, aby wyświetlić)

DEFAULT vesamenu.c32
PROMPT 0
MENU TITLE Program antywirusowy i narzędzia
MENU INCLUDE pxelinux.cfg/graphics.conf

label main menu
menu label powrót do menu głównego
kernel vesamenu.c32
append pxelinux.cfg/default

label drweb
menu label DrWeb
kernel memdisk
append iso raw initrd=isodrweb.iso

label eset
menu label Eset
kernel memdisk
append iso raw initrd=isoeset_sysrescue.iso

label kav
menu label KAV Rescue CD
KERNEL kav/rescue
APPEND initrd=kav/rescue.igz root=live rootfstype=auto vga=791 init=/init kav_lang=pl udev liveimg doscsi nomodeset quiet splash

# Ładujemy ISO na podstawie pełnej ścieżki, można ładować z innego TFTP
label winpe
menu label WinPE z innego TFTP
kernel sccm2012.test.local::smsbootx86memdisk
append iso raw initrd=sccm2012.test.local::smsbootx86isoWinPE_RaSla.iso

label clonezilla
menu label Clonezilla
kernel memdisk
append iso raw initrd=isoclonezilla.iso

W rezultacie katalog c:remoteinstallsmsbootx86 zawiera strukturę
c:\remoteinstall\smsboot\x86
pxelinux.cfg
chain.c32
ldlinux.c32
libcom32.c32
libutil.c32
pxechn.c32
vesamenu.c32
pxelinux.com
background.png
pxelinux.cfg
pxelinux.cfg
pxelinux.cfg
ISO
abortpxe.0
wdsnbp.com
bootmgfw.efi
wdsmgfw.efi
bootmgr.exe
pxeboot.n12
pxeboot.com
abortpxe.com
default
av.conf
graphics.conf
*.iso
Dla architektury x64 analogicznie kopiujemy i tworzymy taką samą strukturę w folderze c:remoteinstallsmsbootx64

Uzupełnienie
Przy użyciu polecenia menu PASSWD hasło można ustawić lub tak, jak jest, lub używając algorytmu skrótu, dodając na początku parametru odpowiednią sygnaturę
Algorytm
Sygnatura
MD5
$1$
SHA-1
$4$
SHA-2-256
$5$
SHA-2-512
$6$
W ten sposób dla hasła Qwerty i algorytmie MD5
menu PASSWD $1$15opgKTx$dP/IaLNiCbfECiC2KPkDC0
Można wygenerować hasło na przykład za pomocą internetowego generatora hashy www.insidepro.com/hashes.php?lang=rus, ciąg MD5(Unix)

2. Konfigurujemy ładowanie PXELinux

Teraz wskaźmy, w jaki sposób załadować pxelinux.com i uzyskać menu.
Wskazywanie bootloadera pxelinux.com za pomocą funkcji WDS nie działa w SCCM. Komendy w formie

wdsutil /set-server /bootprogram:bootx86pxeboot.com /architecture:x86

nie są przetwarzane. Aby upewnić się, że obrazy rozruchowe nie są skonfigurowane, można wykonać polecenie wyjścia konfiguracji serwera WDS

wdsutil /get-server /show:images

W ten sposób w SCCM 2012 nie można wskazać własnego pliku do ładowania przez PXE dla dostawcy SMSPXE. Dlatego skonfigurujemy aktywny zakres serwera DHCP.
W parametrach aktywnego zakresu DHCP określamy parametry zgodnie z tabelą

Opcja DHCP
Nazwa parametru
Wartość

066
Nazwa hosta serwera rozruchowego
sccm2012.test.local

067
Nazwa pliku rozruchowego
smsbootx86pxelinux.com

006
Serwery DNS
192.168.57.10

015
Nazwa domeny DNS
test.local

W opcji 066 wskazujemy FQDN nazwę serwera sccm, w opcji 067 podajemy ścieżkę do x86 bootloadera pxelinux.com zaczynając od korzenia TFTP, w opcji 006 podajemy adres IP serwera DNS. W przypadku, gdy w opcji 066 używana jest krótka nazwa serwera, w opcji 015 podajemy sufiks DNS domeny.

Uzupełnienie
Szczegółowo konfigurację DHCP opisał mvgolubev tutaj. Ale na DC opcja 150, adres IP serwera TFTP, był niedostępny w ustawieniach zakresu DHCP i wskazanie opcji 150 przez netsh nie działało.

3. Sprawdzanie działania

Główne ustawienia zostały zakończone i można przystąpić do testowania. Wskazujemy na komputerze testowym w BIOSie, aby ładował się przez sieć i logujemy się do menu

Wybieramy opcję „Start to SCCM” i jeśli komputer ma przypisaną sekwencję działań, to po pewnym czasie pojawi się okno „Kreator tworzenia sekwencji działań” z propozycją wpisania hasła

Restartujemy maszynę, ponownie wchodzimy do menu, wybieramy w menu „Antivirus and tools” i wpisujemy hasło Qwerty

Wybieramy dowolny element i obserwujemy ładowanie obrazu ISO do pamięci

Czekamy i obserwujemy rezultat

Sprawdzanie zakończone

4. Dodatkowe ustawienia i cechy

Konfiguracja routingu

Jeśli klient, serwer DHCP i serwer zawierający program rozruchowy sieci znajdują się w tej samej sieci, dodatkowa konfiguracja nie jest wymagana. Jeśli jednak klient oraz serwer DHCP lub serwer WDS/SCCM znajdują się w różnych segmentach sieci, zaleca się skonfigurowanie na routerach przekazywania pakietów rozgłoszeniowych od klienta do działającego serwera DHCP oraz działającego serwera WDS/SCCM. W literaturze anglojęzycznej proces ten znany jest jako „aktualizacja tabeli IP Helper”. Wówczas klient, po otrzymaniu adresu IP, łączy się bezpośrednio z serwerem zawierającym program rozruchowy sieci poprzez pakiety DHCP, aby pobrać program rozruchowy sieci.
Dla routerów Cisco używa się polecenia

ip helper-address {ip address}

gdzie {ip address} adres serwera DHCP lub serwera WDS/SCCM. Przy używaniu tego polecenia przesyłane są również następujące pakiety rozgłoszeniowe UDP

Port
Protokół

69
TFTP

53
Domain Name System (DNS)

37
Usługa czasu

137
NetBIOS Name Server

138
NetBIOS Datagram Server

67
Bootstrap Protocol (BOOTP)

49
TACACS

Drugą metodą uzyskiwania przez klienta informacji o programie rozruchowym sieci bezpośrednio z serwera DHCP jest określenie opcji 60, 66, 67 na serwerze DHCP. Wykorzystanie parametru DHCP 60 z wartością „PXEClient” w całym zasięgu działania DHCP, tylko jeśli serwer DHCP znajduje się na tym samym serwerze, co usługi wdrożeniowe Windows. W takim przypadku klient łączy się z serwerem usług wdrożeniowych Windows bezpośrednio protokołem TFTP przez port UDP 4011, a nie przez DHCP. Ta metoda nie jest zalecana przez Microsoft z powodu problemów z równoważeniem obciążenia, błędnym przetwarzaniem parametrów DHCP oraz parametrów odpowiedzi usług wdrożeniowych Windows po stronie klienta. A także dlatego, że użycie tylko dwóch opcji 66 i 67 DHCP pozwala na ominięcie parametrów określonych na serwerze rozruchu sieciowego.
Należy również otworzyć następujące porty UDP na serwerze usług wdrożeniowych Windows
port 67 (DHCP)
port 69 (TFTP)
port 4011 (PXE)
oraz port 68, jeśli wymagana jest autoryzacja DHCP na serwerze.

Szczegóły procesu konfiguracji i niuansów przekierowania między różnymi serwerami WDS opisano poniżej w źródłach:
Zarządzanie programami rozruchowymi w sieci http://technet.microsoft.com/ru-ru/library/cc732351(v=ws.10).aspx
Zarządzanie serwerem http://technet.microsoft.com/ru-ru/library/cc770637(v=ws.10).aspx
Limity wsparcia Microsoft Product Support Services (PSS) dla rozruchu sieciowego środowiska Windows Preinstallation (Windows PE) 2.0 http://support.microsoft.com/kb/926172/en-us
Jak przekazywać rozgłoszenia UDP (BOOTP/DHCP) na Cisco http://www.cisco-faq.com/163/forward_udp_broadcas.html
Cecha działania i konfiguracji DHCP na routerach Cisco (Część 2) http://habrahabr.ru/post/89997/

Dodatkowe możliwości lokalnego rozruchu

Na środowisku testowym polecenie

localboot 0

wyświetla taki błąd

Z dokumentacji syslinux wynika, że

localboot 0

załadunek odbędzie się z lokalnego dysku. A przy wskazaniu konkretnej wartości 0x00 z głównej (primary) dyskietki, przy wskazaniu 0x80 z głównego (primary) dysku twardego. Zmieniamy polecenie na

localboot 0x80

lokalny system operacyjny został załadowany.
Jeśli istnieje potrzeba załadowania z konkretnego dysku, partycji lub polecenie localboot nie działa, można skorzystać z możliwości modułu chain.c32. Po jego załadowaniu, komendą append wskazujemy konkretny dysk lub partycję dysku, numeracja dysków zaczyna się od 0, numeracja partycji od 1, ponieważ przy wskazaniu partycji 0 załadowany zostaje MBR. Przy wskazaniu dysku partycję można pominąć.

KERNEL chain.c32
APPEND hd0 0

lub

KERNEL chain.c32
APPEND hd0

Źródła: http://www.syslinux.org/wiki/index.php/SYSLINUX#LOCALBOOT_type_.5BISOLINUX.2C_PXELINUX.5D
http://www.gossamer-threads.com/lists/syslinux/users/7127

Kolejność i opis ładowania plików przez PXE

Jak już wspomniano na początku artykułu, katalog, w którym znajdują się pliki WDS do załadunku, jest zawarty w wartości parametru RootFolder w gałęzi rejestru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTP
Wartość domyślna C:\RemoteInstall
Tutaj w parametrze ReadFilter wskazane są katalogi, w których serwer TFTP szuka plików do ładowania, zaczynając od korzenia. Przy zainstalowanym SCCM 2012 SP1 ten parametr wygląda następująco

boot*
tmp*
SMSBoot*
SMSTemp*
SMSImages*

Jeśli zmienisz wartość parametru na * to będą przetwarzane wszystkie pliki znajdujące się w katalogu RemoteInstall.

Rola punktu wdrożeniowego SCCM 2012 jest zapisana w parametrze rejestru ProvidersOrder, znajdująca się w gałęzi HKLMSystemCurrentControlSetWDSServerProvidersWDSPXE
Parametr ProvidersOrder może przyjmować wartości

SMSPXE
punkt obsługi PXE w SCCM

SMS.PXE.Filter
Obsługiwacz skryptów PXE z MDT (Microsoft Deployment Toolkit)

BINLSVC
Standardowy obsługiwacz WDS i RIS

Przy zainstalowanym SCCM parametr ProvidersOrder ma wartość SMSPXE. Zmieniając parametr można zmieniać kolejność ładowania dostawców.

W katalogu RemoteInstall znajdują się następujące standardowe pliki

wdsnbp.com

Program do sieciowego ładowania, zaprojektowany dla usług wdrażania Windows i realizujący następujące zadania:
1. Wykrywanie architektury.
2. Obsługa oczekujących komputerów. Gdy włączona jest polityka automatycznego dodawania, ten program do sieciowego ładowania jest wysyłany na oczekujące komputery, aby wstrzymać ładowanie sieciowe i poinformować serwer o architekturze komputera klienckiego.
3. Wykorzystanie linków do ładowania sieciowego (w tym użycie parametrów 66 i 67 protokołu DHCP)

PXEboot.com

(Domyślnie) Wymaga, aby użytkownik nacisnął klawisz F12, aby kontynuować ładowanie sieciowe

PXEboot.n12

Nie wymaga naciśnięcia przez użytkownika klawisza F12 i natychmiast zaczyna ładowanie sieciowe

AbortPXE.com

Uruchamia komputer za pomocą następującego elementu uruchamiającego w BIOS bez oczekiwania

Bootmgr.exe

Menadżer rozruchu Windows (Bootmgr.exe lub Bootmgr.efi). Ładuje za pomocą oprogramowania układowego bootloader Windows z określonej partycji dysku lub poprzez połączenie sieciowe (w przypadku ładowania sieciowego)

Bootmgfw.efi

Wersja EFI programów PXEboot.com i PXEboot.n12 (w EFI wybór ładowania lub nieładowania PXE odbywa się w powłoce EFI, a nie przez program ładowania sieciowego). Program Bootmgfw.efi łączy możliwości PXEboot.com, PXEboot.n12, abortpxe.com oraz bootmgr.exe. Obecnie istnieje tylko dla architektur x64 i Itanium

Default.bcd

Magazyn danych konfiguracji rozruchu (BCD), format REGF, można ładować w REGEDIT, zastępuje plik tekstowy Boot.ini

Ładowanie przebiega w następującej kolejności z opisem powyżej
1. Ładowany jest wdsnbp.com.
2. Następnie ładowany jest pxeboot.com odpowiedniej architektury
3. PXEBoot.com ładuje bootmgr.exe i magazyn danych konfiguracji rozruchu BCD
4. Bootmgr.exe odczytuje wpisy systemu operacyjnego z danych konfiguracji rozruchu BCD i ładuje plik Boot.sdi oraz obraz Windows PE (boot.wim)
5. Bootmgr.exe rozpoczyna ładowanie Windows PE, odwołując się do Winload.exe w obrazie Windows PE

Jeśli w RemoteInstall są foldery

Boot
Images
Mgmt
Templates
Tmp
WdsClientUnattend

ich obecność oznacza, że przed dodaniem roli punktu rozpowszechniania w SCCM 2012 (punktu serwisowego PXE w SCCM 2007) miała miejsce konfiguracja zainstalowanych Usług wdrażania systemu Windows (WDS), w wyniku czego te foldery zostały automatycznie utworzone.
Dla roli punktu rozpowszechniania (punktu serwisowego PXE w SCCM 2007) wystarczą tylko następujące foldery

SMSBoot
SMSIMAGES
SMSTemp
Stores

To nie oznacza, że SCCM został zainstalowany nieprawidłowo, ale może wskazywać na potencjalne źródło błędów.
Bardzo szczegółowe rozwiązanie różnych problemów z integracją WDS, SCCM i PXE zostało omówione w artykule Troubleshooting the PXE Service Point and WDS in Configuration Manager 2007