Saga o wdrażaniu Red Hatów: a może wypróbujmy Windowsy?

Wielotygodniowa przygoda z uruchamianiem narzędzi do uwierzytelniania i wdrażania systemów redhatowych zakończyła się względnym sukcesem. Względnym, ponieważ była konieczna pewna zmiana planów. Niemniej, misja została wykonana i narzędzia nienadzorowanej instalacji działały zaskakująco dobrze. Co więcej, wykorzystywałem je do instalowania spakowanych obrazów partycji z Windows 7 (będąc świadomym szeregu niewybaczalnych wad takiego podejścia, niestety chwilowo nie mieliśmy wyjścia). W międzyczasie jednak w sieci, niejako „pod spodem” stawialiśmy równoległą architekturę, docelowo zgodną na poziomie uwierzytelniania: mowa rzecz jasna o Active Directory. Gdy ruch w sieci zaczął być routowany przez kontroler domeny Windows Server, pojawiła się pokusa, by redhatowo instalować tylko Linuksy, ale Windowsa to jednak stawiać „porządnie”, z podłączeniem do serwera aktywacji, z zasadami grupy i przede wszystkim – z wykorzystaniem Windows Deployment Services. Oznaczałoby to, mielibyśmy dwa równorzędne serwery PXE (jeden do instalowania Linuksa, drugi do Windowsów), ale poprawna konfiguracja sprawiłaby, że nie walczyłyby ze sobą (wyścig DHCP).

Stwierdziłem, że to bardzo dobry pomysł. Optymistycznie nastrajał mnie również fakt, że swego czasu używałem WDS do instalowania Windows XP na kilkuset stacjach w poprzedniej pracy. Zapamiętałem więc ową usługę jako zawsze działającą i bez wątpienia łatwą w instalacji i konfiguracji. W końcu co przecież może pójść źle? To Windows Server, tutaj wszystko po prostu działa. Na pewno całość będzie działać o niebo lepiej, niż kapeluszowy Cobbler i pakiety RPM… prawda?

Niestety, nie. Windows Server 2012 R2 (a więc oparty o Windows 8.1) dołączył na tym polu do grona oprogramowania, które nie działa i niech będzie mi wolno przedstawić kolejną odsłonę niekończącej się historii o wdrażaniu systemów i użyć jej jako dowodu, że obecnie naprawdę nic już nie działa tak, jak piszą na pudełku. I mimo, że spodziewałem się problemów, to, co mnie spotkało było niezwykle rozczarowujące.

Zacznijmy od tego, że WDS, a więc „Usługa Wdrażania systemu Windows” po zainstalowaniu nie jest gotowa do pracy. Samo to nie jest szczególnie dziwne, wszak Windows Server domyślnie nie uruchamia żadnej zainstalowanej roli, zmuszając administratora do aktywnej i świadomej konfiguracji. W tym przypadku jednak istotne jest, jak bardzo WDS nie jest gotowe do pracy, nawet po przeprowadzeniu wstępnej konfiguracji. Usługa wdrażania jest bowiem całkowicie pusta i nie oferuje żadnych systemów. Nie tylko systemów do instalacji, ale również systemów zdolnych do uruchomienia przez sieć. Redhatowy Cobbler również wymaga początkowego „nakarmienia go” obrazem ISO Fedory, żeby miał co serwować przez sieć, ale WDS wymaga znacznie więcej zabawy.

Trochę wprowadzenia

Nie chcę robić przewodnika po PXE, więc opiszę to szybko: instalator sieciowy wymaga obrazu systemu, który będzie przesyłał klientom po TFTP. To alternatywa dla uruchomienia komputera z płyty DVD z systemem. Potem taki system zachowuje się identycznie – zamiast płyty leci przez sieć. Dlatego Cobbler potrzebuje obrazu ISO z Fedorą, a WDS wymaga… obrazu WIM. Pliki WIM to tak naprawdę jedyne istotne obiekty na płycie DVD z Windows. Pierwszy plik, boot.wim, to obraz systemu WinPE, który jest uruchamiany z płyty (pomyślmy o tym, jak o Windows Live DVD). Drugi, o nazwie install.wim, to obraz całego systemu, który zostanie zainstalowany. Dlatego instalacja Windows trwa tak szybko: obraz zainstalowanego systemu jest „gotowy”, instalator jedynie rozpakowuje go na dysk. Ma to szereg zalet, o których później. W tej chwili chodzi nam o plik „boot.wim”, on bowiem będzie serwowany przez sieć. Dopiero gdy komputer uruchomi przez sieć system z tego pliku, będzie można uruchomić prawdziwy instalator i posłać na stację inny obraz systemu. Dlatego też, żeby użyć WDS potrzebujemy, poza Windows Server, płyty z innym, klienckim Windowsem, żeby zabrać z niego plik boot.wim. Zawsze odnosiłem wrażenie, że to naprawdę nie powinno być potrzebne, a potencjalne zalety (np. dostępność na różne architektury, sterowniki itp.) są naciągane i trudne do obronienia.

Przygotowanie rozruchu

Potrzebuję więc płyty z Windows 8.1, żeby zabrać z niej plik boot.wim i wrzucić do WDS. Nic prostszego: wziąłem płytę serwisową z Okienkami zainstalowanymi na klienckich komputerach i wdusiłem plik boot.wim jako obraz systemu do startowania przez sieć dla WDS. Przez myśl przeszło mi „fakt, to przecież było takie proste, jak to robiłem ostatnio!”. Prawidłowości losu uczą, że za takie myśli drogo się płaci, więc od tego momentu było już tylko gorzej. Gdy obraz uruchomienia dodał się tak łatwo, coś musiało pójść nie tak. Uruchomiłem z sieci jedną ze stacji roboczych, komputer wystartował przez PXE, zaczął uruchamiać system Windows Preinstallation Environment po czym… poinformował o braku sterowników do karty SIECIOWEJ. Tak jest. Do tej samej karty sieciowej przez którą pobrał się na ów komputer. Jest to dowód na prostotę TFTP: jeżeli jakaś karta sieciowa implementuje PXE, będzie zdolna do pobrania dowolnego systemu przez sieć bez pytania i bez żadnych wymagań wstępnych (stąd „T” w nazwie „TFTP”), ale owa prostota sprawdza się tylko do momentu, w którym system zyskuje samodzielność, rozpoczyna autonomiczne zarządzanie zasobami i inicjalizuje urządzenia. Wtedy usiłuje przejąć kartę sieciową i nie będzie umiał jej wykorzystać, o ile nie dostarczymy sterowników. To oczywiście słodkie, że brakuje sterowników akurat do sieciówki, ale to powszechny problem. Płyta główna owej stacji roboczej została wyprodukowana po publikacji systemu Windows 8.1 i jego obraz instalacyjny nie mógł zawierać sterowników do urządzenia z przyszłości.

Sterowniki!

Powszechność owego problemu ma swoje odzwierciedlenie w konsoli zarządzania WDSem, która oferuje oddzielny obszar do dodawania sterowników. Można za jego pomocą aktualizować zamontowane obrazy o dodatkowe sterowniki lub instruować WinPE na temat sprzętu poprzez podrzucanie mu paczek z wymaganymi sterownikami podczas procesu rozruchu przez sieć. Wygląda to następująco:

Prawda, że ładne? Tak to powinno wyglądać i tak to pamiętam. W miejscu, w którym musiałem tego użyć, ów element WDS po prostu nie działa. Nie i już. Wersja przystawki MMC jest ta sama, jest nią bowiem rewizja 16384. A więc nie tylko taka sama, jak u mnie, ale i nawet nietknięta żadną aktualizacją. A więc przystawka WDS jest na tyle prosta, że nie wymagała aktualizacji. Odpadło zatem podejrzenie, że to jakaś łatka z Windows Update postanowiła popsuć konsolę MMC na tamtym serwerze. Problem okazał się poważniejszy. Zarówno powershell (którym można zrobić wszystko), jak i dedykowane konsolowe narzędzie do WDS nie potrafiły wykonać żadnych operacji związanych z dodawaniem sterowników. Oznacza to, że instalacja roli na serwerze jest uszkodzona w niediagnozowalny sposób. Szybkie poszukiwania w Google pozwoliły natknąć się na drugiego człowieka, który otrzymywał identyczne komunikaty o błędach na swoim 2012 R2, ale powodem były ścieżki względne w poleceniu. Żadną miarą nie było to powodem u mnie. A więc recepty brak. Na szczęście narzędzia wdrażania nie są mi obce (oczywiście, gdy działają poprawnie) i znałem jeszcze jeden sposób na dodanie sterowników. Tutaj kłaniają się wspomniane zalety plików WIM.

WIM to skrót od „Windows Image”, to takie mądrzejsze ISO, które poza strukturą systemu plików wymusza strukturę samych plików, przez co Windows jest zapisany jako zbiór zależnych od siebie pakietów. Przywołuje to skojarzenia z linuksowymi pakietami RPM, ale rozwiązanie Microsoftu jest o nieco lepsze: możemy „podłączyć” (mount) taki obraz WIM do narzędzi serwisowych Windows, zwanych DISM i przeprowadzać na nim operacje takie, jak integrowanie aktualizacji, oprogramowania i sterowników. Wprowadzone zmiany możemy następnie zapakować z powrotem do pliku WIM i wykorzystać w usłudze WDS, ale nie tylko. Możemy np. zrobić płytę/pendrive’a z Windows, który będzie instalował system ze zintegrowanymi aktualizacjami i sterownikami dopasowanymi do naszego komputera. Zawsze trochę mniej roboty przy reinstalacji. Kolejną zaletą jest to, że struktura zainstalowanego systemu Windows jest zawsze powtarzalna i mniej więcej taka sama, co oznacza, że możemy podpiąć do narzędzi DISM system już zainstalowany i to w dodatku na żywo (z poziomu tego właśnie zainstalowanego systemu). Właśnie w ten sposób Windows Update instaluje aktualizacje. Jeżeli ktoś zastanawiał się dlaczego podczas instalowania łatek tak wiele zasobów zajmuje program „TrustedInstaller” to powodem jest właśnie proces integrowania aktualizacji z obrazem.

Stos Serwisowy

W zeszłym roku, gdy przygotowywałem obraz WIM systemu Windows 8.1 dla mojego starego MacBooka, okazało się, że integracja wszystkich aktualizacji psuje Sklep i wszystkie aplikacje Metro (w tym taki detal jak Panel Ustawienia!) i rozwiązaniem jest reinstalacja aktualizacji Windows 8.1 Update, która ma z 800MB. Na szczęście Windows Update sam zauważał, że system jest wybrakowany i oferował tę aktualizację, zamiast twierdzenia, że pakiet nie pasuje, albo jest już zainstalowany. Problem okazał się dobrze udokumentowany i powtarzalny, rozwiązaniem była instalacja łatki w trybie online, bowiem z nieznanych powodów integrowała się nieprawidłowo w obrazach samodzielnych. Był to zły znak na przyszłość, oznaczało to bowiem, że popsuto doskonałe narzędzia do obrazowania i niedługo DISM/WDS dołączą do powiększającego się grona renomowanego oprogramowania, które nie działa.

Wracając jednak jeszcze do mojej nieszczęsnej karty sieciowej: postanowiłem podłączyć obraz boot.wim do DISM i ręcznie dodać do niego paczkę ze sterownikami do karty sieciowej. Z jakiegoś idiotycznego powodu (nie chciało mi się podłączać folderów udostępnionych do zdalnego pulpitu ani tworzyć udziałów sieciowych na stacjach roboczych) postanowiłem dokonać tego w wierszu poleceń bezpośrednio na kontrolerze domeny z WDS, zamiast robić to grzecznie na swojej maszynie. W efekcie, obraz boot.wim był uszkodzony. Ale, ale dlaczego? Przecież użyłem DISM, zrobiłem to tak, jak piszą w dokumentacji do obsługi plików WIM, co mogło pójść nie tak? Windows nie potrafi poprawnie zrobić obrazów z Windosem? Otóż… TAK. Zaiste nie potrafi. Gdzieś w roku 2014 wydano aktualizację dla systemu Windows Server, która psuje obrazy WIM tworzone za pomocą systemowych narzędzi serwisowych DISM. Problem jest udokumentowany i znany, a winowajcą jest aktualizacja KB2919355. Jako rozwiązanie sugeruje się odinstalowanie owej aktualizacji. Po tym zabiegu DISM podobno działa poprawnie i robi prawidłowe obrazy. Podobno, bo nie mogę tego sprawdzić. System na serwerze został zainstalowany z nośnika, na którym owa aktualizacja była już zintegrowana. Jak więc obejść ten problem? Jak rozwiązać nienaprawiony błąd w najnowszym serwerowym systemie operacyjnym Microsoftu, kosztującym kilka tysięcy złotych? Należy oczywiście użyć Windows 7. Otóż wraz z erą Windows 8 i 10, Siódemka stała się nowym XP. Systemem, na którym magicznie wszystko działa, mimo, że na nowszych powinno, ale jakoś nie chce. Kompletne zaniedbanie obsługi WIM w nowych okienkach to efekt porzucenia użytkowników korporacyjnych na rzecz klientów indywidualnych. Windows 10 to system „consumer grade”, słusznie nie wzbudza skojarzeń z idealnym rozwiązaniem dla firm. To, co najbardziej mi się tutaj nie mieści w głowie to fakt, że to przecież firmy i instytucje zarabiają dla Microsoftu pieniądze. Użytkownicy indywidualni uciekają do Jabłek i Androida, a jeżeli Windows 10 (również ten mobilny) dalej będzie się „rozwijał” w tak nędznym stylu, jak obecnie, owa ucieczka jedynie przyspieszy. Tymczasem powodów do aktualizacji z Windows 7 do Windows 10 dalej brak (OneDrive’a sobie doinstaluję, brak BitLockera przeżyję).

Windows NT 6.1

Zróbmy więc obraz pod Windows 7! Następnie przygotowany boot.wim podrzucę na serwer i umieszczę w WDS. Zobaczmy więc, czy ten proces się powiedzie. Powiódł się. Podczas rozpakowywania i integrowania sterownika, pobrałem jednak w tle obraz ewaluacyjny wersji LTSB systemu Windows 10 i wyodrębniłem obraz uruchamiania właśnie z niego. Kompilacja z czerwca 2015 posiadała już wbudowany sterownik do karty sieciowej wyprodukowanej dwa lata wcześniej, więc obraz uruchomił się i wykrył sieć. Podobnie było z przygotowanym na jego podstawie obrazem przechwytywania. Moim oczom ukazał się jakże dopasowany interfejs Aero instalatora Windows 10, kontrolowanego przez WDS. Dopiero na tym etapie owo szacowne rozwiązanie jest gotowe do pracy! W ten właśnie sposób Microsoft realizuje implementację paradygmatu KISS… Trzy godziny bezsensownej szamotaniny ze sterownikiem do jednego urządzenia były więc wstępem do jakiejkolwiek konfiguracji serwera wdrażania. Tutaj również ktoś wykazał się szaleństwem. Zanim zacznę tęgo narzekać, opowiedzmy sobie, jak to „kiedyś bywało”. W chwalebnych czasach Windows XP (i usług instalacyjnych z Windows Server 2000), obrazy instalacyjne przygotowywało się poprzez „zapieczętowanie” systemu programem sysprep, do którego dołączano plik odpowiedzi w prostym formacie INI. Tak przygotowany obraz słało się na serwer… i tyle. System podczas instalacji odpowiadał na wszystkie pytania z podanego pliku odpowiedzi. Potem nadeszła dobra zmiana.

Obecnie program sysprep dalej istnieje w systemie, ale skłonienie go do zintegrowania pliku odpowiedzi jest trudniejsze. Nie jest niemożliwe, można to zrobić z wiersza poleceń. Ale nie jest to „wskazana”, „optymalna” ani przede wszystkim „właściwa” metoda. Tym razem geniusz inżynieryjny fachmanów z Microsoftu objawił się inaczej. Otóż pliki INI o przejrzystej składni zostały zastąpione plikami XML. A przecież, jak mawia nieomylny (zwłaszcza w kwestii obrażania losowych ludzi) Linus Torvalds:

XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist

Niezwykle zachęcające, czyż nie? Nie mamy już ładnie zadanych pytań przez SysPrep. Najlepszy System Operacyjny Świata oferuje nam jakieś infernalne, przerażające gałęzie znaczników, o niezapamiętywalnych nazwach i zaopatruje je w jeszcze bardziej zniechęcające menu kontekstowe. Dokumentacja jest niezwykle szczegółowa, ale żeby ją przetrawić, trzeba czasu. Zazwyczaj i tak kończy się na tutorialach z jakichś mołdawskich blogów pisanych przez niedźwiedzie, ponieważ pierwszy samodzielnie przygotowany plik odpowiedzi nie działa (nigdy). Ale to przecież jeszcze nie wszystko. Znajdujemy się dopiero na początku listy tzw. pozornie dobrych pomysłów. Niech ktoś zatrzyma karuzelę raka! Kolejnym punktem jest podział na plik odpowiedzi dla serwera i plik odpowiedzi dla samego obrazu. Skąd ten podział? Otóż właśnie z powodu owych Pozornie Dobrych Pomysłów. Pierwszy plik odpowiada na pytania systemu posłanego na stację przez sieć. Drugi – na pytania systemu, który instaluje się po rozpakowaniu na owym komputerze. System posłany przez sieć pyta o to, który obraz zainstalować i na którym dysku ma się on znaleźć. Rozpakowany obraz pyta o wszystkie te bzdury, które pojawiają się „po wyjęciu płyty”: nazwa użytkownika, nazwa komputera, hasło administratora, licencja, strefa czasowa i poziom aktualizacji. Brzmi rozsądnie, prawda? Są to przecież dwa różne systemy, więc to całkiem logiczne, że mają dwa pliki odpowiedzi dla dwóch zbiorów pytań. Niestety, to rozwiązanie jest morderczo idiotyczne i nie trzeba spędzić z nim szczególnie dużo czasu, żeby natychmiast to zauważyć.

Pliki odpowiedzi

Po pierwsze, pytanie o podział dysku następuje na poziomie sieci, a nie obrazu. Dotyczy więc wszystkich obrazów. Co z tego? Otóż wyobraźmy sobie scenariusz, w którym mamy 120 komputerów z dyskami 1TB, ale 60 innych komputerów z dyskiem 256GB… Domyślnie WDS „utnie” 3 objętości większego dysku. Można temu zaradzić poprzez oskryptowanie rozszerzenia partycji z poziomu już zainstalowanego obrazu, ale to jednak jest żenujący problem. Po drugie, pliki odpowiedzi WDS nie mają ŻADNEGO walidatora. W przeciwieństwie do Red Hata, który swoim ładnym poleceniem „cobbler validateks” sprawdza pliki odpowiedzi pod kątem poprawności, WDS pozwala na podłączenie dowolnego pliku. Pół biedy, gdyby taki plik był po prostu źle sformatowany. Prawdziwy problem leży gdzie indziej. Chodzi o to, że nic nie powstrzymuje nas przez udzieleniem dowolnej odpowiedzi na dowolne pytania na dowolnym z etapów instalacji. W praktyce oznacza to, że możemy skonfigurować użytkowników, nazwę komputera, licencję, klucz produktu i tapetę dla mini-systemu uruchamianego przez sieć oraz próbować instruować zainstalowany już system, jak ma sobie podzielić na dysk, na którym już się znajduje. I nic nie zgłosi żadnego błędu. Czy to oznacza, że nie ma żadnych logów? Ależ są! Dostęp do nich pojawia się jednak dopiero po rozpakowaniu obrazów i przejściu przez OOBE. Nie jest to wyłącznie problem natury estetycznej, zmuszający nas do „pilnowania się” przy tworzeniu plików. Zachodzi bowiem coś znacznie gorszego: jeżeli plik jest nieprawidłowy, dowiemy się o tym dopiero po godzinie.

Losowe Trudności

Powiedzmy, że źle skonfigurowaliśmy dołączanie do domeny. Podaliśmy „krótką” (WINS) zamiast „długiej” (kwalifikowanej, DNS, LDAP-owej). Żaden walidator nie sprawdzi, czy da się wysłać takie żądanie, więc beztrosko dodajemy taki plik do obrazu. Czekamy godzinę, aż 120GB obraz rozpakuje się i spróbuje przejść przez fazę OOBE, na której wywali się, nie umiejąc podłączyć do domeny. Podgląd zdarzeń na serwerze wychwyci błąd, ale po szczegóły odeśle nas na (źle skonfigurowaną) stację roboczą. Nie możemy się na nią zalogować, bo przecież nie dodała się do domeny. Musimy liczyć na to, że instalacja OOBE wywaliła się dopiero po dodaniu nowych użytkowników lokalnych (i pamiętamy do nich hasło). Wtedy możemy się zalogować lokalnie i zobaczyć logi. Jeżeli mamy szczęście. W logach dowiemy się, że nie udało się znaleźć nazwy domeny. Poprawiamy więc plik i sprawdzamy, czy działa tym razem. Ponownie czekamy godzinę… Dokumentacja wcale nie pomoże. Jest tam napisane, że mamy podać „domain”, po prostu. Bez opisania, czy jest to „fully qualified domain name”, czy nie. Takich przykładów są tuziny. Więc teraz proszę pomyśleć, co się stanie, jeżeli okaże się, że w pliku odpowiedzi jest jakiś inny błąd… Oczywiście, zapewne spotkam się z komentarzem „nie umiesz, to nie rób”. Problem z tym rozumowaniem polega na tym, że wdrażałem WDS już wcześniej, dwukrotnie, i nie miałem takich problemów. Więc albo miałem wtedy szczęście (trafiłem na poprawną składnię), albo również doszedłem do tego „the hard way”, metodą prób i błędów, tylko zapomniałem o tym, pragnąc wymazać ów proces z pamięci, dla własnej higieny psychicznej. Ponadto, liczba pytań na forach, serwisie wsparcia Microsoft, blogach i innych, zupełnie szalonych miejscach, dotyczących poprawnego ujęcia pliku odpowiedzi jest tak olbrzymia, że chyba świadczy o problemach projektowych WDS, a nie o masowym udarze mózgu tłumu administratorów ze wszystkich zakątków świata. Zresztą szczegółowość wielu przepisów-gotowców jest na tyle znamienna, że świadczy o tym, jak bardzo ich autorzy chcą ustrzec niewinnych śmiertelników przed powtarzaniem ich błędów. Liczba komentarzy pod wpisami świadczy o tym, że jest to nierówna walka.

Więcej losowych trudności

Windows Deployment Services ma takich kwiatków o wiele więcej. Bardzo fajnym jest na przykład podział na „bezpieczny” i „niebezpieczny” (może lepiej „niezabezpieczony”?) proces nienadzorowanego dołączenia do domeny. Nazewnictwo tego procesu jest kompletnie postawione na głowie. Różnica między dwoma jego trybami polega na tym, że w trybie bezpiecznym podajemy hasło dostępu, a w trybie niebezpiecznym, polegamy na losowym generowaniu poświadczeń. Kłopot w tym, że hasło dostępu jest hasłem użytkownika uprawionego do wpinania stacji do Active Directory, na poziomie administratora domeny, a jest ono przechowywane tekstem w pliku odpowiedzi. W pliku odpowiedzi dostępnym jako udział udostępniony, widoczny w sieci dla wszystkich użytkowników. Nie da się tego wyłączyć, bo wtedy WDS krzyczy, że katalogi mają nieprawidłowe uprawnienia. Prędzej czy później, ktoś znalazłby taki plik i mógł zalogować do domeny z pełnymi prawami. Dlatego należy stosować „niebezpieczny” sposób dodawania do domeny – oczywiście pod warunkiem, że działa. Gdy unikniemy błędów związanych z niepodaniem pełnej kwalifikowanej nazwy domeny, możemy rozbić się o problemy z uwierzytelnieniem stacji. Przypominam, że logi z informacją o tym pojawią się dopiero po rozpakowaniu około stugigabajtowego pliku i dopiero wtedy będzie można coś poprawiać. Chyba, że zechcemy być zbyt nowocześni: jeżeli posiadamy komputery z interfejsem UEFI, WDS nada obiektowi złe prawa, odmawiając między innymi zmiany hasła stacji, co oczywiście poskutkuje błędem uwierzytelnienia i niepowodzeniem dodania do domeny (musimy poczekać godzinę, żeby się o tym przekonać). Nie da się przeskoczyć błędu z UEFI w inny sposób, niż wyłączenie automatycznego tworzenia obiektu w AD, a więc „zatwierdzania” stacji. Wady tego rozwiązania są dość istotne: po pierwsze, tracimy kontrolę nad tym, kto w ogóle uruchamia w sieci żądania instalacji sieciowej, bo przecież zaczęliśmy pozwalać na to wszystkim; po drugie, tracimy okienko, w którym możemy (na serwerze, za pierwszym razem) podać nazwę komputera, wg. ustalonej, własnej konwencji nazewniczej. Dzięki temu zdajemy się na nazywanie komputerów wedle szablonu przez WDS i choć da się na ów szablon wpłynąć, że to na tyle mało elastycznie, że w kontenerze z komputerami robi się śmietnik i nie wiadomo dokładnie, który wpis odpowiada której stacji. Co wcześniej w ogóle nie było problemem, ponieważ były numerowane kolejno.

Why me?

Na tym etapie zacząłem się zastanawiać, jakim cudem nie napotkałem takich problemów trzy i cztery lata temu. Najwyraźniej powodem było to, że najpierw wdrażałem Windows XP, który jest i na zawsze pozostanie całkowicie bezproblemowy, a potem zastosowałem plik odpowiedzi z jawnym hasłem, który usuwałem, zanim ktokolwiek miał dostęp do sieci. Mój półświadomy zmysł unikania problemów wyprowadził mnie jednak po latach na manowce, wprawiając w błędne przekonanie, że usługa WDS nie będzie umiała mnie zaskoczyć, bo nie zrobiła tego wcześniej. Lesson learned.

Poza jawnymi, rażącymi błędami w implementacji WDS, jest jeszcze sporo zwykłych niedoróbek projektowych. Na przykład, gdy podamy odgórnie nazwę komputera, ale nie opiszemy procedury OOBE, instalator, w ładnym okienku, poprosi nas o nową nazwę komputera. Bez zaglądania do MMC na pewno podamy nazwę inną, niż ta, którą sobie wymyślił, ponieważ generuje je losowo. Gdy to zrobimy, nastąpi rozbieżność w atrybutach obiektu między fizycznym komputerem, a jego manifestacją w Active Directory, złączonymi wspólnym identyfikatorem GUID. Nie wspominając o tym, że podanie nazwy „z palca” niekoniecznie jest instalacją nienadzorowaną…

MDT?

Być może odezwie się tutaj kilka osób, które miały wcześniej do czynienia z WDS i odpowiedzą mi, obrażając przy tym niewybrednie, że powinienem był użyć MDT albo najlepiej to już w ogóle System Center. Być może – ale nie są to argumenty w pełni słuszne. Po pierwsze, SCCM jest oddzielnym produktem. Wymaga zdobycia, instalacji i konfiguracji. Ponadto, niezależnie od tego, jak bardzo SCCM pomaga, jego skuteczność nie sprawia, że upośledzenie WDS nagle staje się uzasadnione. Wadliwy produkt nie staje się mniej wadliwy przez to, że da się ominąć jego wady innym rozwiązaniem, nawet, jeżeli okazuje się ono „niezbędne” w świetle cyrków odstawianych przez WDS. Jeżeli zaś chodzi o MDT, to prawdopodobnie tak właśnie się skończy przygoda z WDS, ale zapewne zabawa z MDT objętościowo będzie nadawać się na czwartą część moich zmagań. Pamiętajmy też, że MDT jest w większości „nakładką” na WDS i jedynie częściowo uzupełnia go o własne rozwiązania. Prawdopodobnie serwuje szereg nowych problemów, o ile w ogóle rozwiązuje poprzednie. Zresztą chciałem zainstalować MDT jeszcze podczas tych zmagań, ale przez dwa dni nie działało Centrum Pobierania Microsoft, a odnośniki z DreamSparka również prowadziły właśnie tam. „Gateway timeout” prześladował mnie w pracy i w domu, więc po prostu miałem idealne wyczucie czasu i zwyczajowa dozę szczęścia.

Podobno MDT działa. Nie wiem, bo nigdy go nie potrzebowałem – stosowane rozwiązanie samoistnie przestało działać z biegiem lat. Przechowywanie haseł do domeny jawnym tekstem najwyraźniej też poprawnie dodaje komputery do domeny. Jedynie dedykowane narzędzie, będące integralną częścią kontrolera domeny, ma jakieś nieakceptowalne jeszcze w ubiegłej dekadzie problemy. Udało mi się je rozwiązać, wdrożenia działają, ale musiałem na to poświęcić cały dzień. Ale ciekawe, czy ktoś zgadnie, co trzeba było wyłączyć...