SID a klonowanie.

Zapewne Ci z was, którzy aktywnie używają DRBL’a w swojej pracy mieli juz okazję wykorzystać pakiet DRBL-Winroll. Ci z Was, którzy realizowali już rollouty, masowe migracje czy deploymentu, wiedzą też o konieczności zmiany SID’a maszyn – często wykorzystując narzędzie Marka Russinovicha ‚NewSID‚

No właśnie – czy zmiana SID‚a jest konieczna? Dużo się bowiem zmieniło od czasu Windows 98 😉
Pod koniec roku 2009, Mark Russinovich, twórca (między innymi) świetnego narzędzia NewSid,  opublikował wpis na swoim blogu: http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx w którym dosyć autorytatywnie rozprawia się z mitem ‚konieczności zmiany SID‚a’ w klonowanych systemach.

Podsumowując artykuł – dla tych, którzy klonują stacje robocze oparte na systemach Windows, zabawa w zmianę SID przyda się tylko i wyłącznie gdy … stawiacie kontrolery domen Active Directory 😉 Pozostali mogą spać spokojnie, sytuacja gdy maszyny z tym samym SID’em zbuntują się i zaczną dzielić się tajnymi plikami jest praktycznie niemożliwa 😉

Dla tych którzy chcą jednak i te rzeczy w swojej sieci miec pod kontrolą pozostają minimum 3 rozwiązania.

1. Użyj Microsoftowego programu SysPREP.

Zaletą tego rozwiązania jest dosyć dokładne przygotowanie unikalnego systemu dla identycznych stacji roboczych, jak również szybkość i prostota działania.
Wadą jednak pozostaje konieczność ponownej ręcznej rejestracji/aktywacji systemu, z jego nużącym wpisywaniem klucza oraz przechodzenie przez etap ‚wykrywam/wykrywam/wykrywam/chyba instaluję’.

O ile w przypadku instalacji wersji OEM’owych – wydaje się to być jedynie słuszną drogą (jak również przygotowywanie wersji dla klienta końcowego do samodzielnej rejestracji), o tyle w przypadku korzystania z licencji typu MOLP/Select/VLK dokładanie roboty jest zupełnie niepotrzebne.

2. Użyj narzędzia NewSID
Chociaż narzędzie to zostało wycofane pod koniec 2009 roku z witryny SysInternals, wciąż jeszcze można je znaleźć na dzisiątkach stron z przydatnymi programami.
Zaletą tego pakietu jest doskonała zgodność z przeszłymi wersjami systemów oraz prostota działania.

Z racji wycofania wsparcia dla tego narzędzia, niewiadomym jest jak będzie się ono zachowywac po wydaniu kolejnych poprawek do systemów Vista/Windows 7, jak i przyszłych edycji Windowsowej familii. W niektórych przypadkach problemy sprawiać moga próby wykorzystania tego narzędzia w zautomatyzowanej formie – na przykład wygenerowaniu nowych nazw dla hosta opartych o przewidywalny schemat.

3. Uzyj narzędzia DRBL-Winroll
Zaletą narzędzia jest jego wszechstronność – nie tylko możemy zmienić SID (nazwę) stacji roboczej, ale również jego przyszłe ustawienia sieciowe, nazwę grupy roboczej i dostępność usługi sshd.

Wadą rozwiązanie jest: konieczność przygotowywania domyślnych konfigów na określonej grupy maszyn (np. kojarzenie IP/grupy roboczej z MAC okreslonych stacji roboczych) i automatyczna instalacja pakietu CygWin. W przypadku chęci kozrystania z setupów automatycznych z serwera DRBL niezbędne jest skonfigurowanie kluczy ssh.

Dla tych którzy szukają wciąż NewSID’a – link: TU

DRBL – mechanizm klonowania.

Wspominałem wcześniej o jednej z podstawowych funkcjonalności serwerów DRBL – mechaniźmie klonowania stacji roboczych z wykorzystaniem wspólnej pracy Clonezilli i PXE. W skrócie – serwer DRBL zapewnia nam możliwość startu źródłowej stacji roboczej za pomocą PXE, Clonezilla wraz z pakietami towarzyszącymi klonuje zawartość dysków stacji roboczych do plików. Pliki mogą być zapisywane (używając kilku wskazanych metod kompresji) za pomocą SMB/FTP/SSH/NFS lub na lokalnych dyskach. Wspierane filesystemy to min:

• ext2,
• ext3,
• reiserfs,
• xfs,
• Jfs
• FAT16/32,
• NTFS 3 i 5(streams),
• HFS+
• Praca blokowa (block-by-block, sector-by-sector)

Idea ta pozwala na wykonanie jednoczesnych operacji na dowolnej ilości stacji roboczych – co więcej, w zależności od ilości danych i szybkości sieci, samo odtwarzanie/zapisywanie trwa od kilkunastu sekund, do kilkunastu minut.
Wyobrażcie sobie następujące zastosowanie: organizacja, w której wystepuje kilka modeli stacji roboczych. Każda z nich może spełniać inną rolę – od stacji użytkownika wprowadzającego dane po stacje księgujące, graficzne, administracyjne, techniczne – wszystko zależy od zastosowanego profilu oprogramowania lub ustawień systemowych.
Przy każdej awarii lub standaryzacji czeka nas nie lada wyzwanie:

– instalacja OS (często aktywacja ponowna – a więc wyjaśnianie dlaczego właściwie aktywuje się ta kopię po raz kolejny)
– instalacja wszystkich możliwych poprawek, service packów, Support Packów danego producenta itp.
– instalacja niezbędnego oprogramowania
– konfiguracja pod użytkownika

Każdy pracownik działu IT doskonale zna ten schemat. Aby ułatwić sobie życie: wykorzystując DRBL, na jednej ze wskazanych maszyn tworzymy instalację wzorcową (np. OS+poprawki+w miarę stałe ustawienia), resztę doinstalowując za pomocą skryptu z wykorzystaniem wolumenów sieciowych.

Z małą ilością użytkowników (stacje profilowane pod konkretnych userów a nie role) możemy pójśc o krok dalej – przygotowujemy pełny obraz: OS+poprawki+aplikacje+ustawienia charakterystyczne. Czas kompresji i rozmiar pliku wynikowego zależą ściśle od ilościu materiału do kompresji oraz maszyny na jakiej to wykonujemy.

Na szczęście sama dekompresja jest błyskawiczna – mam przygotowane obrazy pod różnych klientów w różnych instytucjach – przeciętny czas odtworzenia stacji roboczej po awarii to około 6 minut (obraz), 2-3 minuty na restart maszyny i dalsza konfiguracja za pomocą skryptu sieciowego – kolejne 3 minuty.

Idąc dalej tym sposobem – o ile jest taka potrzeba, za pomocą mechanizmu WoL możemy zaplanować wykonywanie kopii wskazanych maszyn np. co weekend.

Jak widać w czasie poniżej 15 minut można mieć pełne Disaster Recovery 😉

Co z serwerami zapytacie?
Rewelacyjnie. Wiemy bowiem, iż bez pełnego DR, w środowiskach które nie pracują jako HA – przeważnie posiadając jedną/dwie nie zwirtualizowane maszyny spełniające swoją rolę – metoda ta sprawdza się bardzo dobrze.
Zarówno w środowisku serwerów HP/DELL/IBM oraz innych firm trzecich, przy znikomym nakładzie środków i pracy możemy spokojnie wykonywać kopie OS umieszczane na dyskach macierzowych (SmartArray w HP, ServeRaid w IBM i PERC-H w Dell’u).
Minimalistyczny DR w tego typu maszynach obejmuje:
– konfigurację RAID HW
– odtworzenie OS za pomocą DRBL
– odtworzenie danych dla aplikacji/systemu z backupu.

Dla przykładu: DR zaprojektowany przeze mnie dla 200 maszyn HP DL 380 G4/G5, z Windows 2003, trzema różnymi wolumenami logicznymi (recovery OS), zajmujący około 20GB, odtwarzał się w około 8-9 minut (sieć 1Gb). Synchronizacja partycji z danymi – kolejne 10 minut.

WindowsDefender i błąd 0x800106ba

Denerwująco nieprzyjemny błąd. Z zupełnie nieznanego mi powodu, usługa Windows Defender (windefend) nie chciała wstać, przy próbie uruchomienia wyświetlając ten nieszczęsny błąd. Co więcej, Windows Update od dobrych paru miesięcy męczył się z jednym z uaktualnień – oczywiście zestawem definicji dla tegoż Windows Defendera.

Internet pełen był dobrych rad – od ‚jak to nalezy przeinstalować Windows Defendera’ (Taa DAAA, Vista – sienieda) po oczyszczanie katalogu ‚Software Distribution‚ (nie pomogło) oraz przestawianie usługi z uruchamiania w trybie ręcznym na ‚Automatyczny’ (kicha).

Próba wystartowania usługi wskazywała na problem z plikiem, jego brakiem lub nieprawidłowym formatem. Jak to w Windowsie bywa – jakim plikiem lub jakim formatem, pozostało słodka tajemnicą programistów z Redmond.

Nie chcąc instalować kolejnych syslogów weryfikujących każde szczęknięcie dyskiem postanowiłem podejść do sprawy metodą siłową.

Pobierzcie Windows Defendera dla waszego systemu operacyjnego z: http://www.microsoft.com/windows/products/winfamily/defender/default.mspx

Plik /WindowsDefender.msi/ należy umieścić w jednym z folderów tymczasowych np. c:\MyFolder

Wydajemy polecenie w ‚cmd’

msiexec /a windowsdefender.msi /qb TARGETDIR="C:\MyFolder"

W katalogu C:\MyFolder otrzymujemy katalogów strukturę:

2010-06-06  21:14    <DIR>          Application Data
2010-06-06  21:14    <DIR>          Program Files
2010-06-06  21:14    <DIR>          Windows

Zakładając iż naszym dyskiem systemowym jest C:\ należy skopiować i NADPISAĆ w miarę możliwości katalogi i pliki odpowiednio:

Program Files – C:\Program Files

Windows – C:\Windows

Katalog ‚Application data’ kopiujemy do c:\Users\All Users\ nadpisując wszystkie pliki w ścieżce.

Teraz tylko:

net start windefend

I możemy się cieszyć działającym Windows Defenderem, którego i tak od razu wyłączamy 😉

UWAGA!

W wersji hardcore (zajęte pliki, kopiowanie nic nie dało) musimy skorzystać z kopiowania tychże plików offline, startując system z dowolnego innego nośnika (może być Linux, Rescue, WinPE, cokolwiek).