UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Migrace OS z Windows XP na Windows 7 v rámci rozsáhlé organizace Autor BP: Pavel Charvát Vedoucí BP: Ing. Tomáš Kroček 2014 Praha
ZADÁNÍ BAKALÁŘSKÉ PRÁCE
Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Migrace OS z Windows XP na Windows 7 v rámci rozsáhlé organizace vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne 19. 4. 2014. (Pavel Charvát)
Poděkování Děkuji vedoucímu bakalářské práce Ing. Tomáši Kročkovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
Migrace OS z Windows XP na Windows 7 v rámci rozsáhlé organizace OS migration from Windows XP to Windows 7 in a large organization 6
Abstrakt Předmětem této práce je nalezení efektivního způsobu migrace klientských operačních systémů v rozsáhlé počítačové síti a porovnání zkoumaných mechanismů s reálným průběhem migrace. Práce zachycuje jak konkrétní úkony, vedoucí k přechodu na nový operační systém, tak procesy plánování, na jejichž základě jsou tyto úkony provedeny. Také je v této práci představen způsob použití nástrojů navržených pro jednotlivé kroky, ze kterých se celý proces migrace sestává. Kromě standardních činností provázejících upgrade OS, jakými jsou posouzení kompatibility HW a SW vybavení, záloha a přenos uživatelských dat, vytváření image apod., je věnována pozornost také koexistenci dvou rozdílných infrastruktur - Microsoftu a Novellu, v jednom firemním prostředí. Součástí textu jsou také praktické rady pro řešení konkrétních problémů, které se během procesu přechodu na nový operační systém objevují. Klíčová slova: migrace, operační systém, image, light-touch, high-volume deployment, kompatibilita, nástroje Abstract The object of this thesis is to find an efficient way of migration of client operating systems, in a large network, and comparison of found mechanisms with real process of migration. It shows both the particular actions which lead to the transition to a new operating system as well as the planning processes on which these actions are performed. It also describes how to use the tools designed for the individual steps of which the whole migration process consists. In addition to standard activities accompanying the OS upgrade, such as evaluating the compatibility of hardware and software, backup and transfer of user data, image creation, etc., the attention is also paid to the coexistence of two different infrastructures, Microsoft and Novell, in the same corporate environment. Thesis also contains a practical advice for solving specific problems appearing during the process of transition to a new operating system. Keywords: migration, operating system, image, light-touch, high-volume deployment, compatibility, tools 7
Obsah 1. Úvod 10 2. Teoretická část 14 2.1. Plánování 14 2.2. Příprava 16 2.2.1. Posouzení kompatibility HW 16 2.2.2. Posouzení kompatibility SW 17 2.2.3. Tvorba image 18 2.2.4. Tvorba aplikačních balíčků 19 2.3. Nasazení 20 2.3.1. Scénáře nasazení 20 2.3.2. Typy image 21 2.3.3. Nástroje pro vytvoření image 22 2.4. Migrace uživatelských nastavení a dat 22 3. Praktická část 24 3.1. Popis výchozího prostředí společnosti 24 3.2. Příprava na migraci 25 3.2.1. Projektový tým 25 3.2.2. Příprava infrastruktury 25 3.2.3. Zajištění kompatibility HW 30 3.2.4. Zajištění kompatibility SW 35 3.3. Ověření postupů migrace v referenčním prostředí 39 3.3.1. Koexistence prostředí Novell a Microsoft 39 3.4. Proces migrace 40 3.4.1. Volba metody nasazení 40 3.4.2. Obecný postup reinstalace PC 41 3.4.3. Záloha dat 43 3.4.4. Tvorba image 44 3.5. Instalace aplikací 48 3.6. Provoz 50 4. Závěr 51 8
5. Seznam použitých zdrojů 53 6. Seznam použitých zkratek 56 7. Seznam obrázků 58 8. Seznam tabulek 59 9. Seznam příloh 59 Příloha 1 Aplikace nekompatibilní s Windows 7 60 Částečná nekompatibilita nebo neaktuálnost 60 Zásadní nekompatibilita nebo úplná nefunkčnost 61 9
1. Úvod S blížícím se ukončením podpory operačního systému Windows XP SP3 v dubnu 2014 se stává migrace na novější operační systém velmi aktuální otázkou. A to především pro firmy a korporace. Větší společnosti se totiž často brání změnám ve svém IT prostředí. Není se čemu divit, změna, jakou přechod na jiný operační systém představuje, totiž přináší spoustu potenciálních rizik. Také plánování takového přechodu může být velkou výzvou. Obzvlášť u velkých korporací se může jednat o náročný a dlouhodobý proces, který vyžaduje vynaložení nemalých prostředků jak finančních, tak i pracovních. Windows XP byl a stále je velmi oblíbeným operačním systémem, vždyť i dnes (srpen 2013), téměř 12 let po jeho uvedení na trh, je tento systém nainstalovaný zhruba na 20 % osobních počítačů (1) (2). Obrázek 1 - rozšíření OS - červenec 2013 (2) Hlavním cílem této práce je nalézt efektivní způsob, jak tento náročný proces úspěšně realizovat a vykonat všechny potřebné úkony vedoucí k úspěšnému přechodu na nový operační systém. Efektivním způsobem je zde myšlen postup, který umožní provést migraci v plánovaném rozsahu a rozumném čase a současně neomezí uživatele koncových stanic v jejich práci. Jelikož se jedná o tak zásadní krok, a protože se týká tak velkého množství uživatelů a společností, bylo o tomto tématu napsáno už mnohé. Je možné nalézt spoustu relevantních informací jak na webu, v podobě článků a dokumentů různých stupňů odbornosti, tak i v tištěné formě. K migraci svého operačního systému nabízí, v celku pochopitelně, nejvíce 10
informací společnost Microsoft, která má kromě tištěných a elektronických publikací a dokumentů také velmi solidně vypracovaný systém vzdělávacích kurzů Microsoft Virtual Academy (MVA), týkajících se jejich produktů. Mezi těmito kurzy lze nalézt přímo i kurz Migrating from Windows XP to Windows 7 (3), který si klade za cíl provést IT pracovníky procesem přechodu z prostředí Windows XP na Windows 7, včetně představení vhodných nástrojů a procesů. Dalším velmi dobrým kurzem v MVA, který se týká nasazení OS Windows 7, je Deploying Windows 7 (4). Tento kurz je velmi obsáhlý, skládá se z 12 modulů, ve kterých shrnuje vše od plánování, přes přípravu prostředí, tvorbu a úpravu instalačních images 1 až po nastavení politik internetového prohlížeče IE 9. Kromě výše zmíněných kurzů, připravuje Microsoft také tzv. virtuální laby (Virtual Labs), ve kterých si uživatelé, především pak IT profesionálové a vývojáři, mohou jejich produkty vyzkoušet a naučit se je používat, nastavovat a nasazovat. Tyto laby jsou dostupné přes internetový prohlížeč (podporované jsou IE 7+, Mozilla Firefox 5.0+ a Google Chrome 10.0+), ve kterém se spustí doplněk umožňující připojení do cloudu, a spuštění virtuálních PC připravených pro daný lab. Migraci operačních systémů Windows se ale věnují i jiné společnosti než Microsoft. Obecně platí, že se o konkrétních migracích systémů dá najít jen málo podrobných informací. Společnosti, které migrací prošly, považují tyto informace většinou za interní. Firmy, které nabízejí provedení migrace na nový OS nebo alespoň nějakou její část, si chrání své know-how a materiály, které v tomto kontextu uveřejňují, jsou spíše reklamního charakteru a nabízejí jen okrajové informace. Často je přístup k těmto materiálům podmíněn registrací na stránky dané společnosti, na základě které pozná, kdo hledá informace k danému tématu. Takový člověk pak může očekávat, že se mu společnost ozve a nabídne mu, či jeho firmě, své služby. Společnost Symantec ve svém dokumentu (5) například rozděluje proces přechodu na 7 kroků. Od plánování, přes vytvoření image a aplikačních balíčků, zálohování uživatelských dat a následné automatizované migrace, až po měření a reportování výsledků přechodu. Dokument však představuje jen velmi stručný rámec postupu a neobsahuje žádné konkrétní informace. Symantec zde deklaruje své bohaté zkušenosti s nasazením OS Windows a odkazuje na své produkty, které doporučuje k tomuto účelu využít. Dokument v podobném duchu nabízí také společnost VMware (6). Ta v něm zdůrazňuje to, jak je migrace na OS Windows 7 z pracovního i finančního hlediska náročný projekt 1 Pojem image bude vysvětlen dále v kapitole 2.2.3. 11
a nabízí možnost zjednodušit ho pomocí svého produktu. Ani v tomto dokumentu však nelze najít žádné informace použitelné k vlastní migraci. Dalším velkým hráčem na IT trhu, který nabízí materiály shrnující tzv. best practices pro migraci klientských OS na Windows 7 v korporátním prostředí, je společnost Intel (7). Intel úspěšnost svého programu ukazuje sám na sobě, kdy konstatuje, že díky němu provedl nasazení tohoto OS na 30 % ze svých 100 000 PC v průběhu 9 měsíců (v době uvedení dokumentu v říjnu 2010). Intel vsadil na šestiúrovňový program nasazení posouzení připravenosti prostředí a aplikací, vytvoření instalační image, zaškolení (uživatelů i IT pracovníků), komunikaci a Business Intelligence. Důraz je zde kladen především na dostatečnou kontrolu připravenosti používaných aplikací 2 a na dostatečnou informovanost, jak ve fázi příprav (správná komunikace mezi jednotlivými odděleními, informovanost managementu), testování aplikací (komunikace s vývojáři i uživateli aplikací), tak během nasazení OS, ale také po nasazení (zaškolení uživatelů, publikování řešení běžných problémů, které se po migraci často vyskytují). Dalším důležitým výstupem, který z materiálu Intelu vyplynul, je potřeba několika různých metod nasazení OS, protože použití jedné jediné není v rozsáhlém a heterogenním prostředí velké firmy reálné. Migracím i automatizovanému nasazení OS Windows 7 jsou věnovány i některé další bakalářské nebo diplomové práce. Za bakalářské práce mohu jmenovat práci Aleše Crhy z Fakulty informatiky Masarykovy univerzity (8), která je věnována právě automatizovanému nasazení MS Windows. Tato práce je vlastně shrnutím samotného nasazení Windows 7, metod a typů instalace OS a nástrojů, které jsou k tomuto účelu používané. Práce je doplněna o praktickou ukázku nasazení OS ve virtuálním prostředí. Z diplomových prací se tématu hromadného nasazení OS věnuje práce Bc. Jana Křiváka z Fakulty aplikované informatiky Univerzity Tomáše Bati ve Zlíně (9). Autor v ní popisuje nasazení OS Windows 7 v prostředí Všeobecné zdravotní pojišťovny. Zaměřuje se na zabezpečení nově nainstalovaného OS. Trochu překvapivě, s ohledem na velikost společnosti, se praktická část práce věnuje jen instalaci typu Light-Touch (LTI). To ovšem autor vysvětluje roztříštěností prostředí společnosti a pomalému WAN připojení jednotlivých poboček, kvůli kterému je metoda Zero-Touch Installation (ZTI) nepoužitelná. Nalezení praktického popisu některé konkrétní migrace klientských stanic na OS Windows 7, ve všech jejích fázích i s řešením nastalých problémů, není vůbec jednoduché, přestože je to velmi aktuální téma. Tato práce si klade za cíl právě takovým zdrojem informa- 2 Postup zjišťování kompatibility aplikací v podání Intelu je možné nalézt v dokumentu Remediating Applications When Migrating from Microsoft Windows XP* to Microsoft Windows 7* (31) 12
cí být. V teoretické části budou podrobně rozebrány procesy plánování, přípravné práce před nasazením a samotné nasazení operačního systému Windows 7 na klientské stanice. Budou zde představeny nástroje a ověřené postupy, pomocí kterých lze jednotlivé fáze efektivně a úspěšně řešit. V praktické části pak bude popsána reálná migrace operačních systémů v rozlehlé heterogenní síti konkrétní organizace. Součástí této migrace bude také vytvoření nové serverové infrastruktury a její koexistence včetně součinnosti se stávající infrastrukturou. Jedním z prvků zadání je totiž vybudovat vedle stávající infrastruktury, postavené na produktech firmy Novell, infrastrukturu novou, jejímž základem bude prostředí společnosti Microsoft, jehož adresářová služba Active Directory je snadněji začlenitelná do systémů, které organizace využívá, a umožňuje jejich snadnější správu pracovníkům IT. V závěru bude zhodnoceno, jak úspěšně migrace proběhla, kde, jakým způsobem a především proč se lišila od teoretických předpokladů. Budou rozebrány problémy, které se v jejím průběhu objevily a bude posouzeno, zda a případně za jakých podmínek se jim dalo předejít. 13
2. Teoretická část I když je každá společnost jedinečná a její prostředí může mít svá specifika, existují obecné standardní procesy, které je možné při přechodu na nový operační systém využít. Tyto procesy se dají rozdělit do tří kategorií - plánování, příprava a nasazení. Každá z těchto kategorií pak obsahuje řadu dílčích kroků. 2.1. Plánování Plánování je velmi důležitá fáze, bývá ale často podceňována a považována za zbytečnou ztrátu času. Faktem ale je, že správné a důkladné naplánování celé migrace naopak mnoho času ušetří. Umožní také vyhnout se velkému množství problémů nebo je alespoň předvídat a být na ně připraven. Microsoft rozděluje nasazení operačního systému podle rozsahu IT prostředí na Low-Volume a High-Volume (10). Low-Volume Deployment se hodí pro malé a střední firmy a nároky na plánování jsou u něj mnohem menší než u nasazení ve velkých společnostech. V obou případech Microsoft doporučuje použití nástroje Microsoft Deployment Toolkit (MDT). MDT obsahuje jak velké množství dokumentace a průvodců týkajících se nasazení operačního systému, tak i přednastavených rámcových projektů, které lze při nasazení použít nebo z nich alespoň vyjít. Pro naplánování migrace v rozsáhlém prostředí je doporučeno využít best practices principů vycházejících z Microsoft Operations Framework (MOF). MOF nabízí jakési průvodce tzv. SMF (Service Management Functions), hodící se pro různé fáze životního cyklu IT služeb z pohledu společnosti Microsoft. MOF 4.0 v podstatě představuje alternativu k jiné velmi rozšířené metodice procesního řízení v IT, kterou je ITIL V3. (11) Obrázek 2 - Fáze životního cyklu IT služby podle MOF 4.0 (11) Dobré naplánování migrace operačních systémů není limitováno použitím některé konkrétní metodiky. Kromě dvou výše zmíněných existuje spousta jiných a některé společnosti mají dokonce vytvořené i své vlastní. Zásadní je proces plánování nepodcenit. 14
Podle MOF 4.0 by High-Volume Deployment měl procházet následující fáze: Vize reprezentovaná dokumentem Envision SMF (12) zahrnuje sestavení vhodného základního projektového týmu a vytvoření dokumentu, ve kterém jsou specifikovány role a zodpovědnosti jednotlivých členů týmu. Dále obsahuje vytvoření a odsouhlasení vize a rozsahu projektu, určuje jeho milníky a posuzuje možná rizika. Obrázek 3 - Průběh procesu vytvoření a obhájení vize (12 str. 11) Naplánování projektu reprezentované dokumentem Project Planning SMF (13) popisuje mimo jiné plán na vytvoření vývojového a testovacího prostředí, funkční specifikace nasazení, ale také navržení plánu celého projektu a harmonogram. Příprava reprezentovaná dokumentem Build SMF (14) obsahuje přímo vytvoření testovacího prostředí, instalaci serverů, síťových prvků, nastavení záloh a datových repositářů. Patří sem také psaní skriptů, vytváření balíčků aplikací a tvorba images a také testování nebo tvorba dokumentace. Stabilizace reprezentovaná dokumentem Stabilize SMF (15) tato fáze přichází na řadu poté, co je vytvořeno vše potřebné pro zdárné nasazení systému, ale ještě před samotným procesem nasazení. Obvykle sem spadá pilotní testování. 15
Nasazení reprezentované dokumentem Deploy SMF (16) v této fázi je zahrnuto samotné nasazení operačního systému. 2.2. Příprava Přípravná fáze vychází ze správného naplánování. Je možné ji rozdělit na několik důležitých kroků. 2.2.1. Posouzení kompatibility HW Před přechodem na nový operační systém je zásadní zjistit, zda je vůbec možné tento systém rozumně používat na dostupném hardwaru. Velké společnosti často mají velmi různorodé portfolio výpočetní techniky. Počítače bývají nakupovány v postupných vlnách a i přes snahu udržet prostředí co nejjednotnější nutně dochází k tomu, že se v něm vyskytuje několik různých hardwarových modelů. Je pravděpodobné, že se mezi nimi najdou i modely, které by nebylo rozumné provozovat s novým, náročnějším, operačním systémem. Existuje-li ve společnosti přehled jednotlivých hardwarových konfigurací osobních počítačů, notebooků, případně dalších zařízení kompatibilních s nasazovaným operačním systémem, lze jej porovnat s doporučenou hardwarovou konfigurací nasazovaného systému. V případě Windows 7 je doporučena následující minimální konfigurace (17): 32bitový (x86) nebo 64bitový (x64) procesor s frekvencí 1 gigahertz (GHz) nebo vyšší 1 gigabyte (GB) paměti RAM (32bitový systém) nebo 2 GB paměti RAM (64bitový systém) 16 GB volného místa na disku (32bitový systém) nebo 20 GB (64bitový systém) Grafické zařízení DirectX 9 s ovladačem WDDM 1.0 nebo vyšším Pro rozsáhlejší prostředí, která nejsou z pohledu hardwaru dostatečně zmapovaná, se nabízí použití volně dostupného nástroje Microsoft Assessment and Planning Toolkit (MAP Toolkit). Tento nástroj umožňuje oskenování síťové infrastruktury a nalezení připojených počítačů, jejich hardwarové konfigurace i některé informace o nainstalovaném softwaru. Výhodou je, že k získání těchto informací není potřeba na klienty instalovat žádného agenta. Aplikace také po sběru dat automaticky vygeneruje závěrečnou zprávu a přehledné seznamy nalezeného HW i SW. Dokáže také zhodnotit, zda by počítač, který momentálně nesplňuje hardwarové nároky, prošel s případným upgradem a určí co konkrétně je potřeba upgradovat. 16
Obrázek 4 - připravenost klientských PC na instalaci Windows 7 (MAP Sample Documents generovaný aplikací MAP Toolkit, zdrojem dat byl vybraný vzorek PC společnosti) Použití nástroje MAP je celkem pohodlné a výstupy, které nabízí, jsou k posouzení připravenosti HW na migraci dostatečné. Problém je, že tímto způsobem lze nalézt pouze PC, která jsou aktuálně připojena do prohledávaného prostředí. Je sice možné prohledávání spouštět opakovaně a tím nalézat další stroje, které během předchozích prohledávání nebyly aktivní, nikdy se nám však v rozumné době nepodaří nasbírat informace o všech používaných počítačích. Zejména jde o počítače ležící ve skladech a notebooky pracovníků, kteří se do vnitřní sítě připojují jen výjimečně. V praxi je tedy často nutné spojit použití nástrojů jako je MAP s ručním posuzováním kompatibility na základě evidence majetku. 2.2.2. Posouzení kompatibility SW Otázka kompatibility SW je z určitého pohledu podobná posuzování hardwarové kompatibility. Ostatně, jak již bylo uvedeno výše, aplikace MAP, která byla použita na ohodnocení HW, sbírá základní informace i o SW, který byl na skenovaných PC nainstalovaný. Tyto informace jsou ale tak strohé, že je v podstatě nemožné je pro ohodnocení softwarové kompatibility použít. K tomuto účelu se hodí aplikace nebo lépe řečeno soubor aplikací Application Compatibility Toolkit (ACT). Nicméně ani ten nezajistí úplné posouzení kompatibility všech používaných aplikací. Některé aplikace bude třeba otestovat na referenčním testovacím PC s nainstalovaným OS Windows 7 nebo dokonce přímo v produkčním prostředí. Pomocí ACT, resp. jeho nástroje Application Compatibility Manager (ACM), lze posbírat informace o nainstalovaných aplikacích (18). Získané informace je možné následně porovnat webovou službou Microsoftu, která zahrnuje informace o komptabilitě aplikací. 17
Tímto způsobem je možné potvrdit kompatibilitu spousty běžně používaných aplikací. V seznamu nalezeného SW bude ale určitě i mnoho aplikací, o kterých služba MCE žádná data neposkytuje. Takové aplikace je nutné otestovat. Navíc, podobně jako MAP, ani ACT nedokáže pravděpodobně nalézt všechny aplikace, které jsou v dané společnosti používané. Do seznamu aplikací se totiž dostanou jen ty, které jsou klasicky nainstalované. I pro zajištění kompatibility SW tedy platí, že je třeba použít i další metody nalezení používaného SW. 2.2.3. Tvorba image Jedním z klíčových úkolů migrace OS je vytvoření tzv. image. Image je zjednodušeně řečeno obraz nainstalovaného počítače, který je nastaven a vyladěn podle aktuálních požadavků. Tento obraz je následně použit jako vzor a je nasazen, v ideálním případě, na všechny ostatní počítače ve společnosti. Realita bývá trochu odlišná. Většinou existuje několik různých images reprezentující určité skupiny počítačů, které jsou vzájemně z různých důvodů odlišné. Nasazení Windows 7 pomocí image nahrává fakt, že už instalace samotného čistého operačního systému probíhá formou image. Tento způsob instalace OS Windows se poprvé objevil na verzi Windows Vista a nahradil tak těžkopádnější instalace starších operačních systémů Microsoftu. Nasazení OS pomocí image je elegantnější, lépe nastavitelné (přináší možnost vytvářet hardwarově a jazykově nezávislé instalace) a lépe předvídatelné oproti staršímu způsobu instalace. 2.2.3.1. Vytvoření image pomocí nástroje MDT Existuje hned několik způsobů jak vytvořit image. Microsoftem doporučený způsob spočívá v použití nástroje Microsoft Deployment Toolkit (MDT). Využití MDT je základem tzv. Lite Touch Instalace (LTI). LTI je strategie nasazení OS, která sice využívá velkého stupně automatizace, ale bez zásahu IT pracovníků se neobejde. O stupeň výše, z hlediska míry automatizace, stojí strategie zvaná Zero Touch Instalace (ZTI). Ta se obejde i bez lidského zásahu, zato ale potřebuje vytvoření odpovídající infrastruktury. Pro úplnost uveďme, že existuje ještě opačný typ nasazení, tzv. User Driven Instalace (UDI), která je plně manuální. Ta se ale při větších migracích z pochopitelných důvodů nepoužívá. Postup vytvoření image pomocí nástroje MDT je ukázán na následujícím obrázku. Prvním krokem je vytvoření úložiště a nahrání instalačních a konfiguračních zdrojů (images, instalační soubory apod.), které budou třeba pro vytvoření image. Dalším krokem je vytvoření tzv. Task Sequence (TS), tedy posloupnosti kroků vedoucí k vytvoření image. Následně je nastaven Deployment Point (DP), bod, ze kterého se budou instalace provádět a vygenerováno preinstalační prostředí (Pre-installation Environment - PE), z něhož se pak 18
image aplikuje na cílový, v tomto případě referenční, PC. Poté je vytvořena image referenčního PC a ta je nakonec nastavena jako zdroj pro instalaci ostatních počítačů. Obrázek 5 - Postup vytvoření image pomocí nástroje MDT (10 str. 184). 2.2.3.2. Ruční vytvoření image K vytvoření zdrojové image, která bude následně naimplementována na ostatní PC, je možné dojít i bez použití nástroje MDT. Ruční vytvoření image spočívá v nainstalování OS na referenční PC a jeho následné donastavení. Především se jedná o instalaci dalšího SW a potřebná nastavení. Referenční PC nakonec musíme tzv. zobecnit, tedy zbavit instalaci specificky uživatelských nastavení a všech SID (Security Identifiers). Toto zobecnění se provádí pomocí nástroje Sysprep (10 str. 219). Nástroj se nachází přímo ve Windows 7 (%SystemRoot%\System32\Sysprep). 2.2.4. Tvorba aplikačních balíčků Aplikace, které nejsou přímo součástí systémové image, ale jsou na PC potřeba, je možné na počítač nasadit za pomoci balíčků. Aplikační balíček je možné nasadit v rámci Task Sequence přímo při instalaci image nebo dodatečně za pomoci správcovského nástroje, např. System Center Configuration Manager (SCCM). Existují tři instalační metody, kterými lze aplikace nasazovat. První a nejrozšířenější je metoda automatické instalace. Tu podporuje většina aplikací. Jedná se o instalační soubor (např. msi nebo exe), který lze spouštět s různými parametry nebo odpovědními soubory (response files) specifikujícími způsob instalace. Parametry, které je možné u instalátorů použít, se nejčastěji dají najít v dokumentaci nebo pomocí parametru /? (např. setup.exe /?). 19
Druhou metodou je tzv. repackaging neboli přebalení. To z aplikace nepodporující automatickou instalaci vytvoří balíček, který umí instalaci automatizovat. Příkladem takového nástroje je třeba AdminStudio od společnosti Flexera Software. Poslední možností je použít specializovaný nástroj, který odkliká instalaci jakoby ručně např. Windows Script Host. Používá se tam, kde není možné použít předchozí dvě metody. 2.3. Nasazení 2.3.1. Scénáře nasazení Existují čtyři základní scénáře nasazení. Nový PC Nasazení OS na nový PC. Není tedy potřeba řešit uživatelská data ani aplikace. Upgrade PC Reinstalace starého OS na novější (na stejném HW) při zachování uživatelských dat i aplikací. Obnova PC (Refresh) Reinstalace provedená za účelem aktualizace PC nebo odstranění chyby (na stejném HW). Často jde o aplikaci stejné verze OS. Uživatelská data jsou zachována, ale aplikace nikoli. Obrázek 6 - Průběh scénáře obnovy PC (19) Výměna PC Jde o výměnu PC se starším OS za PC s novým OS. Uživatelská data jsou zálohována a přesunuta na nový stroj. 20
Obrázek 7 - Průběh scénáře výměny PC (19) 2.3.2. Typy image Podle toho, zda image přímo obsahuje aplikace, aktualizace, ovladače a další nastavení, rozlišujeme tzv. tenké a tlusté image. Oba typy mají svá pro i proti. Tenká image neobsahuje další aplikace, je tedy menší, sama o sobě se rychleji naimplementuje na cílový PC, je obecnější a nezastarává. K plnohodnotné práci, ale samotný OS nestačí a na PC je potřeba doinstalovat i další aplikace, to naopak celou implementaci zpomaluje. Nasazení aplikací vyžaduje často další nároky na infrastrukturu a v některých případech tak není praktické nebo ani možné doinstalovávat aplikace dodatečně. Typicky se jedná o počítače umístěné v detašovaných lokalitách, které jsou připojeny k aplikačním distribučním bodům pomalým připojením nebo tuto konektivitu nemají vůbec. V takových případech se běžně používají tlusté image představující v podstatě kompletní plnohodnotnou instalaci se všemi potřebnými aplikacemi. V praxi se nejčastěji používá určitý kompromis mezi těmito dvěma druhy hybridní image. 21
Obrázek 8 - Procesy nasazení tenké a tlusté image (10 stránky 254, 255). 2.3.3. Nástroje pro vytvoření image ImageX Jedná se o nástroj příkazové řádky, který je možné použít k vytváření, modifikaci i nasazení image. Nemusí se nutně jednat o image operačního systému. DISM Podobně jako u ImageX jde o nástroj příkazové řádky, který slouží k vytváření i úpravám image. Je používán především k offline úpravám, které předchází samotnému nasazení OS. Je součástí některých sad nástrojů (Windows OPK, Windows AIK), ale také přímo OS od Windows 7 výše. SIM Windows System Image Manager je grafický nástroj, pomocí kterého je možné vytvářet a modifikovat odpovědní soubory určené k automatizovanému nasazení OS Windows. Odpovědní soubory se tímto nástrojem vytváří poměrně intuitivně přidáváním komponent a balíčků do jednotlivých fází, kterými může instalace OS Windows probíhat. Těchto fází je sedm, ale během instalace nemusí být procházeny všechny. 2.4. Migrace uživatelských nastavení a dat Důležitou součástí migrace OS je také přenos uživatelských dat. I zde existuje více způsobů, jakými to lze provést. Microsoft pro tento účel vytvořil dva nástroje. Jedním z nich je Windows Easy Transfer (WET). WET je grafický nástroj, hodí se především pro domácí uživatele nebo pro migrace malého počtu strojů. Pro rozsáhlé migrace je určen nástroj příkazového 22
řádku User State Migration Tool (USMT). Ten je v porovnání s WET mnohem lépe nastavitelný a je skriptovatelný. USMT verze 5 je obsažen ve Windows Assessment and Deployment Kit (ADK). Umožňuje přesouvat uživatelská data ze systémů Windows XP a novějších na systémy od Windows Vista výše. USMT se skládá ze dvou programů Scanstate a Loadstate. Prvně zmiňovaný oskenuje zdrojový PC a podle definovaných parametrů uloží uživatelská data. Loadstate pak uložená data aplikuje na cílový PC. V případě scénáře obnovy PC (refresh) lze využít ještě jedné vlastnosti, kterou OS Windows 7 ve spolupráci se souborovým systémem NTFS nabízí, a které dokáže USMT vhodně využít. Jde o zálohu pomocí tzv. hardlinků. Hardlink představuje alternativní odkaz na již existující data. Při migraci uživatelských dat za využití hardlinků dojde k vytvoření těchto alternativních odkazů všech dat, které mají být přeneseny a po instalaci OS jsou tyto odkazy přeneseny zpět na určená místa. Tento způsob migraci uživatelských dat velmi urychlí, protože fyzicky se s daty na disku vůbec nehýbe. 23
3. Praktická část 3.1. Popis výchozího prostředí společnosti Společnost, v níž probíhala reálná migrace, má ústředí v Praze a pobočky ve všech ostatních 13 krajích ČR. V krajských městech jsou oblastní centrály, pod které spadá vždy několik okresních pracovišť v okolí. Pražská centrála má téměř 1000 zaměstnanců, krajská pracoviště dohromady okolo 600 kmenových zaměstnanců. Pracoviště jsou vzájemně propojena pomocí VPN. Z pohledu infrastruktury se jedná o hvězdicovou topologii. Jednotlivá krajská i okresní pracoviště jsou připojena do pražské ústřední centrály. Krajská mají pronajatou linku, okresní jsou připojena přes ADSL. Obrázek 9 - Schematické zobrazení topografie společnosti (vlastní zpracování) Ve společnosti se používá přibližně 2000 osobních počítačů a notebooků. V poměru zhruba 4:1 ve prospěch PC. Na většině z nich je nainstalován OS Windows XP. I přes snahu udržet co nejjednotnější prostředí, je modelové portfolio výpočetní techniky celkem rozmanité, a to především u notebooků. Počet modelů, se kterými se počítá pro přechod na nový operační systém, se pohybuje okolo 25. Ve společnosti se aktivně využívá 200 až 300 aplikací. Neexistuje však jejich přesný seznam. Přestože v době, kdy se rozhodovalo o migraci na nový OS už byly na trhu dostupné Windows 8, bylo rozhodnuto, že se provede migrace na systém Windows 7. Zdůvodněno to bylo především tím, že v té době již měla společnost nakoupeno téměř 200 notebooků 24
s Windows 7 Professional. Investice do Windows 7 tedy byla nižší než by tomu bylo u Windows 8. OS Windows 8 byl navíc cílen především na tablety a rozdílnost vzhledu i ovládání v porovnání s Windows XP byla posouzena jako příliš veliká. V neprospěch Windows 7 však hraje například fakt, že ve verzi Professional, na rozdíl od Windows 8, neobsahuje technologii BitLocker pro šifrování dat. Bude-li tedy v budoucnu potřeba šifrovat data, bude třeba pořídit nějaký šifrovací nástroj třetí strany, případně povýšit verzi OS. 3.2. Příprava na migraci 3.2.1. Projektový tým Pro účely plánování i samotného řízení průběhu migrace byl vytvořen sedmičlenný projektový tým. V týmu bylo zastoupeno IT oddělení, bezpečnostní oddělení, oddělení klientské podpory a oddělení vývoje aplikací. Projektový tým byl sestaven necelý rok před konečným termínem migrace, tedy relativně pozdě, s ohledem na rozsah projektu. Scházel se pravidelně jedenkrát týdně. Souhrou několika okolností se však po několika měsících rozpadl a formální řízení projektu v podstatě zaniklo. Během projektu se kvůli tomu objevilo několik zásadních nejasností týkajících se jak rozsahu, tak metodiky nasazení. Nedostatečným vedením utrpěla také informovanost top managementu a z toho plynoucí podcenění situace i nedostatek uvolněných prostředků potřebných pro plynulý průběh migrace. 3.2.2. Příprava infrastruktury Jednou z nejzásadnějších věcí, na kterou mělo negativní dopad nedostatečné vedení projektu, byla příprava infrastruktury použité k nasazení nového OS. Do poslední chvíle nebylo jasné, která technologie bude k migraci a následné správě koncových stanic použita. Ve hře byl nástroj ZenWorks od společnosti Novell, který byl používán na stanicích s Windows XP. Používaná verze 7 však není kompatibilní s Windows 7. A novější verze 11, která by mohla být použita, nebyla zatím dostatečně otestována ani nasazena. Mezi oběma verzemi navíc existují takové rozdíly, že se dá její nasazení srovnat s nasazením jiné technologie. Druhou možnost představovalo postavení infrastruktury na technologiích Microsoft. Vytvoření adresářové služby Active Directory (AD) a použití nástroje System Center Configuration Manager (SCCM) pro nasazení Windows 7 i následnou správu klientských stanic. Nedostatkem této možnosti bylo silné zakořenění technologií Novell v celé společnosti. Kromě nástroje ZenWorks používá společnost poštovní řešení Novell GroupWise a adresářové služ- 25
by a file system běžící na Novell Open Enterprise Server (OES). Existovaly hned tři různé varianty této možnosti: Použít AD a SCCM čistě jen pro účely migrace klientských OS. Tato varianta by byla nejméně časově náročná a nepředstavovala by v podstatě žádné nároky na změny stávajícího prostředí. Znamenala by ale nutnost paralelního provozu obou infrastruktur. Začlenit stanice a uživatelské účty do AD a současně zachovat souborové, tiskové a poštovní služby na infrastruktuře Novell. Výhodou této varianty by bylo zajištění lepší správy prostředí. Nevýhodou ovšem opět nutnost provozovat paralelně obě infrastruktury. V tomto případě by bylo navíc potřeba najít způsob, jak efektivně synchronizovat uživatelské účty a hesla mezi AD a edirectory. Kompletní migrace prostředí. Infrastruktura postavená na řešení Microsoft by nahradila všechny stávající produkty Novell. Tato varianta by znamenala vytvoření jednotného prostředí a eliminovala by nutnost pravidelných nákladů na provoz infrastruktury Novell. Představovala by však mnohem vyšší náročnost plánování a větší časové nároky. Nakonec byl zvolen postup, který se nejvíce blíží druhé variantě použití Microsoft infrastruktury. Tento postup byl navíc několikrát ve svém průběhu pozměněn, což znatelně degradovalo jeho použitelnost. Z finančních důvodů nebylo pořízeno dostatečné HW vybavení a vytvoření potřebné infrastruktury tak bylo nakonec omezeno jen na centrálu společnosti. Ze stejných důvodů bylo rozhodnuto o tom, že se nebude řešit synchronizace uživatelských účtů. Uživatelské účty budou nadále existovat pouze v infrastruktuře Novell, v AD budou vytvořeny pouze účty počítačů. Toto rozhodnutí v konečném důsledku znamená omezení možnosti správy uživatelů. 3.2.2.1. Vytvoření infrastruktury Microsoft Active Directory Základem prostředí Microsoft je jeho implementace adresářových služeb Active Directory. V původním plánu bylo postavit doménu s dvěma Domain Controllery (DC) v ústředí a jedním replikovaným DC v na každém kraji. Okresní pracoviště by se hlásila k pražským serverům. Do poslední chvíle se ale nepodařilo najít dostatek HW prostředků ani financí na jejich dokoupení. Vytvořeny byly tedy jen 2 DC v ústředí. Pro správnou funkci AD musí být v síti povoleny určité porty, jinak může dojít k mnoha problémům, například s přidáváním PC do domény, při autentizaci nebo replikaci. 26
Seznam portů, které pro svou správnou funkci AD potřebuje je dobře popsán na stránkách Microsoft TechNet (20). Postup instalace DC na Windows 2012 Server Core Pro server zprostředkovávající služby Active Directory Domain Controlleru je ideální použít odlehčenou instalaci Windows server, tzv. Core. Core instalace neobsahuje grafické prostředí ani některé další komponenty. Spotřebovává tedy méně systémových prostředků, rychleji nabíhá a představuje menší bezpečnostní hrozbu. Postup instalace je celkem srozumitelně popsán na webu Petri IT knowledgebase (21). Lze jej shrnout do následujících kroků: 1. Nainstalovat Windows 2012 Server Core (ideálně v anglické lokalizaci kvůli lepšímu troubleshooting). 2. Pomocí nástroje sconfig nastavit statickou IP adresu (a masku, bránu a DNS) a název PC. 3. Nainstalovat AD roli příkazem: Install-WindowsFeature AD-Domain-Services IncludeManagementTools 4. Přepnout (promote) server do role DC příkazem: Install-ADDSDomainController -DomainName addomain.local - InstallDNS: $True Credential (Get-Credential) Pozn.: Pokud vytváříme novou doménu (potažmo upravujeme les) musí být zadány přihlašovací údaje účtu disponujícího oprávněními Schema Admin a Enterprise Admin. Obrázek 10 - Nastavení serveru pomocí nástroje sconfig na verzi Core (21). 27
DNS Active Directory vyžaduje použití služby DNS. V našem případě jsme nastavili na DC službu DNS, tak aby obsloužila vnitřní doménu prostředí Microsoft a dotazy na vnější objekty byly forwardovány na primární DNS společnosti, která není součástí nově vytvořené domény. V primární DNS byl naopak nastaven odkaz, který zajistí, že dotazy směřující na nově vytvořenou doménu budou poslány na příslušné doménové kontrolery. SCCM K distribuci images i aplikací na koncové stanice a jejich následnou správu byl určen produkt System Center Configuration Manager (SCCM). Podle původních plánů měla být vytvořena Primary Site na ústředí a na krajích pak distribuční body, ze kterých by byl distribuován obsah po místních LAN linkách. Kvůli nedostatku finančních prostředků však ani v tomto případě nebyl zajištěn potřebný HW. Zůstalo tedy pouze u jednoho distribučního bodu na ústředí. Kvůli nevhodnosti WAN linek pro posílání velkého množství dat (image i SW balíčky) tak byly kraje odříznuty od možnosti nasazovat OS a spravovat počítače pomocí SCCM. Na detašovaných pracovištích tedy probíhala migrace ručně, nasazením připravené tlusté image z flash disku (bude detailněji popsáno dále). Pro zvolený scénář bylo tedy potřeba nainstalovat Primary Site server. Ten vyžaduje SQL server alespoň ve verzi Standard (verze Express nestačí). Další požadavky na systém jsou uvedeny na stránkách Microsoft TechNet (22) (23). Postup instalace System Center 2012 by se dal shrnout do následujících kroků (24): 1. Instalace a nastavení požadovaných rolí (roles) a funkcí (features) na serveru..net Framework 3.5 SP1 (feature) pro instalaci je potřeba zadat zdroj z instalačního média adresář sources\sxs.net Framework 4.0 Remote Differential Compression (feature) BITS (feature) IIS (role) Windows Deployment Services (WDS) pokud chceme používat OS deployment 28
Vše jde přidat pomocí powershellových příkazů: Import-Module ServerManager Add-WindowsFeature NET-Framework,BITS,RDC,Web-Server, Web-Windows-Auth,Web-Lgcy-Mgmt-Console,Web-Mgmt-Console, Web-WMI,Web-Metabase,Web-Scripting-Tools,Web-Asp-Net,WDS 2. Rozšíření schématu AD lze provést dvěma způsoby (25 str. 82). a) Spuštěním nástroje ExADSch.exe z instalačního média Configuration Manageru. b) Importem souboru ConfigMgr_ad_schema.ldf pomocí nástroje LDIFDE (Lightweight Data Interchange Format Data Exchange). 3. Vytvoření kontejneru System Management v AD. Lze provést nástrojem ADSI Edit v CN=System vytvoříme nový objekt typu Container s hodnotou System Management. Nad tímto kontejnerem musíme nastavit oprávnění Full control serveru (tedy objektu typu Computers nebo lépe skupině, jejímž členem je server), na kterém běží SCCM. Dělá se to proto, aby o sobě mohl server publikovat v doméně informace. Toto je možné provést jak nástrojem ADSI Edit, tak nástrojem Active Directory Users and Computers (ADUC). Nakonec je ještě potřeba nastavit Primary Site SCCM aby publikovala informace do AD. To provedeme v konzoli Configuration Manageru, v sekci Administration ve vlastnostech Site (Site Configuration -> Site -> Properties) na kartě Publishing. 29
4. Instalace SQL serveru. Obrázek 11 - Přidělení oprávnění na kontejner "System Management" (25 str. 88). SCCM 2012 potřebuje SQL Server verze Standard nebo Enterprise (podle velikosti prostředí Standard podporuje maximálně 50.000 klientů, což nám ale bohatě stačilo). K licenci Systém Center 2012 je možno použít SQL 2012 Server Standard - není potřeba dokupovat licenci. System Center vyžaduje u SQL 2012 alespoň Cumulative Update 2. 5. Instalace SCCM 2012. Instalace se spustí kliknutím na Install na úvodní obrazovce průvodce, kterého spustíme pomocí souboru splash.hta z instalačního média. 3.2.3. Zajištění kompatibility HW Hardwarová kompatibilita může být posouzena buď praktickým vyzkoušením a subjektivním posouzením rychlosti odezvy PC při spouštění a používání typických aplikací nebo papírově porovnáním konfigurace PC s hodnotami doporučenými výrobcem OS. V rozsahu velké spo- 30
lečnosti je rozumně použitelný v podstatě jedině druhý ze způsobů, a to nejlépe za použití některého specializovaného nástroje. Takovým nástrojem, který je navíc volně k dispozici, je například Microsoft Assessment and Planning Toolkit (MAP). 3.2.3.1. Sběr informací o HW MAP má čtyři základní funkce: vyhledání počítačů a aplikací, posouzení jejich připravenosti k migraci, sledování využívání SW pro plánování virtualizace a migraci privátních a veřejných cloudů. (26) Pro účel migrace se hodí první dvě z nabízených funkcí. Vyhledávání lze provést několika způsoby, které je možné i libovolně kombinovat a není k němu potřeba instalovat žádného agenta na prohledávané počítače. Je možné vybrat jeden z celkem osmi inventarizačních scénářů. Pro dané podmínky se hodí scénář vyhledání PC se systémem Windows, tyto PC se totiž budou migrovat. MAP umožňuje i hledání Linux/UNIX nebo virtuálních počítačů, umí také hledat aktivní zařízení a uživatele z AD nebo několik typů serverů. Po vybrání scénáře je třeba vybrat metodu nebo metody, kterými bude prostředí prohledáno. Při pátrání po zařízeních s OS Windows se nabízí využít AD DS. Společnost bohužel tyto doménové služby od Microsoftu před migrací nevyužívala, bylo tedy nutné použít některé z dalších metod. V úvahu připadalo využití síťových protokolů Windows (členství v pracovních skupinách) nebo prohledávání rozsahů IP adres. Použít lze obě metody najednou. V první z nich určíme, které nalezené pracovní skupiny nás zajímají, ve druhé určíme rozsah IP adres, které se budou prohledávat (pro jedno prohledání je povoleno maximálně 100 000 IP adres). Následně je potřeba nastavit účet nebo účty, které budou použity pro připojení k nalezeným PC a jejich pořadí. Tyto účty jsou využity pro obě (resp. všechny) metody vyhledávání. 31
Obrázek 12 - Metody vyhledávání klientů v MAP (Sejmuto z nástroje MAP). Po zadání potřebných údajů je spuštěno vyhledávání. Po jeho skončení se zobrazí přehledné výsledky reprezentované především koláčovým grafem, který zobrazuje 3 barevně odlišené skupiny PC ty které je možné migrovat, ty které potřebují nějaký menší upgrade, aby je bylo možné migrovat a ty, které nejsou k migraci vhodné. Podrobněji se vyhodnocení HW kompatibility věnuje následující kapitola. Jak už bylo zmíněno v teoretické části, není možné se spokojit jen s výsledky, které nalezl MAP. Nezohledňují totiž všechny PC, které se ve společnosti používají. Zejména jde o počítače ležící ve skladech a notebooky pracovníků, kteří se do vnitřní sítě připojují jen výjimečně. U první skupiny se lze spokojit s konstatováním, že všechny typy PC, které leží ve skladech, jsou používané i v provozu. Jejich připravenost k migraci lze tedy posoudit podle nasbíraných dat. O noteboocích toto tvrdit nelze, v nasbíraných datech jich bude jen minimum. Naštěstí je vydávání notebooků jednotlivým pracovníkům ve společnosti dobře sledováno. Jejich HW výbava je, oproti klasickým počítačům, méně často upravována. Většinou tedy existuje docela přehledný seznam používaných typů notebooků a často platí, že všechny notebooky stejného typu mají také stejnou výbavu. Posouzení jejich připravenosti k migraci bylo tedy provedeno porovnáním HW konfigurací jednotlivých typů notebooků ze seznamu s doporučenými hodnotami. 32
3.2.3.2. Vyhodnocení kompatibility HW Vyhodnocení zda je či není PC kompatibilní s Windows 7, provádí MAP podle velmi jednoduchých pravidel. Jde čistě o porovnání nalezených hodnot s hodnotami doporučenými. Dobře je to vidět při vygenerování reportu, který se skládá ze dvou částí - excelovského souboru s nalezenými a utříděnými daty a textového dokumentu Proposal přinášejícího jakési manažerské zhodnocení s přehledem kompatibilních zařízení i těch, které je nutné případně upgradovat. V excelovském dokumentu lze najít spoustu zajímavých informací roztříděných do jednotlivých listů. Mezi nimi je mimo jiné list nazvaný AssessmentValues obsahující referenční hodnoty CPU, paměti a volného místa na disku. Na základě porovnání nalezených informací s těmito hodnotami posuzuje MAP kompatibilitu HW s OS Windows 7. Výchozí nastavení lze upravit podle potřeby. Je možné také zapnout kontrolu existence DVD mechaniky a vyhovující grafické a zvukové karty. Na dalších listech tohoto dokumentu je přehled nalezených HW komponent, obsahující informace o tom, zda pro ně existuje funkční ovladač pro Windows 7. Spíše doplňkovou informaci představuje seznam nalezeného SW, který obsahuje pouze název, verzi a počet PC, na kterých byl objeven. Pro posouzení kompatibility SW jsou tyto informace nedostatečné. Tabulka 1- Referenční hodnoty pro porovnání kompatibility HW (vygenerováno nástrojem MAP). Pro posouzení kompatibility notebooků (které nemohl MAP nalézt, protože nebyly připojeny do sítě v době skenu) bylo nutné postupně porovnat jednotlivé typy notebooků ze seznamu vypsaného na základě evidence majetku. Seznam byl doplněn dohledanými informacemi o CPU, paměti a kapacitě HDD, tedy stejnými informacemi, které k posouzení kompatibility používá aplikace MAP. 33
Tabulka 2 - Přehled používaných typů notebooků v ústředí společnosti vypsaný podle evidence majetku, doplněný o informace potřebné k posouzení kompatibility s Windows 7 (vlastní zpracování). Ve sloupci Status je barevně označena připravenost notebooků na migraci na Windows 7. Zelená znamená připraven. Žlutě označené notebooky jsou na bezproblémový běh Windows 7 slabé, ale po vhodném upgradu by na nich tento OS bylo možné provozovat. Červená znamená, že notebook není vhodné (nebo ani možné) přeinstalovat na Windows 7. Žlutě označené notebooky mají vesměs dostatečnou kapacitu HDD, upgrade CPU u notebooků není zrovna běžný, jediná reálná možnost jak vylepšit výkonnost těchto strojů je tedy zvýšení operační paměti. Doporučená hodnota RAM pro 32 bitovou verzi Windows 7 je 1 GB, nicméně pro opravdu pohodlnou práci na tomto OS jsou optimální spíše 2 GB. Je na zvážení, do kterých typů investovat, a které notebooky přestat používat. Důležitým vodítkem pro toto rozhodování může být i počet notebooků daného typu, který se ve společnosti používá. Investovat například do nákupu 1 GB nebo 2 GB RAM modulů pro Lenovo ThinkPad X61s, kterých je v centrále společnosti používáno 15, a které jinak splňují kritéria provozuschopnosti Windows 7, je vcelku rozumné rozhodnutí. Naopak snažit se upgradovat například Asus EEE PC, který je ve firmě jen jeden a je postaven na slabé architektuře Intel Atom, lze obhájit o poznání hůře. 34
3.2.4. Zajištění kompatibility SW 3.2.4.1. Sběr informací o SW Prvním krokem zajištění kompatibility SW je sběr informací o tom, jaké aplikace se ve společnosti využívají. K tomuto účelu se hodí jeden z nástrojů ACT - Application Compatibility Manager (ACM). V něm je možné vytvořit balíček pro instalaci agenta, který posbírá informace o aplikacích nainstalovaných na daném PC a uloží je do předdefinovaného adresáře. Není potřeba jej instalovat na všechny PC, ideální je vytipovat několik počítačů, které svým softwarovým vybavením reprezentují celé prostředí společnosti. Nalezená data jsou následně zpracována ACM. Výsledkem je seznam všech nalezených aplikací. Tento seznam je možné porovnat s údaji poskytovanými webovou službou Microsoft Compatibility Exchange, která zahrnuje informace o komptabilitě aplikací od Microsoftu, nezávislých výrobců softwaru a ACT komunity. K jednotlivým aplikacím v ACM lze samozřejmě dopisovat i vlastní hodnocení. U vybraných záznamů jde nastavením zakázat, aby se údaje o nich posílaly Microsoftu, tyto aplikace pak nebudou posouzeny službou MCE. Jednotlivým aplikacím v seznamu je možné nastavovat priority (4 úrovně od Business Critical do Unimportant) i statuty (testováno, opraveno, připraveno k nasazení, nebude se nasazovat). Obrázek 13 - Ukázka posouzení kompatibility SW v ACM (sejmuto z nástroje ACM). Ještě před začátkem testování aplikací a případného řešení konkrétních problémů s kompatibilitou, bylo třeba se zamyslet, zda jsme získali data o všech používaných aplikacích. Odpověď na tuto otázku zní ve většině případů ne. Do seznamu aplikací se totiž dostanou jen ty, které jsou klasicky nainstalované. Nedostanou se sem například portable aplikace. Je také možné, že jsou ve firmě používané nějaké speciální programy, které jsou také mimo rozlišovací možnosti ACM. Pokud tedy chceme pokrýt opravdu všechny aplikace, které jsou ve firmě 35
používány, musíme použít ještě jiné způsoby jejich nalezení. V ideálním případě si společnost vede záznamy o všech používaných programech, ale to u většiny firem bohužel neplatí. V našem případě byl vytvořen jednoduchý formulář, který byl umístěn na intranetové stránky a uživatelé (speciálně programátoři a správci aplikací) do něj vyplňovaly informace o SW, který používají, vytvářejí či spravují. Obrázek 14 - Formulář pro nahlašování používaných aplikací. 3.2.4.2. Řešení problémů s kompatibilitou SW Po identifikaci všech aplikací, které jsou v prostředí společnosti používány, bylo nutné vybrat všechny ty, u kterých potřebujeme kompatibilitu s OS Windows 7 zjistit jejich otestováním (informace o jejich kompatibilitě nebylo možné nijak jinak dohledat). Pro testování aplikací se ideálně hodí virtuální prostředí. V tomto konkrétním případě bylo zvoleno vytvoření několika virtuálních PC pomocí programu VMWare Workstation. Virtuální PC kopírovaly v co největší míře skutečné nastavení klientských PC ve společnosti, ale s novějším OS (místo Windows XP byly nainstalovány Windows 7) a byly připojeny do firemní sítě. Pro každou testovanou aplikaci byl vytvořen testovací protokol a stanoven jednoduchý postup testování. U speciálních aplikací bylo testování prováděno přímo jejich tvůrci, správci nebo zkušenými uživateli. Na základě vyplněného testovacího protokolu byla posouzena kompatibilita jednotlivých aplikací. V případě problémů s kompatibilitou bylo nutné 36
zjistit příčinu nefunkčnosti aplikace a poté zjistit, jestli je možné tuto příčinu nějakým způsobem odstranit nebo obejít. Pro zjišťování příčin nefunkčnosti aplikací i jejich odstraňování jsou dobrými pomocníky další z nástrojů, které jsou součástí ACT. Jedná se o Standard User Analyzer (SUA) nebo SUA Wizard, které slouží k monitorování volání API testovaných aplikací a hlídá potenciální problémy, zapříčiněné především technologií User Account Control (UAC) (27). Jedná se tedy o problémy s oprávněními. U aplikací, které jsou funkční na Windows XP, ale na Windows 7 nefungují správně, je většinou problém právě v nedostatečném oprávnění. Od zavedení technologie UAC pracuje totiž i uživatel mající administrátorská oprávnění standardně pod omezenými uživatelskými oprávněními a k elevaci práv dochází až v případě, že si o to daná aplikace řekne. Některé starší aplikace s tímto ale nepočítají a s UAC si neporadí. Vyřešit tento problém není naštěstí většinou složité. Stačí danou aplikaci (případně instalátor nebo obecně spouštěcí soubor) spustit jako správce, tímto způsobem si totiž lze explicitně povýšit oprávnění, i když si o to aplikace sama neřekne. Aby nebylo zapotřebí spouštět aplikaci vždy takto krkolomně, je možné v nastavení spouštěcího souboru zatrhnout možnost, aby se daná aplikace vždy spouštěla s povýšenými právy. Obrázek 15 - Nastavení aplikace tak, aby se vždy spouštěla se zvýšenými právy (sejmuto v OS Windows 7). 37
Další možností je vytvořit tzv. shim, tedy opravu konkrétní nekompatibility (28). Součástí ACT je nástroj Compatibility Administrator, který je určen k vytváření právě těchto oprav (29). Tento nástroj obsahuje (ve verzi 6.1) 398 různých oprav (fixů), z nich je vytvořeno 86 různých módů kompatibility (Compatibility Modes). Mezi nimi je mimo jiné i mód RunAsAdmin, který řeší výše zmíněný problém s tím, že si některé aplikace neumí říci o zvýšení oprávnění. Mezi módy jsou i ostatní nastavení, která lze najít na kartě Kompatibilita ve vlastnostech aplikací (viz předchozí obrázek). Compatibility Administrator obsahuje také knihovnu více než 7000 aplikací a jejich oprav potenciálních problémů s kompatibilitou s Windows 7. Pokud mezi nimi opravovaná aplikace není, je možné pro ni vytvořit shim vybráním konkrétní opravy nebo kombinací oprav. Tyto opravy je možné sdružit do společné databáze nebo je rozdělit do několika nezávislých databází. Databáze s opravami lze následně vyexportovat v podobě souboru sdb a nainstalovat na PC pomocí příkazu sdbinst. Zajímavostí je, že samotný čerstvě nainstalovaný systém už mnoho shimů obsahuje. Opravené jsou touto cestou například Internet Explorer, některé aplikace MS Office nebo MS SQL Server. Tyto opravy jsou udržovány ve speciální databázi s názvem Global. Obrázek 16 - Compatibility Administrator s vytvořenou databází pro opravu aplikace P4G na správu řízení spotřeby notebooků Asus (sejmuto z nástroje CA). Většina z testovaných aplikací neměla žádné výrazné problémy s funkcionalitou na Windows 7. Našly se ale také aplikace, které jsou na Windows 7 nefunkční nebo jen velmi problematicky fungující. Důvody nefunkčnosti aplikací se dají zobecnit do dvou skupin: Nesprávná nebo nemožná instalace. Nestabilita při běhu aplikace nebo některých jejich důležitých funkcí. 38
Seznam nefunkčních aplikací je uveden v příloze Aplikace nekompatibilní s Windows 7. Součástí přílohy je také popis nekompatibility a navrhované řešení. Pokud se vyskytl problém s kompatibilitou u krabicových verzí softwaru, bylo to téměř vždy proto, že se jednalo o starou, dávno nepodporovanou verzi. V takových případech bylo doporučeno přejít na novější verzi dané aplikace nebo na jiný alternativní SW v aktuální verzi, pokud je to možné. Nejde jen o otázku funkcionality, ale často také o otázku bezpečnostní. Nepodporované verze SW jsou nezáplatované, což může být především u rozšířených programů velmi nebezpečné. 3.3. Ověření postupů migrace v referenčním prostředí Před zahájením samotné migrace byly zvolené postupy migrace otestovány v referenčním prostředí. Z důvodů finančních škrtů se jednalo o referenční prostředí malého rozsahu. Skládalo se ze 3 virtuálních serverů, na kterých byly nainstalovány infrastrukturní prvky (domain controller, SCCM a WSUS), a několika referenčních osobních počítačů (virtuálních i fyzických). Prostředí bylo nejprve v oddělené VLAN, aby nezasahovalo do produkční sítě. V této fázi bylo ověřeno nasazování image pomocí PXE, přiřazování do AD domény a nasazování balíčků pomocí SCCM. Kvůli otestování koexistence s prostředím společnosti Novell, bylo následně nutné referenční prostředí připojit k produkční síti, protože připojení referenčního prostředí používaných služeb Novell by svým rozsahem přesahovalo možnosti použité infrastruktury. Z finančních i časových důvodů byl zrušen plánovaný pilotní provoz. Namísto něj bylo vybráno několik uživatelů, kterým se po ověření funkčnosti postupů v rámci referenčního prostředí provedla migrace přednostně. 3.3.1. Koexistence prostředí Novell a Microsoft Hlavním úkolem, který je potřeba vyřešit pro to, aby bylo možné obě technologie provozovat paralelně vedle sebe je zajištění synchronizace účtů a jednotné autentizace. Rozhodnutí nevytvářet uživatelské účty v prostředí AD sice oddálilo nutnost vytvoření mechanismu synchronizace účtů, ale uživatelské přihlášení to spíše znesnadnilo. Znamená totiž nutnost vytvářet na klientských stanicích lokální uživatelské účty. Dalším problémem je to, že administrátor vytvářející lokální účet samozřejmě nezná přihlašovací heslo daného uživatele. Klient Novell sice disponuje možností synchronizovat lokální heslo s heslem v Novell edirectory, v tomto případě je ale nutné první přihlášení provést ve spolupráci s uživatelem. Uživatel při prvním přihlášení zadá své heslo do prostředí 39
Novell, administrátor následně zadá iniciační heslo korespondujícího lokálního účtu a nastaví synchronizaci. Tímto dojde k synchronizaci obou hesel do tvaru hesla z prostředí Novell. Není tedy možné tento proces automatizovat. Na druhou stranu, jakékoli následné změny hesla, vyvolané ze strany serveru (vypršení platnosti hesla) i ze strany uživatele, proběhnou transparentně a hesla zůstávají i nadále synchronizována. Obrázek 17 - Změna hesla vyvolaná uživatelem. Mění se jak lokální heslo (uživatele test_ms3 na PC s názvem CSU213153), tak heslo prostředí Novell (uživatele test_ms3 ve stromu STATISTIKA). Sejmuto z OS. 3.4. Proces migrace 3.4.1. Volba metody nasazení Migrace byla prováděna metodou obnovy PC, někdy je tato metoda nazvaná také Wipe-and-Load. Spočívá v exportování uživatelských dat na jiné místo, reinstalaci OS a následné nahrání dat zpět na reinstalovaný PC. V případě, že je použita tenká image nebo obecně image, která neobsahuje všechny potřebné aplikace, je nutné následně doinstalovat jak je, tak i případné aktualizace. Vzhledem k tomu, že v původním nastavení PC byl harddisk rozdělen na 2 oddíly, kdy první, systémový oddíl, obsahující instalaci Windows XP byl veliký jen 20 GB nebo 30 GB, nebylo možné použít pro zálohování uživatelských dat metodu hardlinků. 30 GB je pro instalaci systémového disku ve Windows 7 příliš málo, bylo tedy potřeba přerozdělit HDD v jiném 40
poměru. Disk byl rozdělen na 100 GB 3 systémový oddíl a zbytek pro datový oddíl. U některých notebooků majících 80 GB HDD, byl poměr rozdělení určen na 50 GB + zbytek (cca 30 GB). Migrace probíhala formou LTI, s pomocí SCCM. ZTI byla bohužel vyloučena už proto, že instalované PC nebyly nastaveny tak, aby bootovaly pomocí Pre-Execution Environment (PXE), tedy pomocí síťové karty. Byl proto potřeba ruční zásah do BIOSu PC. Společnost navíc nemá vyvinutý dokument management a většinu dat, se kterými uživatelé pracují tak mají uloženu na svých lokálních discích. To představuje problém pro zálohování dat. Jelikož jsou všechna důležitá data na discích uživatelů, bylo rozhodnuto, že automatizovanému ukládání dat při migraci bude pro jistotu předcházet ještě ruční záloha dat (zálohování dat bude ještě věnována samostatná kapitola). 3.4.2. Obecný postup reinstalace PC Na místě (v kanceláři uživatele) Nastaven BIOS, tak aby bylo možné bootovat přes PXE, síťová karta byla posunuta na první místo bootovací sekvence. Při probuzení pomocí PC Wake-on-LAN nastaveno bootování na server. Přidání paměti RAM do PC, aby mělo k dispozici 2 až 4 GB. Zálohování těch dat, která musí probíhat pod uživatelským účtem (typicky osobní certifikáty 4 ). Vzdáleně Vytvoření účtu uživatelského PC (device) v SCCM. K tomu je potřeba zadat název PC, MAC adresu a SMBIOS GUID. 3 V případě uživatelů, kteří potřebují velký diskový prostor pro svá data, je možné nastavit systémový oddíl menší, aby zbylo více místa na datový oddíl. Nastavovat systémový oddíl na méně než 50 GB už ale představuje potenciální riziko, že velikost nebude stačit. 4 Pozor! Do uživatelského účtu je samozřejmě možné se dostat i bez pomoci uživatele resetováním hesla. V takovém případě, budou ale některá data porušena. Například pak nepůjde vyexportovat privátní klíč osobního certifikátu. 41
MAC adresa i SMBIOS GUID jdou získat z BIOSu daného PC nebo pomocí příkazů v OS: a) MAC adresa getmac b) SMBIOS GUID wmic csproduct get uuid Pozn.: Oba údaje je možné do formuláře vytvoření účtu vložit (není třeba je vypisovat). U MAC adresy to jde i přesto, že výpis pomocí příkazu getmac používá jako oddělovače bloků adresy pomlčku (-), zatímco SCCM očekává dvojtečku (:). Toto vložení ale nejde provést klávesovou zkratkou Ctrl+v, musí být provedeno pomocí myši přes kontextovou nabídku. Obrázek 18 - Přidání účtu počítače do SCCM (generováno z nástroje SCCM) Přidání účtu PC do kolekce s migrační task sekvencí a kolekcí pro instalace aplikací, které daný uživatel potřebuje ke své práci (myšleno aplikací, které nejsou součásti image). 42
Vzdáleně, po pracovní době uživatele Odkopírování uživatelských dat (prováděno jen pro jistotu, kdyby došlo k problému při průběhu migrace). Restart PC, po kterém se automaticky spustí migrační task sekvence nabootováním přes PXE (její součástí je záloha i následné obnovení uživatelských dat). Přiřazení balíčků s aplikacemi a nastavením, které se mají na PC nainstalovat pomocí SCCM po doběhnutí instalace OS. Vzdáleně před pracovní dobou uživatele druhý den Vytvoření lokálního účtu uživatele v nově nainstalovaném OS (specifický požadavek této konkrétní společnosti, běžně se nevytváří lokální, ale doménový účet). Případná donastavení prostředí nebo aplikací, která nebyla součástí migrační task sekvence ani dalších instalovaných balíčků. Na místě (v kanceláři uživatele) po jeho příchodu druhý den První přihlášení (opět kvůli specifickým požadavkům společnosti, dojde při něm k synchronizování hesla novellovského uživatelského účtu s heslem lokálního uživatelského účtu. Případná instalace osobního certifikátu uživatele. Případně jiných aplikací, u kterých je nutná přítomnost uživatele. 3.4.3. Záloha dat Data byla zálohována odkopírováním mimo PC a následným vrácením zpět po dokončení reinstalace PC. Důraz byl kladen především na pracovní data, uložená na datovém oddílu. Ta byla zálohována jednoduchým skriptem přidaným na začátek migrační task sequence SCCM, ještě před přerozdělení disku. Jejich obnovu zajistil obdobný skript přidaný jako jeden ze závěrečných kroků do stejné TS. Záloha byla provedena nástrojem ImageX, který vytvořil obraz datového disku. Výhoda tohoto trochu netradičního způsobu zálohování dat spočívá ve snadném naskriptování, použití komprese a schopnosti poradit si s příliš dlouhými názvy cest k souborům. K obnově byl použit nástroj DISM. Oba nástroje jsou dostupné v PE prostředí. Zde je vhodné upozornit na to, že instalace Windows 7 sice také obsahuje nástroj DISM, ale ve verzi, 43
která nezná parametr apply-image. Nejjednodušší způsob jak vrátit data zpět na datový oddíl je tedy využít DISM právě z preinstalačního prostředí. Skutečným oříškem se ovšem ukázalo být nalezení způsobu, jak pojmenovat soubor zálohy tak, aby obnovovací skript věděl, že se jedná o zálohu stroje, který právě instaluje. Situaci komplikoval fakt, že spolu s migrací docházelo ke změně konvence pojmenování PC. Původní název PC před migrací byl tedy jiný, než název po migraci. Původní instalace navíc neobsahovala agenta Configuration Manageru, který by si změnu PC pohlídal. Jako vhodné řešení se ukázalo být pojmenování složky se zálohou podle MAC adresy PC, která samozřejmě zůstává stejná po celou dobu migrace. Následují oba skripty 5 : Zálohovací skript ipconfig/all FIND /I "Physical Address" > c:\mac.txt for /f " tokens=11* delims=, " %%i in (c:\mac.txt) DO SET MACAddress=%%j mkdir i:\%macaddress% x:\windows\pkgmgr\imagex /capture d: i:\%macaddress%\zaloha.wim "ImageD" Obnovovací skript ipconfig/all FIND /I "Physical Address" > c:\mac.txt for /f " tokens=11* delims=, " %%i in (c:\mac.txt) DO SET MACAddress=%%j Dism /apply-image /imagefile:i:\%macaddress%\zaloha.wim /index:1 /ApplyDir:D:\ Před spuštěním migrace PC je vhodné pro jistotu zvážit zálohu dat ještě jiným způsobem např. klasickým kopírováním na síťový nebo externí disk. 3.4.4. Tvorba image Vzhledem k tomu, že infrastruktura potřebná k automatizaci migrace byla zajištěna pouze v ústředí společnosti, nastala potřeba vytvořit co nejtlustší, ale zároveň co nejobecnější image, která by mohla být použita především na detašovaných pracovištích (kraje a okresy). 5 Před zálohou i obnovou předchází v TS krok, ve kterém je připojen síťový disk (i:\). Pod písmenkem x: je namapováno ve výchozím nastavení preinstalační prostředí. 44
Tato image byla nakonec použita také v ústředí. Obzvláště proto, že byl nedostatek času na odladění TS založené na tenké image, a také pro jednoduchost a rychlost nasazení tlusté image. Image byla vytvořena na referenčním PC. Tento PC byl reprezentantem nejrozšířenějšího typu modelu používaného ve společnosti. Obsahovala aplikace, které se instalují na všechny počítače ve firmě a také společné nastavení. Pomocí nástroje Sysprep s použitím odpovědního souboru byl také vytvořen výchozí uživatelský účet (Default), který slouží jako šablona pro zakládání lokálních uživatelských účtů. Následuje obsah odpovědního souboru unattend.xml pro vytvoření výchozího uživatelského účtu: <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="specialize"> <component name="microsoft-windows-shell-setup" processorarchitecture="x86" publickeytoken="31bf3856ad364e35" language="neutral" versionscope="nonsxs" xmlns:wcm="http://schemas.microsoft.com/wmiconfig/2002/state" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <RegisteredOwner /> <CopyProfile>true</CopyProfile> </component> </settings> </unattend> Při vytváření image je vhodné vypnout tzv. rearm při použití nástroje Sysprep. Rearm obnoví odpočítávání zbývajících dnů zkušební doby. Lze však pro jednu instalaci OS použít maximálně 3x. Při dalším použití zobecnění OS pomocí nástroje Sysprep se nejenže neprovede rearm, ale samotné zobecnění OS neproběhne korektně. Vypnutí rearm při zobecnění image je možné nastavit také pomocí odpovědního souboru. Jeho obsah je následující: <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="generalize"> <component name="microsoft-windows-security-spp" processorarchitecture="amd64" publickeytoken="31bf3856ad364e35" language="neutral" versionscope="nonsxs" xmlns:wcm="http://schemas.microsoft.com/wmiconfig/2002/state" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <SkipRearm>1</SkipRearm> </component> </settings> </unattend> Samotné spuštění nástroje Sysprep pro vytvoření výchozího uživatelského účtu a následného nabootování do auditního režimu, který je vhodný na donastavení image, může vypadat například takto: 45
C:\Windows\System32\sysprep\sysprep.exe /generalize /audit /reboot /unattend:d:\unattend(defusr+skiprearm).xml 3.4.4.1. Přidání ovladačů Proto, aby bylo možné vytvořenou image nasadit na všechny modely PC používané ve společnosti, bylo potřeba dostat do ní ovladače všech zařízení obsažených v těchto modelech. K tomuto účelu lze velmi jednoduše použít nástroj DISM následujícím postupem (30): 1. Připojit (namountovat) image offline do souborového systému referenčního PC pomocí parametru /Mount-Image. 2. Přidat ovladače parametrem /Add-Driver. 3. Odpojení image pomocí parametru /Unmount-Image následovaného parametrem /Commit, který zajistí uložení změn v image. Ovladače k počítačům Dell lze stáhnout ve formě balíčků cab z následující stránky: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-driver-cabfiles-for-enterprise-client-os-deployment.aspx HP má pro tyto účely nástroj SoftPaq Download Manager, který je dostupný na jejich webových stránkách: http://www8.hp.com/us/en/ads/clientmanagement/driversbios.html?jumpid=va_r11260_go_clientmanagement_sdm#softpaq-download-mng 3.4.4.2. Nasazení image Nasazení image v ústředí probíhalo pomocí nástroje SCCM postupem popsaným v kapitole Obecný postup reinstalace PC. Nasazení na detašovaných pracovištích probíhalo ručně, pomocí upravených instalačních flash disků (FD). Ty byly vytvořeny z originálního instalačního média (formátu iso) pomocí nástroje Windows 7 USB/DVD Download Tool. Úprava spočívala ve dvou jednoduchých krocích: 1. Nahrazení původního souboru install.wim (v adresáři Source na FD) připravenou imagí. Název install.wim musí zůstat zachován. 2. Přidáním odpovědního souboru Autoattend.xml do kořene FD. Tento odpovědní soubor byl vytvořen pomocí nástroje Windows System Image Manager (SIM). 46
3.4.4.3. Task sequence Protože k nasazení nového OS byla aplikována tlustá image, nebyla použitá task sequence nijak dlouhá ani složitá. Neobsahovala přímo žádné aplikační balíčky. Jednotlivé aplikace byly dodány pomocí SCCM až následně. Použitá TS se skládala z následujících kroků: Nabootování do Windows PE Připojení síťového disku pro zálohu dat Záloha dat pomocí ImageX Rozdělení disku na systémový oddíl a datový oddíl Přiřazení písmene C:\ systémovému disku Aplikace image Nastavení OS Připojení k doméně Připojení síťového disku pro obnovu dat Obnova dat pomocí DISM Instalace a nastavení klienta Configuration Manageru 47
Obrázek 19 - Task sequence SCCM použitá při migraci (sejmuto z Configuration Manager Console) 3.5. Instalace aplikací Instalace aplikací nebyla součástí samotné migrační TS. Většina aplikací, které jsou ve společnosti využívány všemi uživateli, byla přímo součástí image. Ostatní aplikace se doinstalovaly dodatečně buď ručně nebo přiřazením balíčku a automatickou instalací přes agenta SCCM. SCCM rozlišuje mezi pojmy aplikace (application) a balíček (package). Zjednodušeně řečeno, aplikace jsou distribuovány pomocí msi souborů a ostatní instalace (většinou exe) ve formě balíčků. Všechny programy, od nichž se podařilo sehnat instalační soubor ve formě msi byly instalovány jako aplikace. To s sebou nese několik výhod. SCCM si dokáže z msi souboru vytáhnout potřebné informace o verzi, výrobci apod. Aplikace instalované pomocí msi se dají také snadno pomocí SCCM odinstalovat a lze mezi nimi nastavovat tzv. supersedence neboli nahrazení starší verze aplikace verzí novou. Instalační soubory typu exe, dávkové soubory s příkazy nebo adresáře a soubory, které bylo potřeba pouze překopírovat, byly distribuovány jako balíčky. 48
Obrázek 20 - Výřez ze seznamu použitých SW balíčků (sejmuto z Configuration Manager Console) Aplikace i balíčky je možné distribuovat dvěma způsoby. Buď jako vyžadované (required) nebo jako volitelné (available). Vyžadované se instalují automaticky bez ve vyhrazeném čase bez součinnosti uživatele. Volitelné aplikace jsou počítači (nebo uživateli) pouze dány k dispozici, nainstalují se až poté, co dojde k ručnímu spuštění instalace v aplikaci Centrum softwaru. 49