Wdrożenie systemu Windows w wirtualnym świecie

Autor: Wes Miller

Opublikowano: 26 września 2008

Zawartość strony

	Wirtualne wdrożenie
	Wykorzystanie narzędzia Sysprep
	Sterowniki i warstwy abstrakcji sprzętu
	Różne zmiany
	Optymalizacja
	Obawy dotyczące hosta
	Inne mechanizmy rozmieszczania
	Migracja
	Zmień to co zmienić możesz i zaakceptuj to, czego zmienić nie zdołasz
	Adresy w sieci Internet związane z narzędziem Sysprep

Wirtualizacja zasobów informatycznych jest wszechobecna. Wszyscy, którzy jeszcze z niej nie korzystają, powinni zacząć. Wirtualizacja redukuje zależności sprzętowe, tworząc w zasadzie własną warstwę abstrakcji sprzętu i umożliwiając przenoszenie jednego lub więcej systemów gościnnych, takich Windows Server czy klienckie systemy operacyjne Windows, między systemami hosta. Wirtualizacja różni się rzecz jasna od emulacji pod tym względem, iż nie imituje procesora gościa. Po prostu reprezentuje zasoby systemu hosta w taki sposób, że gościnne systemy mogą uzyskać do nich dostęp. Domyślnie systemy hosta są jednakowe dla systemów gościnnych. Zasadniczo możemy przenieść wirtualny system gościnny z systemu zbudowanego przez jednego producenta OEM do innego systemu zbudowanego przez innego producenta OEM, sprzęt hosta zwykle nie gra żadnej roli. Jednak istnieją pewne ograniczenia. Na przykład w przypadku przeniesienia systemu gościnnego ze sprzętu z procesorem jednego producenta, takiego jak AMD, do innego, takiego jak Intel, mogą pojawić się problemy (w zależności od wykorzystywanej technologii wirtualizacji). Wynika to z faktu, iż technologia przetwarzania wirtualnego przekazuje jedynie informacje z hosta do systemu gościnnego i z powrotem. Nie emuluje szczególnego procesora na potrzeby systemu gościnnego (jak na przykład program Microsoft® Virtual PC uruchomiony w systemie Macintosh bazującym na procesorze PowerPC).

Jednak wirtualizacja emuluje na potrzeby systemu gościnnego kluczowe składniki sprzętowe. Najczęściej mechanizm ten obejmuje jedynie sieć, video (zazwyczaj bardzo ograniczone urządzenie bez emulowania zaawansowanej grafiki GPU) i pamięć masową. Wszystkie te składniki funkcjonują w ten sposób, iż prezentują jeden lub więcej typów emulowanych programowo urządzeń dla systemu gościnnego. Czytelnicy, którzy od jakiegoś czasu czytają tę serię artykułów, zauważą zapewne, że jest to ta sama lista urządzeń, którymi zajmuje się system Windows® PE. W aspekcie wirtualizacji są to te same typy urządzeń, które trzeba posiadać, aby system Windows mógł realizować określone zadania. Ponadto wszystkie technologie wirtualizacji muszą emulować BIOS. Chociaż mogą także emulować interfejs EFI (Extensible Firmware Interface), jednak ograniczona liczba systemów operacyjnych wspierających EFI wskazuje na wąskie zastosowanie tego interfejsu. Emulacja umożliwia uruchamianie wirtualnych systemów gościnnych. BIOS oraz każde z urządzeń emuluje rzeczywiste urządzenie w oprogramowaniu i prezentuje to urządzenie dla systemów gościnnych. To oznacza, że niezbędne są te same sterowniki (nie zawsze dostarczane przez system Windows), których wymagałyby prawdziwe urządzenia. Jest to aspekt, który warto mieć na uwadze.

Choć pewne technologie wirtualizacji pozwalają również na nawiązywanie połączenia z urządzeniami USB (lub USB 2.0), niniejszy artykuł nie zawiera szczegółowego omówienia tych technologii. Poza tymi urządzeniami USB, które wymagają albo sterowników (drukarek, bezprzewodowych kart sieciowych USB NIC itd.) lub określonego wsparcia DirectX® (niedostępnego w większości technologii wirtualizacji), zwykle przygotowanie ich do działania nie wymaga wielkiego nakładu pracy. Należy pamiętać, że wsparcie dla USB lub innych nieemulowanych urządzeń zależy rzecz jasna od zastosowanej technologii wirtualizacji. Trzeba znać ograniczenia (ang. sharp edges, jak nazywa je autor artykułu) wykorzystywanego produktu wirtualizacji, zanim próbuje się zintegrować go z nowymi urządzeniami.

Obecnie istnieją dwaj główni dostawcy technologii wirtualizacji dla systemu Windows: Microsoft oraz VMware (vmware.com). Pojawili się również dodatkowi, dobrze zapowiadający się producenci, tacy jak Parallels (parallels.com).

Po przedstawieniu ogólnej koncepcji, autor tego artykułu poświeci pozostałą jego część na wyjaśnienie, w jaki sposób można skonfigurować wirtualizację, jak uniknąć najczęstszych pułapek oraz jak wdrożyć ją na wielu maszynach w danym środowisku.

Wirtualne wdrożenie

Wdrożenie systemów wirtualnych nie musi różnić się od wdrażania systemów fizycznych. Ale jak zobaczymy, istnieją dobre argumenty przemawiające za ich rozróżnieniem.

We wczesnym dniach istnienia systemu Windows NT® trzeba było dokonywać instalacji przy pomocy programu instalacyjnego. Można było stworzyć odpowiedni skrypt, ale i tak trzeba było przejść przez cały proces. Po zakończeniu działania programu instalacyjnego, funkcja kopiowania wybranego obrazu do wielu systemów, która stanowiłoby dość przydatną koncepcję, po prostu nie była wspierana.

W końcu firma Microsoft zdecydowała, że sensownie byłoby wspierać posiadające zduplikowany dysk lub "sklonowane" systemy Windows NT. A zatem obecnie każda metoda dostępna podczas wdrażania systemu fizycznego, jest również dostępna w ramach wdrażania systemu wirtualnego. Można użyć technologii: Winnt32 (lub setup.exe w przypadku Windows Vista® oraz Windows Server® 2008), Windows PE (1.x lub 2.x w zależności od wdrażanego systemu klienckiego, co zostało objaśnione w poprzednich artykułach z tej serii), Remote Installation Services (RIS) lub Windows Deployment Services (WDS) bądź Sysprep (narzędzie System Preparation do wdrażania wprowadzone wraz z Windows NT 4.0) bądź też swojej ulubionej technologii duplikowania dysku (na przykład ImageX).

Oczywiście jest to konieczne tylko wtedy, gdy określony system operacyjnych jest wdrażany po raz pierwszy. Później wystarczy po prostu go skopiować. Jednak istnieje pewien problem dotyczący metod duplikacji bazujących na dysku, takich jak przed chwilą wspomniane.

 Do początku strony

Wykorzystanie narzędzia Sysprep

Pierwotna decyzja firmy Microsoft o niewspieraniu duplikacji dysku wynikała głównie z problemów z identyfikatorem Windows NT Security Identifier (SID). Na szczęście z pomocą przyszło narzędzie Sysprep. Jednak najpierw przyjrzyjmy się samemu problemowi. Jak wspomniano w artykule support.microsoft.com/kb/314828, identyfikator SID składa się z numeru wersji struktury SID (zazwyczaj identyfikatora GUID, Globally Unique Identifier), który identyfikuje konkretny komputer z systemem Windows. Ten identyfikator jest następnie wykorzystywany do jako główna część identyfikatora wszystkich kont lokalnych. Konta lokalne posiadają swoje własne unikalne identyfikatory, nazywane identyfikatorami względnymi (RID). Identyfikator RID składa się z identyfikatora konta podłączonego na końcu identyfikatora SID. A zatem połączenie tych dwóch identyfikatorów służy do identyfikacji lokalnego konta.

Spójrzmy, na czym polega problem, na przykładzie identyfikatora SID Administratora S-1-5-21-191058668-193157475-1542849698-500. W tym przykładzie S-1-5 to deskryptor, który wskazuje, że jest to identyfikator SID: litera S jest wszechobecna w tekstowych reprezentacjach SID) natomiast cyfry 1 oraz 5 reprezentują odpowiednio numer wersji identyfikatora SID systemu Windows NT oraz wartość identyfikatora organizacji (w tym przypadku Windows Security). Reszta ciągu to właściwy identyfikator SID zawierający liczbę 500, która wskazuje, że jest to dobrze znany identyfikator SID konta Administratora systemu Windows. Konto Administratora, które jest tworzone domyślnie (bez możliwości usunięcia) na wszystkich instalacjach systemu Windows, posiada SID kończący się liczbą 500. Lokalne konta użytkowników dodawane do systemu Windows po instalacji rozpoczynają iterację od 1000 wzwyż.

Narzędzie PSGetSID, udostępnione w zestawie Windows Sysinternals (wspomnianym już w tej serii w artykule dotyczącym PSTools o adresie technetmagazine.com/issues/2007/03/DesktopFiles), pozwala na sprawdzenie identyfikatora SID dla danego użytkownika systemowego lub dla systemu. Rysunek 1 prezentuje dane wyjściowe narzędzia PSGetSID dla identyfikatora SID systemu wirtualnego oraz identyfikator SID dla konta użytkownika 1003.

Rysunek 1: Dane wyjściowe narzędzia PSGetSID dla identyfikatora SID wirtualnego systemu oraz identyfikator SID konta użytkownika 1003.

Ponieważ identyfikatory RID lokalnego konta bazują na identyfikatorze SID, w przypadku duplikowania dysku systemu lub kopiowania obrazu maszyny wirtualnej pojawia się dość oczywisty problem. Nieprzeprowadzenie zmiany identyfikatora SID (główne, ale nie jedyne zadanie narzędzia Sysprep) powoduje powstanie kopii kluczowego elementu, który czyni system Windows unikalnym. Gdyby System A oraz System B posiadały ten sam identyfikator SID Administratora, użytkownicy w każdym z tych systemów identyfikowaliby się jako ten sam użytkownik. To samo odnosiłoby się do wszystkich lokalnych kont z Systemu B podczas uwierzytelniania w Systemie A i na odwrót. A co gorsza, systemy te miałyby te same identyfikatory SID w usłudze Active Directory®. A zatem gdybyśmy zezwolili Systemowi A na uwierzytelnianie się w zasobie domenowym, ale nie zezwolilibyśmy na to Systemowi B, powstałaby kolizja. Natomiast gdybyśmy ustawili odmowę dla Systemu B, w efekcie system A też zostałby objęty odmową.

A zatem niezbędne jest ponowne wygenerowanie identyfikatorów SID w systemach przy użyciu narzędzia Sysprep. W szczególności w scenariuszach systemu wirtualnego, ponieważ propagacja obrazów systemu jest bardzo łatwa. Nie należy wykorzystywać żadnych zewnętrznych narzędzi do modyfikowania identyfikatora SID, wyłącznie Sysprep. Narzędzie Sysprep stanowi zaprojektowaną, przetestowaną i wspieraną przez firmę Microsoft technologię przygotowywania systemów do duplikacji (nawet systemów wirtualnych). Rysunek 2 prezentuje przykładowy widok narzędzia Sysprep przed zmodyfikowaniem identyfikatora SID w systemie. W przypadku przygotowywania systemu do duplikacji należy zawsze odznaczać opcję "Don't regenerate security identifiers".

Rysunek 2: Opcja " Don't regenerate security identifiers " powinna być odznaczona w przypadku przygotowania do duplikacji.

Poza nadaniem nowego identyfikatora narzędzie Sysprep modyfikuje również ogólnie znane prywatne magazyny danych tak, aby odzwierciedlić identyfikator SID oraz nazwę maszyny lub aby przygotować ich szyfrowanie do pracy z nowym identyfikatorem SID. Przykładowe obsługiwane magazyny to magazyn danych Scheduled Tasks oraz wartości w IIS Metabase (jeśli zainstalowane są usługi IIS).

Ponadto narzędzie Sysprep wymusza usunięcie wszystkich kart NIC w systemie oraz likwiduje wraz z nimi dane konfiguracji sieciowej dla kart NIC. Ponieważ konfiguracja sieciowa jest powiązana z definicją karty NIC w rejestrze, a relacja tej karty NIC bazuje na identyfikatorze sprzętu dla karty NIC (która podczas przenoszenia systemu wirtualny-do-wirtualnego często ulega uszkodzeniu), Sysprep oczyszcza te zwykle porzucane dane.

Sysprep usuwa również z systemu wszystkie informacje o członkowstwach Active Directory. W efekcie w ramach swojej pracy musi wymusić usunięcie systemu z domeny. Dzięki temu systemy, które właśnie otrzymały nowe identyfikatory SID, mogą zostać bezpiecznie dołączone do domeny. Niektóre narzędzia modyfikujące identyfikatory SID pozwalają na zmianę SID maszyny bez usuwania jej z domeny, ale nie jest to ani rzetelne ani bezpieczne. Jeśli absolutnie musimy uruchomić Sysprep na maszynie, która jest członkiem domeny, powinniśmy usunąć ją z domeny przed uruchomieniem narzędzia Sysprep lub uruchomić narzędzie Sysprep i pozwolić mu wykonać to zadanie.

W związku z tym, jeśli wirtualizujemy jakiekolwiek kontrolery domeny (DC), musimy zduplikować systemy, które są po prostu autonomicznymi serwerami i nie zostały promowane do kontrolerów domen oraz nie są dołączone do domeny. Nie możemy bezpiecznie duplikować dysku kontrolera domeny, za wyjątkiem systemu Windows Server 2003 Small Business Server Edition. Aby bezpiecznie tworzyć nowe kontrolery domeny, należy stworzyć obraz dysku serwera, który jest gotowy do dołączenia do domeny i promowania do kontrolera domeny. Narzędzie Sysprep nie potrafi bezpiecznie modyfikować identyfikatorów SID na kontrolerach domeny (za wyjątkiem bardzo specjalistycznej instancji SBS jeden las/jeden serwer).

Poza zmianą identyfikatora SID i usunięciem maszyny z domeny narzędzie Sysprep modyfikuje również nazwę maszyny.

Być może zabrzmi to zbyt stanowczo, ale tworząc obrazy systemów wirtualnych (lub choć tworząc ich kopie), musimy zrealizować wszystkie powyższe zadania. Jest to bardzo ważne, w szczególności gdy wykorzystujemy te systemy w sieci z innymi fizycznymi lub wirtualnymi systemami, w domenie lub wraz z inną ich kopią w sieci.

Jeśli nie zastosujemy narzędzia Sysprep podczas duplikowania systemów wirtualnych, prawie na pewno napotkamy wiele oczywistych problemów (konflikty Active Directory lub inne sieciowe kolizje) oraz kilka innych problemów, których możemy się nie spodziewać. Na przykład obrazy wirtualne będą bardzo podatne na ataki, ponieważ włamanie na jeden z nich pozwoli na uzyskanie dostępu do pozostałych.

 Do początku strony

Sterowniki i warstwy abstrakcji sprzętu

Jak wspomniano, wirtualne sterowniki dołączone do wirtualnego obrazu mogą nie zawierać wszystkich wymaganych sterowników dla systemu Windows odgrywającego rolę hosta. Podczas wdrażania (lub wdrażania obrazów dysków przy użyciu Sysprep) powinniśmy upewnić się, że dysponujemy sterownikami dla urządzeń, ponieważ przerażający błąd sterownika 0x0000007B może pojawić się równie dobrze podczas przenoszenia wirtualnego obrazu z jednego sterownika magistrali magazynowania na inny, jak i podczas pracy ze sprzętem fizycznym. To samo odnosi się do kart sieciowych NIC. Chociaż większość produktów do wirtualizacji dąży do zapewnienia wirtualnego urządzenia, które jest dość uniwersalne, nadal może pojawić się potrzeba zastosowania dodatkowego sterownika.

Nie możemy również ignorować tej irytującej warstwy abstrakcji sprzętu (HAL). O ile to możliwe, chcielibyśmy tworzyć wieloprocesorowe maszyny wirtualne z wsparciem dla zaawansowanego interfejsu konfiguracji i zasilania (ACPI) (patrz intel.com/technology/iapc/acpi), jeśli wybrana technologia wirtualizacji zapewnia odpowiednie wsparcie. Konwertowanie między warstwami HAL generalnie nie jest wspierane (więcej szczegółowych informacji zawiera artykuł support.microsoft.com/kb/309283). Wprawdzie pewne technologie wirtualizacji lub co ważniejsze wiele technologii migracji deklaruje, że potrafi bezpiecznie przenosić instalacje Windows bez wsparcia dla ACPI na instalacje z wsparciem dla ACPI bądź na odwrót. Jednak nie jest to prawdą, a wynikowe instalacje systemu Windows nie będą wspierane przez firmę Microsoft w przypadku napotkania problemów. Te same ograniczenia zaprezentowane na wspomnianej stronie sieci Web dotyczą także systemów zwirtualizowanych. Rysunek 3 prezentuje przykładowy widok warstwy HAL w Menedżerze Urządzeń (Device Manager) na jednej z maszyn wirtualnych autora. W tym przypadku działa ona przy użyciu jednoprocesorowej warstwy HAL z wsparciem dla ACPI. Nie należy mylić jej jednak z pojedynczym procesorem, może być ona podmieniana przez jej wieloprocesorowych krewniaków.

Rysunek 3: HAL w Menedżerze Urządzeń na maszynie wirtualnej.

 Do początku strony

Różne zmiany

Poza modyfikacją SID oraz nazwy maszyny należy również zmienić pewne wartości, które mogą być charakterystyczne dla wykorzystywanej technologii wirtualizacji. W szczególności należy zmienić adres MAC (unikalny identyfikator urządzeń sieciowych). Co więcej, wiele aplikacji wirtualnych również posiada swój własny unikalny identyfikator. Większość z nich przechowuje je we własnych plikach konfiguracji maszyny, a zatem warto znać sposób manipulowania tymi wpisami (przy zachowaniu ich poprawności). Wiele produktów wirtualizacji z wsparciem dla technologii PXE konfiguruje wartość SMBIOS UUID w oparciu o własny unikalny identyfikator. Jeśli maszyna ma zostać dołączona do domeny, należy podkreślić konieczność modyfikacji tego identyfikatora (lub umożliwić dokonanie zmiany oprogramowaniu wirtualizacyjnemu, o ile wspiera ono taką funkcję). W przeciwnym przypadku zarządzanie systemami WDS lub RIS może stać się niemożliwe (może dojść do konfliktu identyfikatorów GUID). Większość znanych autorowi tego artykułu rozwiązań wirtualizacyjnych miała poważne problemy z siecią w przypadku zduplikowanego adresu MAC. A zatem, o ile sytuacja nie dotyczy jedynie przeniesienia maszyny wirtualnej, bardzo ważne jest zmodyfikowanie adresu MAC, jeśli oprogramowanie wirtualizacyjne samo tego nie zrobiło.

Inne komponenty, o których należy pamiętać podczas przygotowywania systemu wirtualnego do rozmieszczenia, są wszelkie mapowane dyski lub migawki. W zależności od rozwiązania wirtualizacyjnego mogą być one różnie nazywane, często spotykanym określeniem jest termin dysk różnicowy. Jeśli uruchamiamy narzędzie Sysprep w celu przygotowania systemu i posiadamy migawkę (lub inny stan odwracalny), która towarzyszy systemowi wirtualnemu, musi ona zostać zniszczona, aby obraz pozostał bezpieczny i niezawodny po zduplikowaniu. W przypadku migawki lub innej technologii "wycofywania zmian dysku", przywrócenie migawki mogłoby oznaczać powrót do stanu, w którym zachodzą konflikty między systemem stworzonym na podstawie oryginalnej maszyny wirtualnej a innym systemem (a nawet oryginalnym systemem źródłowym, jeśli został on przywrócony z powrotem). A zatem wszelkie migawki i relacje dysków różnicowych powinny być wykonane za pośrednictwem narzędzia Sysprep.

 Do początku strony

Optymalizacja

Większość technologii wirtualizacji zawiera dodatki lub narzędzia maszyny wirtualnej, które pomagają w ulepszeniu wydajności i jakości interakcji z systemem gościnnym z poziomu hosta. Zaliczają się do nich zwykle zadania optymalizacji wejść z myszki i klawiatury oraz inne ulepszenia wydajności, a często także poprawiona interakcja kopiowania i wklejania lub inne interakcje między hostem a systemem gościnnym. Przed wdrożeniem należy zainstalować najnowsze wersje tych narzędzi w systemach wirtualnych.

Należy również upewnić się, że pamięć maszyny klienckiej jest skonfigurowana w sposób optymalny z punktu widzenia gościnnego systemu operacyjnego, ale również w kontekście hosta, na którym zostanie on umieszczony. Najgorszą rzeczą, jaka może się nam przydarzyć, to umieszczenie obrazu systemu Windows XP z konfiguracją zużycia 1GB pamięci RAM w systemie hosta, który w ogóle nie dysponuje taką ilością pamięci RAM.

Należy także pamiętać o ograniczeniach, które posiada obecnie większość technologii wirtualnych. A zatem ważne jest, aby użytkownicy wiedzieli w jaki sposób podejmować interakcję z urządzeniami peryferyjnymi podłączonymi do systemów wirtualnych, a także jakie aplikacje będą, a jakie nie będą działały na gościnnym systemie operacyjnym (większość z nich nie wspiera na przykład DirectX 9 lub 10 bądź wspiera starsze wersje jedynie w ograniczonym stopniu). Użytkownicy mogą nie wiedzieć, co to oznacza i w jaki sposób się przejawia (pewne aplikacje niezbyt dobrze radzą sobie z obsługą takich konfiguracji).

 Do początku strony

Obawy dotyczące hosta

Generalnie nie musimy poświęcać zbyt wiele uwagi komputerowi hosta, na którym uruchomiona jest technologia wirtualizacji. Niezależnie od tego, czy pod spodem działa pełny system operacyjny lub Hypervisor typu pierwszego operujący bezpośrednio na sprzęcie. Większość technologii wirtualizacji została zaprojektowana tak, aby gościnny system operacyjny nie musiał wiedzieć o hoście nic lub prawie nic. Jednak warto abyśmy wiedzieli, jakie hosty są wykorzystywane, na wypadek napotkania problemów po przeniesieniu systemu gościnnego z jednego hosta na inny. Ponadto powinniśmy wiedzieć, jakie są ograniczenia produktu do wirtualizacji wybranego producenta dotyczące określonych platform. Nawet jeśli możliwe jest przejście z jednego systemu na inny, może ono wiązać się z utratą lub zyskaniem wybranych funkcji Hypervisor typu drugiego systemów operacyjnych hosta (aplikacji wirtualizacji).

 Do początku strony

Inne mechanizmy rozmieszczania

Zastosowanie narzędzia Sysprep lub duplikacji dysku (lub po prostu uruchomienie Sysprep i skopiowanie maszyny wirtualnej) to oczywiste metody wdrożenia systemów wirtualnych, ale istnieją również inne. W rzeczywistości niezależnie od tego, czy wykorzystywane są obrazy czy program instalacyjny, zastosowanie systemu Windows PE może być łatwiejsze w przypadku wirtualizacji niż w przypadku maszyn fizycznych, ponieważ wykorzystywane są pliki ISO zamiast fizycznych nośników CD. Pewne technologie wirtualizacji niezbyt dobrze radzą sobie z nośnikami DVD, dlatego trzeba sprawdzić, czy określony dostawca wirtualizacji zapewnia odpowiednie wsparcie. Można użyć programu winnt32 lub setup.exe (w przypadku systemu Windows Vista lub Windows Server 2008), ale nie przynosi to żadnych szczególnych korzyści. W przypadku zastosowania innych technologii wdrażania systemu Microsoft, takich jak Automated Deployment Services, technologia wirtualizacji wspiera PXE, umożliwiając szybkie przeprowadzenie wdrożenia poprzez sieć, jak w sytuacji posługiwania się usługami RIS lub WDS.

 Do początku strony

Migracja

Poza właściwą migracją całego komputera, nie należy także zapominać o narzędziu migracji stanu użytkownika (USMT). Narzędzie USMT ułatwia przenoszenie ustawień użytkownika z klienta fizycznego do nowego systemu wirtualnego. A zatem jeśli użytkownicy chcą przenieść swoje stare dane i ustawienia na nową maszynę wirtualną, można na przykład w prosty sposób pobrać pliki i ustawienia z systemu Windows XP, przechować je w UNC, a następnie umieścić na nowej maszynie wirtualnej.

 Do początku strony

Zmień to co zmienić możesz i zaakceptuj to, czego zmienić nie zdołasz

Rozważając migrację maszyny fizycznej na wirtualną lub na odwrót, należy pamiętać o kwestiach, które można i których nie można zmienić. Można zmienić następujące aspekty instalacji systemu Windows:

• Warstwa HAL (ale jedynie z systemu jednoprocesorowego do wieloprocesorowego lub na odwrót, dopóki bazują one na tej samej konfiguracji zasilania).

• Kontrolery magazynowania masowego (nie jest to łatwe, ale większość rozwiązań do migracji maszyny fizycznej na wirtualną usiłuje zrobić to samodzielnie). Warto wiedzieć, iż większość producentów dostarcza rozwiązania magazynowania IDE oraz SCSI. Należy z rozwagą dokonywać wyboru w fazie rozmieszczania, ponieważ przechodzenie z jednego standardu na drugi nie jest zbyt łatwe. Zasadniczo wybranie SCSI owocuje większą niezawodnością urządzenia (dotyczy to implementacji emulacji urządzeń SCSI większości producentów).

• Kontroler sieci (chociaż w scenariuszu migracji maszyny wirtualnej na wirtualną będzie on taki sam w obrębie technologii jednego dostawcy).

Nie można zmienić następujących aspektów instalacji systemu Windows:

• Warstwa HAL (poza wspomnianym wcześniej przypadkiem, gdy wykorzystywana jest ta sama konfiguracja zasilania). Nie należy zakładać, że wybrane rozwiązanie do migracji stworzy stabilną i niezawodną instalację systemu Windows (a co ważniejsze, nie będzie ona wspierana przez firmę Microsoft).

 Do początku strony

Adresy w sieci Internet związane z narzędziem Sysprep

Następujące dokumenty zawierają wiele pomocnych informacji dotyczących narzędzia Sysprep:

• Designing Image-Based Installations with Sysprep

• How to Use the Sysprep Tool to Automate Successful Deployment of Windows XP

• How to Use the System Preparation Tool (Sysprep.exe) to Perform Disk Duplication

• Using the System Preparation Tool on Dissimilar Computers

O autorze

Wes Miller mieszka w Austin w Teksasie. Poprzednio pracował w firmie Winternals Software w Austin oraz w firmie Microsoft jako Program Manager oraz Product Manager do spraw systemu Windows. Można skontaktować się z nim przy pomocy adresu technet@getwired.com.

Do początku strony