Bezobslužná instalace klientů pomocí nástroje Microsoft Deployment Toolkit

Transkript

1 VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačních technologií Studijní program: Obor: Aplikovaná informatika Informatika Bezobslužná instalace klientů pomocí nástroje Microsoft Deployment Toolkit BAKALÁŘSKÁ PRÁCE Student: Vedoucí: Oponent: Ondřej Chmelař doc. Ing. Alena Buchalcevová, Ph.D. Ing. Hynek Stehlík 2014

2 Prohlášení Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal. V Praze dne 13. května Ondřej Chmelař

3 Poděkování Tímto bych rád poděkoval mé vedoucí práce doc. Ing. Aleně Buchalcevové, Ph.D. za její čas, cenné rady a připomínky, hlavně pak psychickou podporu a důvěru. Dále děkuji své matce PaedDr. Vladimíře Chmelařové za její podporu během studia, bez které bych nemohl se studiem začít a také svému kolegovi Michalu Doležalovi, Dis., který mě k nasazování softwaru přivedl a mnohé mě v této oblasti naučil.

4 Abstrakt Tato práce řeší praktickou přípravu prostředí pro automatizovanou bezobslužnou skriptovanou instalaci operačních systémů Windows a softwaru na nich především pomocí nástroje Microsoft Deployment Toolkit. Důraz je kladem na parametrizovatelnost a jednoduchost správy celého řešení, které může být prodáno jako hotový produkt. Vytyčený cíl byl splněn založením prázdného repositáře nasazení a následným importováním ovladačů, operačních, systémů, aplikací, aktualizací a databází instalovaných zařízení. Podařilo se mi dosáhnout vysoké úspěšnosti a v práci jsem vytvořil systém, který je funkční, snadno ovladatelný, plně parametrizovatelný a připravený do ostrého nasazení. Přínosem této práce je kromě kompletního řešení běžného podnikového problému také snaha o přiblížení skriptovaných instalací odborné veřejnosti, která soudě dle informací získaných v průběhu sběru informací, stále preferuje klonovací metody. Klíčová slova Software deployment, Microsoft Deployment Toolkit, skriptovaný, nasazování softwaru, MDT, WDS.

5 Abstract This thesis addresses the practical realization of environment for unattended automated scripted installation of Windows operating systems and software running on them mainly using Microsoft Deployment Toolkit. Emphasis is put on parameterization and management simplicity of the solution, which can be sold as a finished solution. My objective was met by creating empty Deployment Share, and then importing the drivers, operating systems, applications, updates and database with installed computers. I managed to achieve a high success rate and in this thesis, I ve created system that is functional, easy to use, fully parameterized and ready to use in real world. The contribution of this work is in addition to a complete solution of the current business problem also trying to introduce bit deeply scripted installation to experts, which according to the experience gained during research, still prefers cloning methods. Keywords Software deployment, Microsoft Deployment Toolkit, scripted, MDT, WDS.

6 Obsah 1 Úvod Pojem nasazování softwaru Cíle práce Způsob dosažení Návrh řešení Příprava prostředí Testování řešení Vyhodnocení Rešerše zdrojů Nasazování softwaru - software deployment Nasazování koncových stanic Instalační strategie z hlediska míry interakce člověka Nástroj Microsoft Deployment Toolkit Princip síťové instalace MDT Jiné formy instalace Návrh řešení Výběr strategie interakce instalace Způsob instalace aplikací Správa ovladačů hardwaru Realizace řešení Definice laboratorního prostředí Instalace serverů a služeb AD DS Služby domény Active Directory WDS Služby pro nasazení systému Windows ADK Windows Assessmet and Deployment Kit for Windows 8.1 a Microsoft SQL Server 2012 Express MDT Microsoft Deployment Toolkit Příprava repositáře nasazení Založení nového repositáře nasazení a SQL databáze... 17

7 6.3.2 Zpracování operačních systémů Zpracování ovladačů Přidání aplikací Přidání počítačů Přidání aktualizací Microsoft Windows Přizpůsobení, generování a import Windows PE Otestování nasazovacího prostředí Otestování na virtuálním počítači Otestování na fyzickém počítači Komplexní uživatelský scénář použití připraveného řešení Obstarání ovladačů hardwaru Přidání počítačů do MDT databáze Příprava v Active Directory Aktualizace Windows PE Změna jména duplicitního počítače Aktualizace aplikace Úprava role Závěr Závěr Terminologický slovník Seznam literatury Seznam tabulek, výpisů a obrázků... 44

8 1 Úvod Nedílnou součástí životního cyklu každého softwarového produktu je jeho nasazení. S rostoucím počtem uživatelů nejrůznějších softwarových produktů a cenou práce počítačových odborníků roste důraz na co nejjednodušší a zároveň lehce parametrizovatelný a škálovatelný způsob distribuce softwaru ke koncovým uživatelům. Nasazování softwaru dnes musí být na takové úrovni, kdy si jednoduché softwary dokáží uživatelé nainstalovat díky připraveným nástrojům sami a složitější nesmí společnost stát cenné člověkohodiny svých ICT zdrojů. Oblastí nasazování softwaru, kterou v této práci analyzuji a realizuji, je bezobslužné nasazování softwaru v podnikových řešeních běžících v prostředí operačních systémů Microsoft Windows. Tato platforma byla zvolena kvůli své univerzálnosti a širokému praktickému využití. 1.1 Pojem nasazování softwaru Pojem nasazování softwaru zahrnuje všechny aktivity, které dělají softwarový systém připravený k použití. Obecně se proces nasazení softwaru skládá několika vzájemně souvisejících aktivit s možností přechodu mezi nimi. Tyto činnost se mohou vyskytovat jak na straně vývojáře, tak i spotřebitele, ale také u obou stran. Protože je každý softwarový systém unikátní, přesné proces procedur je těžce definovatelný. Proto je nasazování softwaru interpretováno jako obecný proces, který je třeba přizpůsobit specifickým požadavkům nebo charakteristikám. [1] Nasazování softwaru začíná po jeho dokončení vývojovým týmem a končí odinstalací, případně ukončením podpory ze strany výrobce či dodavatele. V této práci se zaměřuji na oblast hromadného nasazení hotových softwarových produktů a jejich základního nastavení v podnikovém prostředí. Klíčovým předpokladem použitelnosti v tomto druhu řešení je připravenost aplikací, která je naštěstí v tomto ohledu na dobré úrovni. Celý proces pak probíhá jako jedna velká sekvence skriptů. 1

9 1.2 Cíle práce Cílem bakalářské práce je připravit řešení pro centrální síťové instalace koncových stanic v prostředí školních zařízení. Součástí řešení je také analýza, návrh, otestování a vyhodnocení. Instalace musejí probíhat s minimálním zásahem člověka. Testování řešení probíhá v laboratorním prostředí simulujícím podnikovou síť nasazením operačního systému a několika aplikací na třech stanicích. Důraz je kladen také na pružnost celého řešení, které nebude potřeba při drobné aktualizaci prostředí složitě a draze rekonfigurovat. Jde tedy o model, ve kterém je příprava řešení outsourcována na specializovanou externí společnost a správu poté provádí lokální všeobecně zaměřené IT oddělení. Dalším neméně důležitým požadavkem je míra zásahu do aktuálního prostředí a cena celého řešení. 1.3 Způsob dosažení Z důvodu snadné obsluhy podobné mnohým dalším nástrojům Windows Serveru, cenové dostupnosti (licence zcela zdarma) a nutnosti minimálních zásahů do produkčního prostředí byl vybrán nástroj Microsoft Deployment Toolkit Návrh řešení Při návrhu řešení jsem čerpal ze své praxe v instalacích operačních systémů, aplikací i ovladačů v prostředí školních zařízení, které jsou navíc specifické omezeným výkonem hardwaru a silně nejednotným prostředím, kde podcenění analýzy a zvolení špatné logiky nasazování vede k velmi pracné správě systému, která s sebou nese nejen nadbytečné náklady, ale také zbytečnou alokaci kvalifikovaných pracovníků a více příležitostí k chybám. Dalším dopadem nezohlednění cílového prostředí je pomalost celého nasazovacího procesu, který může na starším hardwaru trvat neúměrně dlouho Příprava prostředí Také samotná příprava laboratorního prostředí vyžadovala analýzu, jejíž cílem bylo zvolit parametry prostředí tak, aby bylo realizovatelné ve studentských podmínkách a zároveň se co nejvíce podobalo skutečnému nasazení v praxi. Vzhledem k absenci dostupné laboratoře s volným serverem byla zvolena cesta 2

10 virtualizace na notebooku a použití instalačních medií pro akademické použití z webu Microsoft Dreamspark Testování řešení Funkčnost a ovladatelnost navrženého řešení je ověřena simulací několika scénářů, se kterými se lidé zodpovědní za nasazování softwaru běžně setkávají a které mohou při správě nastat. Kromě virtuálních klientských počítačů s omezenými možnostmi modifikace hardwaru byl použit také jeden fyzický počítač, starší notebook Philips Freevents X Vyhodnocení Vyhodnocení návrhu zohledňuje především ovladatelnost a tvárnost celého řešení, které je připraveno k předání správcům nasazování softwaru, kteří nemusejí přesně znát všechny principy a zákonitosti, které místo nich ovládá specializovaná outsourcovaná firma. 3

11 2 Rešerše zdrojů V této kapitole jsou uvedeny použité zdroje, které se zabývají nasazováním softwaru a obecnými definicemi používaných pojmů a jsou relevantní pro tuto práci. Najít ucelenou knihu na toto téma nebyl vzhledem k povaze tématiky a jejího rychlého vývoje snadný úkol. Nakonec jsem však našel knihu zahraničních autorů, kteří jsou ve světě nasazování softwaru velmi známé a uznávané osobnosti [2]. Publikace je vydána pouze v anglickém jazyce, což se nakonec ukázalo jako velmi přínosné, neboť zdroje v jiném jazyce prakticky nejsou dostupné a není tedy nezbytné pro účely vyhledávání studovat terminologie v dalších jazycích. Kniha je čtvrtým pokračováním série o nasazování software a nejsou zde proto naprosté základy práce s nástrojem Microsoft Deployment Toolkit. Důraz je kladem především na novinky v nasazování software, které s sebou přinesly Microsoft Windows 8 a pokročilé virtualizační funkce jako VDI a App-V. Praktické návody a analýzy začínají samotnou přípravou na přechod ze starších verzi Windows právě na verzi 8. Tyto scénáře jsou v době ukončení podpory Windows XP jistě velmi aktuálním tématem, ale rozcházejí se s mou filozofií nasazování software, která staví na maximálně čistých řešeních a přenášet případný nepořádek z verze na verzi není dle mého čisté řešení. V dalších kapitolách jsou rozebrány možnosti automatizace nasazování novinek typu Windows RT, Windows To Go nebo přepracovaná spolupráce s UEFI 1. Nechybí ani zvláštní kapitola o nasazování Microsoft Office 2013, které tvoří aplikační základ velkého množství prostředí, kde má automatizované nasazení softwaru smysl (střední a velké podniky). Dalšími zdroji jsou především nejrůznější znalostní databáze [3, 4, 5, 6, 7, 8, 9], které jsou často jediným důvěryhodným pramenem zastřešeným samotným autorem specifikace daného pojmu. Vzhledem k tomu, že cílové prostředí a nasazovací nástroj jsou postaveny na technologiích společnosti Microsoft, není překvapením velké množství pramenů v Microsoft TechNet Library [10, 11, 12, 13, 14, 15, 16] a Microsoft Developer Network [17, 18]. 1 Unified Extensible Firmware Interface = rozhraní mezi operačním systémem a hardwarem 4

12 Posledními zdroji, které však nelze citovat, jsou školení mého kolegy Michala Doležala, DiS., který mě do problematiky nasazování software uvedl a osvětlil základní pojmy a zákonitosti, a školení pořádané pod záštitou Windows User Group občanského sdružení fungující díky podpoře společnosti Microsoft, které pravidelně pořádá večerní přednášky pro IT profesionály na aktuální témata. Přednášející jsou Microsoft MVP (Microsoft Most Valuable Professional), což zaručuje velmi vysokou informační hodnotu a zaručeně správné a podporované postupy. Poslední navštívená akce byla na téma Deployment Windows II. část [19]. Poslední pramen nelze hodnotit jako zdroj, ze kterého jsem přímo čerpal. Jedná se o knihu. Tvorba informačních systémů: principy, metodiky, architektury [20], která mne provázela dosavadním studiem a jako celek mi pomohla pochopit principy informačních systémů, mezi něž nasazování softwaru rozhodně patří. Bez tohoto nepřímého zdroje by práce nemohla být pochopena v souvislostech, v jakých je zamýšlena. 5

13 3 Nasazování softwaru - software deployment V této kapitole je obecně popsán teoretický základ a principy nasazování koncových stanic, tzv. deploymentu. Tato část je důležitá pro pochopení podstaty fungování automatizovaného nasazování a jeho možností. Nasazení je dle metodiky RUP definováno jako Disciplína v procesu softwarového inženýrství, která zajišťuje přenos vyvinutého systému k jeho uživatelům. [21] 3.1 Nasazování koncových stanic V oblasti nasazování operačních systémů a aplikací se vyžívají dvě metody instalací - první založená na obrazech disků (image based, naložena na bitových kopií, tzv. ghostování ) a skriptovaná instalace (scripted install). Pozn.: Obě metody jsou založeny na skriptech, avšak jen u druhé jmenované jsou také aplikace instalovány pomocí skriptů. Používanější metodou je využívající obrazy disků založená na klonování vzorového počítače. Ten se ručně nainstaluje a nastaví, proběhne generalizace (zobecnění odstranění uživatelských profilů, jména počítače, atd.) a zachycení vzorového (referenčního) obrazu disku, tzv. Golden Image. Tento způsob je velmi oblíbený díky rychlosti nasazení a jednoduchosti konfigurace. Jeho smysl je nevíce vidět např. v bankovních institucích, kde je potřeba všechny softwarové konfigurace schvalovat a kde je držen standard v modelech počítačů. Zjednodušeně řešeno instituce nakoupí např stejných počítačů, připraví jeden referenční obraz, u něj provede patřičné interní certifikace a ten pak použije na všech zařízeních. Alternativní skriptovaná instalace instaluje aplikace pomocí skriptů využívajících bezobslužné parametry instalátorů, případně transformačních balíčků. Tato instalace je složitější na konfiguraci, avšak mnohem flexibilnější a čistější žádné klonování, vše je nastaveno na míru konkrétního počítače. Doplňkovou formou instalace aplikací je spuštění instalátoru na základě skupinových politik (Group Policy). Tato metoda se však opouští, neboť je omezena jen na balíčky MSI, není v dostatečné míře pod kontrolou a vznikají nepříjemné 6

14 situace (např. celé oddělení přijde v 9 hodin do kanceláře a všude se začne v jeden okamžik instalovat software ze síťového zdroje). Dalším problémem je chování v případě detekce jiné verze stejného programu tato situace vytváří konflikty a při špatné konfiguraci může politika zvolený software naopak odinstalovat. V této práci touto metodou proto dále nezabývám. 3.2 Instalační strategie z hlediska míry interakce člověka Nasazování rozlišuje tři různé režimy (strategie) instalace a to kompletně bezobslužnou instalaci (Zero Touch Installation - ZTI), instalaci s minimálním počtem zásahů člověka (Lite Touch Installation - LTI) a instalaci řízenou uživatelem (User Driver Installation - UDI). U kompletně bezobslužné instalace (ZTI) jsou všechny volby učiněny za uživatele a tomu v ideálním případě stačí pouze počítač zapnout, ve spolupráci s technologiemi vzdálené správy na úrovni hardwaru jako např. Intel vpro není potřebný ani tento krok, avšak vzdálená správa stanic na této úrovni není předmětem této práce. Ve znalostní bázi společnosti Microsoft je ZTI definováno tímto způsobem. Jako nasazovací nástroj je zde uveden Configuration Manager, avšak princip strategie je stejný napříč programy a prostředími. Tato strategie nevyžaduje žádnou interakci během nasazování softwaru. Proces je plně automatizován přes Configuration Manager 2007 R2. Doporučujeme tuto strategii, pokud má vaše organizace experty na nasazování softwaru, počítačové sítě a produkty Configuration Manageru 2007 R2, a máte řízenou síť s více než 500 klientskými počítači. [12] Instalace s minimálním počtem zásahů člověka (LTI) vyžaduje jednoduchou akci od uživatele, nejčastěji tzv. deployera, která pro konkrétní zařízení doplní unikátní parametry nebo jednoduše jen předá přístupové údaje pro přístup na nasazovací server. Tato práce se věnuje tomuto režimu instalace. Jak vyplývá z níže uvedené citace společnosti Microsoft, jedná se o ideální kompromis vhodný i pro instalace simulované v této práci. Tato strategie vyžaduje určitou interakci během nasazení. Akce je vyžadována na začátku instalace a zbylý proces je již bezobslužný. Doporučujeme 7

15 tuto strategii, pokud má vaše organizace vyčleněný IT personál a řízenou síť s klientskými počítači. Předešlé zkušenosti s nasazováním softwaru nejsou vyžadovány, ale jsou přínosné pro používání této strategie. [13] Instalace řízena uživatelem (UDI) je nejméně užívanou metodou, avšak i tuto MDT nabízí. Uživatel zde vybírá veškeré parametry, což je často nejen nad uživatelské schopnosti, ale také mimo bezpečností politiky. Citace od společnosti Microsoft obsahuje zmínku o Configuration Manageru, avšak princip UDI je u všech nástrojů stejný. Uživatelsky řízená instalace je řešení založeno na Configuration Manageru 2007 R2 umožňující technikům a/nebo koncovým uživatelům vybrat nejrůznější nasazovací nastavení během instalace: Nastavení jazyková, Bitlockeru, nebo jaké aplikace mají být nainstalovány. Zkráceně řečeno je to forma nasazování softwaru viditelna a ovladatelná uživateli. Ale není to jen to UDI přichází také s navrhovacím nástrojem, který umožňuje správcům navrhovat uživatelskou část. - [3] 8

16 4 Nástroj Microsoft Deployment Toolkit Vzhledem k cílovému prostředí školního zařízení je použit bezplatný nástroj Microsoft Deployment Toolkit (dále také jako MDT, dříve známý pod názvem Business Desktop Deployment - BDD). Tento nástroj umí jak základní nasazení podobné standardní Windows Server roli WDS (Windows Deployment Services), tak i komplexní nasazovací systém postavený nad SQL databází pracující s parametry každého klienta. Současná verze 2013 umožňuje nasazení Microsoft Windows verze 7 a vyšších [11], avšak při úpravě skriptů a sekvencí nebo využití čistě klonovací metody principiálně dokáže nasadit také nižší verze, kterými se vzhledem k jejich neaktuálnosti nebudu zabývat. Nástroj umožňuje také instalaci serverových operačních systémů, avšak jedná se jen o funkcionalitu vyplývající z povahy obrazů disků bez hlubšího reálného použití. Jednotky serverů je vždy lepší pohlídat ručně a větší množství identických serverů není běžný scénář prostředí pro bezplatný Microsoft Deployment Toolkit. 4.1 Princip síťové instalace MDT Samotné nasazování začíná spuštěním bootovací 2 sekvence počítače z PXE (Pre- Execution Environment, čili ze sítě) do Microsoft Deployment Toolkitem vygenerovaných Windows PE (Preinstallation Environment), v nichž jsou v závislosti na zvolený režim instalace získávány od uživatele parametry instalace. Přenos obrazu disku probíhá protokolem TFTP (Trivial File Transfer Protocol). V případě strategie zvolené v této práci (LTI) se zadají pouze přístupové údaje k diskům se sdílenými soubory k nasazení. Na základě identifikace počítače pomocí MAC adresy použité síťové karty (Media Access Control) a/nebo WMI (Windows Management Instrumentation) jsou pak všechny ostatní údaje vyplněny automaticky dle záznamů v SQL databázi (Structured Query Language) provázaných s položkami v repositáři nasazení (Deployment Sharu). Součástí parametrů je také sekvence úkolů (Task Sequence), která řídí celý proces nasazení. Sekvence úkolů je možné 2 Boot = spouštění operačního systému počítače 9

17 vytvářet vlastní, případně využít připravené šablony zajištující hladký průběh celé operace. 4.2 Jiné formy instalace MDT kromě svého primárního zacílení na síťové instalace podporuje také vypálení instalačního repositáře na optický disk nebo flash disk. Tato funkcionalita má smysl při výjezdu na vzdálenou pobočku se slabou nebo žádnou konektivitou na server s repositářem. Jedná spíš o nouzové řešení, které přichází o výhodu velmi pružného deploymentu a instalační medium má tak statickou podobu jako klonovaný obraz disku. Navíc je zde problém s velikostí repositáře, který často vyžaduje dvouvrstvé DVD disk nebo USB flash disk vyšších kapacit. 10

18 5 Návrh řešení V této kapitole jsou vybrány a obhájeny klíčové parametry nasazování softwaru, které ovlivní celkový pohled na aplikovaný scénář. Tyto volby jsou rozsah interakce administrátora/uživatele a vlastnosti používaných obrazů disků. 5.1 Výběr strategie interakce instalace Při návrhu řešení je nutné nejdříve zvolit režim interakce instalace. V ideálním případě se nabízela plně bezobslužná instalace (ZTI). Ta však není z bezpečnostního hlediska ideální, protože do sebe zapisuje přístupové údaje do repositáře nasazení a SQL databáze. Dalším rizikem je také omezený přehled o instalacích, což může vést k odcizení softwarových licencí a/nebo sabotáž repositáře nasazení. Zvláště ve školním prostředí hrozí riziko, že student prolomí heslo do systému BIOS vyjmutím CMOS baterie, spustí bootovací sekvenci ze síťového zdroje, který tak jednoduše zformátuje počítač a v případě skriptované instalace také dostane přístup do repositáře nasazení, spouštění skriptů zastaví a obsah disku si zkopíruje, případně jej smaže. Uživatelsky řízená instalace zde nepřichází v úvahu, tu si lze představit jen mimo produkční prostředí nebo mezi velmi zkušenými uživateli. Byla tedy zvolena instalace s minimálním zásahem člověka (LTI) jsou vyžadovány jen přístupové údaje do repositáře nasazení. Tato strategie se osvědčila jako ideální kompromis mezi bezpečností a náročností na správu. Navíc při změně hesla není potřeba celý inicializační Windows PE obraz znovu vygenerovat a importovat do WDS serveru Způsob instalace aplikací Nejrozšířenějším způsobem instalace operačního systému a aplikací je metoda založena na obrazech disku (image based), tedy klonování ručně instalovaného a nastaveného systému. Tento způsob je dobrý např. do bankovního prostředí, kde jsou všechny počítače stejné a obsahují stejnou softwarovou sadu, která podléhá určitému schvalovacímu a testovacímu procesu. V této práci jde o instalaci do školního prostředí, což s sebou obnáší větší počet hardwarových konfigurací a softwarových sad, které nelze všechny integrovat do jednoho velkého obrazu, protože místní hardware je obvykle silně podprůměrný. 11

19 Zvolena byla tedy forma instalace pomocí instalačních skriptů jednotlivých aplikací. Výhodou této instalace je jednoduchá editace softwarové sady, která spočívá v editaci konkrétní sekvence, případě přepsání instalačního souboru v repositáři nasazení. Kvůli změně tak není potřeba ručně instalovat operační systém a všechny programy s výjimkou editovaného a následně zachytávat tzv. Golden Image (referenční obraz disku). 5.2 Správa ovladačů hardwaru Po zralé úvaze o celkovém množství variant ovladačů byla zvolena skriptovaná instalace, která počítá s holým systémem, tzv. Thin Image [2], do které je potřeba vše potřebné přidat v průběhu instalace, což přináší otázku integrace ovladačů hardwaru. MDT nabízí i bez spolupráce s SQL databází zahrnutí aplikovaných položek pomocí tzv. Selection profilů (výběrové profily). Tato funkcionalita je velmi dobře využitelná při výběru ovladačů hardwaru přímo na míru instalovanému počítači, což značně redukuje čas instalace, která nemusí nahrávat gigabajty dat, které počítač stejně nevyužije. Obrazy disku s integrovanými kompletními sadami ovladačů se označují jako Thick Image. [2] 12

20 6 Realizace řešení Praktické poznatky jsou shrnuty v této kapitole, která je pojata jako popis postupu při realizaci cíle práce vytvoření řešení. V postupech nejsou uvedeny slepé uličky a nevydařené pokusy, takže celou kapitolu lze využít také jako jednoduchou příručku objasňující pozadí přípravy systém, případně pomůcku správci dodaného nasazovacího systému, který si nebude jistý významem jakýchkoliv kroků při správě. 6.1 Definice laboratorního prostředí Hardwarový základ laboratorního prostředí tvoří hypervisor 3 notebook HP Elitebook 9470m. Zátěž je rozložena mezi SSD disk a plotnový harddisk se otáčkami, což ve spolupráci se šestnácti gigabajty operační paměti RAM a procesorem Intel Core i5-3437u zaručuje rychlý běh dvou až čtyř virtuálních strojů tvořících laboratorní prostředí. Dalším fyzickým zařízením je opět notebook, Philips Freevents X55 s procesorem Intel Core2 Duo, avšak ten je pouze v roli klienta, na kterém probíhá testování nasazování softwaru na fyzický stroj. Jeho jméno je BCPC3.BC.LAB. Mezi kolejní sítí VŠE a laboratorní prostředí je posazen síťový prvek D-Link DI-524 sloužící jako router oddělující vnitřní a vnější síť, DHCP server (Dynamic Host Configuration Protocol) a switch. Obrázek 1: Topologie laboratorní sítě Softwarová část je založena na produktech firmy Microsoft a to konkrétně Windows 8.1 s rolí hypervisora Hyper-V, pod nimiž běží dva servery s operačním 3 Hypervisor, označován také jako správce virtuálních strojů, je program, který umožňuje běh více operačních systémů sdílejících zdroje jednoho hostitele. [19] 13

21 systémem Windows Server 2012 R2. První (jméno BCDC1.BC.LAB) plní roli doménového kontroléru (Active Directory Domain Services) a DNS serveru (Domain Name Services). DNS role je nutná z důvodu uložení doménových konstant např. kde hledat doménový kontrolér nebo WDS server. Doména se jmenuje BC.LAB a její funkční schéma je na úrovni Windows Serveru 2012 R2. Druhý server (BCAPP1.BC.LAB) je koncipován jako aplikační a běží na něm role WDS (Služby nasazení Windows - Windows Deployment Services). Dále je na něm nainstalováno MDT a Microsoft SQL Express server sloužící k uložení databáze počítačů, rolí, aplikací a dalších parametrů nasazování. Kromě serverů jsou virtualizovány také dva klienti, BCPC1.BC.LAB a BCPC2.BC.LAB, jež běží pod Windows bit, resp. Windows 7 32bit. Všechny virtuální stroje jsou připojeny přes virtuální switch přímo na fyzický switch neprobíhá tedy tzv. NATování (Network Address Translation) mezi hypervisorem a klienty. 6.2 Instalace serverů a služeb Součástí práce je i zdokumentování způsobu instalace a konfigurace serverů umožňující lépe pochopit podpůrné nástroje, které jsou nezbytnou součástí nasazovacího prostředí AD DS Služby domény Active Directory Nejdříve je nutné založit novou doménu, ve které budou všechna zařízení, což umožní jejich lepší správu. Jelikož je připravováno nasazování softwaru pro Microsoft Windows prostředí, nabízí se adresářová služba Active Directory. Ta se instaluje formou aktivace role na Windows Serveru, přičemž se definuje její název (v tomto případě BC.LAB) a úroveň funkčního schématu (případě této práce nejvyšší, tj. Windows Server 2012 R2). Doménový kontrolér (BCDC1.BC.LAB) se do ní přidá automaticky, druhý server (BCAPP1.BC.LAB) musíme přidat ručně. 14

22 Obrázek 2: Parametry nasazovacího serveru (Zdroj: Autor) WDS Služby pro nasazení systému Windows Základem pro inicializaci klienta ze síťového zdroje jsou Služby pro nasazení systému Windows (Windows Deployment Services WDS). Tato služba publikuje obrazy disku, kterými se klienti mohou inicializovat a které obsahují buď kompletně připravené instalace operačních systémů, nebo jen nástroje pro jejich nasazení. Případ této práce je ten druhý tj. klient se inicializuje do předinstalačního prostředí Windows (Windows Preinstalltion Enviroment Win PE), to připraví na disk instalaci a smaže se. Po restartování se spustí přípravné soubory, které dokončí instalaci. WDS je další z rolí Windows Serveru, takže její aktivace probíhá jednoduchým průvodcem v nastavení serveru. Po aktivaci je nutné server nakonfigurovat pro práci v adresářové službě Active Directory, určit místo uložení jeho pracovních souborů a zvolit režim odpovídání: Neodpovídat žádným počítačům Odpovídat pouze známým počítačům Odpovídat všem známým i neznámým počítačům o Vyžadovat potvrzení pro neznámá zařízení ve správcovské konzoli. Byla vybrána možnost odpovědi všem počítačům, která vyžaduje nejméně administrativy, kterou je cílem minimalizovat z důvodu předání dalším uživatelům 15

23 nasazování softwaru. Bezpečnost je řešena až na úrovni Windows PE, kde je nutné zadat přihlašovací údaje pro přístup do repositáře nasazení ADK Windows Assessmet and Deployment Kit for Windows 8.1 a Microsoft SQL Server 2012 Express ADK je balík nástrojů pro práci s instalacemi operačních systémů Windows, a proto je vyžadována pro chod MDT. Tato prerekvizita obsahuje nejen potřebné obrazy disků Windows PE a podpůrné programy, ale také instalační sekvenci Microsoft SQL Serveru 2012 Express pro snadné použití databáze k MDT. Ve velkých instalacích se nepoužívá SQL Express, ale plnohodnotný SQL server, kde se vytvoří další instance, která bude vyhrazena pro MDT. Při použití instalace pomocí ADK průvodce je automaticky připravena instance ADK. Ve výchozím stavu není u databáze povolen přístup pomocí Named Pipies 4, které jsou v MDT výchozí doporučovaná metoda. Bez tohoto zásahu nelze databázi připojit. Obrázek 3: Povolení protokolu Named Pipies na databázi MS SQL Serveru (Zdroj: Autor) 4 Named Pipe je pojmenovaná jedno- nebo dvousměrná komunikační cesty mezi serverem a jedním nebo více klienty. Všechny instance named pipe sdílejí stejné jméno, ale každá instance má své vlastní mezipaměti a spouštěče a poskytují samostatný kanál pro komunikace klientů se servery. Užití instancí umožňuje více klientům přistupovat k jedné named pipe současně. 16

24 6.2.4 MDT Microsoft Deployment Toolkit MDT je bezplatný nástroj volně ke stažení z webu Microsoft.com, aktuální verze byla publikována 16. října Instalace probíhající v pár krocích neumožňuje téměř žádné parametry. Obrázek 4: Konkrétní verze použitého Microsoft Deployment Toolkitu (Zdroj: Autor) 6.3 Příprava repositáře nasazení Tato kapitola shrnuje předpokládaný ideální postup při založení a následné konfiguraci repositáře nasazení Založení nového repositáře nasazení a SQL databáze Nový repositář nasazení se zakládá v ovládací konzoli MDT jménem Deployment Workbench, která je zásuvným modulem do standardní Microsoft Management Console (MMC). Kromě umístění celého repositáře na pevném disku se zde definuje také zjednodušená UNC (univerzální síťová) cesta. 17

25 Obrázek 5: Adresářová struktura repositáře nasazení na disku (Zdroj: Autor) Dále je třeba připojit samotnou databázi, pro kterou byla připravena ADK instance SQL serveru. Nedílnou součástí procesu je povolení síťového protokolu Named Pipes na příslušné instanci. Po úspěšném připojení lze volit mezi připojením stávající databáze nebo vytvořením nové. Volba připojení stávající databáze bude užitečná při přenosu nasazování k zákazníkovi, nyní je však cílem tvorba nové databáze. Dokončením průvodce je repositář nasazení včetně databáze připraven k použití. Obrázek 6: Připravené repositář nasazení a připojená SQL Express databáze (Zdroj: Autor) 18

26 6.3.2 Zpracování operačních systémů Prvním krokem je importování operačních systémů, konkrétně jejich bitových kopií. Po této akci je nutné k obrazům přiřadit instalační sekvence úkolů, které celou instalaci řídí a nahrazují tak připravené nastavení na instalačních discích, které doplňují o vlastnosti poskytnuté databází MDT Import operačních systémů MDT nabízí hned několik zdrojů importování operačního systému a to: Plná sada zdrojových souborů vybírá se přímo obsah instalačního disku Vlastní soubor WIM využití při importování zachycených obrazů disku WDS obrazy možnost importu obrazů z WDS serveru V této práci byla zvolena první možnost, zdrojová media jsou oficiální edice z webu Microsoft Dreamspark. Následujícím krokem je definice jména složky, pod kterou budou soubory uloženy v repositáři nasazení. Samotný import je časově vcelku náročná operace, protože kromě kopírování několika gigabajtů dat do repositáře probíhá také extrakce souborů, jejich analýza a zpracování pro účely užití v MDT. V našem případě byly z disků rozpoznány dvě edice Windows 8.1 a pět edicí Windows 7. Zvláštností je, že při bootování z disků není výběr edice povolen. Obrázek 7: Seznam nalezených operačních systému nalezených na dvou mediích (Zdroj: Autor) Definování sekvence úloh Sekvence úloh (Task Sequence) je stavebním kamenem procesu nasazování softwaru. MDT nabízí mnoho šablon operací, pro které je optimalizováno, avšak nic nebrání uživateli sestavit vlastní sekvenci. Díky této funkcionalitě není třeba znát všechny jednotlivé kroky nasazování softwaru ty jsou předpřipraveny a uživatel je 19

27 může dle potřeby doladit. Pro účely této práce poslouží šablona Standard Client Task Sequence, která nainstaluje importovaný operační systém na klientský počítač. V dalších krocích lze kromě konkrétního operačního systému definovat také aktivační klíč (vhodné pro firemní multilicenční instalace bez aktivačního serveru, např. KMS Key Management Services), jméno a heslo výchozího uživatele a lokálního správce, označení organizace nebo domovskou stránku. V této práci se aktivace vůbec neřeší, neboť jejich počet je u školní licence omezen a nutné soubory pro aktivační KMS server nejsou součástí školní licence. Obrázek 8: Možnosti sekvencí úloh, které MDT nabízí (Zdroj: Autor) Zpracování ovladačů Ovladače hardwaru jsou alfou a omegou velkého množství problémů s instalacemi. Málokterá situace je hůře řešitelná, než když operační systém, tedy prostředník mezi hardwarovými zdroji a aplikacemi, špatně spolupracuje s hardwarem. Zpracování ovladačů je fáze přípravy nasazování softwaru, která více než jakákoliv jiná vyžaduje důkladné praktické otestování Získání ovladačů V podnikovém prostředí uvažujme převážen značkové počítače renomovaných výrobců s příslušnou podporou v podobě dostupnosti repositáře aktuálních a otestovaných ovladačů například na svých webech nebo FTP serverech. Zde je získání jednoduché a spočívá ve stažené jednotlivých balíčku, případně obrovských balíků obsahujících veškeré ovladače. Už jsem se dokonce setkal s balíky přímo pro Windows PE. 20

28 U neznačkových skládaných konfigurací nejsou tyto balíky k dispozici, a proto je získávání realizované buď metodou pokus-omyl, případně ruční instalací a poté extrakcí pomocí nástrojů třetích stran. Osvědčil se mi nástroj Double Driver od autora Budy Setiawan Kusumah [22], který slouží primárně k záloze ovladačů, avšak k účelům nasazování softwaru slouží stejně dobře. Obrázek 9: Aplikace Double Driver (Zdroj: [22]) Ovladače virtuálního hardwaru lze získat extrakcí integračních balíčků, v tomto případě to jsou Hyper-V Integration Services nacházející se v balíčku %windir%\system32\vmguest.iso na hypervisorovém stroji Organizace ovladačů MDT umožňuje třídění importovaných ovladačů do jednotlivých adresářů, což s sebou přináší snazší třídění a definování výběrových profilů. Struktura je plně v režii uživatele, v tomto případě jsem zvolil logiku výrobce model operační systém. 21

29 Obrázek 10: Výsledkem analýzy je tato hierarchie ovladačů (Zdroj: Autor) Import ovladačů Import probíhá obdobně jako v případě operačních systémů a to vybráním příslušné složky, jejíž obsah se analyzuje (vyhledají se soubory ovladačů, jako jsou např. INF), zkopíruje do nasazovacího sdílení a zařadí do zvoleného adresáře. Podstatná je identifikace třídy ovladače z důvodu přidání ovladačů síťové karty a úložiště přímo do Windows PE (jinak by ani nemohlo začít kopírování instalačních souborů). Obrázek 11: Scanování složky a import nalezených ovladačů (Zdroj: Autor) 22

30 Definice výběrových profilů Tzv. výběrové profily spojují importované prostředky do logických celků, se kterými je pak mnohem snazší manipulace. Výběrový profil může zahrnovat: Celé nasazovací sdílení Aplikace Operační systémy Ovladače Balíčky (aktualizační) Sekvence úloh Nejčastější využití nacházejí při sdružování ovladačů, které tak mohou vybrat například ovladače konkrétního modelu pro konkrétní operační systém. Kromě přehlednosti se tím docílí také zmenšení přenášeného objemu dat a urychlení instalace, protože není třeba přidat nepoužitelné ovladače. Obrázek 12: Způsob výběru zahrnutých ovladačů (Zdroj: Autor) Přidání aplikací Import aplikací nabízí stejně jako import operačních systémů volbu více druhů zdrojů, odkud je možné čerpat. Kromě zahrnutí složky se zdrojovými soubory nabízí také odkaz na existující síťovou složku. Osobně jsem tuto funkcionalitu využil při nasazování balíku CAD softwaru od společnosti Autodesk, který tvoří vlastní repositář a není proto nutné jej duplikovat, což kromě narušení celistvosti tichého instalátoru přináší vzhledem ke své velikosti také obrovské ztráty cenného 23

31 diskového prostoru. Poslední možností je vytvoření balíku dříve přidaných aplikací, který může reprezentovat například globální aplikační základ nebo specializovaný software včetně jeho prerekvizit instalovaných v přesném pořadí. Základním předpokladem úspěšného importu aplikace a hlavně jejího nasazení je bezobslužný a tichý chod jejího instalátoru. Bez této podmínky se sekvence zastaví a bude čekat na interakci uživatele Parametry tiché instalace Nejjednodušší formou bezobslužné instalace jsou tiché parametry instalátoru, na které reaguje každá rozumně napsaná aplikace. Tyto parametry jsou nejčastěji: /s, /silent, /q, /quiet. případně přesnou frázi poradí parametr /?. Vše je bohužel plně v režii konkrétního vývojáře. Kromě definice argumentů do main metody instalátoru se u pokročilých balíků využívá instalační služba Windows msiexec, která se stará o korektní instalaci, odinstalaci a opravu balíků MSI (Microsoft Installer). Tato metoda má nespornou výhodu v tom, že se jedná o standard jakékoliv MSI vždy reaguje na obecné parametry. Obrázek 13: Získání bezobslužných parametrů instalátoru GIMP (Zdroj: Autor) 24

32 Transformační balíčky Nejpokročilejší formou nasazování aplikací jsou instalace doprovázené transformačními balíčky, které kromě úpravy instalátoru s sebou nesou také kompletní nastavení softwaru od jeho instalovaných součástí, přes aktivační čísla až po uživatelské profily. Jejich tvorba vyžaduje specializované nástroje. Příkladem aplikací využívajících tuto formu je Adobe Reader nebo balík Microsoft Office. Obrázek 14: Přidání aplikace využívající vlastní transformační balíček (Zdroj: Autor) Definice rolí Role jsou první funkční rozšíření, které je k dispozici díky napojení na SQL databázi. Jde prakticky o databázi parametrů, která bude instalovanému počítači přiřazena. Počítač může mít více rolí, takže se nabízí tvorba více rolí dle skupiny společných znaků. Ve vzorovém nasazovacím prostředí mají počítače zpravidla tři role: Obsahující operační systém Definující aplikace Ukončovací role Role s operačním systémem obvykle obsahuje definice rozlišení (Osvědčilo se mi 2560 x 1600 pixelů jakožto maximum v cílových prostředích. V případně nižšího rozlišení se na toto zmenší.), údaje pro přidání do domény, heslo účtu lokálního správce, definice časového pásma a klávesnice a konečně sekvenci úloh s požadovaným OS. 25

33 Další role definuje pouze aplikace a to v přesném pořadí instalace. Toto je důležité v případě neošetření prerekvizit pomocí balíků aplikací, případně odsunutí instalace bezpečnostního softwaru, který by mohl zasahovat do sekvence, na poslední místo. Poslední role obsahuje pouze vynucení restartování počítače jakožto signálu o dokončeném nasazování Přidání počítačů Stejně jako role jsou i počítače databázové záznamy obsahující velké množství parametrů. Nejpodstatnější je identifikace počítače, kterou lze definovat čtyřmi způsoby: Asset tag (majetkový štítek např. inventární číslo definováno v prostředí BIOS) Universally Unique Identifier (UUID) Sériové číslo (pouze u značkových počítačů) MAC adresa Po identifikaci počítače mu lze parametrem DriverSelectionProfile (výběrovým profilem ovladačů) přiřadit příslušné ovladače a parametrem OSDComputerName jméno. Nakonec je možno přiřadit počítači dříve připravené role Ručně Ruční způsob spočívá ve vyplnění naprosto všech parametrů ručně - úplně všech, bez možnosti kopírování, využívání šablon a podobných prostředků. Když jsem se na tuto obtíž ptal Microsoft MVP (Most Valuable Profesionála) na přednášce o nasazování softwaru v sídle Microsoftu, konstatoval, že toto bohužel opravdu MDT neumí a že nemůžeme čekat od bezplatného nástroje dokonalou funkcionalitu Powershell skript Předchozí problém lze řešit sice ne úplně čistou cestou, avšak elegantně demonstruje výhodu řešení postaveného na standardní SQL databázi. Jedná se o přímé vkládání údajů do databáze pomocí Powershell skriptu. Původní skript [10] od Michaela Niehause se mi podařilo pochopit a modifikovat pro účely hromadného vkládání v mém sestavení. Nejdříve je nutné naimportovat sadu Powershell příkazů, tzv. cmdletů, připojit se k databázi, vytvořit počítače a přiřadit jim výběrové profily 26

34 ovladačů, jména a role. Údaje jsou čerpány z CSV souborů. Ve výpisech jsou uvedeny vlastní modifikace skriptů. Výpis 1: Skript pro vytvoření počítačů v databázi OSDComputerName,Mac,Description,Serial,DriverSelectionProfile,Xresolution,Yresolution BCPC-A,,BCPC-A,SERIOVE-CISLO-01,Vyrobce-Model-W8.1x64,, BCPC-B,,BCPC-B,SERIOVE-CISLO-02,Vyrobce-Model-W8.1x64,, BCPC-C,,BCPC-C,SERIOVE-CISLO-03,Vyrobce-Model-W8.1x64,, BCPC-D,00:00:00:00:01:00,BCPC-D,,Vyrobce-Model-W8.1x64,, BCPC-E,00:00:00:00:02:00,BCPC-E,,Vyrobce-Model-W8.1x64,, Výpis 2: Skript pro přiřazení rolí počítačům Get-MDTComputer -serialnumber SERIOVE-CISLO-01 Set-MDTComputerRole 8.1 Pro x64','ucebna informatiky W8.1 x64','konec') Get-MDTComputer -serialnumber SERIOVE-CISLO-02 Set-MDTComputerRole 8.1 Pro x64','ucebna informatiky W8.1 x64','konec') Get-MDTComputer -serialnumber SERIOVE-CISLO-03 Set-MDTComputerRole 8.1 Pro x64','ucebna informatiky W8.1 x64','konec') Get-MDTComputer -macaddress 00:00:00:00:01:00 Set-MDTComputerRole 7 Pro x32','univerzální základ','konec') Get-MDTComputer -macaddress 00:00:00:00:02:00 Set-MDTComputerRole 7 Pro x32','univerzální základ','konec') Obrázek 15: Skriptované přidání počítačů do databáze (Zdroj: Autor) 27

35 6.3.6 Přidání aktualizací Microsoft Windows Aktualizace Windows lze přidávat buď přímo do instalačního obrazu Windows, nebo lépe pomocí výběrových profilů balíčků. Výhoda tohoto postupu spočívá v jeho schopnosti jednoduše operovat s jednotlivými položkami a například v případě konfliktu libovolných aktualizací s prostředím ji lze jednoduše deaktivovat. Pro získání sady aktualizací byl použit bezplatný nástroj WSUS Offline 9.2 [23]. Hierarchie aktualizací je založena na verzi operačního systému, z čehož vyplývá také definice výběrových profilů. Připravený profil je poté zadán do sekvence úloh na místo před samotnou instalací. Ve výsledku tedy budou aktualizace tak či tak vepsány do instalačního media, rozdílem však je, že při každé iteraci plně kontrolujeme použité balíčky. Osobně nejsem této metodě příliš nakloněn, protože takto přidané aktualizace nelze v případě potřeby odinstalovat a nejsou ošetřeny posloupnosti, což přináší problémy v případě navazujících balíčků nebo balíčků vyžadujících po instalaci restartování počítače. Pokud bych měl opět zmínit pojem čistá cesta, přiřadil bych k němu integraci jen kumulativních aktualizací, tzv. Service Packů a zbylé aktualizace nechal dle potřeby konkrétní sestavy nainstalovat automaticky například přes noc. Díky roli WSUS (Windows System Update Service lokální kopie aktualizačního repositáře) není tato operace ani náročná na přenosy z Internetu. Obrázek 16: Zahrnutí balíčku aktualizací do instalační sekvence (Zdroj: Autor) 28

36 6.3.7 Přizpůsobení, generování a import Windows PE Pro spuštění samotného procesu nasazování softwaru je třeba nejdříve přes síť nabootovat do Windows PE - prostředí, které stáhne na disk všechny potřebné soubory a skripty dle parametrů počítače, resp. jeho rolí. Tato odlehčená verze Windows v sobě mj. nese ovladače pro úložiště a sítové karty. Tyto ovladače jsou nezbytné proto, aby bylo vůbec možné soubory po síti stáhnout a připravit na disk. Z tohoto důvodu je vhodné image po každém importování nových ovladačů těchto tříd znovu vygenerovat. Před prvotním generováním je přínosné provést ještě několik přizpůsobení (pravé tlačítko myši na nasazovací sdílení Rules Edit Bootstrap.ini). V laboratorním prostředí jsem nastavil předvyplnění domény, nastavení českého rozložení klávesnice a vlastní obrázek pozadí. Uživatelské jméno a heslo nevyplňuji záměrně z bezpečnostních důvodů, vše ostatní je definováno v konkrétních rolích. Obrázek 17: Náhled na pravidla Windows PE a konfigurační soubor bootstrap.ini (Zdroj: Autor) Po doladění je nutné spustit samotný proces generování Windows PE image. Tato operace je v závislosti na množství přidávaných ovladačů poměrně časově náročná, proto průvodce nabízí buď pouze optimalizaci (přidání nových ovladačů např. při dodávce nových počítačů a jejich zařazení), optimalizaci s kompresí (komprimace ulehčí switchům) nebo kompletní přegenerování (to je časově velmi náročné, protože se přidávají všechny síťové a úložiště ovladače). Při prvním generování se časově náročnější variantě samozřejmě nevyhneme. MDT si nejdříve rozbalí čistý obraz, přidá ovladače, vepíše nastavení ze souboru bootstrap.ini a obraz disku opět zabalí. Výsledkem jsou dva WIM soubory (v případě výběru pouze 29

37 platformy x86 nebo jen x64 je jen jeden), které je následně nutné naimportovat do WDS serveru, který je publikuje klientům bootujícím ze síťové služby. Pozor, při opětovném generování je třeba nově vzniklé image naimportovat do WDS. Nestačí je tedy jen přegenerovat. Obrázek 18: Přidání vygenerovaného obrazu disku na WDS server (Zdroj: Autor) 6.4 Otestování nasazovacího prostředí Nedílnou součástí realizace nasazování softwaru je jeho důkladné otestování, které odhalí mnohé souvislosti, které nelze na teoretické rovně plánování odhalit. Může se jednat o nevhodnou verzi ovladače, chybějící prerekvizity, či jiné souvislosti. V rozsáhlejších prostředích s mnoha pobočkami si lze představit model s více WSD servery, v laboratorním prostředí se WDS server nachází jen jeden, tudíž je jeho otestování triviální. Obrázek 19: Nabídka obrazů disku WDS serveru na IP adrese (BCAPP1.BC.LAB) (Zdroj: Autor) 30

38 6.4.1 Otestování na virtuálním počítači Testování se nakonec protáhlo na dlouhé hodiny a sklouzlo spíše v ladění a laborování. Problémy začaly s generacemi virtuálních strojů, které Hyper-V rozlišuje. Druhá generace, tedy ta, od které lze předpokládat pokročilejší funkce, si 100% nerozumí s WDS serverem, atak nabízí pouze 64bitové Windows PE. Problém vyřešen smazáním virtuálních strojů a znovuvytvořením jejich náhrad v režimu předchozí generace. Posledním krokem je volba MAC adres, kterými se počítače identifikují v databázi MDT. Problém tedy byl v omezené podpoře UEFI. Obrázek 20: Dokončená instalace Windows 8.1 přítomny jsou aplikace, ovladače a je správně přiřazeno jméno a doména (Zdroj: Autor) 31

39 Obrázek 21: Průběh instalace Windows 7 ve fázi aplikací, aktuálně běžící instalátor Microsoft Office 2013 v bezobslužném režimu (Zdroj: Autor) Otestování na fyzickém počítači Průběh byl velmi podobný jako v případě virtuálních počítačů. Díky konfiguraci sítě, která byla nastavena na maximální transparentnost, proběhlo nalezení WDS serveru a následné stažení a rozbalení instalačních souborů a skriptů bez větších problémů. Paradoxně byl tedy průběh hladší, než i virtuálním strojů. U hardwarových počítačů bývá problém s ovladači, čemuž jsem ale předešel extrahováním ovladačů před formátováním. 32

40 7 Komplexní uživatelský scénář použití připraveného řešení Tato sekce se věnuje praktické použitelnosti hotového nasazovacího prostředí jako produktu outsourcované firmy objednateli s menší odborností IT personálu. Jsou zde popsány nejčastější scénáře, které mohou potkat správce nasazování a na které musí být repositář maximálně intuitivně připraven. Otestování jejich intuitivnosti a názorné vysvětlení je důležité pro splnění jednoho z cílů práce příprava řešení pro předání obecně zaměřenému IT oddělní. Scénář: Do společnosti dorazilo x kusů nových počítačů identické hardwarové konfigurace a dvou rozdílných aplikačních rolí. Mezitím se vyskytlo duplicitní označení počítače a je třeba aktualizovat jednu aplikaci na novější verzi. 1. Obstarání ovladačů hardwaru 2. Přidání počítačů do MDT databáze 3. Příprava v Active Directory 4. Aktualizace Windows PE 5. Změna jména duplicitního počítače 6. Aktualizace aplikace 7. Úprava role 7.1 Obstarání ovladačů hardwaru Všechny počítače jsou nového hardwarového standardu, tudíž nejsou jejich ovladače na serveru. Z nějakého důvodu nefunguje FTP server dodavatele, a proto je kompletní balík nedostupný. Obnovovací média nejsou přibalena, avšak Windows z důvodu podkladové licence pro multilicenční program na disku připraveny jsou. V takovém případě se ukázala jako ideální cesta nainstalování jednoho počítače a záloha všech jeho ovladačů nástrojem Double Driver (viz dřívější kapitoly). Výstupem je kompletní sada ovladačů, kterou již není problém naimportovat do nasazovacího prostředí a připravit do výběrových profilů. 33

41 7.2 Přidání počítačů do MDT databáze Následně je třeba počítače přidat do MDT databáze a přiradit jim příslušné role a výběrové profily. Lokální správce má připravenou šablonu skriptu, kterou buď upraví, anebo vytvoří dle vzoru pomocí např. MS Excelu nové skripty, kterými všechny operace provede najednou a bez rizika překlepů. 7.3 Příprava v Active Directory Vhodné se taktéž ukázalo připravovat v adresářové službě počítačům účty, které se tak okamžitě spárují a možné na ně ještě během instalace aplikovat skupinové politiky (Group Policy) například pro odsunutí automatických aktualizací, import certifikátů nebo úpravu firewallu. Opět je vhodný skript, tentokrát v tomto znění: Výpis 3: Skript pro vytvoření účtů počítače v adresářové službě. Význam syntaxe: cn = jméno počítače, ou = organizační jednotka, dc = doménový řadič. dsadd computer "cn=test1,ou=desktopy,ou=pocitace,dc=bc,dc=lab" dsadd computer "cn=test2,ou=desktopy,ou=pocitace,dc=bc,dc=lab" 7.4 Aktualizace Windows PE Finálním krokem je opět přegenerování bootovací image z důvodu zakomponování nových ovladačů a její import a publikace ve WDS. 7.5 Změna jména duplicitního počítače Problematické jsou zejména při ručním přidávání počítačů duplicitní názvy počítačů. V bezdoménovém prostředí lze problém vcelku rychle a beze škod vyřešit, avšak v doménovém prostředí se původní heslo počítače přemaže heslem nového počítače, což zapříčiní ztrátu důvěryhodnosti mezi počítačem a doménovým řadičem, která vede ke znemožnění přihlašování se do daného počítače. Když už k takové situaci dojde, je nutné před přeinstalací postiženého počítače změnit jeho jméno v databázi, jinak se bude situace opakovat. Tato položka je ve vlastnostech počítače jako OSDComputerName. 34